In mobile, the user is king. For a mobile operating system to be successful, users must buy phones running that operating system. Software is the result, not the cause, of the mobile revolution. The need for nice apps comes only when enough phones are sold and used. Without beating around the bush, this has been a major problem for the overall Windows Phone strategy. The partnership between Nokia and Microsoft has been the right move for selling more (compelling) devices and increasing the need for more apps and more integration with the rest of the Microsoft ecosystem.
From a consumer's viewpoint, Windows Phone is firmly the third OS by market share at present, following Android and iOS. Some analysts reckon that Windows Phone may be second only to Android by 2015 in a world with only four major mobile platforms left: Android, Windows Phone, iOS, and BlackBerry. In this regard, having excellent devices running the operating system is key. Applications are the offspring of large-scale device adoption.
Windows Phone, however, has much more potential in a B2B perspective as it's part of one technology stack that offers integrated mobile solutions and that is not limited to the device endpoint. This is what Gartner calls the "Mobile Enterprise Application Platform" (MEAP). In this regard, Microsoft seems a much more complete partner than any other company in the mobile space; and Windows Phone is a pillar of Microsoft's implementation of MEAP.
Microsoft has a wide range of middleware technologies for backing mobile solutions. Let's have a look at what it takes to develop mobile solutions using the Microsoft stack. First off, any mobile front end needs a layer that acts as a facade on top of existing services. Microsoft has various flavors of ASP.NET and IIS to create back-end sites and REST layers; it also has Windows Communication Foundation (WCF) to create effective service-oriented infrastructure; and it has SQL Server and Dynamics CRM just to name a couple of storage- and business-related products.
You can use the same programming languages (C#, Visual Basic) and development framework (the .NET Framework, XAML) on the front and back ends and the same tools: Visual Studio and Blend.
As a mobile platform, Windows Phone leverages the Silverlight framework for development. While not all Windows Phone devices have the same screen size and hardware equipment, developing for Windows Phone devices is much easier than, say, for Android. There's nothing close to the difficulty of the Android device jungle when working with Windows Phone.
Compared with writing iOS and Android applications, developing applications for Windows Phone is much easier. If you're coming to Windows Phone with a .NET background, you will feel right at home.
Beyond this, writing a Windows Phone app poses the same challenges as any other mobile application — local storage, fake multitasking, wacky connectivity, limited resources, constrained input, and more. These are all standard challenges. Writing a mobile application is never quick and never cheap; but at least the tools around Windows Phone make it a lot easier, faster, and probably cheaper.
An area of Windows Phone development that certainly doesn't currently exceed expectations, however, is testing. As a developer, you can unlock your device and install up to 10 applications for live testing. But for the end user who wants try out the app under development, Windows Phone is annoying. On Android and BlackBerry, you email the executable; the customer checks the email on the target phone; the user taps on the executable; the executable installs and runs fine on the phone (and any other phone). On iOS, you run through a similar drill and download the app to the device via iTunes.
On Windows Phone, however, you have to set up a beta program and upload a version of the app that can run against a number of uniquely identified devices. Then the Windows Phone portal emails testers who download and install the application. The problem is that it currently takes 24 hours for the download to be available to the user. This is not ideal for sending quick updates and bug fixes during the development phase. In the alternative, the customer's device could be unlocked, thus allowing for direct upload. Unlocking requires getting a paid account to the Microsoft marketplace. This is not a tough condition as the customer still needs to register if she wants to publish the application in her name. However, it requires that the customer run Zune and Visual Studio tools on some computer, and not all customers are Windows-based.