Primer: The Windows Store Certification Process for Windows Phone Developers
As I travel around, I’ve met many people who are familiar with the Windows Phone application certification and submission process – it’s been around for a couple of years now! Perhaps not surprising, though, is that few people I’ve met have the same comfort level with understanding the Windows 8 Store and understanding how that differs from traditional desktop applications and web applications.
In this post, I’m looking not so much at converting an app (that will be another post) but instead looking at the certification process and any other gotchas I’ve experienced.
Windows Phone 7
If you’ve stumbled on this post and haven’t considered Windows Phone development, here’s a quick way to get started. Download Visual Studio Express for free, develop/test your app keeping the certifications in mind, create your MSDN App Hub account ($99/year), and submit your app.
I’ve been on both sides of the fence: as a developer, developing Windows Phone applications like Squeakbox, and as a tester, helping the WP app certification team test a few apps built to control Sonos music systems. (My role as an app tester was only honorary – I’ve got a pretty big Sonos installation and could easily/eagerly try out the apps!).
Based on my experience and feedback from other developers and internal discussions, the biggest problems developers typically run into with application certification requirements relates to interfering with phone functionality, small app violation policies, and of course, technical certification requirements.
Phone functionality is pretty easy to test for but often overlooked … how does the app respond when a phone call comes in? How does it look in a light vs dark theme? What about the back button? App violation policies are often easily correctable – for example, with push notifications, the app must have the user opt-in and provide a way for the user to opt-out if they later change their mind.
Occasionally, there is some confusion over application capabilities, or app cap. Each application has a manifest file that includes metadata for the application – one of which lists all the capabilities the app needs. This is important because these capabilities are displayed to the end user. So, for example, Squeakbox allows you to record sound clips, play sound clips from the media library, respond to sensors, and uses push notifications (among other caps). All of these are listed on the application page so the user may feel uncomfortable, say, if a simple app wants to use the phone contacts, for example.
The confusion, though, is understandable and here’s why. According to this document:
For Windows Phone applications, you should specify the capabilities required by your application, such as networking, the location sensor, or the camera. If you do not accurately specify the capabilities, your application might not work correctly or it might fail the submission process to the Windows Phone Marketplace. You specify the application capabilities in the application manifest file (WMAppManifest.xml). Depending on whether you are targeting Windows Phone OS 7.1 or Windows Phone OS 7.0, you can use the Marketplace Test Kit or the Windows Phone Capability Detection Tool to detect the application capabilities.
Seems simple enough. But the manifest doc says:
The application manifest file is generated in Visual Studio, and you should not edit the file manually. <snip> Some of the values in the manifest file will be updated automatically after you submit your application to the Windows Phone Marketplace. Examples include the Author, Publisher, and ProductID attributes, and the CAPABILITIES element.
So, you shouldn’t change the capabilities yourself, Visual Studio should handle it. And even if it doesn’t, the Marketplace should be able to tell what capabilities are required, and override what you put in your manifest.
Some final considerations when testing: It’s possible that one tester misses something another tester won’t. That happened to me. Above I mentioned that Squeakbox allows the user to record sound clips. The app can also run while the screen is locked. If you combine those features, you’re app can go into some possible eavesdropping territory. It was something I never thought of, and something that didn’t get caught in the first submission. So, consider how users might use your application.
Finally, be sure to run the Windows Phone Marketplace Test Kit. If nothing else, it will quickly determine if the core requirements have been met. This can save you a LOT of time.
Windows Phone App Hub (Where your account will be)
Application Certification Requirements (Stuff your app will have to do, or not do!)
Visual Studio Express for Windows Phone (Develop your app, if you don’t have Visual Studio)
First off, there is no immediate way to get an app in the Windows Store, but you can create an account here to register applications for notifications. However, if you have an app in development and would like to get it into the store, contact me. Many apps are getting into the store via a gated review with a premiere field engineer -- a few weeks ago at TechEd, we helped do this for many people in our App Accelerator area. The first step, though, is to have your app under development.
If you haven’t seen the Windows Store yet (and why not? You’re running the latest release, right?) then check out this video: