A Review of Roboto for Continuous Integration and Delivery

Development iOS Tools

My last post was about Jenkins as a solution for continuous integration and continuous deployment. While we still love the power and flexibility of the platform, let’s be honest, it's not for everyone. Jenkins takes time to set up and maintain, time that most people would much rather just spend building stuff. If you don't think you have the time or manpower to dedicate to a self-managed, self-hosted CI solution, that’s quite alright. As it turns out there are dozens of other CI and CD solutions out there. One that's caught our eye here at Savvy Apps is Roboto.

Roboto is a mobile-focused, turnkey solution that helps distribute apps quickly with virtually no extra work involved. At the moment, it won’t replace a complete, fully-automated testing CI stack but it will certainly help teams get their app in the hands of beta testers faster and easier.

How Roboto Works for Continuous Integration and Delivery

First, let me tell you how it works. Roboto is primarily a continuous delivery platform. This means while it does build and compile source code from team members on a project, either on demand or on commits made on any or all branches, its focus is more on preparing and distributing the binary files to team members, beta testers, and even Apple’s TestFlight or App Store. Notice that Roboto is mobile focused and works exclusively with iOS and Android apps. It supports the latest version of Xcode and development in Swift, which is more than many other CI solutions can say at the moment.

The Builds dashboard is where you can manually trigger new builds, review previous ones or upload your own.

Roboto pulls and builds the source code in a unique folder in /Library/Caches on a machine of your choosing through their Mac app. Sharing our source code and private code signing keys with hosted solutions makes us (and our customers) a little uneasy, so having the build occur on one of our machines without any extra configuration or setup is a huge plus. Roboto will listen in the background for requested builds, either from a commit on an important branch or a specific request through their web console. Again, having this control over which machine stores and compiles the source code is very important to us. You can choose to have every team member’s machine listen for builds or just one. We preferred to keep it simple and enabled one CI box to listen for incoming builds 24/7, so a machine is always on standby, ready to compile.

What’s really nice about Roboto is the fluid, turnkey setup. Roboto relies on Git and Xcode. That’s it. It integrates well with CocoaPods, if you’re using it. Roboto can install your required pods as needed but there is nothing else you need on your machine for Roboto to work. No plugins, no configuration files, no build scripts. Simple, right?

Since all of our team members (non-developer members included) already have those tools installed, it really makes Roboto convenient for everyone to learn and use. This also helps prevent the appointment of a “CI guy,” which usually ends up happening on teams with more complex CI tools. If only a small subset of team members knows how to maintain and fix the CI, bottlenecking and other blocking issues can arise.

Roboto is convenient for everyone to learn and use, eliminating the need for a CI guy.

Once the build is complete, only the binary is hosted on Roboto’s servers. Roboto can send out emails with download links to anyone you have added or you can just distribute the provided build link yourself

How to Make a Roboto Build

So what does it take to make a Roboto build? Well, once you create an account (they do support a free trial) and install the Roboto Mac App, create a new app in Roboto. All you need to do is give it a Git repository URL, a scheme/workspace name, and select how you want builds to trigger. You may also want to add emails to the “Access” panel to alert team members that a new build is ready. Builds can be triggered off of commits to a single or multiple branches or just manual requests through the web console. Ensure your machine is listening for jobs and click “Request Build.” Within a few minutes, Roboto will compile and sign your app on that machine and email everyone you’ve given access to, telling them that a new app binary file is ready to install. You can add release notes to each build if you wish, as well as customize values in your app’s info.plist. That’s pretty much all there is to it!

You can set your own custom info.plist properties to be injected with each build.

We got an .ipa file on our phones in minutes after the first Roboto installation on one of our machines. I should note, however, the second machine we tried to install it on did not work as flawlessly. Roboto crashed and terminated in the background while building on that machine. It didn't finish the build. Luckily, its support team was quick to respond and very helpful in resolving the issue. They actually posted a version update with a patch a few days later

How Roboto Can Improve its Continuous Integration

Now, Roboto is not perfect. Like all CI pre-packaged tools, you are limited to the features provided and usually locked into that system with little to no support for migrating platforms. There really isn't much here you’d need to migrate but Roboto could be promoted from a good choice to the default choice for us if they supported a few more features.

Currently, you can’t run any kind of testing suite for your app out of the box. This is one of the key factors in continuous integration. Unless you’re verifying the code still works somewhere else in the pipeline, you could be automatically delivering buggy software.

Another feature we miss is in-app updates. Granted, this would require either source code changes with a Roboto framework or the like but our customers love the fact we can initiate app updates inside the app without them ever having to look at their email for new builds. This may be possible soon with Roboto, as they are working on a RESTful API that could expose build links like this.

Customized branding is another seemingly small item Roboto is missing but one that could really make a difference to customers. Again, the features Roboto already has are great but a customer will probably want to see an email with their own logo and styling rather than Roboto’s when they’re installing their app.

Concluding Note

Right now, Roboto is a great continuous delivery tool, which we think is what they are striving for at the moment. If all you need is a super easy way to deliver app iterations to beta testers or teammates, especially Swift apps, Roboto is probably the way to go. If you’re looking to add some more steps to your continuous integration cycle like testing, code styling, analyzing, etc or have picky customers that would be put off by seeing Roboto’s name all over the new build emails, you’ll probably have to find another tool that suits your needs better. The support and quick iteration cycle of updates from the Roboto team does hold promise and we will be looking forward to future releases.

Matthew Tea is a developer with a passion for quality, tested code. He's a team player with a strong desire to learn new and upcoming technologies.

You made it this far so...