Resolving certification errors (Windows)

10 out of 13 rated this helpful - Rate this topic

In this article

Security tests
Technical compliance
Content compliance

Here are some of the actions you can take and links to additional references that can help you resolve issues found during the certification of Windows Store apps and desktop applications that you submit to the Windows Store.

This list is not meant to be exhaustive, but it should help you to resolve some of the more common errors that cause certification failures. If you still need help, visit our forums to discuss your issue with community members.

Certification errors fall into three categories:

Security tests
Technical compliance
Content compliance

Security tests

Tests the app 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.

Technical compliance

Runs the Windows App Certification Kit.

For info about running these tests on your own computer, see Testing your app with the Windows App Certification Kit.

Content compliance

The app is reviewed to ensure it complies with the Certification requirements for Windows apps.

1. Windows Store apps provide value to the customer

1.1 Your app must offer customers unique, creative value or utility in all the languages and markets that it supports

Common reasons why apps fail this requirement:

The value or usefulness of the app is not clear.
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 variation on the content. Collections of apps that are functionally similar should in general be delivered as a single, unified app.

For help with planning and designing your app, review this topic:

Planning Windows Store apps

1.2 Your app must be fully functional when the customer gets it from the Windows Store

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”, “more to come”, 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 is misleading or vague.
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 any hardware or network requirements.
The app uses the default icons generated by Microsoft Visual Studio or included in SDK samples.

For help with developing and testing your app, review these topics:

1.3 Your app’s trial functionality must reasonably resemble its full functionality

For more info about implementing trial versions of your app, review these topics:

1.4 Each app must display only one tile after it is installed

For more info about app tiles and images, see:

For more info about using secondary tiles, see Secondary tiles overview.

2. Windows Store apps can display ads but are more than just ads or websites

2.1 Your app must not display only ads

For help with planning and designing your app, review these topics:

For more info about adding ads to your app, see Windows Advertising.

2.2 Ads in your apps must comply with our content policies

Review the content requirements at 5. Windows Store apps are appropriate for a global audience, and then review your ads or check with your ad provider.

2.3 Your app must not use its description, tiles, notifications, app bar, or the swipe-from-edge interaction to display ads

A common reason why an app might fail this requirement is that its description, tiles, app bar, or Settings charm (including the About link) are used for promotional materials.

Review the Windows Store app design guides and move your ads to a place in the app where they are allowed.

2.4 The primary experiences your app provides must take place within the app

A common reason why an app might fail this requirement is that it redirects the user to the web browser to complete one of its primary scenarios.

Review the Windows Store app design guides and add the external functionality to your app.

If you just want to provide a link to your website, you don't need an app because you can pin the link to the Start screen.

2.5 Ads must not execute program code that didn't come from the ad provider

Make sure that you have implemented the ads in your app correctly. You might also need to check with your ad provider to learn more about the nature of the ads they provide.

3. Windows Store apps behave predictably

3.1 You must use only the Windows Store app APIs to implement the features of your Windows Store app

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 in compliance with the spirit of 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? (Remember that Windows RT systems do not support third-party desktop applications.)

More info about Windows programming:

3.2 Your app must not stop responding, end unexpectedly, or contain programming errors

Make sure to test your app on the currently specified version of Windows 8, newly installed and with no additional software. Use the Windows PowerShell script to get a developer license so you can sideload the app (Show-WindowsDeveloperLicenseRegistration). We also recommend you test your app on all architectures that it supports, on additional computers, or in other configurations to help identify potential errors.

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. To avoid this, make sure your development tools are up to date.
Apps that implement the Store commerce APIs, from the Windows.ApplicationModel.Store namespace, should be tested to verify that they correctly handle typical exceptions such as loss of network connectivity.
Before publishing to the Store, make sure the app’s code is using the CurrentApp class (not CurrentAppSimulator), and then run the app with no network connectivity to verify that the app doesn’t crash.

Learn more about testing your app at Testing your app with the Windows App Certification Kit and run the test on different types of computers.

Tip

If your app has been certified and listed in the Store, review the Quality data from your Dashboard to find out about any problems your app might have when installed on your customers' computers.

3.3 Your app must provide the same user experience on all processor types that it supports

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 the app to support features that are found in one architecture and not found in another, for example, you must consider the app to be two different apps. In this case, you would need to name them differently and build and submit them separately to the Windows Store.

3.4 Updates must not decrease your app’s functionality in a way that would be unexpected to a reasonable customer

