Microsoft’s Build announcements: breaking the vicious circle
Microsoft’s first-day keynote at its Build developer conference today focused first on Azure and Office platform advancements, but finally moved on to Windows, where the real meat of the day was in my mind. When it comes to Windows, and Windows Phone in particular, one of the key challenges continues to be what I refer to as the user/app vicious circle. Simply put, in our post-iPhone world, when there are no users on a platform it’s tough to attract developers, and when there are few developers and hence few apps, it’s tough to attract users. Windows Phone suffers from a number of issues (see my free in-depth report on the platform), but one of the biggest continues to be the app gap and the app lag.
Attempts to break the vicious circle
The challenge for Microsoft is that’s really tough to break this vicious circle unless you can somehow goose either user numbers or the number of apps. What I saw in today’s keynote was an articulation of Microsoft’s strategy to do both, as shown below:
Universal apps and a billion users
On the one hand, Microsoft continued to talk up the benefits of Windows 10 and universal apps, along with its goal to have 1 billion users on Windows 10 across all devices within 2–3 years[ref]It’s worth noting that I think Microsoft’s comparison of this figure to other platforms was somewhat spurious on several levels. To the extent that Windows 10 represents a “single version” of an OS, the idea that it won’t be updated in a major way during those 2–3 years seems incredibly backward. However, I don’t think that’s the case — I think Windows 10 will continue to be updated, but on that basis it doesn’t represent a single version any more than, say, OS X is a “single version” of an operating system. All this, of course, also leaves aside the fact that Microsoft was comparing its goal for 2–3 years down the line with numbers for Google and Apple today. It’s entirely possible that Google will have close to a billion users on a single version of Android in 2018 — we simply have no way of knowing. But we do know that there are only a tiny number of users on Windows 10 today. [/ref]. The attempt here is to focus developers’ attention on the overall size of the platform across different device types, rather than smartphones explicitly. I’ve written before here about why I don’t think that strategy will work in the mass consumer market, but Microsoft clearly believes there’s merit to this argument.
Porting apps to Windows
The bigger news, though, was the text in red on the bottom half of the diagram above: all the ways in which Microsoft will lower the bar for porting an application from the web, older Windows development environments, Android, and iOS onto Windows 10. By making it easier for developers to port their existing applications onto Windows 10, Microsoft hopes to lower the barrier to entry and make it more attractive to support Windows Phone. I think it’s heartening that Microsoft recognizes the need to optimize by operating system rather than simply porting apps over as-is: BlackBerry’s use of Android apps set this bar extremely low, and many of the Android apps ported to BlackBerry perform poorly on the platform as a result.
Three problems with this approach
However, that brings me to the first of several problems I see with this approach: when developers still have to spend time optimizing their apps for the platform, is the bar low enough to entice them across? If developers are choosing between Android (with over a billion users on smartphones today) and Windows (with a potential base of a billion across PCs, tablets, and smartphones 2–3 years down the road) as a secondary operating system after iOS, will this make them choose Windows? If they’re considering Windows development as a third option after iOS and Android, will this tip the scales in the right direction? I suspect that for many developers, it won’t.
But the problem is much broader than that: the initial cost of porting an app to a new operating system can be significant, but the ongoing cost of maintaining the app over time, especially if feature parity across platforms is important, can be at least as significant. Now picture a scenario where a developer has used the Android or Objective-C tools to port an app from one of the other two platforms: the code ported over fine, but they’ve had to spend time optimizing and customizing the app so that it really shines on Windows. What happens when the Android or iOS app is updated with new functionality? Does the developer re-port the whole app and start from scratch with the optimizations? Or does he or she instead update the version previously created for Windows Phone with the new functionality? Either way, the workload for updating the Windows app is likely fairly similar to what it would have been had he or she simply created a Windows app in the first place. And in fact, since Windows 10 apps are universal, to really appeal to the full base of users, the developer will have to create optimizations for all the different types of devices the app might run on, so in some ways the total workload may actually still be greater on Windows than on other platforms which run on a narrower range of form factors.
The third problem is that porting apps often results in a lowest common denominator approach, in which the very people most likely to be attracted to a lower-cost porting method are those least likely to be willing to put the time and effort into making the experience really shine on each platform. You can often spot the apps on a platform which were built in this way, because they make use of generic rather than platform-specific UI elements and conventions, fail to take advantage of each platform’s unique capabilities, and so on. Microsoft used the example of game developer King and its Candy Crush app to highlight the potential of this approach, but I suspect this was a close hand-in-hand partnership and may even have involved some financial incentives (a strategy Microsoft has certainly used with other developers), so it may not be representative of the broader picture. Again, I think it’s great that Microsoft is pushing the idea that apps should be optimized for Windows and not just ported at a basic level, but I wonder what degree of enforcement will be applied to this approach. I worry that the laissez-faire attitude that’s led to thousands of copycat and trademark-infringing apps in the current Windows Phone store will lead to similar problems on a larger scale under this approach.
This ship might have sailed
Overall, I come back to what I wrote about in my in-depth report on Windows Phone: Microsoft may just be coming into the market too late, given the existing dominance of Android and iOS, to make a real dent in the smartphone side of the market. Yes, Microsoft brings a unique base of many PC users to the table too, but I suspect that the days of successful monetization of desktop software in the consumer market are numbered. The real opportunity is in the smartphone market, and there I don’t see much of what Microsoft announced today making much of a difference in breaking the vicious circle. As I’ve said before, the universal apps story makes a ton of sense in the enterprise market and potentially in a handful of other specific categories such as news, e-readers and so on, but so many of the consumer apps popular on mobile devices have no place on the PC and benefit little from this approach. Lowering the bar for porting apps across will likely boost app numbers a little, but I don’t see them changing the game in terms of the app gap. And by definition, they won’t solve the app lag problem, because you can’t port an app until you’ve already built it for another platform.