Chapter 16. Deploying apps to beta testers and the stores

This chapter covers

  • Using App Center to distribute apps to beta testers
  • Publishing Android apps to the Google Play Store
  • Publishing iOS apps to the iOS App Store

In the previous chapter you added some final release prep to your app—you turned on analytics and crash reporting, set up builds in App Center, and ran some UI tests on a range of devices in the cloud. You’re finally ready to put your app into the hands of your users, starting with beta test users and then finally releasing to the stores.

In this chapter you’ll see how to use App Center to distribute your apps to beta testers, including automatically updating these installs whenever you push out a new release. We’ll then follow up by looking at how you can actually release your apps to the stores, including what information you need to provide with your apps. As in the previous chapters, we’ll only be focusing on Countr here. We’ll also be looking at one OS at a time, starting with Android.

16.1. Distributing Android apps to beta testers

Before you think about a final, production release of your app to the app stores, it’s worth putting it in the hands of some beta testers first. This way you can get real-world feedback, address usability issues, and find and fix bugs. If you just put it out to the stores immediately, you’d risk bad reviews. It would be a shame for your app to fail because of one-star reviews that could have easily been avoided with a little beta testing. Ideally you want to allow beta test users to play with your app as soon as possible, even before the app is finished—the quicker you get feedback, the sooner you can change your app.

Visual Studio App Center makes it easy to distribute apps to beta testers. From App Center you can register test users via email and notify them every time a new build is ready. You can even set your app to check for updates every time it’s launched, and, if an update is available, to automatically update itself.

16.1.1. Enabling app distribution

Enabling app distribution is incredibly easy on Android. You set up the users you want to test your app, and they make a small settings tweak on their devices. Then you either automatically distribute your app on every build, or distribute manually whenever you want to release an update.

Registering users

App Center has the concept of collaborators—people who are collaborating on your app or are part of your organization in various capacities. Each app collaborator is registered by an email address and has one of three possible roles:

  • Manager— This role has complete control over an app, including managing all settings, adding collaborators, and configuring services like testing, distribution, and analytics.
  • Developer— Developers can create builds against branches and run them, or run UI tests.
  • Viewer— This role is for app users only—they can see and download builds. This is the role you need for your beta testers.

To create a collaborator, head to the Settings tab for your Android app inside App Center, click the Edit button in the Collaborators section (it looks like a pencil), and then add your collaborators’ email addresses (figure 16.1). For beta test users, you’ll set the role to be Viewer.

Figure 16.1. You add and configure app collaborators from the Settings tab.

Once you assign a collaborator, they’ll receive an email inviting them to collaborate on your app. They’ll need to click the Accept Invitation link in the email, which will open a web page where they can accept the invitation and create an App Center account if they don’t already have one (using a username and password, or by connecting via Facebook, Google, GitHub, or a Microsoft account).

Once they’ve accepted the invitation and created an account, there’s one last thing they’ll need to do—allow apps from unknown sources. Although Android has minimal security, later versions will by default block the installation of apps from outside of the Google Play store. This block is easy to turn off from the Settings app—head to Personal > Security, and then under Device Administration turn on the Unknown Sources option (figure 16.2). Be aware that some device manufacturers like to tweak the Settings app, so this option may be in a different place in the settings.

Figure 16.2. Allow apps to be installed from unknown sources.

Be warned, turning the Unknown Sources setting on allows apps to be installed from any unknown source—both your apps from App Center and more nefarious apps from other places. The user will still need to explicitly tap an Install button to install an app, but less technically savvy users may need a bit of security training before turning this option on.

Creating distribution groups

App Center allows you to group and manage collaborators by adding them to distribution groups, which are named groups of collaborators. These distribution groups allow you to distribute different builds to different people. For example, you could have a QA group that gets every build of your app for thorough testing and a Beta Testers group that only gets manually distributed builds at major milestones. Collaborators on your app can belong to multiple groups. When you create users, they are all by default added to a distribution group called Collaborators that’s created for you when you first create your app.

You can manage these groups by selecting Distribute > Groups from your app in App Center. To add a new distribution group, click the New Group button at the top right, enter a group name, and enter the collaborators to add to the group, as shown in figure 16.3. You can start entering the names of users who are already set up for your app, and you’ll see an autocomplete box with their details that you can select from. Or you can enter an email address to add new users, and they’ll be invited to sign up with App Center and become a collaborator.

Figure 16.3. Add distribution groups to allow you to distribute different builds of your app to different users.

Distributing builds

Once you have your collaborators, you can distribute your app to them in one of two ways: automatic distribution on every build, or manual distribution.

Automatic distribution is the simplest way to provide updated builds. Every time your app is built (either manually or by pushing code to a branch set up to build on every push), your users get notified about it and can install or update your app. This is great for pushing bug fixes and new functionality to your test group. It also ensures that your app builds successfully inside App Center, including passing a launch test, before it’s distributed.

To turn automatic distribution on, head to the Build tab for your Android app, select the master branch, click the spanner button to configure the branch, scroll to the bottom, and check the Distribute Builds option (figure 16.4). If you’ve set up multiple distribution groups, you’ll be able to select one of those groups here, and the app will only be automatically distributed to the group you select. This defaults to the Collaborators group.

Figure 16.4. Distribution can be configured on each branch.

Once you click Done, your branch will be built and an email will be sent to all collaborators in the selected distribution groups, letting them know there’s a new version of your app available. They’ll need to open this email on their Android device and follow the link provided to install your app. This is shown in figure 16.5

Figure 16.5. After each build, users will get an email with a link to download and install your app from App Center.

Once users receive the email, they can tap the Install button on the email which will take them to a web page inside App Center where they can download your app. This page shows some details about the version they’re installing, such as the version number and release notes, and it has a Download button that downloads the APK to their device. Once it’s downloaded, they’ll be able to open the downloaded APK to install it.

To manually distribute an APK, you’ll need to build it yourself and then upload it to App Center for distribution to your users. Although this is less convenient than the automatic distribution, it does give you more control over your releases. For example, if one user has a particular issue on their device, you could create a new distribution group just for that one user, create a possible fix or add more logging to your local source code, create a local build, and manually distribute it just to the affected user. If your code changes fix their issue, you can then push them to your source code repo and redistribute to everyone.

To manually deploy your app, create an archive signed with your app’s keystore—we looked at the process for doing this back in chapter 13. Once you have your APK, select Distribute > Releases inside App Center and then click the Distribute New Release button at the top right. A panel will slide out (figure 16.6) with a number of steps you can follow to distribute your app. Start by clicking the Upload APK button and select your APK, or drag and drop your APK file over the button. Your APK will then be uploaded, which may take a while depending on the speed of your internet connection. Once your release is uploaded, click the Next button.

