Here are the available language sets for Windows Store app development:
If you develop on the Microsoft stack, at least some of these languages should be familiar and, of course, Web developers know HTML and friends quite well. It makes sense that many of the same language sets are available for Windows Phone development: XAML with C#, Visual Basic .NET, and C++.
If you’re creating a cross-platform native app (not a Web site) outside of the Microsoft ecosystem, the language landscape changes to these two options:
Fortunately, Xamarin has come to the rescue for .NET and Windows developers who want to write cross-platform apps. There’s no need to learn Java (although it’s quite similar to C#) or Objective-C, the language of iOS development (more on this later).
Now that you have a solid idea of what languages are available to use, I’ll look at how easy or difficult each one is to learn.
XAML developers from both the Windows Presentation Foundation (WPF) and Silverlight camps continue to write the same declarative XAML for the UI layout alongside C#, Visual Basic .NET or C++ as its compiled companion. As you might expect, in XAML there are new libraries and namespaces dedicated to the Windows 8 modern experience.
There’s a great amount of parity among the declarative languages—that is, any “ML” language—concerning the amount and quality of UI controls. In general, if you find a control in XAML, it likely exists in HTML or the WinJS library and vice versa; however, there are one or two differences between the two.
XAML developers will hardly notice a change except for some namespaces and other trivial changes. Expression Blend is still a great tool to do UI design in XAML, while Visual Studio is best for the compiled language behind the scenes. A widespread third-party ecosystem exists around XAML UI controls, such as grids for XAML on the WPF platform, and many of these controls work the same way or similarly between Windows Store and Windows Phone apps.
Windows Azure Mobile services (which you can learn more about in another blog post, “Use Windows Azure Mobile Services to Power Windows Store and Windows Phone Apps,” at bit.ly/15nhO8d) and the Windows Azure platform offer several native APIs for all the popular platforms as well as REST APIs that are inherently cross-platform. Because REST is an open standard, you can access its data from any language, anywhere, at any time, via a consistent interface. REST interfaces make it easy to develop across platforms because—despite language syntax and quirks—the code has a general consistency, or pattern. Public APIs, such as those provided by Twitter, Facebook, weather services and so on, usually return JSON or XML (or both) that you can consume via REST or XMLHttpRequest (XHR).
SQLite is a local database option available across all platforms and languages. SQLite is available as a NuGet package for Windows Store and Windows Phone apps in Visual Studio 2012. You can also access it through a Xamarin toolset and use its libraries to access SQLite databases on iOS and Android. SQLite is easier to use with XAML apps than HTML apps.
For complete details on data-access technologies for Windows Store and Windows Phone apps, see my March 2013 column, “Data Access and Storage Options in Windows Store Apps,” at msdn.microsoft.com/magazine/jj991982.
Objective-C is syntactically and operationally different from the other languages, as Java and C# behave similarly because they’re managed languages. However, if you’re writing cross-platform apps, you aren’t doomed to separate codebases such as Objective-C for iOS, Java for Android and C# for Windows platforms, because the aforementioned Xamarin tools make it easy to write in C# and generate Java and Objective-C. Xamarin provides a native code-generation toolset for cross-platform device development (that is, mobile and tablet devices), and it’s the lowest common denominator for doing cross-platform native development. As a result, developers from just about any platform can easily move their skills to the Windows platform or cross-platform via Xamarin and C#. Developers from the iOS and Android platforms would do well to pick C# as their language of choice if they want to publish on the Windows platform as well as the others. Note, however, that some developers in Redmond disagree, advocating that it’s more convenient to develop libraries in C++ and C because they can be accessed by iOS (directly) and Windows apps (via Windows Runtime, or WinRT, components). They point out that this approach is “free” (most Xamarin tools cost money) and more performant than third-party tools. I favor just creating and sharing Xamarin components, as time to market is more important than the negligible performance benefits—and I don’t particularly like using C++.
Not all apps are greenfield apps (that is, new or rewritten). Most, in fact, are brownfield—or legacy programs—especially if the code you’re writing is for the enterprise. Many apps are really parts of a larger ecosystem of software made of multiple apps or multiple UIs that interact with business logic, service layers, public APIs or libraries.
Migrating Web apps in particular can be tricky, as you often need to keep the content of an existing Web site intact yet integrate that same content into the client app and make it feel like a native experience. This is because business requirements frequently dictate that the original Web site or architecture must remain unchanged. This can cause the look and feel of the app to be different from its host OS, making usability difficult, and it can block the user’s natural workflow. Fortunately, if you’re porting an existing Web site or app, you often have the choice to integrate instead. If this is the case, then the Apache Cordova framework (formerly PhoneGap) can help. Cordova enables you to create hybrid, Web-native apps by integrating Web content and native UI components and publishing across platforms. Conversely, integrating Web content with a native WinJS Windows Store app isn’t difficult to do using WinJS, and the experience is usually smoother for the user. Native apps enjoy a closer integration experience with the OS than client Web apps do, because native apps have access to modern hardware resources such as the camera, microphone, device settings, accelerometers, geolocation and so on. In addition to this, native apps have a distinct lifecycle and contain state, whereas Web apps are lightweight and stateless.
If you write business and productivity apps, you usually have your choice of any language that suits you, because things such as performance and UI controls are so similar. These apps tend to be common forms-over-data apps. The current set of technologies is what normally drives language and technology choices for these kinds of apps.
Wondering what happened to F#? While F# isn’t one of the basic templates for Windows Store and Windows Phone app development, you can reference and consume components created in F#. It’s also a great language for processing analytics and running code on the back end—and all apps need a back end.
Rachel Appel is a consultant, author, mentor and former Microsoft employee with more than 20 years of experience in the IT industry. She speaks at top industry conferences such as Visual Studio Live!, DevConnections, MIX and more. Her expertise lies within developing solutions that align business and technology focusing on the Microsoft dev stack and open Web. For more about Appel, visit her Web site at rachelappel.com.
Thanks to the following Microsoft technical experts for reviewing this article: Eric Schmidt (firstname.lastname@example.org) and John Kennedy (email@example.com)
More MSDN Magazine Blog entries >
Browse All MSDN Magazines
Subscribe to MSDN Flash newsletter
Receive the MSDN Flash e-mail newsletter every other week, with news and information personalized to your interests and areas of focus.