This post is part 3 of series of Xamarin.Forms – real life stories posts.
So, we have made number of decisions so far. We decided that our app will use Xamarin and we’ll use Xamarin.Forms framework. What do we need to start?
First of all we need to define which operating system we need to support. In our case we need to support iOS, Android, and Windows (8.1 and 10).
- iOS – ensure you have some Mac handy. It could be MacMini somewhere in your home/office, or you can rent one using one of cloud services (Mac in a cloud , XCloud, or a similar service). It required for iOS compilation and running iOS simulator. You can use either Visual Studio linked to this Mac or Xamarin Studio on this Mac as your IDE. If you want to deploy/debug on an iOS device, it must be connected to Mac( you won’t be able to do so if you use a Mac in the cloud)
- Android – full freedom of choice here. You can Visual/Xamarin Studio on your PC or Xamarin Studio on your Mac
- Windows/Windows Phone – the only choice is Visual Studio.
Couple of details about iOS, full setup procedure is described on the Xamarin website. It’s very detailed and covers all aspects of Windows – Mac integration. At the end your Visual Studio will indicate that connection is established by displaying a green screen icon:
As good developers we cannot call development environment setup completed without continuous integration and continuous deployment up and running. Obviously there are multiple ways to do this – we’ll go through the process of settings up Xamarin CI/CD in Microsoft VSTS.
Previously, setting up Xamarin CI in the cloud wasn’t a simple process. Main reasons were Xamarin licensing and Mac connectivity for iOS builds. After recent acquisition of Xamarin by Microsoft licensing issue is now solved. Now, full Xamarin stack could be used even with free Visual/Xamarin studio Community edition.
The new VSTS build system is really cross platform and flexible. If your build is Windows-based (i.e. Web/Windows.Android) either hosted(cloud) or local agent can be used. For iOS build local agent must be installed on Mac. Once configured, every source code update could trigger the build. Richard Woollcott has created very detailed description of how to create and manage Xamarin based CI environment (start from this initial post of the series).
OK, CI is done. What about CD (continuous deployment)? When we talk about mobile apps, continuous deployment has a different meaning when compared to web application. In case of web application, continuous deployment means that my application is automatically updated after a succesful build. In the mobile world, it means that application is ready for install after a succesful build. HockeyApp looks like the best to help with this – it allows you to collect crash reports and manage test test versions of your app on multiple platforms. When on iOS and Android, HockeyApp also installs new versions on a device. More details can be found in Richard Woolcott blog. Unfortunately, HockeyApp doesn’t support deployment on Windows platform. In this case we can use HockeyApp account to store test builds. We can use VSTS build to generate deployment package (*.appxupload). This package can be uploaded to HockeyApp. Testers can download these packages manually and run installation .ps script. Alternatively, Windows deployment packages can be stored as build artefacts. Artefacts can be made available for testers for download.
Tip: When creating VSTS build, I recommend labelling your source code upon succesful completion and match label name to the build number.
Why is it a good practice? After number of releases you can have numerous versions up in a wild. Plus you have numerous versions/platforms in testing. Once you get crash report from HockeyApp, you can re-create you source code state by using your version number as a label selector. Once this is done, it will be much easier to reproduce the crash, fix it, and merge the fix into the main branch.