2. The publication process

During development, you typically deploy your app to developer-unlocked phones, but normal users will install your app on retail phones. There are actually two supported ways to install an app onto a retail phone (that is, a phone that has not been developer-unlocked): via the Windows Phone Store, and via a company hub app. The standard mechanism is via the Windows Phone Store. For developers, the portal to the Windows Phone Store is called the Windows Phone Dev Center, which you can access by going to http://dev.windowsphone.com. When you submit your app to the Windows Phone Store, it goes through multiple stages, and you can track the progress of the submission through eight reported stages on your dashboard, as indicated in Figure 3. The textual and graphical data you supply as part of your submission is validated up front when you submit it. Therefore, failures at any later stage will be the result of certification failures. If the submission does fail any of these tests, you need to resubmit your XAP and start the process again.

Figure 3. There are eight distinct stages in the publication process.

You can’t resubmit a XAP after it has already started going through testing. If you resubmit a XAP at any other time, this will obviously restart the certification process. There are other data changes which will also trigger recertification, including anything which requires re-evaluating your data for acceptable content, including the following:

When you’re ready to submit your app to the Windows Phone Store, you must log on to the Dev Center by using your Microsoft Account (formerly known as your Windows Live ID). On your dashboard, you’ll find a button to submit an app. If you’re continuing a previously saved submission, you can select the submission from the list on your dashboard, as shown in Figure 4.

Figure 4. You can select any of your published or in-progress app submissions from your dashboard.

The submission tool is mostly intuitive. There are two forms for required information (basic app info, your XAP and the Windows Phone Store images), and three further forms for optional information (in-app advertising, market selection and custom pricing, and map services tokens).

As you fill in the forms, you can save at any point. This gives you the opportunity to pause if you need to and go back to complete the submission later. Or, you can abandon the process at any point before final submission. If you need to, you can completely delete the submission. If you want to start again from scratch and use the same app alias, you can also delete the old entry for the app alias from your Dev Center dashboard. Everything remains editable and under your control until you click the Submit button.

The first page (see Figure 5) asks you to provide the following information:

Figure 5. The first page of the submission tool, on which you enter basic app info.

Figure 6 depicts the bottom half of the first page, on which you specify the market distribution and publishing details. For distribution, the default is to publish to all markets except those with stricter content rules. However, if you’re sure your app meets all certification requirements of all markets, you can specify distribution to all markets, instead. This relates to section 3 of the certification requirements, that covers formal certification for games as well as potentially offensive content for all apps. Your app must not contain any content that could be deemed offensive in any market you target for distribution. Content might be offensive in certain countries/regions because of local laws or cultural norms. Examples of potentially offensive content in certain countries/regions include, but are not limited to, the following:

Figure 6. You also specify market distribution and publishing details on the App Info page.

Note that the default is to publish your app automatically as soon as it passes certification. If you want to control when your app becomes public, you can specify that on this page. The final option on this page is for setting up an authenticated web service for sending push notifications .

On the second page, you upload your XAP and provide a Windows Phone Store description. When you upload your XAP, the Dev Center tool parses it to extract the supported operating system (OS) version, languages, resolutions, and capabilities, as illustrated in Figure 7. The XAP version number is an arbitrary value that you supply manually; this is not extracted from the XAP, and it need not be the same as the version in the app manifest (nor the assembly or file versions).

Figure 7. The Upload And Describe Your XAP page is where you upload your XAP.

A XAP can contain multiple languages. These are detected by the tool, and for each language you must then provide a description and keywords (see Figure 8). The description here is not the same as the description in the WMAppManifest.xaml (which is restricted to 255 characters). The Windows Phone Store description is limited to 2,000 characters. The keywords are arbitrary, but they should certainly reflect the topic or nature of your app. You can supply up to five, but you must supply at least one.

Figure 8. You must provide a description for each supported language.

Finally on this page, you upload the required artwork, which are exactly the same images you specified in the Store Test Kit: a 300×300 pixel Windows Phone Store icon and at least one screenshot for each supported resolution (these are always portrait even if your app runs only in landscape). You can also provide up to seven additional screenshots for each resolution. In addition, you can provide a 1000×800-pixel background image, which will be used if your app is designated as the feature app in the Windows Phone Store at any time. The bottom of the Upload page is depicted in Figure 9.

Figure 9. You upload the same images that you specified in the Store Test Kit.

Notice that the Upload page also includes two optional sections that are not immediately obvious. They’re over on the right side of the page, accessed via drop-down arrows (see Figure 10). Select the Technical Exception check box in case your app requires an exception to the certification approval process for technical reasons. You would not normally select this option, because doing so will slow down the approval process and approval could be withheld. There are very few scenarios for which you would need to apply for a technical exception; for example, if your app interacts with third-party hardware (perhaps a media streaming device or a Bluetooth accessory).

Figure 10. The Upload page includes two drop-down sections, which are optional.

The Certification Notes text box is where you can provide special testing instructions for the testing and certification of your application. You can use this if it is not clear from the UI. This is limited to 1,000 characters. If your app behaves in an unexpected way in any scenario, you should document it here so that the testers don’t fail it simply because they don’t understand how it’s supposed to work. This is also the right place to provide dummy credentials if your app requires an account for any operations. The second optional section (More Options Per Language) is where you can provide legal and privacy URLs and a support email address, on a per-language basis.

When you’re done filling in the submission form—assuming that you haven’t missed any required field—you are returned to your dashboard, where your new app will be listed as pending certification.

When you submit your app, it goes through both static validation and automated testing, to verify that it meets all the policies and requirements. If it passes certification, it is repackaged and signed before it is made available to the Windows Phone Store. The Windows Phone Application Certification Requirements are described at http://aka.ms/WinPhone8DevInternals/MSDN.

You can cancel a submission before or after it has been certified, but you cannot do anything to it while it is actually going through the certification process.