An app can fail to meet this requirement if it appears to the tester that an updated release has less functionality than the release that is currently available from the Windows Store. An app can also fail to meet this requirement if, in the update, you charge for functionality that is free in the current release—for example, if you require the users to make an in-app purchase to access the functionality.

To change the pricing model of your app—for example, by making features available through in-app purchases—you must submit the app as a new app and not as an update to an existing app. To avoid this complication, consider your app's pricing model carefully.

More info about configuring your app's features:

3.5 Your app must fully support touch input, and fully support keyboard and mouse input

Common reasons why apps fail this requirement:

One or more tiles in the app do not work with touch.
The app does not support keyboard and mouse.

The Windows 8 touch language is described in Touch interaction design.

3.6 Your app must use the mechanisms provided by the system for those features that have them

Common reasons why apps fail this requirement:

The app displays unexpected behaviors when the reviewer snaps the app or moves the divider so that the snapped app becomes the main app.
The app uses a button, gesture, or other UI element to close the app.
The app closes programmatically.
The app does not suspend and resume to a reasonable state.
The app has a bottom app bar, but the bar does not show up with a bottom-up swipe.
The app has a top app bar, but the bar does not show up with a top-down swipe.

For more info:

Review the interactions supported by Windows 8 in Touch interaction design.
Review the App contracts and extensions.
Review the Application lifecycle.

3.7 Deleted

Merged with 3.5 Your app must fully support touch input, and fully support keyboard and mouse input in version 1.1.

See the Revision history of the Certification Requirements for Windows apps.

3.8 Your app must meet the basic performance criteria on a low-power computer

The launch time and suspend time of an app depends on many variables such as system load and configuration, which can vary from one computer to another and from one test to another. Because of this variability, a launch time or a suspend time that is just under the limit in one instance, could be just over the limit, and fail the test, in another.

If the app’s launch time or suspend time is close to the limit, review what the app is doing to handle those events and look for ways to reduce that activity.

Launch and suspend performance test describes the requirements for this test.

Make sure to test your app on a newly installed version of Windows 8 with no additional software running.

3.9 All app logic must originate from, and reside in, your app package

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.

3.10 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.

If your app does not support ARM, it must support the minimum feature level chosen on the Store portal.

Because customers can change the graphics hardware in their computers after the app is installed, if you choose a minimum feature level higher than 9_1, your app must detect at launch whether or not the current hardware meets the minimum requirements. If the hardware does not meet those requirements, the app must display a message to the customer detailing the Direct3D requirements.

3.11 If your app contains Windows Runtime components, they must conform to the Windows Runtime type system

There are many requirements for Windows Runtime types. Review the certification requirements closely to see what you might need to change.

4. Windows Store apps put the customer in control

4.1 Your app must comply with the following privacy-related requirements:

4.1.1 Your app must have a privacy statement if it is network-capable

If your app connects to a network, you need to publish a privacy policy.

In particular, if you declare any of the following capabilities, you must maintain a privacy policy:

internetClient
internetClientServer
privateNetworkClientServer

Note that the default templates for apps in Microsoft Visual Studio 2012 include the internetClient capability, so unless you change the default manifest, you will need a privacy policy. Also, if you declare other networking capabilities not included in the list above, you also need to publish a privacy policy.

Provide access to your privacy policy from both your app's Description page in the Store, and from the app’s settings as displayed in the Windows Settings charm.

In general, an acceptable privacy policy is one that:

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

Beyond these general guidelines, we do not provide a sample or a template for a privacy policy.

If you do not actually collect or store personal info from users, say so in your privacy policy.

4.1.2 Your app must obtain opt-in or equivalent consent to share personal information

