Resolving certification errors

Applies to Windows only

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

Security tests

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.

Technical compliance

Errors related to technical compliance can be avoided by running the Windows App Certification Kit on your app and fixing any errors before you submit.

Content compliance

Make sure that your app complies with some of the specific Windows and Windows Phone Store Policies. Some information about specific issues related to individual policies is presented below.

10.1—Distinct Function & Value; Accurate Representation:

Common reasons why apps may not comply:

  • The purpose 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 does not appear to be fully functional. For example, it uses sign-in functionality but doesn't provide users with a way to create an account.
  • The app is functionally similar to your other apps, but with just a slight variation on the content. Collections of apps that are functionally similar should generally be delivered as a single, unified app.
For help with planning and designing your app, see Vision and process.
Additional guidelines to keep in mind:
  • 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).
  • 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.

10.2—Security:

An obvious example of an app that would not comply with security policies 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.

All app logic must also reside within the package. For example, your app should not download a remote script and subsequently execute that script in the local context of your app package.

Your app must only depend on Windows Runtime APIs allowed for Store apps. 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.

Your app must not communicate with local desktop applications or services via local mechanisms. Some examples of apps that wouldn't comply with this policy:

  • 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? (Remember that Windows RT systems do not support third-party desktop applications.)

10.3—App is Testable:

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

10.4—Usability:

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 fails to launch promptly.
  • The app closes unexpectedly.
  • 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.

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.

10.5—Personal Information

If your app accesses or transmits any personal information (or if otherwise required by law) you need to publish a privacy policy.

You need to provide access to your privacy policy from a link in your app's description and also from within the app itself.

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.

10.6—Capabilities:

Your app should not declare capabilities that don't appear to be necessary to perform the described functionality. 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:

10.8—Financial Transactions:

Ensure that your in-app products comply with all policies. For example, apps using the Windows.ApplicationModel.Store namespace or any Microsoft in-app purchase API can sell only digital items and services that can be used within the app. There are additional requirements for apps that don't use a Microsoft in-app purchase API. Be sure to also clearly describe the types of in-app purchases, and the range of prices, in your app description.

Note also that if your app collects credit card information (or uses a third-party processor to do so), the payment processing must meet the current PCI SSC Data Security Standards (PCI DSS).

10.9—Notifications:

Remember that notification content must comply with all Store Policies, and that your app must remain functional even if notifications are disabled. For help understanding how to use notifications correctly, see:

11.1—General Content Requirements:

Review your app's content and metadata. Most apps that contain content that would warrant a rating over PEGI 16 or ESRB MATURE are not allowed.

In addition, all metadata and other content that you submit to accompany your app (including screenshots) must contain only content that would merit a rating of PEGI 12, ESRB EVERYONE 10+, 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.

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. Different markets have different cultural standards, so greater scrutiny may be applied to your app depending on its markets.

For more info, see:

11.11—General Rating Requirements/11.12—Additional Ratings Requirements - Windows Apps:

Things to keep in mind:

  • The content of the app (including ads) must be suitable for the chosen age rating.
  • Certain markets require that you rate your app through a rating board and provide a game definition file (GDF), particularly if it is a game. If you claimed a rating from a rating board in a your GDF file, you must provide the proof of that rating. Your Windows Store age rating cannot be lower than the corresponding age rating in your GDF file.
  • Certain markets require requires a rating from a rating board, you must provide the appropriate did not provide one.
  • Apps listed as either 3+ or 7+ must not provide 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. You must identify those control features and explain their functionality in the Notes to testers.

 

 

Show:
© 2014 Microsoft