When you register for a Windows Dev Center account, your goal is most certainly to submit an app, get it certified, and distribute it to your potential users. In this post I’d like to focus on app submission and certification for Windows Store apps, and share with you a few of the most important tips to moving this process along as efficiently as possible.
#1: Make sure your app fulfills certification requirements
No matter what stage your apps are in, be sure to regularly review the App certification requirements for the Windows Store, which can and do change. (In fact, we updated them just before this article was posted.)
When planning apps for the Windows Store, keep in mind the core principles behind certification: apps need to provide value to potential users, behave predictably, put users in control, and be appropriate for a global audience. If you design your apps around these principles and review the specific requirements, you’re already a long way toward eventual certification.
At the same time, be aware that meeting Store certification requirements does not necessarily mean that your app will meet other requirements, such as content guidelines imposed by an ads provider. Be sure to check the requirements of any service that you’re using in addition to the Store.
#2: Create your Store account early
Apps cannot be certified until you have completed setup of your Windows Dev Center account. Company accounts have verification steps that can take a few days to complete. This is necessary because company accounts can take advantage of additional privileges in apps, such as using shared user certificates, enterprise authentication, and the Documents library.
Also remember to complete the necessary tax forms for your country of origin, which is a requirement for paid apps and in-app purchases. Without completed tax forms, certified apps will not be released and you won’t receive revenue payout.
#3: Reserve appropriate app names early
Names for your app are reserved on the Dev Center Dashboard and apply to both the Windows Store and the Windows Phone Store. The name that you’ll be able to use in an app certainly affects many aspects of your design and branding, so reserve your name early in the development process, including any localized names you need for your supported languages. You might find, of course, that others have already reserved the name you had in mind, so doing this early gives you time to find new names.
Note that the Store distinguishes between the languages that are supported by the app—as identified in the app’s manifest—and the markets in which you make it available, which are indicated through the Dev Center Dashboard. Thus it’s entirely possible to make a Japanese language app available in France, or vice-versa. In these cases, you’d possibly localize the app name as well. But it’s not necessary to localize and reserve app names for markets where you won’t otherwise be localizing the app.
Verify that you have the rights to use the name you choose. Be especially careful when using other company names, such as when you’re employing their services within your app. Each company will have their own policy on how their trademarks can be used by third parties, and if you infringe on their trademarks they can ask that your app be removed from the Store.
For more guidance, see What to name your app.
#4: Submit high quality apps that deliver unique value to customers
When building apps, think about how each one contributes to the strength of your overall portfolio and the quality of the overall Windows Store. We’ve found that customers reward creative and useful apps, and have little interest in unfinished apps or the results of early experimentation. We especially discourage you from submitting variations of the samples we provide in the Windows SDK. Those samples exist to educate you on the use of the Windows APIs and provide code snippets that you can use for specific capabilities. However, they are not intended for consumers nor are they intended to provide starting points for a consumer-facing app.
#5: Declare only those capabilities that the app truly needs
A number of Windows Runtime APIs are protected by capabilities that you declare in the app manifest. It’s important that you declare only those that the app needs at present. You can always add more capabilities to future app updates when you’re using their related APIs.
Declared capabilities are shown directly to consumers on your app’s page in the Windows Store as shown below. Those capabilities need to make sense to consumers, especially those that have privacy concerns such as use of the microphone, camera, and geolocation. If there is any doubt whether your need for a capability is obvious, explain your use of it in the app’s description.
Declaring capabilities for the user’s Pictures, Videos, and Music libraries is typically necessary only if your app presents a full gallery view of library contents. If your need is to only open or save individual files to those locations, it’s better to use the file pickers for that purpose, as they allow the user to select any location in those libraries or anywhere else on their file system and cloud storage providers.
Also be aware that there are three special-user capabilities that guarantee a slower certification process. These are the Documents Library, Shared User Certificates, and Enterprise Authentication. Apps that use these must be submitted through a company account (not an individual account), and are also reserved for very specific scenarios and require written justifications. For more, see App capability declarations.
In addition, apps that declare the Documents Library capability can only be submitted from developer accounts which have acquired an Extended Validation (EV) code signing certificate (see Account types, locations, and fees). Avoid declaring the Documents Library capability for storing configuration files (use your app data folders instead), saving documents, or doing anything outside the allowed scenarios, because attempting to do so will cause rejection. For saving and opening documents in the Documents Library or any other location, just use the file pickers instead because users can choose any location they want through them, including Documents.
#6: Include required privacy policies
A privacy policy is required for all network-enabled apps, which includes all apps that declare the Internet (Client) capability in the manifest. This capability is turned on by default in the Visual Studio project templates, so remember to uncheck that box in the manifest editor if you don’t need it.
Your privacy policy must be posted on a publically-accessible URL. You provide that link when filling out your app’s details on the Dev Center Dashboard, and the Dashboard will enforce this if you’ve declared any of the related network capabilities.
The link then appears on your app’s description page in the Store, and you should also add a command in your Settings pane that launches your policy URL.
Requirement 4.1 of the app certification requirements for the Windows Store provides the specifics of what your privacy policy must contain. Failure to provide a privacy policy will cause your app to fail certification.
#7: Be careful when soliciting user ratings
Because user ratings and reviews are so visible on your app’s page in the Windows Store and affect your app’s discoverability, many developers actively invite their customers to leave feedback. Obviously, good ratings are important, but apps cannot offer rewards for positive ratings or reviews. You must allow consumers to have their own opinions and state them honestly. After all, genuine feedback is how you understand how to improve your app.
When inviting feedback, avoid using any words that suggest a reward, as that will be grounds for rejection. In fact, it’s not even possible to programmatically determine what feedback was left, so there isn’t a way to trigger such a reward in the first place. The most you can do is send a user to your app’s rating and review section in the Store as shown below:
JavaScript:
C#:
#8: Test your app thoroughly
This one is simple. If your app isn’t functional, it will fail certification. Full functionality, however, requires that you test for a wider variety of conditions than you might encounter in your development work. Up-front testing is also important because any updates you make to your app to fix bugs requires that the app goes through the full certification process again.
First, be sure to test on a variety of hardware with different capabilities. This includes touch-only devices, touch-enabled devices, and keyboard and mouse-only devices (when applicable). Also test on x86, x84, and ARM systems—never assume that just because your app works on one that it will work on the others.
Test your app on a variety of screen sizes and orientations, as well as narrow layouts (see Guidelines for resizing to narrow layouts). For this purpose, you can use real hardware that’s available to you, but also employ the Visual Studio simulator which you can configure for a set of canonical screen sizes and scaling factors. Then test your app when the device is disconnected from the Internet and/or on a metered connection. We take connectivity so much for granted that we can easily forget about all the customer scenarios where connectivity isn’t available. So even if your app requires connectivity to function well, make sure that it fails gracefully and alerts the user to that condition rather than crashing or otherwise behaving in a way that will confuse your customers.
Remember also to switch from using the CurrentAppSimulator object, which you use during development to work with the Store APIs, to the CurrentApp object. If you forget, you’ll fail certification right away. Also be aware that some Store APIs will throw exceptions when the device is offline and licensing information isn’t available. Be sure to catch those exceptions, especially for in-app purchases, because you’ll typically never see such exceptions when using the CurrentAppSimulator.
JavaScript:
C#:
#9: WACK your app (run the Windows App Certification Kit)
When you submit your app for certification, the first thing that happens is that the Store runs it through the Windows App Certification Kit or WACK. This tool catches many common problems and issues, any one of which will cause your app to be rejected right away, but you won’t receive any of those results. You can save yourself a ton of trouble, and get detailed reports, by running the tool yourself. It’s included with the Windows SDK, and you can find it by searching for “Cert Kit” from the Start screen.
The WACK subjects the app to a number of tests (see image below), and provides you with a full report at the end of the process. You must address any issues that the report identifies before you submit your app.
Run the WACK throughout your development process rather than waiting until the very end. It will be much easier to fix issues early on, and running the WACK will give you a certain level of regression testing as well.
Note that you can also choose to run only specific tests in the WACK, as shown below. A full test can take 10-15 minutes during which time you should not interact with the app or the machine as a whole. If you’re working on a specific issue that a previous WACK session identified, then you can shorten the process by rerunning only a subset of tests.
#10: Maintain truth in advertising
When filling out all the descriptive information for your app’s page in the Store—including your description, feature list, and screen shots—be honest about the real customer experience of your app. Make sure that whoever is writing this marketing copy is fully attuned to what the app actually does—don’t list features, for instance, that might be implemented in the future, and don’t show unimplemented features in screen shots.
Be sure to also disclose geographical restrictions, that is, identify features that might not be available in some markets. For example, legal requirements might limit certain data that you can supply from your backend services, thereby limiting the functionality of the app itself.
Similarly, disclose any hardware requirements such as required peripherals that are necessary for the user to experience all of your features and capabilities.
You must also disclose the extent of localization. Ideally, you should provide localized versions of your descriptive text, features, search keywords, screen shots, privacy statements, and so forth for each language you declare in your app manifest. If you have any partial localization, however, be sure to disclose it. This includes disclaiming that content the app retrieves from its services might not be localized for the user’s language.
#11: Select an appropriate age rating for your app
Your age rating represents the kinds of content that users can expect to see in you app, and the suitability of that content for children, especially. Your age rating also determines whether your app appears in the Windows Store when age filters are in effect.
The Age ratings and rating boards topic in the documentation fully describes what kinds of content are appropriate for which age rating. Some countries and regions also require a rating from a ratings board, most typically for games, which can involve submitting a rating certificate with your app. Typically this means going through an online self-rating process to obtain the certificate, but some countries require that you submit your app for review, so leave yourself adequate time for that process. The topic above has links to all the ratings boards.
Be especially careful with apps that provide uncontrolled sharing of any kind of personal information or that access social networks, as this requires that the app is rated at 12+ or higher. “Controlled” sharing means that the app includes parental controls or requires parental permission to use sharing features, which must be clearly identified and explained in your Notes to Testers (see #12 below).
If you app acquires unfiltered content from an online service, especially one that allows customers to upload their own, your app’s age rating must match whatever content controls are enforced by that service. Otherwise it’s possible that content that’s inappropriate for your app’s age rating can appear in the app and cause it to fail certification.
Finally, regardless of your app’s age rating, your descriptive content for the Windows Store, including screen shots as well as your publisher name itself, must be suitable for the 12+ rating. For example, a game with a 16+ rating due to graphic violence cannot include screen shots that depict that violence because they’re not allowable with the 12+ rating.
#12: Use the Notes to Testers field
The final step in submitting your app is providing any notes to the testers that they need to properly exercise your app. Manual testing by a human being is the last phase of certification, and that person needs to know how to best use and experience your app, how to access any hidden features, and what test accounts they can use when logins are required. For app updates, also explain what has changed since your last submission. This is especially helpful if you’ve not actually changed any code—perhaps you’ve just updated listing details or added a new set of localized resources.
And remember that you’re talking to a real person through these notes, so please be courteous.
For more, see Providing info to certification testers.
Conclusion
Developers often make the mistake of concentrating too much on the internal workings of their app’s code and too little on the larger process of making that app available to users. The Windows Store certification process is designed to make sure that the apps that get listed in the Store are ready for those potential users. By understanding the process ahead of time, you’ll be able to avoid a number of mistakes that will cause the app to be rejected from certification or otherwise delayed.
For more help on certification issues, see Avoiding common certification failures and Resolving certification errors in the documentation, or visit the Publishing Windows Store Apps forum on MSDN.
Gus Salloum, Program Manager, Windows Store