Technical certification requirements for Windows Phone
These requirements have been replaced by the Windows and Windows Store Policies as of October 23, 2014. Please refer to the Windows and Windows Store Policies for all current requirements and policies related to submitting apps to the Windows Phone Store (and the Windows Store).
These requirements apply equally to an app that implements game functionality, commonly referred to as a game.
5.1.1 - Multiple devices support
The app must run on Windows Phone devices that are compatible with the hardware and screen resolution requirements specified in the package.
By default, the app is considered compatible with lower-memory devices. However, you can opt out of supporting lower-memory devices. For more information about lower-memory devices, see Developing apps for lower-memory phones for Windows Phone 8.
For more information about multiple devices support, see App capabilities and hardware requirements for Windows Phone 8 and Multi-resolution apps for Windows Phone 8.
5.1.2 - App closure
The app must handle exceptions raised by the any of the managed or native system API and not close unexpectedly. During the certification process, the app is monitored for unexpected closure. An app that closes unexpectedly fails certification. The app must continue to run and remain responsive to user input after the exception is handled.
5.1.3 - App responsiveness
If an app performs an operation that causes the device to appear to be unresponsive for more than three seconds, such as downloading data over a network connection or transitioning between a screen or page, the app must display a visual progress or busy indicator.
5.1.4 - App testability
The app must be testable when it is submitted to Windows Phone Store. If it is not possible to test your app for any reason, including, but not limited to, the items below, your app may fail this requirement.
5.2.1 - Launch time
5.2.2 - App responsiveness after being closed
A Windows Phone app is closed and terminated by the OS when the user navigates away from the app. When an app is started after being closed, its launch time must meet the requirements in Section 5.2.1 - Launch Time.
5.2.3 - App responsiveness after being deactivated
A Windows Phone app is deactivated when the user presses the Start button or if the device timeout causes the lock screen to engage. A Windows Phone app is also deactivated with it invokes a Launcher or Chooser API. For more information about Launchers and Choosers, see Launchers and Choosers for Windows Phone 8.
A Windows Phone OS 7.0 app is tombstoned (terminated) when it is deactivated. A Windows Phone OS 7.1, Windows Phone OS 8.0, or Windows Phone 8.1 app becomes Dormant when it is deactivated, but it can be terminated by the system when resource use policy causes it to tombstone.
When an app is activated after termination, it must meet the requirements in Section 5.2.1 - Launch time.
For more information and best practices, see App activation and deactivation for Windows Phone 8.
5.2.4 - Use of Back button
To maintain a consistent user experience, the Back button must only be used for backwards navigation in the app. The following four requirements relate to use of the Back button.
126.96.36.199 - Back button: previous pages
Pressing the Back button must return the app to the previous page or return to any previous page within the back stack.
188.8.131.52 - Back button: first screen
Pressing the Back button from the first screen of an app must navigate away from the app to the previous app on the back stack.
184.108.40.206 - Back button: context menus and dialogs
If the current page displays a context menu or a dialog, the pressing of the Back button must close the menu or dialog and return the user to the screen where the context menu or dialog box was opened.
220.127.116.11 - Back button: games
For games, when the Back button is pressed during gameplay, the game can choose to present a pause context menu or dialog, or it can navigate the user to the prior menu screen.
5.2.5 - Memory consumption
An app must not exceed 90 MB of RAM usage, except on devices that have more than 256 MB of memory.
On Windows Phone OS 7.0, Windows Phone OS 7.1, and Windows Phone OS 8.0, you can use the DeviceExtendedProperties and DeviceStatus classes to query the amount of memory that your app is using, and to adjust behavior based upon the memory available on the device.
For more information on memory requirements for Windows Phone, see App memory limits for Windows Phone 8.
5.2.6 - Trial apps
An app must not invoke either of the Trial APIs in a tight loop. For example, a game app must not invoke either of the Trial APIs while in a game loop. The API should be called infrequently and the value returned should be cached. For information about best practices for creating trial apps, see Creating trial apps for Windows Phone 8.
5.3.1 - Phone calls
The app must not delay or prevent the user from initiating a phone call, answering an incoming phone call, or ending a phone call.
5.3.2 - SMS and MMS messages
The app must not delay or prevent the user from sending or receiving SMS or MMS messages.
Sending a SMS or MMS message
Receiving a SMS or MMS message
5.3.3 - App responsiveness with incoming phone calls and messages
The app must not stop responding or close unexpectedly when there is an incoming phone call, SMS message, or MMS message.
5.4.1 - Malicious software screening
The app must be free of viruses, malware, and any malicious software.
5.4.2 - MSIL type safety verification
Windows Phone implements multiple sandbox mechanisms to help protect the integrity of the device and the apps running on the device. The Common Language Runtime (CLR) on Windows Phone relies on the type-safe execution of app code to help enforce security and isolation mechanisms.
An app must implement type-safe MSIL code to pass certification. For more information about C# unsafe code, see Unsafe Code and Pointers (C# Programming Guide).
5.4.3 - Security transparency verification
The Windows Phone app platform does not allow an app to run security critical code. An app that invokes security critical code will fail certification.
For more information about the .NET Security model, see Security Changes in the .NET Framework 4.
5.4.4 – App logic in a package
Your app must not attempt to change or extend the packaged content through any form of dynamic inclusion of code that changes how the application behaves with regard to the certification requirements. Your app, should not, for example, download a remote script and subsequently execute that script in the local context of the app package.
5.5.1 - Removed
5.5.2 - Content and themes
App content, such as text and visual elements, must be visible and legible regardless of the phone theme without panning horizontally or zooming. For example, if the phone theme changes from black background to white background, the text and visual elements of your app must be visible or legible. As another example, when content loads into a WebBrowser control, the text and visual elements must be visible or legible without requiring the user to pan horizontally or zoom.
5.6.1 - Technical support information
An app must include the app name, version information, and technical support contact information that are easily discoverable.