What Makes Continuous Delivery For Mobile Different?

I talk about Continuous Delivery for mobile applications a lot (just ask my girlfriend). Sometimes I talk about it to myself, sometimes to other people, and every once in a while it comes up in casual conversation with taxi drivers. People have a lot of questions about what Continuous Delivery means, which I typically explain as a process engineers use to automate builds, testing and deployment of their software.

Once I get through explaining that bit they often ask what makes mobile different? If this is something people already do, why build a product focused just on mobile? Those are valid questions, the reality is there are a number of Continuous Delivery products on the web that work really well for other platforms like web. Many of them integrate with Github (like cisimple does) and can push code straight to services like Heroku.

Let me explain why mobile is a different animal…

1) Infrastructure

As we all know, iOS is an huge part of the mobile ecosystem and it doesn’t look like this is changing any time soon. If you’re at all familiar with iOS development then you’re almost certainly well acquainted with Xcode and I’ll bet you a warm cup of coffee you’re running all that on a Mac. Know how I know? Of course, you can only build (and compile) iOS applications on Mac hardware! What that means for CD services is that if you’re going to support iOS you better have some Mac servers. Unfortunately, there are all sorts of scaling difficulties inherent in dealing with Macs, which is likely why other CD services don’t do iOS builds.

2) Compilation/Code Signing

Environments designed to compile mobile applications are quite different from web environments. There are often a number of dependencies that need to be in place to make the compile work. Once a compilation has completed and you’re left with an APK (Android) or IPA (iOS) file there’s a code signing step that’s required before an app can be installed on a device. This is an important and non-trivial step that has no analog in a web environment. Any Continuous Delivery solution that isn’t specifically designed to handle this step will not be able to produce builds that run on devices. Furthermore, since code signing certificates/keystores are sensitive pieces of data the signing process needs to be specially designed to protected them.

3) Testing

Testing mobile applications bares some resemblance to web testing. There are both Functional and Unit testing frameworks for iOS and Android. For more information about what frameworks are available check out this earlier blog post. However, running Functional tests on a mobile application requires the use of an Emulator/Simulator or a physical device. In either case, automatically starting/stopping emulators and simulators is difficult and error prone and physical devices become bottle necks in a hosted environment. There just isn’t a corollary to this for web developers

4) Deployment

Deployment for mobile typically means either distribution to testers or publishing your app to an App Store. For web developers getting your app our there is as easy as committing your code, especially if you’re doing some form of Continuous Delivery. For mobile this is a multi step process that requires building, signing and uploading your app to a service like TestFlight or Hockey App.

Standard

Leave a comment