Windows Phone

Tips on submitting Windows Phone 7 apps to App Hub

Justin James says the experience of getting a Windows Phone 7 app ready for sale via App Hub leaves a lot to be desired. Here are his App Hub submission tips.

The Windows Phone 7 development experience at a code-level isn't perfect, but it is nice in comparison to some of the other mobile app development stories out there. Unfortunately, the experience of getting your app ready for sale via App Hub, Microsoft's developer site for Windows Phone 7 and Xbox 360, leaves a lot to be desired.

Since early November 2009 when App Hub came out, I've gotten three applications into App Hub: one free, one paid, and one paid with free trial. I've also read voraciously about how to ease the process of submitting apps to App Hub. Here's what I've learned that will help you get your application published in App Hub.

App Hub submission tips

Read and thoroughly understand the application guidelines

The first thing to understand is that the App Hub testers are very rigorous when they put your Windows Phone 7 application through its paces. This is really frustrating because they find things that you might not consider bugs but definitely violate the application guidelines. So far, none of my apps have been rejected for something that wasn't in the guidelines. The application guidelines are very clearly written; the only wiggle room in them is what constitutes too much adult content (violence, alcohol and drug use, language, sexual content, and so on). Some is allowed, but not much.

But I have been failed plenty of times for things that surprised me because I did not thoroughly understand the guidelines. Note the emphasis: my fault, not Microsoft's. If you want to play in their yard, you have to follow their rules. And you know what? The rules have a really good reason to be there: They raise the overall value of the App Hub applications. By ensuring the applications that get into App Hub are as bug-free as possible and have some basic consistency in UI, the user experience is improved, which leads to more handset sales and to users who are more willing to download (and even pay for) applications. After all, when you get a phone with great, trouble free apps, you tell your friends and download more; when you get burned a few times, and you also tell your friends, but you won't be getting more apps either.

My experience with Android, for example, is that any piece of junk that will tear up your phone can make it into the Android Marketplace; as a result, I stopped downloading or buying Android apps. So these rules really do help you to make more money.

Follow the Back button rules in particular The biggest challenge with following the rules relate to the Back button (section 5.2.4). It is incredibly tempting to hook into the BackKeyPress event handler and override the functionality with regards to navigation. I know because I did it. Don't do it. Not only are you violating the guidelines in general, but it is very easy to create a loop that the user cannot get out of. One of the underlying problems is that Microsoft deliberately did not provide any way to exit your application -- it can only happen via the Back button or through other actions that can tombstone your app (like pressing the Start button). So what happens is, when you override that Back button navigation, you create a loop and the user can't get somewhere else, and you can't hook into Back in order to just call Exit when needed.

Some folks are talking about raising exceptions and in the application level event handling just calling return. While this may work at a technical level, I suspect that it is frowned upon by the testers, and I would not trust an app to go through that uses this technique. If you have a wizard or some other workflow scenario where the Back button should not return you to the wizard once certain things have occurred, then keep the workflow in one XAML and hook the BackKeyPress event to show the previous or next step or to return to the previous page when on the first step of the flow.

Get things right the first time you submit an app

When submitting your apps, you really want to get things right the first time, including screenshots and description text. When you change this information, it requires your application to be retested, which can take a day or two to process (it even took three or four days for one of my apps). Also, you are only allowed five free application submissions with your initial membership fee (not apps in the market, submissions). So each failed submission, or re-submission to change information, uses one of those slots, even if it is the same app. After those five are used, you need to pay about $20 per additional submission. Why spend $20 per submission when it isn't necessary?

Use the Windows Phone Capability Detection Tool for the manifest file

Another strange gotcha is the application requirements. When you submit your app, Microsoft tests it to see what it needs and lists it as such. In addition, you are supposed to package a manifest file with the application's needs. The best thing to do is to build your application, then use the Windows Phone Capability Detection Tool to see what items need to be in the manifest file, and remove the rest (by default, the manifest file requests all permissions). Next, test your application to death. Check every nook and cranny and ensure that it doesn't throw any security exceptions.

Remove all unused DLLs from your application

You would think that the application is ready now, right? Wrong! It turns out the App Hub process takes it a step further than just using the capability detection tool (which is accurate in terms of detecting your application's true needs) -- it also checks out any references in your application, and what capabilities they might use, if you had a call to them. As a result, any references that can do things that your application does not need will show in App Hub that it does things your application does not actually do. For example, if you include the reference needed for location detection, but never access the location tools, App Hub will still show that your app needs GPS access. The solution is to remove any and all unused DLLs from your application, including the ones added by default that you may not use.

More about the App Hub submission process

There is more to the App Hub submission process than what I have covered here. For more details, I highly recommend that you read these blogs and articles: Jeff Blankenburg's Blankenblog, Adam Nathan's blog, and App Hub Application Submission Walkthrough. I also encourage you to really study the application requirements and guidelines. Happy coding!

J.Ja

Disclosure of Justin's industry affiliations: Justin James has a contract with Spiceworks to write product buying guides; he has a contract with OpenAmplify, which is owned by Hapax, to write a series of blogs, tutorials, and articles; and he has a contract with OutSystems to write articles, sample code, etc.

About

Justin James is the Lead Architect for Conigent.

3 comments
TouchGirlsOnline
TouchGirlsOnline

Hello, I haven't yet submitted to that app hub yet mainly because of the loose wording on adult content... My app has pictures of women... there is no nudity, and my app is on the Google android market place. When I looked into other apps on the market place I found 1 or 2. So I'm a little skeptical to pay the $100 non-refundable and then get denied... The apps that I make are all somewhat adult in nature... but they follow the guidelines... Do you have any advice for this? Thank you very much in advance.

Justin James
Justin James

Have you been having any problems submitting apps to App Hub? If so, what have you done to fix them? J.Ja

Justin James
Justin James

There are a few other apps in the Marketplace that are similar, the kinds of "puzzles with girls in bikinis" kinds of things, for example. I would check out the Marketplace (you can use Bing Visual Search, the Zune software, and possibly a Web site too) and see if other apps that have been approved are similar in content to your app. Unfortunately, the folks in the forum (and the tech support) refuse to answer questions like, "my app will do XYZ, will it be accepted?" so if it is a borderline case, the only way to know for sure is to try it. J.Ja