Well, there are a few good reasons for that: coding for WinRT is harder than it should be, and the developers are not fans of the WinRT UI (so they don't use it).
I am in this very situation, with an app with has dozens of millions of users on Windows (and millions daily).
The first reason is the most important. WinRT requires a lot of rewrites of your code. (and the rationale behind some limitation are often political), and Microsoft is not helping or making it easy for you Notably for networking and multimedia.
Networking: everyone uses the BSD sockets, Win32, Linux, OSX, iOS, Android, Symbian, Bada, etc... And you cannot use them on WinRT. There is a very high chance that your code or one of your library uses it, of course.
But the bad part is that Microsoft does not make easy with a wrapper exposing WinSock-like API based on their new API. Not even a wrapper than does 80% of the needs.
Multimedia and Games: your videogame that works with a C++ engine and OpenGL ES for casual games that works on iOS, Android, Bada,... does not work under WinRT, because OpenGL is not allowed... And I don't even speak about Video acceleration.
Yes, they need to do a massive change in their APIs, but helping the transition would have been a good idea...
So yes, writing yet another Twitter client is easy on WinRT, for more complex applications, well, it is way too hard and difficult to do it this fast.
Well, there are a few good reasons for that: coding for WinRT is harder than it should be
A lot of us haven't even gotten far enough to figure that out. Microsoft just switched us all over to a new UI toolkit (Windows Presentation Foundation) with the release of .NET 3 five or so years ago. We've invested a lot of time and money into getting up to speed with this new technology. And now we're already being asked to migrate away from it and onto yet another Next Big Thing.
Meanwhile, Microsoft zinged its mobile developers (the very ones they're so desperate to court) even harder by deciding that the new mobile platform they brought out only two years ago would not be compatible with the new mobile platform they're bringing out now.
It was twelve years ago this month that Steve Ballmer did his famous monkey dance while repeatedly shouting "Developers!" and apparently slipping into some sort of fugue state. Well, it turns out that all those developers he wanted to make such a big deal of saying are such a big deal? They're are all kind of pissed off and disgruntled right now.
"A lot of us haven't even gotten far enough to figure that out. Microsoft just switched us all over to a new UI toolkit (Windows Presentation Foundation) with the release of .NET 3 five or so years ago. We've invested a lot of time and money into getting up to speed with this new technology. And now we're already being asked to migrate away from it and onto yet another Next Big Thing."
Bingo!
Talked about disrespecting your developers/users by changing the rules of the GUI every couple of years. Only the hardcore fans, pioneers and draftees are jumping into Windows 8. (The rest of us are keeping it locked up in virtual machines.) There's enough work in the Windows development universe, a developer can ignore Metro till it grows up or decent third party tools come out. For f--ks sake, Redmond, I've got real apps, (both web and desktop) to write.
I guess a lot of the people here are too young to remember - but it's always been this way with Microsoft, and admittedly, with most other infrastructure companies out there (Sun had an era like that, NetScape did too). MFC, ATL, ADO, DAO, ...; Win8 might be breaking new ground in how "out of place" your app will be if you don't adopt the latest and greatest, but if you wanted nice modern menubars and toolbars ("Coolbar"), you had to switch from Win32 to MFC in the past. You had to go through hoops to get somethings done with COM without using ATL (with quite a few things working through ATL but not if you try to use COM directly; because no one in Microsoft ever tried to use them NOT through ATL).
And for a long time, it made everyone happy - because jumping on the new thing kept you employable, and actually shipping working products mattered less.
The support library allows you to use features of newer system releases on older systems. See also GDI+ for Win98/NT4 or Windows feature packs for example.
The API changing game is another problem - it does not allow you to use existing application with newer system. As far as I know, this does not happen on Android (for now).
Except that the old widget sets never die. Xt, Athena, Motif, Lesstif, Tcl, gtk, Qt. Even swing and related tools if you include Java.
And so ... they're still in use. While significant new apps may not be getting developed with these tools, plenty of old ones are maintained, and the toolkits are largely serviceable -- they may be used if desired.
They actually provide a bit of useful visual feedback (if you're versed in Linux/Unix history), in that the style and design of an application gives you some idea of how it's going to work and what its quirks may be.
compared to the differences between win32 and WPF those are trivial. Also, the kernel ABI is considered an "internal" ABI, for better or for worse, the kind you wouldn't be able to access without an NDA and signed contract in the commercial world. The kernel's stable interface is its system call interface, which is remarkably stable.
In Metro-style/Windows Store apps? MFC, ATL, ADO, DAO, and Silverlight, large parts of .NET, and COM components not written against the subset of Win32 supported by Metro.
Way back in the day I used to be a Microsoft developer. I got tired of them changing the database API every other year. All the open sources platforms are much more stable. Knowledge in these other platforms doesn't decay as quickly or is at least somewhat useful even after 10 years.
In contrast, Microsoft will just go and kill whole platforms from time to time (e.g Visual Basic) rendering useless years of experience building deep understanding of a platform.
A far worse language with enormous hordes of programmers who had bet their careers on it.
"Classic" VB was the PHP of the client/server era: ugly, reasonably capable, and everywhere.
Imagine the screams you would be hearing across the Internet if the PHP core devs all decided en masse to go work on something else, and PHP was under a closed, proprietary license so nobody could fork it, and you get a sense for what it was like when Microsoft killed VB.
ODBC, which, along with every other database API released by Microsoft in the past decade, is not supported in Metro. Astonishingly, it currently appears to be easier to query a Microsoft SQL Server from an iOS app than from a Metro-style app. Presumably someone could port ODBC and a driver like FreeTDS to Metro, but it'd be made more difficult by the radically different networking APIs, and would still suffer from annoying limitations like the inability to connect to local database server instances (per Windows Store policy).
I think Microsoft is worse about it that other commercial vendors. Perhaps due to a perception (not necessarily incorrect) on their part that their customers are locked in.
If a vendor who only supplies a single product decides to torpedo the APIs that you rely on, they create an easy opportunity for you to switch to another vendor entirely. Whereas historically Microsoft could wreak havoc upon an entire development platform (Visual Basic) knowing that probably all you'll be able to do about it is huff and puff around a bit on the Internet. After all you couldn't jump ship on Windows development - all your customers were Windows users, or your entire IT department was built around Windows, or your corporate intranet is all dependent on IE6, or whatever.
Funny you say that, because Microsoft's software problems are often attributed to bending over backwards to be backward compatible while other vendors like Apple quickly kills compatibility with almost ever release, with even point releases.
Take this game bundled with Windows 95. ftp://ftp.microsoft.com/deskapps/games/public/AAS/Hover.exe
It runs even on Windows 8. Upgrading from Windows 1.0 to Windows 7.
As I said in another comment, I still see some ASP and Visual Basic usage even after all these years, those applications are still supported in Windows 8 and Windows Server 2012. Microsoft stopped making new versions because it wanted to move on to better technology. Want to take a poll on HN about what developers think of Visual Basic and Classic ASP? A case of damned if they do, damned if they don't.
Right, but this is largely orthogonal to the problems with Metro on the desktop. Sandboxed Mac App Store apps are limited, but need not be written against an entirely new set of APIs that is not only unsupported by previous versions of the OS, but unsupported by non-App Store apps running on the current OS version. Say what you will about the Mac App Store, it at least doesn't suffer from all the problems inherent in the iOS App Store model. Metro does.
I am sure there are a lot of people who rejoiced at Microsoft "killing" Visual Basic. And I say "killing" because I see a lot of it in use, they just stopped adding new features to it, the old applications written in the early 90s still work in Windows 8. Try that with other OSes or GUI toolkits.
Yep. And like in the battlefield, fire and motion works when you already have an advantage, but doesn't when you're in an inferior position (Which Microsoft is right now in the mobile market - and are not as dominant in the desktop[1] market)
[1] by which, I don't mean they are remotely in danger of being dethroned. Just that they can't dictate application standards anymore, because most activity happens on the web.
Technically. In reality WinRT is missing A LOT of stuff from WPF (heck WinRT doesn't even reach parity with Silverlight). Simple stuff la x:Static, x:Array are not available.
WinRT 1.0 is basically a subset of Silverlight with a few specific controls thrown in.
> heck WinRT doesn't even reach parity with Silverlight
That reminds me: WPF is not even a superset of Silverlight; There's functionality I need in Silverlight (regarding media codecs) which is not available in WPF, and my only way to get it is to instantiate a browser, run a silverlight app inside, and somehow bridge it all underneath in my app.
You can use Xaml with WinRT. But beyond that cosmetic similarity, it gets pretty different. WPF is implemented in .NET, whereas WinRT is more of a replacement for Win32.
You can still write WPF apps for Windows 8, of course, but they won't be Metro apps, they won't run on ARM tablets and, significantly for the current conversation, they won't be allowed in the Windows app store.
>Meanwhile, Microsoft zinged its mobile developers (the very ones they're so desperate to court) even harder by deciding that the new mobile platform they brought out only two years ago would not be compatible with the new mobile platform they're bringing out now.
WP7 apps will run on WP8 without any modifications or even without anything needing to be done by the developers.
>Well, it turns out that all those developers he wanted to make such a big deal of saying are such a big deal? They're are all kind of pissed off and disgruntled right now.
Citation needed and content farms like TNW who will "print" anything to drive clicks don't count.
I know it's hip on HN to rag on Microsoft, but cmon, two thousand apps for a platform that is a month away from release(only available to MSDN users right now) and everyone is predicting doomsday? Perhaps developers are making use of the last month to further enhance apps before submitting them?
"So yes, writing yet another Twitter client is easy on WinRT, for more complex applications, well, it is way too hard and difficult to do it this fast."
Almost every Metro style application demo I've seen is some variant of a "social" app. Do they really think that the millions of windows developers all suddenly started working on social apps?
Every one of the pivots that they have made in the past few years has been in reaction to some external threat and the developers are in the crossfire. Windows developers are too weary to be excited about yet another wide ranging change.
Visual Studio 2008 to Visual Studio 2010 Professional upgrade price: $249. Visual Studio 2010 Professional to Visual Studio 2012 Professional upgrade price: $499.
I didn't even think of that, but all mobile games on iOS and Android are done with OpenGL ES, and Microsoft doesn't even support it. That could be a major problem for Microsoft.
Contrary to popular belief by many geeks, game consoles do not support OpenGL as well. When they do, like the PS3, is a kind of subset that most studios avoid using anyway, and prefer to make use of the lower level APIs.
You can use the ANGLE library [1] to translate OpenGL ES to DirectX. It's used by both Chrome and Firefox, so it's widely deployed and also tested for OpenGL ES conformance.
Re: networking, you are of course right. At the same time, I can sympathize with Microsoft's decision to abandon Winsock. Cross-platform use of BSD sockets is mired in a deplorable mess of #defines and '90s incompatibilities. For new code, the non-blocking WinRT API is a million times better -- the question is, what can Microsoft do to make porting easier?
Isn't DirectX part of a walled garden? If more games are written in OpenGL, for example, they will be easier to port to Android, Linux, Mac OS, and even the iPhone. A decade ago, it looked like OpenGL was dead. I, for one, am glad to see its resurgence.
OpenGL ES 3.0 and OpenGL 4.3 are going to be even more interesting in regards to that, as developers can write OpenGL ES 3.0 games for iOS and Android devices, and then do a 1:1 port to OpenGL 4.3 PC's, without further modifications, because OpenGL 4.3 fully incorporates OpenGL ES 3.0.
What I find mind-blowing, though, is that Intel's new architecture Haswell which will come out mid 2013, and is supposed to be even more GPU-oriented than previous chips, will only support OpenGL 3.2, which will be 4 years old by the time the chip launches (some sources say OpenGL 4.0 - still 3 years old though)...and yet it will support DirectX 11.1. I find that incredibly disappointing.
I guess Intel just doesn't care about OpenGL. I'm not sure how they are supposed to make us believe that they are serious about entering the mobile market with that kind of attitude towards OpenGL.
Won't it be possible for newer versions of OGL to be implemented in drivers? Or is there a hardware piece required for newer OGL which that chip lacks?
> they will be easier to port to Android, Linux, Mac OS, and even the iPhone.
Bingo. Microsoft was never very fond of the idea of people porting Windows apps to other platforms. If people develop portable apps that run everywhere, the network effects achieved by having OEMs bundling Windows on every PC are neutralized.
The irony is now MSFT needs these other developers to port their successful iOS/Android games to their platform. MSFT shouldn't be making this a difficult choice for devs. The few people who do end up with Win RT tablets and such will likely hear about games/apps working on other platforms and then look to see if they are available on the Win device...and since MSFT put up this wall....well....users will think should've bought an iPad.
(Note, i'm actually a little excited about the Surface tablet as a potential device that crosses the chasm between full tablet and laptop. But I don't have very many apps that I use now on my iPad.)
EDIT: Also, I don't know much about any game development SDK engines that abstract devs from these proprietary libraries and runtimes...however I think they must exist?
You can already get something like the surface: Asus' Transformer series.
I have a Transformer Prime (#2, Transformer Infinity is the newest one) and the keyboard dock. Android apps/games, plus terminal, VNC, etc for doing real work.
And Android 4.0 looks more like Windows 7 than Windows 8 does (black "taskbar" on the bottom with clock and notifications on the right, home button, back button, and app switcher button on the left, and the 'desktop' can have icons and widgets).
> Re: networking, you are of course right. At the same time, I can sympathize with Microsoft's decision to abandon Winsock. Cross-platform use of BSD sockets is mired in a deplorable mess of #defines and '90s incompatibilities. For new code, the non-blocking WinRT API is a million times better -- the question is, what can Microsoft do to make porting easier?
That is not a reason to not code and offer a code wrapper for BSD-sockets-like API based on WinRT sockets.
Of course, no need to cover 100% of the API and they could use lots of warnings to force developers to slow transition.
> Re: networking, you are of course right. At the same time, I can sympathize with Microsoft's decision to abandon Winsock. Cross-platform use of BSD sockets is mired in a deplorable mess of #defines and '90s incompatibilities.
Oh, the irony. If you actually look at those #ifdefs, the vast majority of them are #ifdef __WIN32__ - because Microsoft didn't really care about compatibility when they first adopted BSD code. Compared to Unix/Windows, the differences between BSD and Linux are almost nonexistent.
Funny, I have exactly the opposite opinion: because Metro supports html + javascript it's very easy to get data-driven apps out with very little effort.
Of course if you're doing anything interesting then it's probably a nightmare.. but the vast majority of applications aren't doing anything interesting, so Win RT is great for them.
From what I understand, the HTML+Javascript WinRT APIs are really only supported on the "full" Windows RT/Metro environment, not Windows Phone 8. Windows Phone 8 supports C#/VB+XAML, C/C++, and you can use HTML and Javascript, but only in a web browser control, which is not the same as a true Javascript API with hooks into lower-level constructs. Apparently, you can also run legacy Windows Phone 7 Silverlight apps on Windows Phone 8 as well, but that is just a stopgap to not completely cut ties with the legacy apps.
Well, outputting video and audio should not be too hard to adapt (almost work out of the box).
Decoding does not do system calls, except for hardware decoding, so no worry.
File input is worrying because of the sandbox, but should be doable with some work.
But networking is a nightmare. 20 libraries are using WinSock2 (including some codecs like FLAC), plus libVLC's core. Sure HTTP access is fine, but RTP, RTSP, FTP, HTTPS, multicast UDP are weirder beasts...
To add it to the pain, VLC is a mostly C99 project, but C99 is too new a standard for Microsoft to implement it :)
MonoGame replaces it and is available now for Windows 8. In fact I've completed two games using MonoGame which run using 95% the same code on Windows XP, Vista, 7, and 8. Pretty soon there will be a Linux and Android version as well.
If you want to see what's possible you can check them out:
I was looking for an 'official MS technology' replacing it. I know monogame. I wouldn't think anyone NEW to game dev would start with it; it's for XNA devs wanting a life after, right?
I'm one of those developers who was ready to jump right in and go crazy on the platform...until I fully realized how the ecosystem would function.
1. The Windows app store is Metro only.
2. Developers as well as normal users are actively looking for ways to avoid having to interact with Metro.
Developers have zero interest in personally using Metro, so they have less of an incentive to port their apps. Other desktop users will also not like being thrown into metro just to use a one-off application, maybe unless it's a game, so they'll continue looking for the desktop version of an app.
Microsoft muddied the waters a bit with this word that they aren't even allowed to use anymore. It's variously been used to describe a set of design principles, a UI development toolkit, and a particular subset of Windows software that is designed to run well on tablets and is put together using the aforementioned design principles and framework.
Windows App store apps are Metro-only under one of those three definitions: The framework that we're now supposed to call WinRT.
Which is, of course, not at all the same thing as Windows RT.
HN comments on Microsoft related stories(only negative ones i.e, the positive ones are usually flagged to death even if they rarely get on the front page) sometimes remind me of the blind leading the blind. Some people who don't even use or follow Microsoft technologies are the first to vote up such stories and then comment snarkingly in the comments about things that they seem to have no clue about .
They allow linking to external apps using external payment systems and external installation processes. That's not a great solution for small teams that just want to build apps.
Making a website, creating a setup file, and setting up payment processing and license delivery really isn't much effort - especially when you don't have to pay a 30% commission to the app store.
The benefit of developing for app stores is the extremely smooth process for users to purchase, install, and update apps. Imagine how popular Steam would be if all they had were a bunch of simple games available to purchase, along with links to AAA titles on publisher websites to go buy and download separately.
>> "2. Developers as well as normal users are actively looking for ways to avoid having to interact with Metro."
It hasn't been officially launched yet: how many normal users have spent more than a few minutes with it?
Personally after playing with it for a few weeks I really like it. I've just started developing for it too (being an iOS developer for the last 4 years) and within a few days I am up to speed.
>> "2. Developers as well as normal users are actively looking for ways to avoid having to interact with Metro."
I think this is good. It forces developers to have to learn the new API's. If they didn't do this people would continue to build desktop apps (largely because people are lazy and it's easier to continue working with what you know) and the best apps wouldn't turn metro. Nudging developers to go metro means that when Windows 9 comes around they can get rid of the stupid split (metro/desktop) interface.
The reason is the same that the OS X app store is heavily sandboxed. Microsoft does not want to distribute via its store BonziBuddy type borderline adware/spyware/bloatware/toolbars with always running processes and services and icons in the system tray. It's a pain to enforce on Desktop apps. Contrast that with WinRT apps which are totally self contained and sandboxed except for integrating via Charms.
>2. Developers as well as normal users are actively looking for ways to avoid having to interact with Metro.
Two thousand apps without even the OS really launching or the Surface being released is nothing to sneeze at.
I think the real differentiator will be how well the Windows RT and Windows 8 touch enabled laptops will sell over the holidays. If they sell well, developers and apps won't be far behind.
Yes I've trialled Windows 8 heavily for our environment and installed about 50 "popular highly rated apps". They are all simply put: shit. Flakey, broken, hard to use, slow, huge, not useful and poorly integrated and nothing inbetween. Even the microsoft provided apps with Windows 8 are really shoddy.
Seriously I'm a fan of Windows Phone 7.5 and own a handset with lots of apps installed but it doesn't scale up to the desktop at all.
Not a single existing Windows user is going to bother with this crap - it'll end up going to way desktop gadgets went except you can't turn it off any more.
OS X is still allowing regular people to install apps from whatever source they want, by default.
In Windows 8 you have to either check "Allow all trusted applications to install" in the Group Policy settings in Win Pro/Enterprise, or change a registry setting. This means users will have to go out of their way to install anything beyond what the App Store provides. Well, at least the option is still available.
Steam is an app store for games. Games purchases are impulse driven. When buying from Steam, you either go for a big title that you know you'll find on Steam or you go searching for something that triggers your interest.
On the other hand a large part of discovery on a regular app store is search-driven by actual needs of users that want to accomplish something very specific. Like, just the other day I searched for a way to view/manage my Picasa-stored photos on my iPad.
The number of apps is important for one because this means the app store doesn't solve many specific problems users are having and because Microsoft is known to have a big developer ecosystem since forever (building platforms is what they do best) - and so this lack of enthusiasm reflects badly on them and on Windows 8.
> OS X is still allowing regular people to install apps from whatever source they want, by default.
You must not have used Mountain Lion. By default it won't let you run unsigned apps. You can turn that off in System Preferences under Security & Privacy, but would casual users know how to do that?
> In Windows 8 you have to either check "Allow all trusted applications to install" in the Group Policy settings in Win Pro/Enterprise, or change a registry setting. This means users will have to go out of their way to install anything beyond what the App Store provides.
This only applies to WinRT apps. You can still install whatever desktop apps you want. So if you want to install Picasa, you can do it just like you would on Windows 7.
>OS X is still allowing regular people to install apps from whatever source they want, by default.
>In Windows 8 you have to either check "Allow all trusted applications to install" in the Group Policy settings in Win Pro/Enterprise, or change a registry setting. This means users will have to go out of their way to install anything beyond what the App Store provides. Well, at least the option is still available.
Err what? To my understanding, what you said is exactly opposite, OS X has those restrictions and Windows 8 doesn't. Do you have a reference that Windows 8 restricts third party desktop apps by default?
Wholly to be expected at this point. Until Windows 8 hits the shelves and people start using it there is little incentive to build specifically for it - and since Win7 apps run perfectly well in Win8 there is little reason to focus on Windows 8 by itself at this point.
Once the WinRT tablets get into peoples hands the call for RT-specific apps will increase.
Plus, the WinRT dev environment really isn't as fully baked as we've grown accustomed to in the Windows world. So many things just simply don't exist at this point. I've been looking at building a Javascript-based WinRT project - one of the suggested app build paths suggested by MS and discovered that there is no touch-and-drag support built in yet. You can roll your own using JS-events but .... really, things like that dampen the enthusiasm.
This. People don't even have Windows 8 tablets yet, and the OS itself is still only available to MSDN subscribers. Once the OS and devices hit store shelves development will ramp up exponentially.
Most iOS apps weren't developed before the iPhone was released. They were developed as a result of somebody getting an iPhone or an iPad, thinking "Why can't I do X with this?" and then building an app.
You couldn't even build apps when the iPhone was released. The web was our API, according to Jobs. The homebrew/jailbreak community started up almost immediately to fill that gap until iOS 2 was beta tested and released with 3rd party app support a year later. So yeah, by the time 3rd party devs were brought onboard, there were lots of devices in people's hands. The trick is to have killer first-party apps, which the web browser and maps very much were on the original iPhone. Nowadays, exclusive killer apps are a bit harder to come by.
I work with a lot (80+ developers) in the Microsoft ecosystem. I haven't found a single one who is enthusiastic about Windows 8. Most are looking rather worried as yet again the rug has been pulled from underneath them. They got burned with Silverlight and the first drop of the Foundation series of products and Entity Framework.
Another incompatible API is just more shit to deal with.
> Most are looking rather worried as yet again the rug has been pulled from underneath them. They got burned with Silverlight and the first drop of the Foundation series of products and Entity Framework.
Not one dev saw that coming with those APIs? I don't believe it. Microsoft in the 2000s has been all about throwing APIs against the wall and then deprecating them. Anyone who has been around Microsoft knew this was a risk with Silverlight.
I think the real reason these particular devs got burned is because is because Windows today is like Mac before MacOS X: it's all about incompatibility with the rest of the world, "doing it better", crap like that. MVPs are happy to go along with it and adopt these technologies because they can keep their position of being important in the ecosystem. It's like Apple fans in the 90s. WPF, Silverlight, EF, all this stuff is akin to Apple's OpenDoc, or Dylan, or even Newton. It's shiny technology in an incompatible vacuum.
On the topic of the Windows app store. When Apple made iOS, they took components of MacOS X as the foundation of iOS. But when they released the Mac App Store, they didn't force developers on MacOS X develop to the iOS API. That's what Microsoft is trying to do here. Develop with RT or Metro or GTFO. Pure idiocy. The next step is predictable: Microsoft will have to step in like they have on WP7 and they'll start offering to pay for other people's development costs to do the port. I'd be surprised if they haven't already started offering that.
To be honest, do we really need so many apps? Yesterday I prepared the new phone (Galaxy Nexus) for my mum. I don't think I installed more than 7 apps from the market: Chrome browser, Google Sky Map, Rail navigator (for German railway tickets), Google Authenticator, Kindle reader, Öffi (public transport for a lot of cities), Google Goggles.
Did I miss anything important? Honest question - I'd like to prepare the phone as good as possible, it is her first smartphone. Perhaps some kind of news reader, but personally I don't use them, wouldn't know what news sources to set up.
"We need 1000s of apps" is just something Apple marketing has installed in our brains.
If Windows 8 comes with a decent browser, calendar and email app, they are good to go.
As for desktop PCs - I think only few people are still interested in creating desktop apps? Not counting games.
Individuals don't need that many apps. But since individuals need different sets, we need a large total. Your Mum needs rail navigator for German railway tickets. I need the Dublin Bus app. If you're exhibiting at the Munich Design Conference, you might need their useless lanyard scanning app.
Sometimes users need specific apps that are otherwise interchangeable. Kindle, for Kindle owners. Kobo For Kobo Owners. Gmail for Gmail people. Viber for friends of viber users. Whatsapp. LotusMessenger. Skype. Expensify for people who use expensify. You don't want your Mum to have to tell her friends to use Skype instead of LotusMessenger because her tablet doesn't have LotusMessenger, especially if she already uses it on her laptop or phone.
Raw numbers implicitly assume that the ratio of crap/important is the same across platforms. You could use the number of apps X each app's userbase to get the idea. The platforms are probably look more level if you look at numbers like that.
It's more critical now that people already have smartphones and they'll probably want the 5-10 apps they use to work on whatever tablet they buy.
I made up the Munich Design Conference, so their app is doubly useless :)
I'm sure there is a large percentage of apps that are completely useless or interchangeable for most users. But, at 2000 there are probably plenty of useful (to some people) apps missing where the appstore has dozens.
Maybe it's just me, but the Skype "upgrades" for Android and Linux seems to have gotten progressively worse. Whereas they both used to run smoothly for years, the Linux version now doesn't recognize my webcam (on hardware it had no problems with before, and with no OS upgrad in between) and the Android version stutters and randomly garbles video...
I'm actively looking for better alternatives now. Barring that I'll have to hunt down older versions of Skype..
Agreed on all points. I haven't allowed Skype to update itself in years. You can download an older version of their desktop app for yourself here. if that helps: http://www.oldversion.com/Skype.html
"A lot of software developers are seduced by the old '80/20' rule. It seems to make a lot of sense: 80% of the people use 20% of the features. So you convince yourself that you only need to implement 20% of the features, and you can still sell 80% as many copies.
"Unfortunately, it's never the same 20%. Everybody uses a different set of features."
- games/books/drawing apps/learning apps for your kids
- games for yourself
- music apps: cbc music, rdio & tunein radio for me
- off line reader: pocket or similar
- weather app
- justpictures. A flickr/picasa/facebook/many more picture viewing app. Provides notifications when people have uploaded new pictures, which is its killer feature.
- mx player
- aldiko/fbreader for reading books outside of the kindle walled garden
- atm locater app
- qrcode scanner, which is mostly used for installing apps from outside the store
I admit the one thing I miss is good games for my kid (toddler age). It seems most serious publishers tried the iPad first for such things, Android is lacking behind.
Not a concern for my mum atm, though.
Discovery of apps is actually a real problem for me. I don't have the time to follow app review blogs.
I think Google Goggles also does QR Codes. Not sure if Connect is also an offline reader? I ended up being too lazy to mark articles for later reading, so I just keep some ebooks on the phone for boring situations without internet.
> "Did I miss anything important?"
Yes. These problems apply to Windows on the desktop as well.
And Windows exists as the 800 lb gorilla on the desktop for two big reasons:
1. massive numbers of legacy enterprise apps with mind-boggling levels of customization. (e.g. plugins, forms, scripts, macros, etc)
2. games
Making life easy for developers in updating/supporting those apps on new versions of Windows has been a huge part of maintaining their dominance. If Microsoft makes an upgrade even nearly as difficult as porting to a brand new platform, they're making a huge gamble that developers won't hedge toward cross-platform solutions and web apps.
Which, while great for consumers, would be disastrous for Microsoft.
Sure, but I think people are getting tired of that kind of lock in, and it seems difficult to recreate. Granted, most iPhone users are probably tied to the platform for life because they spent 100s of dollars on apps already. Then again, most of them probably aren't as essential as MS Office.
Also I think the professional companies will simply hire people to port their apps to every platform, no matter how painful it is. Some indie games might be missed, but even then - if they are successful, they probably make enough money to pay for a port.
Absolutely not, and I don't get the fascination with app number counts. I often hear people say "I got a new phone, what apps should I get?" Well, what problem do you need to solve? "Oh I just want more apps" is what they usually say. Then everyone wonders why their battery only lasts 7 hours.
I haven't looked in the Windows 8 store, but as long as it's not 2000 complete garbage apps like the pages and pages of ones you sift through on Play, I don't see the issue.
I used to think that but I switched to WP7, found the two apps I needed the most (Campfire client and a decent bus timetable app) weren't available (or rather there were a couple of each, but they were awful) - and so switched back to iPhone.
How many other people want a Campfire client on WP? Maybe a few thousand. For how many people is the lack of a decent one a deal-breaker? Maybe in the tens. But for me, it's a deal-breaker. Now swap Campfire for some other app ...
And that's why the breadth of the App Store is important.
The issue is that if they only have 2,000 apps, how likely are they to have the random app that solves the specific problem I want solved. The more apps they have the (generally) more likely they are to have the 1 I want.
Yeah, that's what I was thinking the whole time I was reading this article. "Only" 2000 apps? I'd rather have 200 well-designed and useful apps over 20,000 useless spam-ware ones any day of the week.
I've owned an Android device for a year or two and I can say that I have under 30 apps installed on the thing from the app store (and probably 5 of those are superfluous, I'm just too lazy to get rid of them). Yet, it has all the functionality I require. As nice as it is to have thousands upon thousands to choose from, honestly I think fewer can be better in some cases, especially from a consumer's perspective: http://www.nytimes.com/2010/02/27/your-money/27shortcuts.htm... Based on that article (I know it's NYT but it cites a good source or two), fewer apps might even result in more purchases overall.
Well, the problem is that beside the most popular apps 'used by everyone' there are niche apps, used by just a bunch of people. And these make the difference.
Games are still generally missing on Macs relative to PCs. It's also increasingly irrelevant given how much game playing has shifted to consoles and mobile. (Arguably, this--along with the iPod/iPhone/iPad halo effect--has helped fuel the Mac's gain in share. Breadth of desktop apps doen't matter as much as it used to.)
MS doesn't give developers an option better than Apple's. Their platform (win RT) is as close as iOS. Oh, and that Metro. Do they really use this UI daily themselves? Or do they have a secret way to turn it off completely? Perhaps I am just too old to appreciate this new fashion.
"MS doesn't give developers an option better than Apple's. Their platform (win RT) is as close as iOS."
Sorry for disagree but between the other two (Android and WinRT) WinRT is fairly far away from iOS. Not mentioning that is way more comfortable to work on VS rather than Xcode.
It's very expected situation. Developers don't like WinRT and will stick to Win32 forever because Win32 is open platform (anyone can develop for it without paying Microsoft) and WinRT is closed platform where Microsoft can apply censorship in their "app shop". No developer in the whole world wants to be thrown out of that "shop" and supply ideas for next version of Windows for free.
To me, the biggest deal breaker is that having a Windows Phone developer account doesn't let you release applications for Windows 8.
It's a shame because many people including me could at least port some of their apps. An additional 99$/year for the Windows 8 store simply isn't worth it. If there's one major reason why the interest is so low then it's probably it.
I am definately going to stick with Windows Phone for the time being since it's been a great experience and the release of WP8 will bring some needed attention.
But you are forced to use Microsoft's App Store for Metro applications. Even if this works (I haven't tested it, but it seems plausible) you'll probably never able to get your application through Microsoft's certification process... :-(
I simply want to be able to build my own hammer if necessary. Microsoft - of course - does not have to build the hammer I want to use - but give me the possibilities to do so - in this case access to these API functions.
The Javascript engine used for Metro applications (Chakra) also uses these API calls, so even Microsoft is (obviously) not able to relinquish using these API calls for writing a JIT compiler.
So: I really only want to use the tools the platform offers - but in the same way Microsoft does; not in the limited way that Microsoft forces outside developers.
Microsoft loses developers by ignoring the installed base. XP held up WPF adoption, and Win7 will hold up WinRT. That's assuming anybody enjoys using it. It's still easier to ship on Win32 and not worry about these fragmented versions of the OS.
Also this is a tools question too: It's harder to make an app for two versions of Windows than it is to make an app for Windows and something else. The tools just don't make it easy to write conditional code.
When Apple released the App Store there were only 900 apps [1]. Which I believe shows that the number of apps is not a good measure of success. What is a good measure of success is that Apple had 10 million downloads in three days...
There would certainly be more apps in the store if they had opened the store up for more developers before now. They've only been accepting app submissions from most companies for about 45 days and individual developers were only allowed to submit apps 14 days ago.
If they want to subsidize ARM devices, they'll need to make money off the app market. If they don't subsidize, their stance on UEFI secure boot will be seriously weakened and open an avenue for questioning by the DoJ or the EU.
How can they claim that developer interest is 'stagnant'? The number of apps is steadily increasing. What makes them think that Microsoft is worried? This story has almost no basis in fact.
Another report of this story on another tech news site did point out that developers may be aiming their releases for the date when Win 8 is generally available. So we may see an increase in the rate of releases as that date approaches. This is just speculation, just like the story, but at least it brings some balance to the argument.
So what? 2000 is a huge number. I can't even imagine scratching the surface of those, in terms of actually using them. I know they fill different niches, but on my desktop I use maybe about 2 dozen applications on a regular basis. Those 2000 apps could be far better on average than the half-million-or-so in the App Store or Google Play.
Or they could all be junk, and Windows Store is doomed.
Things don't really work like that. You don't want your platform to only have 1000-2000 apps. Why? Because you'll never get the "top 1000" apps in there. Plus, people have different needs for apps. On the real Windows you can find a program for just about anything. You won't be able to say that for the Windows store and Windows RT.
It's not about having the "top 10 apps". It's about having "all the apps you could ever need". And if there are 2000 apps, it most likely doesn't mean that it contains "all the apps you'll ever need". And which platform would you go with? One that has and will have all the apps you'll need or one that has "2000 apps"?
Disagree. First, the hypothesis that the quality distribution within the 2000 is substantially better than within the half-million-or-so is unlikely to be true, at least there's no evidence why it should be so.
Second, the 2000 is absolutely certain not to cover the long tail. The 2 dozen applications you use are not the half a dozen applications I use. Those car engine bluetooth+OBD monitors and bike repair apps are definitely not in the 2000 pool. Not to mention the variety of games out there.
Yeah, it's not the quantity, it's the quality. If there is a large subset of quality Windows 8 applications that's good.
Not everyone is going to put their applications on there straight away - how many put it onto the MacOS Store straight away (though there was A LOT of hype around the mac store).
Mobile application numbers don't really compare to desktop apps, noone really needs a fart app on their PC.
They should give away the professional version of visual studio for free. I think more people will start to write apps for Windows 8. They also should Webmatrix 2 IDE turn into a IDE for JavaScript developers compare able with visual studio. With all fancy auto completion, docs and helpers. And it should be super easy to "export" Windows 8 Apps with Webmatrix 2.
I mean... isn't developer interest in desktop platforms stagnant? I mean... what "apps" do desktop users buy aside from games and the MS Office suite and Adobe? Forgive me if this is massively ignorant of the giant world of desktop software I haven't installed.
An OS that will soon be used by hundreds of millions of people, with a depleted app store. Seems to me like a huge opportunity for devs, as opposed to following the herd into the overcrowded iOS and android stores.
I'm even not a Windows guy but I feel it's too early to tell whether or not Windows 8 is stagnant. There's less than a month's worth of data. I think I'd be more interested in either a November or January update.
After using it fro ~3 months I can conclusively say that anybody writing apps for it should book an appointment with a shrink. Hell the only metro tile I use is the show desktop one.
Give us a couple days. We're undergoing some back-end changes and it's causing the pages to have a jerky scroll for some. Apologies for the inconvenience in the meantime.
How many tablet apps did Android have while launching tablets? How many are even tablet compatible now?
Why should developers launch now instead of polishing their apps and launching at RTM?
I think this is much ado about nothing, once the platform launches and people start buying laptops with touchscreens and tablets, the number of apps will also go up.
I am in this very situation, with an app with has dozens of millions of users on Windows (and millions daily).
The first reason is the most important. WinRT requires a lot of rewrites of your code. (and the rationale behind some limitation are often political), and Microsoft is not helping or making it easy for you Notably for networking and multimedia.
Networking: everyone uses the BSD sockets, Win32, Linux, OSX, iOS, Android, Symbian, Bada, etc... And you cannot use them on WinRT. There is a very high chance that your code or one of your library uses it, of course. But the bad part is that Microsoft does not make easy with a wrapper exposing WinSock-like API based on their new API. Not even a wrapper than does 80% of the needs.
Multimedia and Games: your videogame that works with a C++ engine and OpenGL ES for casual games that works on iOS, Android, Bada,... does not work under WinRT, because OpenGL is not allowed... And I don't even speak about Video acceleration.
Yes, they need to do a massive change in their APIs, but helping the transition would have been a good idea...
So yes, writing yet another Twitter client is easy on WinRT, for more complex applications, well, it is way too hard and difficult to do it this fast.