The app could fail this test if it appears to share personal information (including 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 user of the app.

Tip

If you collect or publish personal information, be sure to provide a link to your privacy policy in the app's description.

4.2 Your app must respect system settings for notifications and remain functional when they are disabled

For more info about notifications, see:

4.3 Your app must not jeopardize or compromise the security or functionality of the Windows system

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 tell if that is why your app failed certification 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 it 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.

More info about Windows programming:

4.4 Your app must not be designed or marketed to perform, instruct, or encourage tasks that could cause physical harm to a customer or any other person

This requirement is about apps that have critical functions such that if the app fails, people could be harmed. An example of an app that could be considered noncompliant is a GPS app marketed for use in life-threatening emergencies, or an air-traffic control app.

4.5 Your app must protect customers from unintentional large data transfers over metered networks

For more info:

4.6 Your app must comply with Windows Push Notification Service (WNS) requirements if it uses WNS notifications

For more info, see the Guidelines and checklist for push notifications.

4.7 If you use a commerce transaction provider other than the Store's, you must identify the provider at the time of the transaction or when it collects any payment info from the customer

If your app uses the Windows.ApplicationModel.Store namespace for in-app purchases, this messaging is provided for you. If your app uses any other method for in-app purchases or to collect payments, it must display a message to the customer stating that you are responsible for the transaction and not the Windows Store.

For example, in-app purchases made from apps produced by Contoso that don’t use the Windows Store for the transaction would display a message such as, “This item is available from Contoso” at the time of the transaction.

For more info, see How to support in-app purchases.

4.8 Your app must prompt the user for authentication to allow a commerce transaction to be accomplished

You can avoid this error by using the Windows.ApplicationModel.Store namespace for in-app purchases. If your app handles commerce transactions in other ways, your app needs to allow the user to require an authentication on every transaction, or to turn off in-app transactions altogether.

4.9 If your app collects credit card info or uses a third-party payment processor that collects credit card info, the payment processing must meet the current PCI Data Security Standard (PCI DSS)

For more info, see PCI SSC Data Security Standards Overview.

5. Windows Store apps are appropriate for a global audience

This section describes types of content that are not permitted in the Windows Store apps that are made available in the Windows Store.

Content means the images, sounds, and text contained in the app, the tiles, notifications, error messages, or ads exposed through your app, and anything that’s delivered from a server or that the app connects to. Because Windows and the apps in the Windows Store are used around the world, these requirements will be interpreted and applied in the context of regional and cultural norms.

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 allowed, unless the app is a game, is rated by a third party ratings board, and otherwise complies with these Certification Requirements. In some cases, Storefront apps or apps that aggregate streams of user-generated content from third-party sources apps may be allowed if given the appropriate age rating, even if they include some content that might otherwise be prohibited.
Metadata and other content that you submit to accompany your app may contain only content that would merit a rating of PEGI 12, ESRB EVERYONE, or Windows Store 12+, or lower.

Note that because different markets have different cultural standards, the more markets you choose to distribute to, the greater the scrutiny that is applied to your app. If your app is rejected but you believe the content is allowed, consider whether the content might be inappropriate at least for some of the markets you chose.

6. Windows apps are easily identified and understood

6.1 Your app must have a unique name

For more info, see Naming your app.

6.2 Your app must have a Windows age rating, and you must submit third-party ratings for your app if you have them

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 and you didn’t provide the proof of that rating
You listed the app as either 3+ or 7+, but it 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.

For more info, see Pick a suitable age rating.

6.3 You must provide technical support info for your app

Microsoft doesn't provide technical support for your app. You must specify how your users can get technical support for your app and ensure that any information provided (such as websites or email addresses) are both functional and relevant when you submit your app.

Common reasons why an app might fail this requirement:

No information provided for app support.
Your support information provides a URL to a page or website that is either under construction, a broken link, or has no information for a user to contact the app developer.
The support information that you provided is an email address that contains characters not permitted in email addresses.

For more info, see Support contact info.

6.4 You must list your app in at least one of the Windows Store's geographic markets

If the content or features of your app will not work in certain regions, you have to mention that explicitly on the Description page.

This requirement is particularly relevant for apps listed in the Rest of World (ROW) market, if the app would work in one region or country but not in another.

For more info, see Choosing your markets.

6.5 You must localize your app for all languages 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.

Common reasons why apps fail this requirement:

The app does not support at least one of the certification languages.
The app is functional in some of the languages for which you submitted it, but not all.
The information on the app's Description page (such as its description, features, or screen shots) does not reflect the amount of localization in the app.

For more info, see Choosing your languages.

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

Make sure that your app's capability declarations are appropriate to the functionality described in the app's description. The app can fail to meet this requirement if it declares capabilities that don't appear to be necessary to perform the described functionality.

If your app declares capabilities that it doesn’t need, it is likely to fail certification. Declaring a lot of capabilities will probably cause the app to be closely scrutinized and to take longer to go through certification.

Three of the capabilities are now restricted to Company accounts, and all apps that declare them will be closely scrutinized. If your app can doesn't need these capabilities, don't declare them:

Windows Credentials (enterpriseAuthentication)
Shared User Certificates (sharedUserCertificates)
Documents Library (documentsLibrary). You can often use the file picker instead of this capability.

For more info, see: