5 tips to get your apps certified quickly

From the beginning, we designed the Windows Store to be a partnership between developers and Microsoft. We’re committed to ensuring that our certification requirements and app submission processes are clear and easily understood, so that you, the developer, can create high-quality apps that customers love. In this post, we want to highlight a few of the patterns we’ve noticed in app submissions, and provide you with some guidance on how to help speed your app through the submission process. Gus Salloum, Program Manager, authored this post.

--Antoine


For an app to be published and to remain in the Store catalog, the app has to comply with the Windows Store certification requirements. These requirements help ensure that apps in the Windows Store are of high quality and interact with the system in ways customers expect. The latest version of the certification requirements are always available on the Dev Center. We also provide a revision history, to help you see how these requirements evolve over time.

Over the past several weeks, we’ve been tracking why apps fail certification and have noticed a few patterns. To help get your app in the Store, we want to provide guidance on the requirements and certification processes that have proved a bit challenging and some suggestions on how to get listed quickly.

Publish a privacy policy when required

Privacy is a key dimension of our promise to customers. It is important that our mutual customers be confident in the apps they get from the Windows Store. We’ve had a statement about privacy policies since we first published these requirements in December 2011, and we’ve recently clarified the expectations to help developers meet this requirement. The requirement now reads:

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

We made this change because we want customers to be comfortable with how you handle their personal information. Any app that connects to a network has the potential to transmit personal information. That’s why we ask and require that you maintain a privacy policy if your app declares one or more of the following capabilities:

  • internetClient
  • internetClientServer
  • privateNetworkClientServer

Your privacy statement explains to users what personal information your app transmits, and how that information is stored and managed. If your app is ad-supported, the policy describes the personal information shared with the ad provider. In cases where your app doesn't actually transmit personal info, just say so in the privacy statement.

As a reminder: there are two places where you have to provide access to your privacy policy:

  • in the Settings charm of your app (this will be available to the users while they're using the app)
  • in the Description page of your app on the dashboard when you're submitting the app (users see this page before they acquire the app)

Submit valuable apps

Certification requirement 1.1 states:

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

We share a common goal: to fill the Store catalog with fantastic apps for customers. Apps that offer very minimal value will be rejected—such apps can hinder discovery of quality apps, which in turn hurts customers and developers alike.

What’s an example of an app that provides too little value? Well, consider our code samples that were created to help developers build apps for the Windows Store. Those code samples make it easy to create an app with basic functionality that demonstrates the capabilities of the Windows 8 platform. Unfortunately, a minority of developers have opted to re-package these samples and submit them to the Store. These apps have little purpose and will fail certification.

Here are a few more examples of apps that fail this requirement:

  • Collections of apps built around a given theme using what appears to be a cookie-cutter app template. We recommend that such apps be combined into one app. That larger app will potentially provide more tangible value to the users (and likely get better ratings and reviews than each of your the apps submitted separately), and have a better chance at passing certification.
  • Apps whose only purpose is to display a limited set of static images (sometimes as little as one image— of a flag or a celebrity for example).

Submit complete apps and avoid misleading app descriptions

Our certification requirement 1.2 states:

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

We require that the apps that you submit be fully functional. We also require that your app description accurately describe the app's features and content, and explicitly list any restrictions the app may have (geographical, hardware-related, or other), so that customers know what they'll be getting before they buy or install your app. When an app fails this requirement, it’s usually for one of the following reasons:

  • Misleading description text or screenshots. The app description must only list features and content that are actually implemented in your app. If you know that some of your app features will not work in certain geographies or in the absence of certain hardware sensors or peripherals, explicitly mention those restrictions in the app description. The goal is to give customers all the information they need before acquiring your app.
  • Including non-functional user controls, broken links, or placeholder sections. The goal here is to avoid giving customers the perception that the app is not finished. In a lot of cases, our testers find placeholders for functionality that a developer intends to provide in a future update. We will reject any app that has such placeholders.
  • Not providing enough details for Microsoft to test your app. If your app requires special instructions to test thoroughly, such as a username and password, you need to include that information when you submit the app.

Properly localize the app submission

Another area in which we’ve seen some questions and confusion relates to our localization policies:

6.5 You must localize your app for all languages that it supports

6.8 You must provide localized screenshots of your app for each language it supports

Windows Store apps can support more than one language (see Package manifest schema reference). This platform feature can help your app reach a wider customer base, but comes with requirements:

  • The list of languages your app supports must include at least one certifiable language.
  • For each of the supported languages on the app dashboard you must supply localized app description elements (text, screenshot images and captions, and so on). This is to ensure that customers have the information they need in their preferred language to make an informed decision about the app.
  • The app must be useful in each of the supported languages, and should present most of its chrome and its content resources in those languages. You can learn more about some of the tools you can use to help you localize your apps in this blog post.

Naturally, apps will fail against this requirement if they declare support for a given language but do not include resources for that language, or if a language used in the app description elements does not match the language that was declared.

As a reminder: we make a distinction between the languages your app supports and the markets you want to distribute your app in. You define the languages in the app manifest, and you choose the distribution markets on the app dashboard.

We hope this helps you save valuable time during the certification process. We remain committed to ensuring that the Windows Store provides a leading experience for both the developers building apps, as well as the consumers using them. We are incredibly excited by the work you are all doing. The apps we’re seeing demonstrate your shared commitment to creating great experiences, and we’re working hard to make sure you have the tools and information to ensure your apps are certified in as little time as possible.

--Gus Salloum