Resolving certification errors
Here are some of the actions you can take and links to additional references that can help you resolve many of the issues related to certification of apps submitted to the Windows Store.
This list is not exhaustive, but it should help you to resolve some of the more common issues that can prevent your app from being listed in the Store, or that can be found later during a spot check of your app. If you need more help, visit our forums to discuss your issue with community members.
Certification errors fall into three categories:
- Security tests
- Technical compliance
- Content compliance
The app is checked for the presence of malicious software.
An app can fail this test if its contents appear to be infected with a virus or if it could serve as an entry point for malware.
Check your development system for viruses and malware by running the latest antivirus software and rebuild your app's package.
The app is tested using the Windows App Certification Kit.
For info about running these tests on your own computer, see Using the Windows App Certification Kit.
The app is reviewed to ensure it complies with the App certification requirements for the Windows Store. Information to help you comply with some of the specific certification requirements is provided below.
Common reasons why apps fail this requirement:
- The value or usefulness of the app is not clear.
- The app has a name or icon that is very similar to other apps in the Store.
- The app is valuable or useful only in a subset of the languages that it claims to support.
- The app uses sign-in functionality, but doesn't provide users with a way to sign up and create an account.
- The app is a single-page app with a very limited set of content and functionality.
- The app is functionally similar to your other apps, but with a slight variation on the content. Collections of apps that are functionally similar should generally be delivered as a single, unified app.
Review your app for unfinished features, unimplemented options and menu choices, and other elements that might make your app appear to be unfinished.
When you submit your app, consider:
- Does your app require a user account? If so, include a test account in the Notes to Testers field.
- Can users make purchases through the app? If so, provide a way to test those purchases.
Some common reasons why an app appears nonfunctional or unfinished include:
- The app includes nonfunctional sections or contains placeholders (with labels like "coming soon" or "not available yet") for primary user scenarios.
- The app doesn’t work on all the architectures that it claims to support. For example, if you state that your app works on any CPU, it must work on all architectures, including ARM.
- The app description uses screen shots or statements that imply features that don't appear to be implemented.
- The app plays background audio, but does not correctly implement play, pause, and play/pause events to enable users to control audio playback.
- The app description doesn't explicitly state hardware or network requirements.
- The app uses the default icons generated by Microsoft Visual Studio or included in SDK samples.
The APIs for Windows Store apps are described in the Windows Store apps API reference. You might also want to review the Alternatives to Windows APIs in Windows Store apps.
Common reasons why apps fail this requirement:
- The Windows Store app requires a local desktop application or service to complete one of its primary user scenarios.
- The app has no clear value or purpose without that desktop application or service installed.
- The app communicates with the desktop application or component using non-approved methods (such as through files or the registry).
If your app depends on a desktop application, keep two aspects of this policy in mind:
- If one or more primary user scenarios within the app rely on a desktop application, that desktop application must be listed in the Windows Store.
- If the Windows Store app does depend on a desktop application, the Windows Store app must not assume that the desktop application is available on the local system. Acceptable apps are those that communicate with the desktop application via the cloud.
If you aren't sure whether your app complies with this policy, ask yourself: If this Windows Store app was deployed on a Windows RT system, would it still function the same way and provide the same value to the user? If it would not, then it may not pass certification. (Remember that Windows RT systems do not support third-party desktop applications.)
Common reasons why apps fail this requirement:
- The app crashes on launch.
- The app crashes randomly or repeatedly
- The app freezes and the user has to close and restart the app
- The app requires a Windows component library that the Windows Store doesn't support.
Here are some tips for avoiding or resolving these issues.
- Make sure your development tools are up to date.
- Before publishing to the Store, make sure the app's code uses theCurrentApp class (and not CurrentAppSimulator).
- Test apps that implement the Store commerce APIs (Windows.ApplicationModel.Store) to verify that they handle typical exceptions, such as loss of network connectivity.
- Run the app with no network connectivity to verify that the app doesn’t crash.
- Test your app on a machine with a fresh installation of Windows and no additional software.
- Test your app on all architectures that it supports, on additional computers, and in different configurations to help identify potential errors.
For more about testing your app, see Using the Windows App Certification Kit .
Tip After your app has been certified and listed in the Store, you can review app quality data to find out about problems it may have experienced after being installed on customers' computers.
One reason why an app might fail this requirement is that it downloads a remote script and subsequently executes that script in the local context of your app package.
- There are a number of reasons an app may not meet this requirement.
- The app must pass the tests provided by the latest Windows App Certification Kit. Be sure you run the current version and resolve any problems before you submit your app. For more info, see Using the Windows App Certification Kit.
- Direct3D apps must support a minimum feature level. If your app includes an ARM or a Neutral package, it must support Microsoft Direct3D feature level 9_1; otherwise, it must support the minimum feature level you indicate. If you choose a minimum feature level higher than 9_1, make sure your app checks whether the current hardware meets the minimum requirements and displays a message to the user if it does not.
- If your app contains Windows Runtime components, they must conform to the Windows Runtime type system. Review the certification requirement 3.12.3 for detailed requirements.
- If the app calls the 3rd party device drivers, it must be a privileged app. See Device sync and update for Windows Store device apps in Windows 8.1 for more information.
- The app packages must be formatted correctly and include a valid app manifest. See App package requirements for more info.
- Informs users of the personal information collected by your app
- Informs users how that information is used, stored, secured, and disclosed
- Describes the controls that users have over the use and sharing of their information
- Describes how users can access their information
- Complies with applicable laws and regulations
The app could fail this test if it appears to share personal information (such as email address or user account information) without explicitly obtaining the opt-in consent of the user. This requirement also applies if the personal information is that of a person other than the one using the app.
If your app uses the advertising ID, it must allow the user to turn off the feature so that no ID is retrieved.
For more info about notifications, see:
4.3 Your app must not jeopardize or compromise user security, or the security or functionality of the Windows device(s), system or related systems, and must not have the potential to cause harm to Windows users or any other person
An obvious example of an app that would fail to meet this requirement is one that is infected with a virus or is itself malicious software. Less obvious examples include apps that, either intentionally or inadvertently, allow or enable malware to enter a system. An app could fail to meet this requirement, for example, if it used a programming practice that some type of malicious software could exploit.
Your app could fail to meet this requirement if it prevents other apps from running as they should. It's not possible to enumerate all of the ways that an app could prevent other apps from running normally, but you can check by testing it on a computer while running other apps. If the other apps behave differently (such as becoming less responsive or losing data) while your app is running, you must find the reason why and fix the issue before submitting the app for certification again.
Another way an app could fail this requirement is if it plays audio in the background, but the audio cannot be heard by the user. It's normal for a media app to stay running in the background so it can play music while other apps are in the foreground, but apps must not play long-running, inaudible media streams in the background.
Finally, an app could be considered noncompliant if it presents a situation where the app fails, people could be harmed (for example, a GPS app marketed for use in life-threatening emergencies, or an air traffic control app). Apps that allow for control of a device without human manipulation would also be considered noncompliant.
Apps using the Windows.ApplicationModel.Store namespace can only sell in-app products that can be used within the app (i.e. digital items or services).
If your app includes in-app billing functionality or captures financial account information, but does not use the Windows.ApplicationModel.Store namespace, the following apply for the listed account types:
Apps submitted from either account type (individual or company) that do not use the namespace for in-app purchases must identify the commere transaction, authenticate the user, and obtain user confirmation for transactions. It must give customers the option to require an authentication on every transaction, or to turn off in-app transactions altogether, if they choose to do so.
For either account type, if your app collects credit card information (or uses a third-party processor to do so), the payment processing must meet the current PCI Data Security Standard (PCI DSS). For more info, see PCI SSC Data Security Standards Overview.
In addition, apps submitted from individual accounts are not permitted to directly collect sensitive financial account info or payments from customers. For more details, review certification requirement 4.7.
Be sure to research applicable law and comply with all requirements. You must also state clearly that Microsoft is not the fundraiser or sponsor of the promotion.
Common reasons why an app might fail this requirement:
- Apps with a rating over PEGI 16, ESRB MATURE, or that contain content that would warrant such a rating, are not generally allowed unless the app is a game, is rated by a third party ratings board, and otherwise complies with the certification requirements.
- Metadata and other content that you submit to accompany your app (including app screenshots) must contain only content that would merit a rating of PEGI 12, ESRB EVERYONE, or Windows Store 12+, or lower. This applies even if the app itself is rated for a higher age group.
- If an app provides a gateway to retail content, user-generated content, or web-based content that is likely to violate this requirement, it must include a mechanism which requires the user to opt in to receiving access to such content.
Additionally, because different markets have different cultural standards, greater scrutiny may be applied to your app depending on which markets you choose. If your app fails this requirement but you believe its content should be allowed, consider whether the content might be inappropriate for some of the markets you chose.
Additional requirements are detailed in the subsections of certification requirement 5.
For more info, see:
Common reasons why apps fail this requirement:
- The content of the app (including ads) is not suitable for the chosen age rating.
- You claimed a rating from a ratings board in a game definition file (GDF) and you didn’t provide the proof of that rating.
- You listed the app as either 3+ or 7+, but the app provides the user with uncontrolled access to online social networks or uncontrolled sharing of personal information with third parties, including other gamers or online acquaintances. For such activity to be considered "controlled," your app must include parental control features that require parental permission to use such sharing features, and you must identify those control features and explain their functionality in the Notes to testers.
- One of the markets you chose to distribute to requires a rating from a rating board, but you did not provide one.
- Your Windows Store age rating is lower than the corresponding age rating in the GDF file you provided
6.6 The capabilities you declare must relate to the core functions and value proposition of your Windows Store app, and the use of those declarations must be compliant with our app capability declarations
The app can fail to meet this requirement if it declares capabilities that don't appear to be necessary to perform the described functionality. Note that declaring a lot of capabilities will probably cause the app to be closely scrutinized and to take longer to go through certification. Make sure not to declare more capabilities than your app needs.
Three of the capabilities are restricted to company accounts, and all apps that declare them will be closely scrutinized. Having a company account does not guarantee that apps using these capabilities will pass certification. If your app doesn't need these capabilities, don't declare them:
- Enterprise authentication (enterpriseAuthentication): Uses Windows credentials for access to a corporate intranet. This is typically used in line-of-business apps that connect to servers within an enterprise. You don't need this capability for generic communication across the internet.
- Shared User Certificates (sharedUserCertificates): Enables an app to access software and hardware certificates, such as certificates stored on a smart card. This is typically used for financial or enterprise apps that require a smart card for authentication.
- Documents library (documentsLibrary): Allows programmatic access to the user's Documents library, filtered to the file type associations declared in the package manifest. Apps can use the file picker to access a user's Documents library without declaring this capability.
Important Apps using this capability can only be submitted from developer accounts which can demonstrate they have acquired an Extended Validation (EV) code signing certificate from a certificate authority (CA). See Account types, locations, and fees for more info.
Apps that declare the Documents library capability must facilitate cross-platform offline access to specific Microsoft OneDrive content using valid OneDrive URLs or Resource IDs, and it must save open files to the user’s OneDrive automatically while offline. Apps that use the Documents library capability for these two purposes may also optionally use the capability to open embedded content within another document.
Only the above uses of the Documents library capability are accepted. Some common reasons that apps declaring the Documents library capability don't pass certification are:
- Partial compliance with allowed use, such as providing offline auto-save only without cross-platform access
- Using the Documents library to store app data that is not directly authored by the user, such as app state
- Using the Documents library as a way to roam app data with the user's OneDrive
Note also that apps may not use the Documents library capability (or any other Library capability) to persist app state after a user uninstalls the app. Apps should use their own cloud service to preserve such state.
For more info, see:
- Here are some ways you can make sure your app meets this requirement:
- Make sure that it's easy for customers to understand what your app does. your description, category/subcategory, and images (including tiles) must be reasonably related to the content of the app.
- If your app has a trial version, make sure the functionality in the trial reasonably resembles the full functionality.
- Disclose any limitations or restrictions that your app has—for example, if it doesn't fully support all input methods (touch, keyboard, and mouse), or if content is limited to certain markets. This last point is particularly relevant for apps listed in the Rest of World (ROW) market (if the app would work properly in one region or country but not in another).
- If you declare your app as accessible, you must comply with accessibility guidelines.
- Make sure to localize the app (including its description, screenshots, and promotional images) in each language that it supports. (The Windows Store differentiates between language support and market distribution. For example, you are allowed to submit an app in French in the US market. This requirement is about languages, not markets.) Each app must support (and be localized in) at least one of the certification languages, and be functional in all languages for which you submit it.
- Make sure that your app has a similar experience across processor types and targeted operating systems. An app doesn't have to support all processor types, but to the customer it must look and act like the same app on all processor types that it does support. If you want to support features that are found in one architecture and not in another, you must create two separate apps with different names. Your app must also provide reasonably comparable experiences for both Windows 8 and Windows 8.1 users. If you use features only available for Windows 8.1, you don't have to reproduce those for Windows 8 users, but all features in your app for Windows 8 users should be available for Windows 8.1 users.)
- Do not imply that your app is associated with a company, government body, or other entity if you do not have permission to make that representation.
Users should be sent directly to the location where they can quickly and easily download your desktop app. Check that the link is correct, and make sure the information on your purchase page is clear and has all the necessary and correct information.
For additional help resolving errors, visit our forums to discuss your issue with community members.