Top five reasons that an application fails for certification in Windows phone 7 apphub

Introduction

I have recently submitted my first home made application to the Windows phone marketplace (AppHub) to be more precise. The link to the application is Binary Clock (still not active at the time of publishing this article.

It is a very simple app and the mere purpose of writing and submitting this application is to try out the app hub and see user responses on the Windows phone market place. This will then lead to my background work, which I hope to be the next killer game after angry birds. :) (keeping my finders crossed there). Now that's another story.

However, to my surprise, the certification process failed and the only reason I did not address one of the top five reasons described later below. Then I found out about these top 5 reasons and wanted to share with other newbies out there planning to publish their next million dollar application.

The Top 5 Failures

The details of all the below can be found from the following Technical Certification Requirements:

1. Application closure
2. Content and themes
3. Back button
4. Language validation
5. Application running on multiple devices

1: Application Closure

This is the most common reason. The application crashing. The developer must make sure the application does not close unexpectedly, i.e., crash, and if it must, then it should display a friendly error message to the user.

As a developer, you can get the crash dump sent back to you via various options, for e.g., letting the user email it.

Also when you go to your apphub, you will be able to get the crash analysis for your app. It's an awesome service for developers and you can get real time analysis on how well your application is performing.

2: Content and Themes

This is the reason why my application failed the first time. Make sure you test your application in both the light and dark theme. The users can completely customize their device and see it in black or white.

The developers don't take into account that the background might be white and they might choose colors that look good in black theme but completely out of place when the theme is light and hence a bad experience for the users.

3: Back Button

Applications should subscribe to the back button behavior that's required.

From mango (7.5) onwards, developers have more fine grain control over the back stack. They can if they wish to, delete items from the back stack.

4: Language Validation

Now at the time of writing this article, 20 languages are supported. More and more developers are taking advantage of this beyond EFIGS (English, French, Italian, German and Spanish).

Due to this, what is observed is that the application description entered in during the submission process is not localized to each targeted language.

Make sure that for each target language of the application, the localized description is of the appropriate type (i.e., in the same language).

Also note that if you have previously published application[s], and selected worldwide distribution, go back to the application dashboard and re-select worldwide again to have the new countries to be selected as this does not happen by default at this moment.

5: Application Running on Multiple Devices

Always remember that there is a huge value in testing the application in an actual device.

For your existing/new 7.0 applications, make sure that you test those applications on Mango devices as well as they become available. This is important because since 7.0 applications are available in the marketplace, end users with Mango devices will be able to use them too.

It is however encouraged to update these 7.0 applications to 7.5. This might raise a question. If you have an existing 7.0 application and then you submit an update targeting Mango devices, what happens to 7.0 users?

Simple! 7.0 applications will remain published in the marketplace and will be visible to the 7.0 users. However, the 7.5 (Mango) users will see the updated 7.5 application.

Conclusion

I hope this experience of mine will be able to help others from suffering from the same certification fail as myself.

To conclude, I would like to say a word on the certification time length. In general, the certification process should take 5 business days or less. If someone fails, they get explicit information on why their application failed the certification process. A detailed test summary report will be provided which outlines which test cases specifically failed. Where it's appropriate, they will get rest run notes that will provide additional notes as to how that error was found (more like a repo step) and how to address the error in some cases.

History

• 15^th November, 2011: Initial post