Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Five Options for iOS Continuous Delivery Without Fastlane

DZone's Guide to

Five Options for iOS Continuous Delivery Without Fastlane

If you're looking to escape Fastlane's frequent build-breaking changes, these five options for iOS continuous delivery are worth examining.

· Mobile Zone ·
Free Resource

Fastlane tools automate entire iOS CI/CD pipelines and allow us to keep an iOS infrastructure as code. Fastlane is a set of tools to automate almost everything, including analyzing, building, testing, code signing, and archiving iOS apps. However, if you look inside, it's nothing but a Ruby layer on top of native Apple developer tools. Fastlane might have saved some time in some cases, but it's worth considering how many developer hours have been wasted by Fastlane's by frequent breaking changes. There are many developers hour wasted on constant learning of Ruby and Fastlane's way of automating things. Like CocoaPods, Fastlane might be another elephant in your iOS project that uses Ruby, which is nothing to do with iOS development. It's not that difficult to learn some native Apple developer tools and remove Ruby and other third-party tools like Fastlane completely from your iOS development toolbox. In this post, we will cover the problems that iOS developers are facing using Fastlane and the current alternatives to Fastlane.

Fastlane claims that it saves developers hours by automating common tasks. It might be true in situations where Fastlane is working as expected, but it's also important to consider how many developer hours are wasted by Fastlane in terms of setup, debugging, and managing. In this section, we will see the common issues that iOS developers are facing using Fastlane.

1. Ruby

The first and major issues with using Fastlane in an iOS project is Ruby. Generally, iOS developers aren't that skilled in Ruby, but in order to use tools like Fastlane or CocoaPods, they have to learn Ruby, which has nothing to do with actual iOS development. Setting up Fastlane tools requires a good understanding of how Ruby, RubyGems, and Bundler work. A Swift version of Fastlane was recently announced to get rid of Ruby, but it's just Swift executing Ruby commands under the hood. I doubt the usability of the Swift version of Fastlane. I have written my initial impressions in this post. Fastlane has good documentation, but iOS developers still have to use Ruby to script all the infrastructure for automating iOS release pipelines.

2. Frequent Breaking Updates

Apple keeps changing the native tools, which in turns constantly breaks the Fastlane tools. They need to always chase Apple and Google (in the case of Android) to accommodate those changes in Fastlane. This requires Fastlane developers to implement these features and release the new version of Fastlane. Most of the time, updating the Fastlane version requires updating the existing Fastlane scripts, if Fastlane versions aren't managed by Bundler. There might be frequent build breakage due to updates and iOS developers need to spend the time to analyze what has been changed in Fastlane and fix the builds accordingly. These breaking updates disturb the main development flow of iOS developers and it ends up wasting hours to fix the build. One of the pain points of using Fastlane is that the options configured in the previous versions of Fastlane don't always work with the newer version, and if you search for a solution, you end up having multiple solutions for the same problems for different versions of Fastlane.

3. Time-Consuming Setup and Maintenance

Although Fastlane provides a great getting started guide with the template code, it's not straightforward to script all the things that we need to automate iOS release pipelines. We probably need to customize the options as per our need, which requires how those options are coded in Fastlane. We can then use different lanes to script our pipeline. It requires a lot of time to learn about Fastlane and Ruby toolbox to get everything set up. The job isn't done when you setup everything needed, it requires constant ongoing maintenance per Fastlane update as mentioned above.

4. Hard to Contribute

You might need to configure iOS release pipelines as per company-specific rules or require Fastlane to do something customized. The only option to do this is writing plugins for Fastlane. Currently, the only way to write a plugin is to write a Rubygem which can be installed as a Fastlane plugin. Again, it requires a deep understanding of the Ruby ecosystem that iOS developers normally don't have. It's unfortunate that iOS developers can't contribute to the tool they are currently using in the toolbox. On top of this, the process of contributing to Fastlane is time-consuming and full of automated bots. It starts with creating a GitHub issue as a proposal, leading to endless discussions. You can read more about the Fastlane contributing guide here.

5. Open Issues on GitHub

There are multiple issues open on GitHub and some of them are closed by automated bots without providing the correct solution to users. A good example of this would be how I wasted multiple days figuring out if the Fastlane match support enterprise app could build a distribution with Xcode 9. While searching for the solution, I found other people looking for the solution as well. This is an example of unresolved issues closed by Fastlane bost without providing the proper solution. I have tried multiple solutions provided on the issuess like 11090, 10543, 10325, 10458. After reading all these things, I couldn't figure out the export method that works for enterprise builds. Some of the users say it works when you use  adhoc while others are saying Ad-hoc or  AdHoc or enterprise. You can imagine how much time it takes to test each export method by archiving an app. I saw that CircleCI users are also frustrated with code signing issues with Fastlane Match.

This is a small list of the problems that Fastlane has created within your iOS project, but you might have a different story and different issues that you never brought up.

5 Fastlane Alternatives

Now we have seen some of the issues with using Fastlane in an iOS project. The question is, can we remove Fastlane from iOS projects completely? The answer is YES. However, you need to spend some time to understand the iOS build process and a few native Apple command line developer tools. I would say it's more worth investing time to learn about native Apple developer tools than learning third-party frameworks. You will never regret learning native Apple command line developer tools. However, if you don't have time to learn these, then there are some other free and paid services that handle everything that Fastlane does. Currently, we have the following free and paid alternatives for Fastlane:

  • Native Apple Developer tools (free)
  • Xcode Server (free)
  • Cloud-Based CI Services (paid)
  • Apple + BuddyBuild (God knows)
  • Swift-based alternatives (free, but not ready)

