Move from Windows Phone Silverlight to Windows Runtime 8
[This article is for Windows 8.x and Windows Phone 8.x developers writing Windows Runtime apps. If you’re developing for Windows 10, see the latest documentation]
Note For info about porting to a Universal Windows Platform (UWP) app for Windows 10, see Move from Windows Phone Silverlight to UWP.
If you’re a developer with a Windows Phone Silverlight app, then you can make great use of your skill set and your source code in the move to the Windows Runtime (WinRT). WinRT is the technology that lets you build Universal Windows apps. You can refer to What's a Windows Runtime app? for more background on WinRT and Universal Windows apps.
When you port your app to the Windows Runtime, not only will you be able to take advantage of the latest phone features, you'll also be using the same app model and UI framework as Windows Store apps—even the same version of common features such as background tasks. That makes it easy to support PCs, tablets, and phones from one code base. And that will immediately multiply your app's potential audience and will create new possibilities with shared data, purchased consumables, and so on. For more info, see Building Universal Windows apps for all Windows devices.
The Windows Runtime version of your phone app (also known as a Windows Phone Store app) will run on any phone with the free Windows Phone 8.1 update. Even so, if you choose to, the Windows Phone Silverlight version of your app and the Windows Runtime version of it can both be available to customers at the same time.
XAML or HTML?
Windows Phone Silverlight has a XAML UI framework based on Silverlight 4.0, and you program against a version of the .NET Framework and a small subset of Windows Runtime APIs. Since you used Extensible Application Markup Language (XAML) in your Windows Phone Silverlight app, it's likely that XAML will be your choice for your Windows Runtime version. You will find the managed APIs, the XAML markup, the UI framework, and the tooling extremely familiar. You can use C++, C#, or Visual Basic along with XAML.
The few exceptions to the rule
The good news is that there's very little that's not supported in the Windows Runtime. Most of your skill set and source code translates very well over to Universal Windows apps, as you'll read in the rest of this porting guide. But here are the few Windows Phone Silverlight features that you may have used for which there is no Windows Runtime equivalent.
|Feature for which there is no Windows Runtime equivalent||Windows Phone Silverlight documentation for the feature|
|Microsoft XNA. In general, Microsoft DirectX using C++ is the replacement. See Developing games and DirectX and XAML interop.||XNA Framework Class Library|
|Alarms and reminders||Alarms and Reminders for Windows Phone 8|
|Clipboard APIs||Clipboard class|
Generating bitmaps for Live Tiles in a Background Task using managed code.
But you can generate a bitmap using native code with Windows.ApplicationModel.Background.BackgroundTaskBuilder.
|Background agents for Windows Phone 8|
|Lens apps||Lenses for Windows Phone 8|
|Lock screen background provider||Lock screen background for Windows Phone 8|
|Photos extensibility||Extending the photo edit picker for Windows Phone 8|
|Ringtone provider||How to use the save ringtone task for Windows Phone 8|
|VoIP apps||VoIP apps for Windows Phone 8|
|Continuous GPS tracking apps||How to continuously track the phone's location|
In this section
This topic provides a comprehensive mapping of Windows Phone Silverlight APIs to their Windows Runtime equivalents.
When porting a Windows Phone Silverlight app to the model for XAML Windows Runtime apps, most of your knowledge and experience will transfer, as will much of your source code and the software patterns you use. Even your UI markup and design can port over readily. You may be surprised at how relatively easy the process is, even if there is a challenge or two along the way.