Figure 16.6. To distribute your app manually, you start by uploading the APK.

In the next panel, you can optionally add release notes describing your changes. In the third panel, you choose which distribution group to send the release to. Clicking Distribute in the final panel will distribute your release. All the users in your distribution group will receive an email with a link to download the new release, in the same way as with automatic releases.

Managing releases

The Releases section of the Distribute tab also allows you to manage your releases. From here you can see all the releases of your app, with details against each including the APK size, version number, and which distribution group it went to (figure 16.7).

Figure 16.7. Manage releases from the Releases section of the Distribute tab.

You can also use this tab to download releases, which is useful if you deleted the email with the app link, if you want to install an older version for upgrade testing (to make sure you have no data loss when upgrading from an older version of your app to a newer one), if you want to install on a device that doesn’t have email set up on it, or if you want to get someone outside of the release’s distribution group to install that release. If you don’t want anyone installing a particular release you can also delete it.

16.1.2. Auto updates

It’s pretty good to notify users with an email and have them click a couple of links to download an update. But what would be much better is if your app were able to detect that an update was available and could allow users to update from inside the app. Happily for us, this is something that App Center supports, and it’s really easy to implement.

To make auto updates work, enable this feature inside your app. Open the Countr solution and add the Microsoft.AppCenter.Distribute NuGet package to the Countr.Droid app. Then enable it by adding distribution to the call to AppCenter.Start in the splash screen. Open SplashScreen.cs and add the following code.

Listing 16.1. Adding App Center distribution to Countr.Droid 
using Microsoft.AppCenter.Distribute;
...
protected override void OnCreate(Android.OS.Bundle bundle)
{
   base.OnCreate(bundle);


   AppCenter.Start("<your app secret>",
                   typeof(Analytics),
                   typeof(Crashes),
                   typeof(Distribute));          1
}

  • 1 Adds distribution to the App Center startup

This tells App Center that as well as supporting analytics and crash reporting, you also want to support auto updates. As you’d expect, your users will need to install this version first before they can auto update—just adding this code to the latest builds won’t auto update any earlier builds that don’t have this turned on. In-app updates also only work for Release configuration builds, not Debug builds. Commit the changes enabling distribution to your source code control so that your app builds, and install this version on your device using App Center.

Once your app starts up for the first time after enabling in-app updates, it will need to quickly connect to App Center to register the installation (figure 16.8). Your app will launch, then switch to a web browser, then back to your app.

Figure 16.8. When you launch your app for the first time, it will connect to App Center to enable in-app updates.

Once distribution has been enabled, the app will check on every startup to see if an update is available, and if there is one, it will tell the user and prompt them to install the update. What defines whether an update is available? Just running another build with the same or updated source code isn’t enough; instead you need to increment the version number. Back in chapter 6 you saw that Android defines two versions: a version number (or code) and a version name. The version name is your internal way of representing the version as a string; here the version number is what we’re interested in. This is a numerical value that’s used to tell Android, App Center, and (as you’ll see later) the Play store that there’s an update to the app.

Every time you want an update to be made available to users, you need to increment this version number. For now you can manually increment it inside the application manifest. App Center does offer a way to auto increment this as part of your builds, but that’s outside the scope of this book.

To see this in action, you’ll need to update the version number. You can do this in Visual Studio for Mac by double-clicking the AndroidManifest.xml file in the Properties folder and incrementing the Version Number field in the manifest editor (figure 16.9). In Visual Studio on Windows, right-click on the Countr.Droid project file, select Properties, select the Android Manifest tab, and increment the Version Number. If you prefer editing XML files manually, it’s the android:versionCode attribute on the manifest node that you need to increment. It doesn’t matter how much you increment this value—all that matters is that the new value is higher. Once you’ve updated the version, commit the change and push it to your source code repository. App Center will then build your changes and make the update available.

Figure 16.9. To indicate that a new version of your Android app is available, increment the version number in the manifest.

Once the code has been built, restart your app on your Android device. Update checks are only run when your app starts up from being terminated, not when it is restored to the foreground, so you may need to explicitly kill your app before relaunching it. This check will connect to App Center and check for an updated version, and when it finds one a dialog will be shown asking if you want to download the update now or delay for a day (figure 16.10). Tap Download and the app update will download in the background. Once the app has downloaded, a dialog will pop up to install it, so tap Install and your app will be updated.

Figure 16.10. Upon launching your app after an update has been distributed, you’ll be asked if you want to update.

16.2. Publishing Android apps on the Google Play store

Once you’ve sent your app to your beta testers, they’ve given feedback, and you’ve used this feedback to make your app ready for release, the next step is to publish your app to a store so users can download and install it. Google has an app store that’s baked into Android, called the Google Play store. You can publish your apps to this store, and any Android user will be able to open the store app on their device and discover and download your app. This store also manages updates, so if you release an updated version to the store, users will be able to easily install the update. Depending on their settings, your app may even be updated automatically with no user intervention required.

16.2.1. Setting up your account

Before you can publish to the Google Play store, you need to set up an account and pay a registration fee. Start by heading to http://play.google.com/apps/publish/ and then sign in with a valid Google account. You’ll then be presented with a few steps to work through to sign up for a developer account. These steps should be self explanatory, and I won’t go into details here as they do change on a regular basis and vary from country to country, and depending on whether you want to charge for your app. The main thing to be aware of is the fee—you’ll need to pay a U.S. $25 registration fee to create an account. The good news is that unlike Apple, this is a one-time charge, not a yearly fee. Once you’ve signed up, you’ll be logged into the Google Play console.

16.2.2. Creating your app

Once you have your account set up, the next step is to create your app. From the Google Play console, click the Publish an Android App on Google Play button (figure 16.11).

Figure 16.11. Click the Publish an Android App button to create a new app on the Play Store and then enter the app’s name.

The first step in publishing an app is giving it a name. Your name can be up to 50 characters in length and doesn’t have to be unique, although if you use the name of another app, you may run into problems. If you try to call your app Facebook, for example, you’ll probably be kicked off the store. Google also requires all names to be suitable for all store users of all ages, so if you use profanity or a title that’s not appropriate for all ages, your app will not make it to the store. Enter the app name you want to use into the Create Application dialog box and click Create.

Uploading your APK

Once you’ve created your app, upload your APK to the Play store. You can’t set your app’s content rating (the appropriate-age rating for your app) until you’ve uploaded an APK.

The first step is to download the APK from App Center. You can download the APK you want to publish by selecting the Build tab, clicking the master branch, selecting the most recent build, and clicking Download > Download Build.

Your app will share its analytics across development, beta testing, and the store

