5. Beta testing
The Windows Phone Store supports a simple beta testing mode for
applications. When you first submit your app, you have the option to
make it available to only a selected set of users. You choose the users
by specifying their Microsoft Account email addresses in the submission
form. You can enter up to 10,000 users for beta testing (a huge
improvement over Windows Phone 7, for which you could only support 100
beta users). When you do this, the Dev Center sends you an email
containing the download link for your app, which you can then send to
your selected users. The Windows Phone Store hides the app from general
availability, making it visible for download to only those users whom
you selected. You need to handle test results from your beta users
directly; there is no Windows Phone Store mechanism to support feedback
in this scenario. There is a 90-day limit to the beta testing period,
and this is enforced by installing a 90-day license for the app on the
phone. After this time, your users will no longer be able to start the
app. You can add more test users at any time during this period. Be
aware also that there is no option to terminate your test period before
the 90-day period has expired. Users who have installed the app will be
able to use it up to the end of the 90-day period. However, you can
delete the app from the Windows Phone Store, so that it is no longer
available to any designated beta users who happen not to have installed
it yet.
Submitting an app for beta distribution is free, and it does not
count against your allowed number of app submissions. You cannot attach
a price to a beta app. Anyone with a Windows phone (and a Microsoft
Account) can be a beta tester, and he does not need to have a
developer-unlocked device. The process is also fast because the app
does not go through the full set of certification tests and generally
becomes available to your beta testers within hours of submitting it to
the program.
There is no special “beta-to-release” upgrade path, so when your
beta test is complete, you need to submit a fresh, full submission to
publish your app in the normal way. It might also be worth pointing out
to users that any data that they create within the app during beta
testing will be lost when the final app is published.
Apart
from fixing bugs, improving the UI, providing fresher data, and adding
features, the other main reason for updating is to take advantage of
new features in the latest version of the platform and SDK. As of this
writing, this means updating from version 7.1 to 8.0. However, some
users will not have upgraded to version 8.0 devices. All version 7.0
and 7.1 apps will continue to work on version 8.0 devices, so if you’re
not adding new features, you could take the path of least resistance
and simply maintain your version 7.x app.
If you are adding new features, one option is to maintain both major
versions of your app in the Windows Phone Store. This means forking
your source code and applying bug fixes in two places, but it does mean
that users can continue to get the benefit of your updates, regardless
of which platform version they use.
You can maintain multiple versions on the Windows Phone Store and
submit updates to each one independently. You might want multiple XAP
versions to support different target markets, or for different screen
resolutions, or indeed for different device versions. Even though some
of the Windows Phone Store metadata for your app is shared across both
versions, most of it is independent. Specifically, the XAP itself, the
catalog details (descriptions and screenshots), pricing and regional
availability, the version number the published/unpublished status, and
the hidden/live status are all independent per version. This means the
version number of your 7.1 version doesn’t need to be the same as the
version number for your 8.0 version. You might submit, for example,
four version updates for your 7.1 version, and only two version updates
for your 8.0 version, and so on, as shown in Figure 14.
One reason to publish an update for an old version 7.1 app is to
enable a “light-up” scenario; that is, to take advantage of version 8.0
features if the app is running on Windows Phone 8.0. To be clear, this
strategy is not the same as publishing an 8.0 version of your version
7.1 app. Rather, it means publishing a version 7.1 update to a 7.1
version app, but including version 8.0 features.
