However, there’s another series of things that are important to keep in mind when you have to make this choice: there is a list of features that, for timing and resources issues, the team wasn’t able to make available in both frameworks. For this reason, if you choose to develop a Windows Phone app, you won’t be allowed to:
- Use the APIs to interact with the clipboard
- Define your app as a lock screen provider, so that it can change the lockscreen’s wallpaper
- Define your app as a ringtone provider
- Use Alarm and Reminders
- Develop a Lens App (which are photographic apps that can be integrated with the native camera app)
- Keep an app running under the lock screen
- Use the Continuous Background Tracking APIs, that can be used to continuosly track the user’s position even when the app is not in foreground
- Use VoIP APIs
- Use the CameraCaptureTask, which is the chooser that can be used to take a picture with the native camera app and import into your application
On the other side, if you develop a 8.1 application using the Silverlight framework you won’t be able to:
- Use the old APIs to manage background audio. You will have to migrate to the new Windows Runtime APIs or keep your application as a Windows Phone 8.0 app
- Make use of the new XAML framework, which is able to fully support devices with different screen sizes
- Use the new XAML controls, like Hub or GridView
- Use the new APIs to edit videos
- Use the new Visual Studio tools for profiling and coded UI tests
It should be clear now that the framework’s choice can’t be based just on the type of application (new or existing one) but also on the features you want to use: if, for example, you’re developing a Lens App or an images catalogue app which acts as a lock screen provider, you’ll be forced to develop a Windows Phone Silverlight 8.1 app.