You’ll notice we’re using the same App Center app for development, beta testers, and the store. This means that crashes and app analytics that come from debugging the app will be mixed in with those from the beta testers and the final users who get the app from the store. This isn’t ideal. In a production app you’d set up multiple apps with different app secrets for development, beta testing, and production, and set these using compiler flags with multiple build configurations. That’s outside the scope of this book, but you can read more about build configurations in Jon Goldberger’s “Demystifying Build Configurations” article on Xamarin’s blog at http://mng.bz/40uO.

The second step is to upload the APK that was built by App Center to the Play store. From the Google Play console, select App Releases from the menu on the left. From the app releases page, you can manage alpha, beta, and production releases. We’re only going to create a production release, as we’ve used App Center to manage our beta already, so click the Manage Production button and then Create Release on the next page.

Google Play App Signing

Google recently added the ability to store and manage your keystores inside their developer console. By using this, you can upload your keystore to Google and have them manage your app signing for you. You download a new keystore that Google creates and use this to sign your apps for publishing to Google; then Google re-signs them with their stored keys. This topic is outside the scope of this book, but you can read more about it in Google’s documentation at http://mng.bz/RWTt.

You should now see a screen allowing you to configure a new production release. If you see an option to sign up for Google Play App Signing, click Not Now to continue. Click the Upload APK button and select the APK you downloaded from App Center. After the APK has been uploaded, click the Save Draft button.

Once your APK has been uploaded, you’ll see it appear in the APKs to Add section, showing the version code from the application manifest. You can also add a release name here—this is an internal name you can use to identify releases, and it defaults to the version name of your app. You can change this name to help track your releases, such as setting it to an internal code name for a particular release based on the features of that release, or to anything that makes sense to you. This name only appears in the Play console, not on the store. You can also add release notes detailing what’s new in this version—that’s not much use for the first version of your app, but as you add updates you can detail them here. Once you’ve filled this all in, click the Save button.

Setting the content rating

Every app published on the store needs to have a content rating. This defines the age your app is suitable for and it covers the content of your app, so consumers can decide if it’s appropriate for them. This content rating can also limit in which countries your app can be published—some local laws prohibit certain content.

To set your content rating, head to the Content Rating tab, and from here you can fill out a questionnaire that’ll be used to automatically set your content rating. Start by clicking the Continue button.

On the first page of the questionnaire, enter your email address and select the type of app you’re publishing. For Countr this is “Utilities, productivity, communication or other”. Work through the questions—the answers should all be No—and then click Save. Once it’s saved you can click Calculate Rating to calculate the rating for your app—this should be suitable for everyone. Once it’s calculated, click Apply Rating to set this rating for your app. When you finally publish your app, you’ll be emailed a content-rating certificate as part of Google’s app review process.

Adding product details

Once you’ve uploaded your APK, add a range of details about your app that will appear on the store listing. These include text descriptions of your app, screenshots, and information about what type of app you’ve submitted. Just like with the app’s name, this content will be available to everyone, so it needs to be suitable for all ages regardless of the app type. If you include a screenshot containing nudity, your app won’t be published (even if you’re publishing an adult content app or a medical/educational app). You can read Google’s policy on this content in the Google Play Developer Policy Center, at http://mng.bz/6Kn2.

Head to the Store Listing tab to enter this information. These fields are required:

  • Title— This is the app name you entered when creating your app—you can change it from here if you need to.
  • Short description— This is a single-line description of your app that’s used on the store as a tagline. This should be a short, snappy sentence to entice users into reading more about your app or installing it. It can be up to 80 characters.
  • Full description— This is where you can enter a more detailed description about your app, covering its features, how it can help users achieve their goals or solve their problems, or anything else that explains your app to your target audience. You can enter up to 4000 characters here.
  • Screenshots— You can attach screenshots to your store listing, either as JPEGs or PNGs. The minimum length of any side is 340 px, and the maximum is 3840 px. You have to attach at least two, and you can add phone screenshots or tablet screenshots. Although these images are called “screenshots,” you aren’t limited to screenshots. Some developers like to attach images containing screenshots with annotations around them, highlighting the features of their app. If you want to capture a screenshot from your device, you’ll need to determine the combination of keys that captures one—usually it’s pressing the volume-down button and the power button at the same time, but it varies from device to device. It can be a pain regenerating simple screenshots from your app for phones and tablets every time you prepare a release, so what some developers do is create UI tests that put the app in a state that looks good and then capture a screenshot. They can then run these tests in Test Cloud against a phone and a tablet and download the resulting images.
  • High res icon— This is a version of your app icon that’s shown on the store listing, so it needs to be larger than the icons that go with your app. It has a required size of 512 × 512 pixels. It also needs to be a PNG file. If you used MakeAppIcon back in chapter 10, you would have received a high res icon as part of the zip file you downloaded. If not, there’s one you can use in the source code that accompanies this book, called playstore-icon.png, in the ImagesCountrAppIconsAndroid folder.
  • Feature graphic— The feature graphic is a banner image that’s displayed across the top of the Play store listing. This needs to be 1024 × 500 pixels in size and should be something that highlights your app, such as cover art, an app and company logo, or a useful part of a screenshot.
  • Application type and category— Tell the Play store what type of app you’re submitting (an application or a game) and what category to put it under. This way your app will appear in the correct store listing. For Countr, the type would be Applications and the category would be Tools.
  • Contact details— Provide an email address that your users can use to contact you. This is publicly displayed, so be warned—you may get some spam! You can also provide your website and phone number if you need to provide support to your customers.
  • Privacy policy— Provide a privacy policy if you’re handling any user data, or you need to tick the box to say that you aren’t providing a privacy policy at this time. If your app does anything with users’ personal data, you have to provide a privacy policy—personal data includes anything that would allow the user to be identified, any financial information, health information, or contact details such as a phonebook.

This is your one chance to hook a user who has discovered your app on the store, so it’s worth putting a lot of effort into making this content very high quality, with well-chosen screenshots and well-written text. You can also provide translations of your content into different languages. You can manage translations from the Manage Translations drop-down, choosing to either manually upload translations or pay someone to do it for you.

Once you’ve added all the required information, click the Save button.

Pricing and distribution

The last step before you can publish your app is to set the price for your app and where and how it should be distributed. To do this, head to the Pricing & Distribution tab. We’ll be distributing a free app here, but if you want to charge for your app, you need to set up a merchant account first—contact your bank if you want to do this. By default your app will be set to free, so leave it like this for now.

