Top 5 Reasons Your Windows Store App Fails Store Certification
Summary : Whether you're trying to get your Windows Store App certified in the Windows Store and running into blockers, or simply writing a new app for Windows 8 that you expect to publish via the Windows Store, check out the great insight provided by Robert Evans and Christophe Nasarre (two Microsoft Premier Field Engineers) in this article on the primary culprits you might run into when it comes to the certification process. They are technical leads for Windows Store App Labs and they provide a multitude of tips and pointers to some great resources. If that’s not enough, they also have the following video to walk you through some of the details. Watch the video, read the post, be informed!
When submitting your app to the Windows Store (https://www.windowsstore.com) you may encounter issues with Store Certification. These are the top 5 most common Store Certification blockers that we’ve seen in our Windows Store App Labs – and how you can fix them. Let’s count-down in reverse order:
Number 5: Your App Should be Fully Functional
Certification requirement 1.2: “App must be fully functional” (also similar failure is related to certification requirement 3.2 “Your app must not stop responding, end unexpectedly, or contain programming errors”).
If you are failing on this certification requirement there are some things you should check:
- Have you tested your App Snapped? Are there overlapping icons in your app bar while snapped?
- Does the charms menu cover up any critical commands?
- If you’ve declared your app as supporting portrait and landscape – does it?
- Does your submitted description talk about features you haven’t implemented yet? Does your app crash at any point?
- If the app plays background audio does it implement play, pause, and play/pause events to enable users to control audio playback?
- If your app has “login” functionality did you create a test user account and provide the username/password in the “Notes to Testers” field when you submit your application?
- Does the app work on all the architectures such as ARM that you checked off and claim to support when you submitted your app?
- Have you run the Windows App Cert Kit against your app – and from an ARM device such as Surface?
Number 4: Localize Appropriately
Certification requirement 6.5: “You must localize your app for all languages that it supports.”
This is different than specifying Markets. Your supported language may differ from the Markets, and Markets are specified when submitting your app under “Selling Details.” For example, if you open Package.apppxmanifest and under your <Resources> specify <Resource Language="x-generate" /> then Visual Studio will automatically add the languages your app supports based on the discovered resources when generating your final manifest. The important thing with regards to certification is that you support at least one of the allowed 37 certification languages. You may support any number of the 66 total allowed languages, but at least one language must be one of the allowed certification languages for testing purposes. Be sure that all of your images are also localized – if you have any images that contain text they should be localized.
Number 3: Performance
Certification requirement 3.8: “Your app must meet the basic performance criteria on a low-power computer - the app must launch in 5 seconds or less and the app must suspend in 2 seconds or less.”
The Runtime broker suspends all threads of any Windows Store App that is not in the forefront. If your app takes more than the allotted time to save state while suspending or takes too long while loading then the your app will be terminated. Typically this failure is uncovered by testing with the latest version of the Windows App Cert Kit which does automated tests of this. Failing on this requirement results in a technical compliance failure. In some cases people run the Windows App Cert Kit on their developer machine but when they submit to the store they still fail with this issue. That is why we recommend running the Windows App Cert Kit against your app on different hardware – including on an ARM device such as Surface.
Then the question is what are you doing in your app when you are loading and when you are suspending? If you are talking to webservices perhaps it works on your local machine but not when you upload as performance may vary based on different network capability. You should avoid any long operations when loading and when suspending and save state only locally. LocalSettings is a keyvalue pair that can be used that saves locally. RoamingSettings saves locally first and then synchs at a later date so that too is a great way to save data – and it is easy to change the default backing store of the SuspensionManager to RoamingSettings (see https://aka.ms/vrrplb).
If you find your initial loading is taking a long time due to heavy operations such as xml serialization then check out the MSDN Splashcreen Sample. They load the app and then create a fake splashscreen while they continue heavy loading operations – that’s one way to get around the time limitations.
Another common issue related to performance is when navigating pages within your app – you should only use simple types for your navigation parameters – such as Strings or Ints.
Number 2: Primary Experiences Stay Within The App
Certification requirement 2.4: “The primary experiences your app provides must take place within the app.”
This was a very common failure reason particularly in the first wave of Windows Store Apps and it is still common today. You should not redirect the user to the web browser to complete one of your primary scenarios. In our labs we recommend developers document their five primary scenarios for testing and include them in their tester notes with each step and a “scenario complete” at the end.
It’s okay to redirect the user to the browser or even embedded browser for other scenarios in your app such as submitting help requests or tutorials and such – but it’s not okay for your primary scenarios. You should not take them out to a browser nor should you use an embedded browser.
The reason is simple – if you are using a browser to complete your primary scenario – then it is arguable that your app should be a website and not an app.
Number 1: Privacy-Related Requirements
Drum roll please… the number one top failure reason for Windows Store Certification is…
Certification requirement 4.1: “Your app must comply with the following privacy-related requirements”
Why do so many people fail on this? By default in Visual Studio, Windows Store App templates have the Internet (Client) capability declared. When this is declared – even if you aren’t using it – you must have a Privacy Statement and it must be available from the Settings Flyout. That Privacy Statement can be a link to your online Privacy Statement or another page within your app that lists the Privacy Statement. If you are not using the network you can simply disable that capability to avoid this requirement. Otherwise it is easy enough to add a settings flyout. There are examples on MSDN or see Tim Heuer’s excellent free Callisto controls also available as a Nuget package.
In that similar category of failure reasons – if you are selling your app – you must also have a help and support section. There are three acceptable help and support options. A telephone, an email address (and they will test if it is a working address) or a webform. The help and support can be a separate link from your Settings flyout or it can be within your About section (also linked in your Settings flyout).
Finally…
If you’ve followed these pointers and you’ve checked the Windows Store Apps Forums and you are still blocked on Store Certification – please don’t sit there in frustration depriving the world of your amazing app!
Please either visit one of our free Windows Store App Labs (www.windowsstore.com/applabs) or follow the instructions below to get fast assistance. There’s even a “chat” option!
1) Visit the URL: https://aka.ms/storesupport
2) Towards the bottom of the page, there is a link that says “…contact us immediately. ”
3) Click that link and then it will ask you to choose the support type. To reach the App Certification team choose the following:
- Problem Type: “App Submission and Certification”
- Category: “Submitting an app”
- Once you do that chose an option for support such as “Request a Call”
Comments
Anonymous
May 09, 2013
Agreed! Just a mention: when reviewing early apps as part of the App Excellence labs, I found that another 3.2 item was frequently a not- or only-partially-implemented Suspend / Resume handler in the app, meaning apps would frequently crash when they attempted to resume from termination. The symptom for these apps was that if you came back to it after 10 seconds away, they'd start completely from scratch again.Anonymous
May 17, 2013
@Tristan: this topic will be covered soon :^)