By most accounts, Microsoft CEO Satya Nadella has inherited a mess in the form of Microsoft's mobile strategy. Moreover, 14 years since then-CEO Steve Ballmer's infamous "developers, developers, developers" chant, Microsoft has confused, frustrated, and in some cases alienated developers with its multiple incompatible development platforms, in particular around mobile devices.
Microsoft's recent introduction of Universal apps attempts to tackle both challenges at once. By enabling developers to build apps that target both Windows Phone devices and Windows 8 tablets, Microsoft aims to clear the air with developers, provide the means for unifying its mobile experience across devices, and jump-start its mobile app ecosystem.
It's a tall order, but it might be a step in the right direction for a company that sorely needs it.
The woeful state of the Windows mobile app market
Microsoft's mobile platform, which includes both Windows Phone and Windows 8 tablets, has had limited success. Of the two, Windows Phone is in better shape, but that's not saying much. Its market share ranges from 4.7 percent in the United States to 11.8 percent in Italy, according to April 2014 figures from Kantar. In countries where Windows Phone sales are close to those of Apple's iPhone, the customer profile is very different, skewing predominantly toward the low end, thanks to the budget Lumia 5xx and 6xx series.
The success of the tablet personality of Windows 8 is harder to quantify, since Windows 8 users predominantly favor desktop (old-style) apps. Judging by the poor selection of apps and low numbers of ratings in the Windows Store, the overall availability and quality of apps for Metro is disappointing, beyond casual gaming.
That's not surprising from a developer perspective. Windows Phone trails well behind Android and iOS, and aside from a small group of users running the ARM version of Windows 8, aka Windows RT, Windows 8 users can also run desktop apps. Thus, developers have a much larger target market with a desktop app, considering how many businesses are sticking with Windows 7 and skipping Windows 8 altogether.
That's not to say Microsoft got everything wrong with Windows Phone and Windows 8. Windows Phone scores highly for usability and design coherence. Windows 8 Store apps bring not only a touch-friendly user interface, but also advantages in deployment, with no setup routines, easy installation and updating from a Store or corporate portal, and security, with each app sandboxed. Intrusive third-party applications cannot damage the user experience on the tablet side in the way that they often do in desktop Windows.
Giving developers the means to make the most of these advantages is essential to improving Microsoft's position in the mobile market. Recent history, however, hasn't played out well when it comes to developer relations with Microsoft on mobile.
Developer confusion: Once bitten, twice shy?
Microsoft's efforts to remake its client platforms have not been helped by its confused developer strategy. Windows Phone 7 launched in late 2010 with a development platform based on Silverlight, a cut-down version of WPF (Windows Presentation Foundation) that, at the time, appeared to form Microsoft's strategic direction for rich client apps. It made sense to use the same platform, extended to support phone features.
The Windows team had other ideas. At around the time Windows Phone 7 first appeared, Microsoft announced a new focus on HTML and JavaScript rather than Silverlight. A year later, at its 2011 Build conference, the company announced Windows 8, with a developer platform called the Windows Runtime (WinRT). WinRT is used for Windows Store apps. It supports several development models: C++ and XAML for general applications, C++ and DirectX for games, .Net (Visual Basic or C#) and XAML, and HTML and JavaScript.
XAML is the XML presentation language used also by WPF and Silverlight, but with significant differences in each case. Porting Silverlight to WinRT or vice versa is possible but not trivial.
The HTML and JavaScript approach uses a library called WinJS. WinJS is rarely used other than for Windows Store apps, but is now a standard JavaScript library for cross-platform browser apps. There is also a Windows-specific namespace that wraps the Windows Runtime API for access to native features.
If you code in .Net, you use the same CLR (Common Language Runtime) as in desktop applications, but with a reduced framework for security reasons. For example, ADO.Net, the database framework, is not supported in WinRT. Microsoft intends for data access to be done via Web services, though for a local database you can use a version of SQLite, a small, fast open source database engine.
C++ code uses the same WinRT API but with a slight performance advantage as one level of wrapping is removed.
All three (or four, if you count DirectX) approaches work well and without dramatic performance differences for most applications.
Considering it was a brand-new platform, WinRT was decent, though early adopters soon discovered gaps. However, for developers who had dutifully followed Microsoft strategy by learning Silverlight, getting them to throw away much of what they learned in favor of WinRT was a big ask and contributed to the poor supply of quality apps. In addition, Silverlight remained the platform for Windows Phone, so developers with apps for both platforms had to write them twice.
Another developer annoyance was that XNA, a well-liked .Net DirectX wrapper that works on Windows and Xbox 360, is not supported in WinRT.
The problems were mitigated by a feature called Portable Class Libraries (PCL). Introduced in 2011, a PCL lets you specify what platforms you want to support in a nonvisual C# or VB library. This is then enforced by Visual Studio. The idea is that you write as much code as possible in portable libraries, reducing the work of supporting multiple Windows platforms.
Even so, the multiple developer platforms on offer within the Windows platform are confusing, to say the least. The developer community has also learned to be wary of adopting Microsoft's latest strategy. Will it be another Silverlight a year or two down the line?
Windows Phone 8.1 and Universal apps
At the Build conference this past April, Microsoft announced Windows Phone 8.1 and Universal apps.
Windows Phone 8.1 is more than a bunch of new smartphone features. It is the first release to implement nearly the same WinRT used for Store apps in Windows 8.x. The app lifecycle -- how it behaves in terms of launch, activation, and suspension -- is the same, and the XAML namespace is the same. To retain compatibility, Silverlight is also supported, so app developers have a choice of which to target.
Developers can take advantage of the convergence of Windows Phone and Windows Store apps via a new project type in Visual Studio. A universal app solution has multiple targets, with a project for each target and another that is shared. When the app is compiled, the shared code is merged with the target-specific code. This gives developers full control over how to maximize shared code, perhaps at the expense of exploiting each platform's features, or to share only nonvisual code and write dedicated user interfaces. Universal apps in Visual Studio 2013 support only Windows Phone 8.1 and Windows 8.1, but developer tools vendor Xamarin uses the same approach to support iOS and Android with its cross-platform C# development platform. Microsoft has also previewed Xbox One as a target.
Alongside Universal apps, Microsoft announced a unified store that allows developers to sell apps once across both phone and tablet platforms.
The XAML factor
Microsoft's Visual Basic drove adoption of Windows in its early days, by providing an easy-to-use development tool for Windows applications. The company has struggled to come up with an equivalent for modern Windows, despite several attempts, including LightSwitch, Project Siena, and App Studio. Many Microsoft developers like C#, which means designing a user interface in XAML, a capable but complex and verbose language. In XAML, seemingly simple tasks become surprisingly hard to implement, although it offers strong support for animations, transitions, and scalable forms.
The main visual design tool for XAML, called Blend, is oriented toward designers rather than developers and is challenging to learn. Visual Studio has its own visual designer, which one expert at Build told me not to use as it inserts unwanted code that messes up your user interface. The complexity of XAML, together with the overhead of managing the app lifecycle correctly, means that creating a high-quality universal app is hard. Using HTML and JavaScript is a viable alternative, but it means giving up C# and the extensive .Net Framework.
XAML is growing in importance. The rumor is that a Store app version of Microsoft Office is being developed in XAML and C++, while Xamarin is using an implementation of XAML for its new cross-platform GUI framework, Xamarin Forms. If Microsoft puts resources into improving XAML and its design tools, that would help adoption of Universal apps.
The pros and cons of Universal apps
Universal apps are most welcome as a means of developing once for both of Microsoft's mobile platforms. If only Microsoft had done this from the start, it would have made more sense and saved developers a lot of pain, not to mention goodwill. Unfortunately, there are obvious snags with Microsoft's Universal app strategy.
To start, most Windows phones currently do not have Version 8.1 installed. A Universal app released today would have a small market. Depending on the operator, some devices running Windows Phone 8 may never be upgraded. In addition, Windows Phone 7.x will never be supported.
Also, porting Windows Store apps to become Universal apps is relatively straightforward, but porting a Silverlight-based phone app is more difficult. This means that the more popular platform is the hardest to port from.
Finally, universal apps are not really universal, since they also require PCs running Windows 8.1. Windows 7 users do not benefit.
The positive take: Given time, most Windows phones will be compatible, and Microsoft's efforts to make Windows 8 more acceptable to desktop users -- such as the revived Start menu briefly shown at Build -- will persuade individuals and businesses to upgrade. Another key feature, also previewed at Build, is the ability to run Store apps in a window. That way, they'll be more familiar and accessible to desktop users, though it breaks the principles of the "immersive UI" that was part of the Windows 8 concept.
An added twist is that corporate Store apps, using another new feature announced at Build, can bypass the app sandbox. It is possible, therefore, for Universal apps to become the primary way to build applications for Windows.
The skeptical view is that Microsoft's universal app strategy is too little, too late. The moribund Windows Store combined with the niche Windows Phone may not form an attractive platform even when combined. Windows, on this view, will remain primarily a desktop platform forever.
The pressure is on Microsoft to succeed on two fronts. First, it must sufficiently improve the next version of Windows enough so that users will upgrade, and it must win enough market share for Windows Phone that it becomes a device that mainstream app vendors feel compelled to support. Both are required for Universal apps to take off.
The company also needs to convince developers that it has settled on an app strategy that will endure, following so many shifts that many have lost their trust.
Hope for Universal apps?
It will not be easy, but Microsoft can take a few steps to help adoption. On the tools side, C# is great, Visual Studio is fine, but the XAML tools need work. Design work on the look and feel of WinRT controls would also be welcome, to soften and tone down their blocky appearance. On mobile devices, a good user interface is beautiful as well as functional.
Second, Microsoft needs to better explain the benefits of WinRT apps over desktop apps. People get that they work with touch, but the security and deployment advantages are lesser known -- and more worthwhile.
Third, the platform needs more excellent first-party apps to show what can be done. In this context, Microsoft Office will be critically important.
Finally, Xamarin's efforts are a gift to Microsoft. Make it a snap to support iOS, Android, Windows Phone, and Windows Store apps from a single code base, and more companies will include Microsoft's mobile platform in their plans. Outside of Redmond's Windows-tinted world, this is what a Universal app really means.
Related articles