There are a number of options you can set here, including various Google programs for families, education, Android TV, or Android Car, but those are outside the scope of our app. These are the fields you should set:

  • Countries— From here you can set the countries your app is available in. Which countries you choose is up to you—the more you choose, the more customers you can get, but this could lead to higher support requirements. Also, be aware that the local laws of each country are different, so you’ll need to ensure that your app is compliant with the law in all countries. Also, watch out for blocked services, such as Facebook being blocked in China—if your app needs Facebook, you should uncheck China in the Countries list. Countr should be fine everywhere in the world, so you can just select the Available radio button at the top of the country list to select everything.
  • Contains ads— Declare if your app has any ads in it. This information is shown on the Play store listing so users can decide before they download your app if they want to put up with ads or not. If your app has ads and you don’t declare it, you risk being kicked off the store.
  • Content guidelines— You must tick this box to declare that your app meets Google’s content guidelines, which are available at http://mng.bz/Var3. If you don’t follow these guidelines, your app will be kicked off the store.
  • U.S. export laws— Google hosts apps on servers in the United States, so when a user outside the United States downloads your app, it’s classed as exporting the software. This means you have to follow the U.S. export laws, especially in regard to encryption (including making web calls over HTTPS). You need to tick this box to say your app complies with all these laws. Google has more information about this at http://mng.bz/yDT3.
Publishing

Once you’ve provided all the required information, you’ll be able to publish your app to the store.

You should see Ready to Publish in the top banner on each page (figure 16.12). If you see a Why Can’t I Publish? button at the top right of the page, something hasn’t been set properly. You can click this button to see what to do to finalize your app for publication.

Figure 16.12. Once your app is ready to publish, the top banner will update to show this.

To publish your app, head to the App Releases tab and click the Edit Release button in the Production section. Click the Review button, verify the details, and then click the Start Rollout to Production button (figure 16.13) and confirm the dialog that’s displayed. Your app won’t be published immediately; instead it will be reviewed and analyzed by Google to ensure that everything is working and that you’re not doing anything dodgy inside your app. Most of the time this is automated, but Google may manually verify your app if it’s deemed necessary. With an app like Countr, it should pass review pretty swiftly, but if Google finds any problems, you’ll be contacted to help resolve them.

Figure 16.13. After reviewing your release, you can roll it out to the store.

It usually takes anything up to a few hours for the first release of an app to be approved (though it can be much less—I published Countr in about 30 minutes), with updates being approved more quickly. You won’t be notified when it’s published—only if there are problems—so keep checking back to see if it’s been successful. Once it has been published, you should be able to open the Google Play store app on any Android device and install the app (figure 16.14). Be warned, though, there are millions of apps on the store, so it may not be easy to find!

Figure 16.14. Once your app has been reviewed, it will appear on the Play store.

Congratulations! You’ve published your first Xamarin Android app to the Google Play store. Now is definitely the time to pat yourself on the back and celebrate a job well done. But for an app to be successful, there’s still more work to do. You need to monitor the analytics in App Center to see how and where your app is being used, and keep an eye out for crashes or bugs. If a bug is found, you’ll have to fix it and get an update out as soon as possible.

Google has tools for managing app rollouts

Google has a huge range of tools and capabilities to help you manage your app, including staged rollouts by country or random percentage of users, A/B testing to evaluate how well features are received, and management for paid apps, in-app purchases, or app subscriptions. You can read more on using the Google Play console to manage and publish your apps in Google’s Play Console Help, at http://mng.bz/w99p.

Reviews and ratings

Once your app has been released, users can download it, enjoy the fruits of your labor, and give you feedback via the Play store in the form of star ratings and reviews (figure 16.15). The higher the star rating, the more likely people are to download your app and the higher up the search results it will end up. Conversely, if your app has a low rating, people will avoid it. Reviews are also a great way to get detailed feedback—for example, if you get a 1-star rating with a comment about a bug, you can fix it and publish an update.

Figure 16.15. Ideally you want to aim for a 5-star rating to get more downloads.

You can monitor reviews from the User Feedback tab in the Play store console. From there you can see ratings broken down by time, app version, country, or other user details. You can also see reviews from users and reply to these, maybe providing support to a user who is having issues with your app, or notifying a user of a bug fix that has been published.

It might be tempting to try to get your rating up by getting people to give you fake ratings (or buying them—there are “click farms” where you can hire people to install and rate your app by the thousand), but if you get caught doing that your app might be kicked off the store, or worse, your developer account might be terminated. This could be a huge problem for an enterprise. If you can’t publish mobile apps, it could be the end of your business.

Publishing updates

At some point after your first release, you’ll probably want to update your app—to fix bugs or add new features. Once your app has been released to the store, all updates are managed by the store. App Center only provides automatic updates to builds that are distributed via App Center, so anyone who installs your app from the store won’t receive any updates unless you push them to the store.

Updates are pushed to the store by creating a new production release in the same way you created the initial release for your app. Once your app is published the Play store, the developer console changes, giving more options to manage your release. To upload a new APK, head to the Release Management section on the left side and select the App Releases tab as you did when uploading the APK the first time around. Work through the same steps as before, clicking Manage Production then Create Release, and uploading a new APK downloaded from App Center. It’s also worth updating the release notes to reflect what has changed. Personally, I feel it’s worth providing entertaining and detailed release notes—not the boring “Bug fixes and other improvements” that is usual for apps like Facebook. Once you upload a new APK, you can see which version will be superseded by the new version, and you can enter a new release name to track this new version.

You can only upload APKs that are for apps with the same package name and signed with the same keystore and a higher version code. If the package name of the new APK doesn’t match, or the version code is the same or lower, it will be rejected. The same is true if the keystore is different (which is why it’s vital to keep the keystore safe).

Once you’ve uploaded a new APK with an incremented version code, click Save and then Review. Review the release to make sure everything is in order and then click Start Rollout to Production. Once again, Google will analyze your app for compliance, and if everything is successful, the updated APK will be available on the store. Existing users will then be able to download and install your update.

16.2.3. Alternative stores

Although Google Play is the major app store for Android users, it’s not the only one—Android is an open OS, which means other stores can be set up to distribute apps. This is important for app developers, as it may make sense to publish your app to multiple stores, especially if you want to target the Chinese market.

