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. 

Links:

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)

Windows 8

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:

From a certification standpoint, many of the requirements are spelled out in this document.   Most of these, particularly for WP7 developers, are expected… app mustn’t crash, limitations on advertising, opt-in consent, etc.   Some of the requirements that might require a little more thought:

3.5 Your app must fully support touch input, and fully support keyboard and mouse input

Your app must provide visual feedback when users touch interactive elements.

Your app must not use an interaction gesture in a way that is different from how Windows uses the gesture. The Windows 8 touch language is described in Touch interaction design.

The Touch Interaction Design, which part of the UX Guidelines, does a good job of illustrating this.

And:

3.6 Your app must use the mechanisms provided by the system for those features that have them

Your app must support a snapped layout. In landscape orientation, your app’s functions must be fully accessible when the app’s display size is 1024 x 768. Your app must remain functional when the customer snaps and unsnaps the app.

Your app must neither programmatically close nor offer UI affordances to close it. Windows 8 Process Lifetime Management closes Metro style apps automatically.

Your app must suspend and resume to a reasonable state.

If your app implements an app bar, that bar must show up with a bottom-up swipe.

If your app implements a navigation bar, that bar must show up with a top-down swipe.

Doesn’t the one about not offering a way to close itself ring a familiar bell from the Windows Mobile and Pocket PC days?  I remember the arguments then.  Smile  But seriously, having applications snap to one side is a great feature of Windows 8 and something you’ll need to keep in mind.  Some apps, like email, calendar, twitter client, etc., are naturals for this type of behavior, others are a bit more difficult.  Check out what some of the applications are doing today when you snap them beside another app.

Another easy to miss requirement but not surprising, for apps that use streaming data:

4.5 Your app must protect customers from unintentional large data transfers over metered networks

Notifications

If you’re used to notifications in Windows Phone, there’s good news and bad news.  The good news:  conceptually, it’s the same.  Tile notifications to update the live tiles with relevant data, toast notifications that presents the info to the user that allows them to interact, and raw notifications to send data directly to the application.    Conceptually (hat tip to Nick Harris for the pic), nothing is really different:

Your app requests a notification URI.  Presumably, you’ll have a web service running somewhere (preferably in Windows Azure!) that receives the channel URI and any relevant information for your app (username, zip code, twitter handle) in order to tie the channel URI to a specific user (bear in mind a user might have multiple channels if they have multiple machines).

However, instead of simply requesting and using a channel URI to send a notification, you’ll need to register the application first and authenticate, via an OAUTH token, to the push notification service.  This provides a good security layer to prevent notifications from untrusted services and authenticates you as the application owner.

Nick Harris has a good rundown of the procedure on his blog

Links:

Win8 App In 30 Days

Generation App

Windows 8 Dev Center

Windows 8 Certification Requirements

Windows 8 Touch Design

Windows 8 Performance Best Practices