Technical certification requirements for Windows Phone
November 04, 2013
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 XAP 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 more information, see App capabilities and hardware requirements for Windows Phone 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.
Your app may close unexpectedly if it tries to access an API that it does not have the security capability to use. For more information about how to work with security capabilities, see How to determine app capabilities.
When handling exceptions, an app should provide a user-friendly error message. You may present a message that is relevant to the context of the app.
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.
A Windows Phone OS 7.0 app is tombstoned (terminated) when it is deactivated. A Windows Phone OS 7.1 or higher app becomes Dormant when it is deactivated but can be terminated by the system when resource use policy causes it to tombstone.
When activated after termination, the app 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.
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 close the app.
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 navigate the user to the prior menu screen. Pressing the Back button again while in a paused context menu or dialog closes the menu or dialog.
5.2.5 Memory consumption
For Windows Phone OS 7.0 and Windows Phone OS 7.1
An app must not exceed 90 MB of RAM usage, except on devices that have more than 256 MB of memory.
For more info 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.
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.5.1 – Language validation
The product description and UI text of your app must be localized to each language the app supports.
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.