At the time of writing, Google Play is not available in China, so if you want to make your app available to a Chinese audience, you’ll also need to publish it on at least one of a number of Chinese Android stores. These include Baidu App store (http://shouji.baidu.com/), Tencent App Gem (http://android.app.qq.com/), and Xiaomi App Store (http://app.xiaomi.com/). These stores are all in Chinese, so you’ll need access to Chinese translations of both your app and your product details to be successful. If your app accesses a backend, you’ll also need to verify that it’s available in China—some cloud services are blocked by the “Great Firewall,” including some of the big names such as Facebook and Google (but not Microsoft’s Azure). If your app relies on a Facebook login, you’ll either need to avoid rolling out to China or add a different login method.

Outside of China, the other big app store to be aware of is Amazon’s Appstore for Android—found by going to your local Amazon site and looking for “Appstore for Android” under the Departments menu, and this is available worldwide. If you want to publish your apps on this store, you can do so at https://developer.amazon.com.

Publishing to the Chinese and Amazon stores is outside the scope of this book.

16.3. Distributing iOS apps to beta testers

We’ve looked at Android, and now it’s time to look at iOS. Although the principles are the same as for Android, there is, as always, the fly in the ointment that is provisioning profiles.

16.3.1. Enabling app distribution

In the last chapter you set up a Debug build for your iOS app in App Center so that you could run the on-device launch tests, as well as run UI tests in Test Cloud. You also signed it with your development provisioning profile. This served your purposes then, but going forward you’ll need different build setups. You need to sign your app with different iOS provisioning profiles depending on where you want to distribute to, and create release builds so that you can enable auto updates.

You can set up distribution groups for your iOS app the same way as previously described for Android. The process for setting up distribution groups in App Center is identical. The only difference is that you need to get a bit more information from your iOS beta test users so that you can create provisioning profiles that include their devices.

Provisioning iOS users

Back in chapter 13 you created a development provisioning profile for your device. This profile was linked to the device UDID (the unique identifier for your device that’s set by iOS) and it allowed you to run your app through a debugger on the device. To distribute your app, we need one of two other types of provisioning profile:

  • Ad hoc— Ad hoc provisioning profiles are used for distributing to beta testers. Just like with development profiles, these are tied to a specific set of device UDIDs and have the same rules about the number of registered devices—a limit of 100 of each type per membership year. When your app is signed with an ad hoc profile, you can install it on any of the registered devices using distribution tools like App Center, Apple’s TestFlight, or iTunes. Unlike with Android, there’s no need to turn on any permissions to allow users to run your apps. Instead, permissions are enabled via the ad hoc provisioning profile.
  • App Store— App Store provisioning profiles are used to sign your app for distribution via the store. Apps signed with this profile can run on any compatible device with no limitations, except that you can only distribute these apps via the App Store.
Apple also has enterprise provisioning profiles

Apple has an enterprise developer program for large organizations, where you can build apps and provision them for distribution just to a limited number of in-house users, not to the store. This allows you to build internal apps that only work for your users and don’t require the full Apple release process or public store distribution. You can read more about this in Apple’s Developer library at https://developer.apple.com/programs/enterprise/.

Before you can create these provisioning profiles, you need to create a new certificate—in chapter 13 you created a developer certificate, but for ad hoc and store profiles you require a distribution certificate. You can create one in the same way as the developer certificate, using the Apple Developer portal or Fastlane from inside Visual Studio for Mac, but instead of selecting iOS App Development for the certificate type, select App Store and Ad Hoc from the Apple Developer portal, or iOS Distribution from Visual Studio for Mac. Once you have the certificate in your keychain, export it as a .p12 file because you’ll need to upload this to App Center later on.

To distribute your app to beta test users, you’ll need an ad hoc provisioning profile set up using the UDIDs of all your beta test users’ devices. This is where iOS becomes a pain—every time you sign up a new beta test user, you need to get the UDID of their device. You can find it in a number of different ways:

  • From Xcode— If the device owner has Xcode installed, they can launch it with the device connected, select Window > Devices, and select their device in the left pane. The device UDID will be shown as the identifier on the right, as shown in figure 16.16.
    Figure 16.16. You can get device UDIDs from the Devices window in Xcode.

  • From iTunes— This is the only way to get the UDID on Windows, and it also works on macOS. Plug the device in, select the device in iTunes, and select the Summary tab. You’ll see a serial number on the right, and if you click the serial number it will change to show the UDID (figure 16.17).
    Figure 16.17. You can get device UDIDs from the Device window in iTunes.

  • From the macOS terminal— If your device is plugged in to your Mac, you can get its details using the Instruments app from the terminal. Launch the terminal and run instruments -s devices. This will show a list of all connected devices, both physical and simulators, with their UDIDs (figure 16.18).
    Figure 16.18. You can get device UDIDs from the macOS terminal using Instruments.

Once you have the UDIDs of your beta testers, enter them into the Devices section of the Apple Developer site, as you did in chapter 13.

Now that you have a certificate and the beta test devices registered, you can create the profiles. Create a new profile as before, but instead of selecting iOS App Development, select Ad Hoc, select your app ID, select the new distribution certificate, check all the devices you want your profile to support, and name it something like Beta test. Once it’s created, download a copy of it so you can upload it to App Center later.

Setting up the ad hoc build

The next thing to do is to set up an ad hoc build to distribute to beta testers. From your iOS app in App Center, select the Build tab, select the master branch, and open the Configure Build panel by clicking the spanner button at the top right.

We’ll be reusing the same branch for all builds

As discussed earlier for Android, we’re going to use the same branch for development, beta test, and store builds. In a production app, you’d ideally set up multiple apps, each with a different provisioning profile, and set the app secrets in different builds using compiler flags.

Configure this branch to build the Countr.sln solution using a release configuration, select Device Build and Build This Branch on Every Push, and then upload the provisioning profile you created for ad hoc distribution and the distribution certificate .p12 file you exported. Make sure the Test on a Real Device setting is unchecked (you can’t test release builds on real devices), and check the Distribute Builds option, selecting the distribution group you want your app to be distributed to. Click Save, and this will save the configuration and start a build.

Once the build completes, an email will be sent out to all collaborators in the selected distribution group with a link to install the app, just as for your Android builds.

The steps for installing the app are a bit different than Android. Before you install the app for the first time, install an App Center provisioning profile to allow installs of apps from App Center—this is part of Apple’s strict security (figure 16.19). Once you click the See Details button in the email, you’ll be guided through the steps. The first page tells you that you need to install the profile and gives instructions about what to do. Tap Install, and you’ll be redirected to the Settings app on the device, where you can install the profile (you’ll need to enter your passcode to approve the install). You only need to do this the first time you install any app from App Center on a device.

Figure 16.19. Before you can install a beta build from App Center, install the App Center distribution profile.

Once this profile is installed, you’ll see the same install page as you did for Android. Tap the Install button, tap Install in the dialog that pops up, and the app will be installed. You’ll see it appear on the iOS home screen. This is shown in figure 16.20.

Figure 16.20. Once the App Center profile is installed, you can install the app on your device.

16.3.2. Auto updates

iOS apps support automatic updates in the same way as Android apps, although the setup is a bit more complicated. Start by adding the Microsoft.AppCenter.Distribute NuGet package to the Countr.iOS app. Then enable distribution inside AppDelegate .cs by making the changes shown in the following listing.

Listing 16.2. Adding App Center distribution to Countr.iOS 
using Microsoft.AppCenter.Distribute;
...
public override bool FinishedLaunching(UIApplication app,
                                       NSDictionary options)
{
    AppCenter.Start("<your app secret>",
                    typeof(Analytics),
                    typeof(Crashes),
                    typeof(Distribute));            1
   ...
}

  • 1 Adds distribution to the App Center startup

Once that’s done, make a change to the info.plist file to tell your app how to open the App Center updater. Open info.plist and switch to the Advanced tab. Click Add URL Type under the URL Types section, and enter appcenter-<your app secret> into the URL Schemes field, where <your app secret> is your app secret from App Center (figure 16.21).

Figure 16.21. Adding the App Center URL schema to the info.plist

Once you’ve made this change, check your code in and push it to your repository to trigger a build. Install this build on your device, and launch it. The first time your app starts, it will open a web page to enable in-app updates, just like the Android version, and then return to your app (figure 16.22).

Figure 16.22. The first time your app starts, it will enable in-app updates.

Just like with Android, iOS apps need to have their version numbers incremented so that App Center can detect an update. The version number is defined in the info.plist file and is made up of multiple parts—a version and a build (figure 16.23). The version is a three-part code in the format of major.minor.revision, and the build is a single-integer build number for a particular version. An update is defined as one of the following:

  • The same version but a higher build number
  • A higher version with any build number (higher or lower)
Figure 16.23. For your app to detect an update, either the build or version needs to be incremented.

If you keep the version number the same, increment the build number; if you increment the version number, you can increment or reset the build number if you want. This means if you’re updating version 1.0 build 1, you can either use 1.1 build 1 or 1.0 build 2.

To test auto updates, increment one of these fields and push your changes to your source code provider. Once the app is built, restart the app on your device and you’ll be prompted to install the update (figure 16.24). Tap Update Now and your app will be terminated, the new version downloaded and installed.

Figure 16.24. When you launch your app after an update is available, you’ll be prompted to install the update.

16.4. Publishing iOS apps on the Apple App store

Now that you’ve beta tested your app, it’s time to upload it to the store. All iOS apps are distributed using the iOS App Store. Unlike Android there are no other stores available.

16.4.1. Provisioning your app for publishing

Before you can publish to the App Store, you need an explicit App ID for your app. Back in chapter 13 you created a wildcard App ID that you could use from any app, but for the store you need an explicit one that’s only used by a single app. From the Apple Developer site, select the App Ids tab, click the plus button, and create a new explicit app ID using the same prefix that you used for your wildcard ID, but ending in Countr instead of *. For example, I would use io.jimbobbennett.Countr.

To publish your app to the store, you need an App Store provisioning profile. Create and download one in the Apple Developer site, signed using the distribution certificate you created for an ad hoc profile and using the new explicit App ID. You won’t need to specify any device UDIDs for this profile—it will allow any device to run your app, providing it’s distributed using the App Store.

The next step is to set up the build in App Center using your App Store provisioning profile and distribution certificate. Ensure the Test on a Real Device and Distribute Builds settings are both turned off. Save this and wait for the build to finish. Once it’s finished, click the Download button and select Download Build to download the app’s IPA.

16.4.2. Setting up your app

Setting up apps for release to the iOS App Store is similar to doing so for the Google Play store—you need to create an app, set up some metadata, upload a binary, and await approval.

iTunes Connect

iOS apps aren’t configured using the Apple Developer site. Instead they’re set up in iTunes Connect. This is the Apple portal for configuring apps available on Apple’s stores—covering iOS, tvOS, and macOS. You can access it at https://itunesconnect.apple.com, logging in with your Apple ID (figure 16.25).

Figure 16.25. iTunes Connect is used to manage all apps released to the Apple App Stores.

Click the My Apps button, click the plus button, and select New App to add a new iOS app.

In the dialog that pops up (shown in figure 16.26), select the iOS platform and enter the app name that you want to appear on the App Store (this is limited to 50 characters). This app name has to be unique across all the millions of apps on the store, so you’ll need to be creative with the name. For example, Countr is already taken, and there are a number of apps with names starting with Countr, so I’ve used the name Countr - Count anything.

Figure 16.26. To create a new app, enter the name and bundle ID.

After entering the name, select the primary language of your app. Then select the bundle ID for your app, using the explicit App ID you set up in the Apple Developer site. This must match the bundle ID in your info.plist file or you won’t be able to upload your IPA. Finally, enter a SKU—a unique identifier for your app, such as a code name for your current release. This is an internal identifier and won’t be shown on the App Store.

Once all this information is entered, click Create.

Wildcard App ID won’t work

You can select a wildcard App ID here, such as com.mycompany.*, but if you do, it will ask for a suffix and create this as an explicit App ID automatically. This means that if your App Store provisioning profile was signed using a wildcard App ID, it won’t match this app, and you won’t be able to upload the app.

Once your app is created, you’ll see the app management screen where you can configure the store listing and app versions. App management in iTunes Connect is broken down into two parts: general app settings, including app information and pricing, and version settings against different versions of your app. As with the Google Play store, all the metadata and images you add to your app must be suitable for all audiences, or your app will be rejected. Before we set this all up, let’s upload the IPA.

Uploading the IPA

Unfortunately, for iOS apps, you can’t upload your IPA using iTunes Connect. Instead you need to use a tool on your Mac called Application Loader that comes as part of Xcode. You can launch this either by finding it using Spotlight (it’s buried inside the Xcode package, not easily accessible from the Application folder) or by launching Xcode and selecting Xcode > Open Developer Tool > Application Loader. Once it loads up, log in with your Apple ID.

From Application Loader, select Deliver Your App (figure 16.27), click Choose, and then select the IPA you downloaded from App Center. Application Loader will check iTunes Connect for an app that matches the bundle ID and will show a screen with the details of your app. Click Next, and Application Loader will connect to iTunes Connect, validate your IPA, and upload it. This may take a few minutes because it does some static code analysis on your app to make sure you aren’t using any private APIs or doing anything you shouldn’t.

Figure 16.27. Application Loader is used to upload IPAs to Apple.

Once your app has been uploaded, it will be analyzed in more depth by Apple, and if any issues are found you’ll be emailed about them. This analysis will take about half an hour. Once your app is ready, you’ll receive an email letting you know it’s finished processing.

You may get a warning about push notifications

Once your app has been submitted in Application Loader, you may get an email warning you that your app registers with the push notification service but doesn’t include entitlements for push. Countr doesn’t use push notifications, so we haven’t set them up, but the App Center SDK includes push-notification code. You can ignore this warning.

Once your app has been uploaded, head back to iTunes Connect to finish setting it up.

App information

The first thing to set up is the app information, and you can access this from the App Information tab on the left side of iTunes Connect. In this tab you can set up some basic information about your app. These are the required fields:

  • Subtitle— This is a short description of your app that’s used on the store as a tagline. This should be a short, snappy subtitle to entice users into reading more about your app or installing it. It can be up to 30 characters and is only shown on the App Store on devices running iOS 11.
  • Privacy Policy— If your app does anything with users’ personal data, you have to provide a privacy policy. Personal data includes anything that would allow the user to be identified, such as account registration, any financial information, health information, or contact details such as a phonebook. You can leave this blank for Countr—we don’t collect any information.
  • Category— You can set a primary and (optionally) a secondary category to categorize your app correctly on the App Store. The primary category for Countr would be Utilities, and if you wanted to set a secondary category you could use Productivity.
Pricing and availability

From the Pricing and Availability tab you can set a price for your app and which countries it’s available in. Set the price to be free—it will be labeled as 0 in your local currency (for example, for me it’s NZD 0). Once you’ve set a price, your app will default to being available in all countries. You can leave this as is or click the Edit button to choose a limited set of countries to release your app to.

Paid apps require different contracts

If you want to charge for your app, you’ll need to sign a paid developer agreement. When you signed up for the Apple Developer program, you will have signed a free app agreement, so to charge for your app you’ll need to head to the first page of iTunes Connect and access the Agreements, Tax, and Banking section to sign the relevant agreement and set up your merchant account.

App versions

Once you’ve set the app information and pricing, the next stage is to set up a new version of your app. Each time you want to release your app, you create a new version, configure any metadata to go out with the version, submit it for review, and then publish it. Versions are numbered and usually tie up with the version information inside your app’s info.plist file. Each new version should have a higher version number, and if you have to submit multiple builds for a version (for example, if Apple finds a bug in your app) then you increment the build, leaving the version the same, and push up a new IPA.

When your app was created, an initial 1.0 version was created, and you can see this on the left side of iTunes Connect. If you click on this version, you can set up its metadata, attach a build to it, and submit it for review. This is the required metadata:

  • Screenshots— You need at least one screenshot from the largest devices of each form factor, so a 5.5″ device if your app supports iPhones, and a 12.9″ device if your app supports iPads. The easiest way to generate these is either using the simulator or Test Cloud, run on an iPhone 7 Plus and an iPad Pro. You can add other screen sizes if you want to, but if you don’t, the larger ones will be scaled down.
  • Description— This is where you can enter a more detailed description about your app, covering its features, how it can help your users achieve their goals or solve their problems, and anything else required to explain your app to your target audience. You can enter up to 4000 characters here.
  • Keywords— Keywords are used to help people search for your app. This is a comma-separated list of words or phrases relevant to your app and that will help people find it. For example, you could enter count, counter, track as the keywords, and your app would be shown to people searching using any of those three words. How high up the ranking it will be displayed depends on the popularity of your app, how good the reviews are, or if Apple likes you. You can use up to 100 characters here.
  • Support URL— This is a link to a website providing support for your app. You have to provide this URL, but Apple is pretty flexible about what the URL points to, as long as the URL provides ways to contact you. For example, you could use your Twitter account URL or a Facebook page. I use the URL of my blog, because there are links on there to contact me.
  • Build— You can upload as many IPAs as you like using Application Loader. From the Build section you can select which build you want to publish with your release. Click Select a Build Before You Submit Your App, select the appropriate build from the popup, and click Done.
  • App Icon— This is the large app icon that will be shown on the App Store for your app, and it needs to be a PNG or JPEG at a resolution of 1024 × 1024 pixels. If you used MakeAppIcon to generate your app icon, it will have generated an app icon for the store along with the rest of the icons, called iTunesArtwork@ 2x.png, so upload this file. You can also find it in the source code that accompanies this book in the ImagesCountrAppIconsiOS folder.
  • Version— This is the public version of your app, and for a first app this will default to 1.0. You should change this to match the version number you set inside your info.plist file to make it easier to track app releases.
  • Rating— Specify a content rating for your app to ensure it’s only made available to the right audience. To set the rating, click the Edit button next to the Rating section and fill in the questionnaire. Countr is suitable for everyone, so you should be able to select None for all categories.
  • Copyright— Enter a copyright message for your app, such as 2017 - My Company. You don’t need to add the copyright symbol at the start.
  • App Review Information— Provide additional information to assist Apple with its reviews. This includes contact information, such as your name, phone number, and email. You can also provide a dummy account for Apple to use if your app requires a sign-in, and by default they tick the “Sign-in required” box, so untick this because Countr doesn’t need any user sign-in.
  • Version Release— Once you’ve set up your app, you submit it for review, and once it’s approved it can be published to the store. You can choose how this publishing happens: whether it should happen automatically, as soon as the app is approved; happen automatically after a given date; or require a manual publish. You can set this choice here—the default is to automatically publish as soon as it’s approved. You’ll normally want to publish immediately unless you have a marketing campaign or release event lined up.

By default, all the content you provide here is in the language you selected as the primary language for your app. You can provide different language versions using the language drop-down at the top right of the Version page.

Once all this metadata is set up, click the Save button, and then click the Submit for Review button at the top right. You’ll then need to answer three questions:

  • Export Compliance— This is to check to see if your app uses any form of encryption. Select No here for this example, as Countr doesn’t use any form of encryption, but if you’re publishing an app that does use encryption for anything, you’ll need to select Yes and answer further questions because the United States has restrictions on the export of encryption. Note that if you make any web calls using HTTPS, you’ll need to select Yes, as HTTPS uses encryption. You can read more about this in the iTunes Connect “Resources and Help” at http://mng.bz/brT6.
  • Content Rights— This is to verify that your app doesn’t display any third-party content, and if it does, that you have the relevant permissions to do so. Countr doesn’t use any third-party content, so you can select No.
  • Advertising Identifier— iOS provides a unique identifier for each device, used for advertisement tracking. Countr doesn’t show any ads, so select No this time, but if you use this for ad tracking you must answer Yes or your app will be rejected and you’ll need to submit a new IPA and start again. Apple will scan your IPA for usage of the API that provides this.

Once you’ve answered these questions, click Submit. Your version will then move to “Waiting for review” and be reviewed by Apple. You should also get an email confirming this. Most apps are reviewed within 48 hours, so it may take a few days to get approved. If your app is rejected, you’ll be told why (and be given a link to the relevant section of their app guidelines), and you can then make any changes that Apple suggests and resubmit your app. The approval process is varied, as real people are involved—you can have one person approve your app, then push up a bug fix before publishing, and have another reject your app for something that was there when the first person approved the app. Apple’s decision is final, though, so it’s very hard to fight them on anything. You can read the guidelines at http://mng.bz/525T.

You can update your app metadata while it’s waiting for review, but not once it is in review. You also can’t change the IPA. If you need to upload a new IPA, remove the app from review using the link that will appear at the top of the app version page, upload a new binary, and then resubmit for review.

Apple is really good at keeping you updated—you’ll get emails as your app moves through the different states, such as when someone starts the review and when it’s approved. You can also install the iTunes Connect app from the iOS App Store, called Connect, that allows you to manage your releases (figure 16.28). Through this app, Apple will send you push notifications when the states change. The different states are shown in table 16.1.

Figure 16.28. Apple is great at updating you about the progress of approving your app. There’s even an app to manage it, called Connect.

Table 16.1. The different states for your app in iTunes Connect

State

Description
Prepare for Submission This is the state all new versions start in.
Waiting for Review Your app has been submitted for review and is waiting for someone at Apple to start the review. You can change any of the app metadata at this point, but if you want to upload a new IPA, remove your app from review.
In Review Someone at Apple is currently reviewing your app.
Rejected Your app has been rejected by Apple. There will be a link on the version page to the resolution center where you can see the issue and reply to the reviewer.
Pending Agreement Your app can be approved before you’ve signed the relevant contracts—for example, if your app isn’t free and you haven’t signed the paid apps agreement. You can find the agreements to sign in the Agreements, Tax, and Banking section available from the iTunes Connect front page.
Ready for Sale Your app has been released to the store and is available for download.

Once your app has been approved, it should be published automatically, assuming you left the version release option set to Automatically Release This Version. If you need to manually release, select the version from the list on the left side of iTunes Connect and click the Make App Available button at the top right—this button will have replaced the Submit for Review button.

Congratulations—you’ve now published your Xamarin app to the iOS App Store (figure 16.29) as well as the Google Play store! A cross-platform job well done. You may struggle to find your app on the App Store to begin with—the iOS App Store takes a while to publish your app globally and index it for searching, and even links from inside Apple’s Connect app may fail for a while. Be patient, it should show after an hour or so.

Figure 16.29. The Countr listing on the iOS App Store

Store distribution is hard

It’s a lot of work with a number of manual steps to distribute to the Apple App Store. To make your life easier, a lot of this process can be automated using Fastlane. You’ve already used Fastlane to generate provisioning profiles from Visual Studio for Mac, but it can do a whole lot more than just profiles. Head to https://fastlane.tools to learn more, or check out the Xamarin University video about Fastlane at http://mng.bz/e1i0.

Reviews and ratings

You can find reviews and ratings for your app inside iTunes Connect by selecting the Activity tab on the top and choosing Ratings and Reviews on the left side (figure 16.30). You can break down ratings and reviews by app version, user’s location, or date. If a user gives a review, you can respond to it, maybe letting them know that their problem is fixed or helping them if they’re stuck.

Figure 16.30. Review ratings and reviews from users via the Activity tab.

Apple is very strict on rating manipulation—your developer account will be terminated if you try to fudge the numbers.

Publishing updates

Once your app has been published, it’s time to think about updates—bug fixes or more features. All updates are managed by the App Store. Just like with Android, App Center updates are disabled for store builds.

You can create a new version using the + Version or Platform button on the left side of iTunes Connect. You can only have one unreleased version of your app at any time, so you can’t create a new version until your previous version has been approved. You also can’t delete versions—if a version needs to be fixed up, you have to change that version instead of deleting it and starting again.

You can only delete published apps

If you build an app and then decide to delete it, you’ll find you can’t unless it has been published. Even if Apple has rejected your app and you can’t publish it, you can’t delete it.

When you add a new version, all the metadata and screenshots from the previous version are copied over. You’ll then need to update this information to reflect your new app version, updating screenshots to match your latest app UI and adding details about what’s new to the app description. You’ll need to upload a new build as well, with an incremented version number. This increment should be to the version number in the info.plist file, not just the build number. You can increment the build number if you want, leave it, the same or reset it, but you need to always increment the version number to indicate a new app version.

Once your new version is ready, click the Submit for Review button to submit your new version for review, and wait while it goes through the approval process.

Make sure anything needed for review is still relevant

The reviews for updates are usually faster than for the initial version, but Apple still does thorough checks. This means anything you set up to help with the initial review needs to still be valid. For example, if you provided a demo account to use, this account should still be working.

Summary

In this chapter you learned

  • App Center can be used to distribute apps to beta testers.
  • Apps distributed by App Center can have in-app updates to help push new versions to your testers.
  • To publish your app, you can use the Google Play store for Android apps and the iOS App Store for iOS apps.
  • There are alternative Android app stores that you may want to target, especially if you want to publish to Chinese users.

You also learned how to

  • Set up App Center distribution groups.
  • Enable in-app updates in your app using the App Center SDK.
  • Create and publish Android apps using the Google Play store.
  • Create and publish iOS apps using the iOS App Store.

Where to next?

Over the course of this book you’ve learned about Xamarin, from developing a simple Hello World app, through learning about the MVVM design pattern, to planning and designing an app, writing a cross-platform model layer and view-model layer, and platform-specific view layers. You’ve run your apps on devices, tested them with automated UI testing, set them up to track how they’re used and detect crashes, and distributed them to beta testers and the store. You’ve been through the entire mobile-optimized development lifecycle and seen how tools from Xamarin and Microsoft can make this journey easy and fun.

To some, Xamarin is just wrappers around the iOS and Android SDKs and the tooling to compile mobile apps, but really it’s a whole lot more. It offers the ability to build a large percentage of your mobile app once, sharing 70–80% of code between iOS and Android. It’s a way to write apps for iOS and Android using one language, and a language that in my opinion is the best around—it gives you great power combined with simplicity, allowing you to write clean, easy-to-read code, with a simple syntax for building multithreaded apps. C# is very important to its creators and has an exciting roadmap of features and improvements coming up.

Xamarin is the tooling that allows you to write mobile apps on a Mac or on Windows, easily switching from one to the other if needed. Xamarin gives you the power to automate your mobile app testing, writing your tests in C#, the same language you use to write your apps. It opens up a huge world of NuGet packages providing amazing cross-platform functionality, as well as giving you plugins that allow you to access platform-specific features, like the camera, from cross-platform code.

The marriage of Microsoft and Xamarin has only strengthened these capabilities. Xamarin tools are now built on top of powerful tools from Microsoft, such as the open source Rosyln C# compiler. Microsoft brings more to the mix in the form of App Center, providing a one-stop shop to introduce mobile app devops. It also has Azure, the best cloud service for developers—something you can access using open source, cross-platform NuGet packages from Xamarin apps as easily as Windows developers can from their applications.

Xamarin has an amazing community of passionate developers from all around the globe and all walks of life. As you continue your journey as a Xamarin developer, I urge you to get involved with the community, whether online, through local events like meetups, or thorough big international conferences such as //Build or Microsoft Connect.

If you want some amazing online content, check these out:

The future of Xamarin is exciting. Every year over the past few years has been the best year yet for mobile app developers, a trend I don’t see stopping.

Now, go build apps!

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.117.91.153