1. Native Apple Developer Tools

Nothing beats learning native Apple developer tools and writing custom scripts as per the requirements of your build and deployment process. Apple has provided command line developer tools to do almost everything that we want. Remember that Fastlane and similar tools also use the native Apple developer tools under the hood. The biggest benefit of the using Apple developer tools is they can't be broken by anyone apart from Apple, and they are backward compatible in most cases. Apple has documented these tools and most of the tools have pages to see all the options provided. In order to script iOS build pipelines, we need to know about the following major tools:

  • xcodebuild - Analyzing, building, testing, and archiving iOS apps. This is the father of all commands, so it's important to learn this tool.
  • altool: Upload .ipa to iTunes Connect.
  • agvtool: To manage version and build numbers.
  • codesign: Manage code signing for iOS apps.
  • security: Manage Certificates, Keychains, and Profiles.

There are supplementary utilities like simctl, PlistBuddy, xcode-select, etc that are needed sometimes in order to deal with simulators, Plist files, and Xcode versions. Once you get familiar with these tools, you'll feel confident about scripting iOS deployment pipelines on your own and being able to fix any issues. In most cases, a few lines of code can land your iOS app in iTunes Connect. I have written an article on deploying the iOS apps from the command line here, but we also need to know code signing to understand the entire flow. Learning and applying Apple developer tools in the iOS build process takes some time, but it's once and for all and you don't need to learn about any third -party frameworks like Fastlane.

2. Xcode Server

Xcode Server is the Continuous Integration service provided by Apple. With the Xcode 9 release, Apple enhanced Xcode Server a lot with a lot of new features that automate almost everything under the hood. Xcode Server is tightly coupled with Xcode. With Xcode Server, we can analyze, test, build, and archive an iOS app without writing a single line of code or script. You probably won't need any tooling to automate the build process if you use Xcode Server for iOS Continuous Integration. You can read more about Xcode Server features here. However, there is one manual step that we need to do to upload binary to iTunes Connect or some other platform. Currently, Xcode Server cannot upload binary to iTunes Connect, but it can be easily achieved with using  altool as a post-integration script of Xcode Server bot.

If you can't manage mac Mini servers in-house, then you can hire some Mac Minis from services like Mac Stadium to get on with Xcode Server instances.

3. Cloud-Based CI Services

There are various cloud-based CI services like BuddyBuild, Bitrise, CircleCI, and Nevercode which offer Continuous Integration as well as Continuous Delivery services. BuddyBuild has been acquired by Apple recently and we will cover that in the next session. These cloud-based CI services handle all the iOS build processes, including testing, code signing, and deploying apps to specific services or iTunes Connect. We can also write our own custom scripts to achieve specific needs. These services completely remove the need for Fastlane or any kind of scripting from iOS projects. However, these services are not free and take control of your project. If you don't have the skills to script the CI/CD infrastructure, then this will be a good option. I have done critical evaluation of all these Cloud-based CI services on my personal project and written my conclusions here. I hope you will find these comparisons useful while selecting the right service for your iOS project.

4. Apple + BuddyBuild

Apple aquired BuddyBuild at the start of the year; that means Apple and BuddyBuild might be working together to provide  painless Continuous Integration and Delivery services for iOS developers. It will be interesting to see what Apple and BuddyBuild will build together and present at WWDC 2018. There are a few things that we may expect, like Apple keeping Xcode Server as a self-hosted solution (free) and integrating BuddyBuild with Xcode as a Cloud-based solution (paid or free), or Apple may completely kill Xcode Server and only keep BuddyBuild as s service, which might be free or paid. However, in all cases, there won't be a need to explicitly script infrastructure unless needed. This will also completely remove the need for tools like Fastlane. The only thing we can do currently is wait until WWDC 2018.

5. Swift Options (Not Ready)

Fastlane has recently added support to configure lanes using Swift rather than Ruby. However, currently, the implementation isn't usable as it's just Swift executing Ruby commands under the hood. It adds lots of irrelevant Swift files in the project, which ideally should be provided as a Swift package (SDK) that can be distributed through CocoaPods, Carthage, or Swift Package Manager. I have written my first impressions of Fastlane Swift here. Another solution is Autobahn, which is a purely Swift implementation Fastlane, but it's too early in development and cannot be used until development finishes. Unfortunately, we have to wait for these Swift-based solutions - they are not ready to use yet in current iOS projects. However, we can hope that, sooner or later, there will be a feasible solution which will allow iOS developers to write configuration code in Swift. In my opinion, Swift is not a scripting language, but can be used for scripting if needed.

Now we have seen all the options to set up Continuous Delivery without using Fastlane tools. The next thing is to decide which options to use for your iOS project. It depends on the skills and experience of the engineers on your team.

  • If the team has iOS engineers without any previous knowledge of CI/CD, then it's worth going for Cloud-based CI solutions that handle everything.
  • If the team has a few iOS engineers with some experience with CI/CD, then it's worth giving Xcode Server a try, as it's fairly easy to configure and use.
  • If the team has experienced iOS developers with sound knowledge of native tools, then it's worth scripting build pipelines.
  • It's a good idea to wait until WWDC 2018 and see what Apple and BuddyBuild will present.

With the use of native Apple developer tools, we can script our entire CI/CD pipeline for iOS projects, which removes the need for third-party tools like Fastlane. However, it requires time and effort to learn the native Apple developer tools. Other options are to use Xcode Server or Cloud-based CI solutions to remove the need to script release pipelines.

Topics:
mobile ,ios ,continuous delivery ,ci/cd ,fastlane

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}