• Five Options for iOS Continuous Delivery without Fastlane
  • Shashikant Jagtap
  • The Nuggets translation Project
  • Permanent link to this article: github.com/xitu/gold-m…
  • Translator: Kim Xixi
  • Proofread by: allenlongbaobao, talisk

Five options for continuous delivery without Fastlane

The original article is posted here at XCBlog

The Fastlane tool automates the entire iOS CI/CD pipeline, allowing us to manage the entire iOS infrastructure in code. Fastlane is a suite of tools that automate everything from analysis, build, testing, code signing, and iOS app packaging. However, if you look deeper, it’s just a Ruby layer on top of Apple’s native developer tools. There may be cases where Fastlane saves some time, but considering the frequent incompatible changes, Fastlane in turn wastes a lot of developer time. Many developers waste valuable time learning Ruby and Fastlane-style automation. Like CocoaPods, Fastlane is probably another white elephant in your iOS project that uses Ruby and has nothing to do with iOS development. It’s not hard to learn some native Apple development tools and completely remove Ruby and other third-party tools (like Fastlane) from your iOS development toolbox. In this article, we’ll look at the issues iOS developers face using Fastlane and the alternatives.

5 problems with Fastlane

Fastlane claims it saves developers time by automating common tasks. This may be true if Fastlane works as expected, but you also need to consider how much time Fastlane wastes in installation, debugging, and administration. In this section we discuss common issues iOS developers may face with Fastlane.

1. Ruby

The first problem with using Fastlane in iOS projects is Ruby. In general, iOS developers are not very good with 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. The recent Swift version of Fastlane claims to do away with Ruby, but it’s really just Ruby commands in the background that Swift executes. I have my doubts about the usability of Fastlane Swift, and this blog post contains my first impressions of fastlane Swift. Fastlane is well documented, but iOS developers still need to use Ruby to write all the infrastructure needed to automate the iOS release pipeline.

2. Frequent incompatible updates

Apple keeps changing native tools, and these changes keep making Fastlane incompatible. They need to constantly chase Apple and Google (in the case of Android) to adapt Fastlane, which requires fastlane developers to implement these features and release new versions. If the Fastlane version is not managed by Bundler, in most cases updating the Fastlane version also requires updating the existing Fastlane script. For potentially frequent build failures, iOS developers need to take the time to analyze the changes in Fastlane and fix them accordingly. Such disruptive updates can interfere with iOS developers’ main development process and waste hours fixing builds. One of the pain points of using Fastlane is that options configured in previous versions of Fastlane don’t always work with newer versions, and if you search for solutions, you’ll end up finding multiple solutions to the same problem for different versions of Fastlane.

3. Time-consuming Settings and maintenance

While Fastlane provides a great guide to getting started with template code, it’s not straightforward to describe all the iOS automation pipeline requirements in a script. We need to customize the options to our needs, which requires knowing how they are written in fastLane scripts, before we can write our pipeline using different Lanes. Learning the Fastlane and Ruby toolkits takes a lot of time to complete all the setup. However, once you’ve got everything set up, the job isn’t done, and you’ll need to do ongoing maintenance with every Fastlane update mentioned above.

4. Contributing code on Github is hard

You may need to configure the iOS release pipeline for company-specific requirements, or ask FastLane for customization. The only option is to write a plug-in for Fastlane. Currently, the only way to write a plug-in is to write a Rubygem, which can be installed as a Fastlane plug-in. Again, it requires a deep understanding of the Ruby ecosystem that iOS developers generally don’t have. Unfortunately, iOS developers cannot contribute code to the tools they currently use in the toolbox. In addition, the process of contributing code to Fastlane is time-consuming and full of robots. It starts with the creation of a Github issue, which leads to endless discussion. You can read more about Fastlane’s contribution guide here.

5. Unresolved issues on Github

Many issues on Github of Fastlane are in the open state, and some of them have been closed by automatic robots without providing users with the correct solution. As a good example, I wasted several days trying to determine whether Fastlane Match supports enterprise application distributions built on Xcode 9. As I searched for answers, I found that other people were also searching for solutions to the same problems. This is an issue that was closed by Fastlane bots without a proper solution. I have tried various solutions provided by issues 11090,10543,10325,10458, etc. After reading all these, I still don’t understand what the export method of enterprise application construction is. Some users said: when you use adhoc it works; Others say ad-hoc or AdHoc. You can imagine how much time it takes to package the application and test each exit method. I saw CircleCI also had users frustrated with fastlane’s match code signing issues.

The list above is just a few of all the problems fastlane has created in your iOS project, and you may have different stories and different problems that you never mention.

5 Fastlane alternatives

Now that we’ve seen some of the problems with using Fastlane in iOS projects. The question now is whether we can completely remove Fastlane from the iOS project. The answer is yes. However, it will take you some time to understand the iOS build process and a few of Apple’s native command-line development tools. I think it’s better to spend time learning about native Apple development tools than learning about third-party frameworks. You’ll never regret learning Apple’s native command line development tools, but if you don’t have the time, there are free and paid services that can take care of all your problems. Currently, we have the following free or paid alternatives to Fastlane.

Fastlane’s Top 5 alternatives

  • Native Apple Development Tools (free)
  • Xcode Server (free)
  • Cloud CI services (paid)
  • Apple + BuddyBuild (God knows)
  • Swift-based alternative (free but not yet ready)

1. Native Apple development tools

There’s nothing better suited to your build and release needs than learning Apple’s native development tools and writing custom scripts. Apple provides command-line development tools to do everything we want. Fastlane and similar tools are also based on Apple’s native developer tools. The great thing about using Apple development tools is that no one but Apple can break it, and they’re all backwards compatible in most cases. Apple has documented these tools, and most have manuals that make it easy to see all the options they offer. To write the iOS build pipeline, we need to understand the following major tools.

  • Xcodebuild — Analyze, build, test, and package iOS apps. This is the father of all commands, so it’s important to learn this tool.
  • Altool: Upload ipA files to iTunes Connect.
  • Agvtool: Manages builds and builds.
  • Codesign: Manages code signatures for iOS apps.
  • Security: Manages certificates, keystrings, and Profiles.

There are some helper tools like simctl, PlistBuddy, xcode-select, etc., which are sometimes needed when dealing with emulators, Plist files, xcode versions, etc. Once you’re familiar with these tools, you’ll feel confident that you can write your own iOS release pipeline and that these tools can solve any problem. In most cases, a few lines of code will send your iOS app to iTunes Connect. I wrote an article about publishing iOS apps from the command line. We also need to know some code signatures to understand the flow. It takes some time to learn how to use Apple developer tools during the iOS build process, but this is a one-time thing and you don’t need to learn any third-party frameworks like Fastlane.

2. Xcode Server

Xcode Server is a continuous integration service provided by Apple. With the release of Xcode 9, Apple has added a number of new features to Xcode Server, almost all of which run in the background. Xcode Server is tightly integrated with Xcode, making it easy for iOS developers to get started. With Xcode Server, we can analyze, test, build, and archive an iOS application without writing any code or scripts. If you use Xcode Server for iOS continuous integration, you probably don’t need any tools to automate the build process. You can read more about Xcode Server features here. However, there is one more step that we need to do manually: upload the binaries to iTunes Connect or another platform. Currently Xcode Server cannot upload binaries to iTunes Connect, but this is easily achieved using Altool as the post-integration script for Xcode Server Bot.

If you can’t manage a Mac Mini Server internally, you can rent some Mac Minis to run Xcode Server through services like Mac Stadium.

3. Cloud-based CI services

There are many cloud-based CI services, such as BuddyBuild, Bitrise, CircleCI, Nevercode, etc., that provide continuous integration and continuous publishing services. BuddyBuild was recently acquired by Apple, which I’ll cover in the next section. These cloud-based CI services handle all iOS build processes, including testing, code signing, and publishing applications to specific services or iTunes Connect. We can also write custom scripts to implement specific requirements. These services completely eliminate the need for scripting fastlane or any iOS project. But these services are not free and can control your project. This is a good choice if you don’t have any CI/CD infrastructure skills at all. I completed all the key steps of these cloud-based CI services on my personal project and wrote my conclusions. Hopefully this comparison and discussion will help you in the process of choosing the right service for your iOS project.

4. Apple + BuddyBuild

Apple’s acquisition of BuddyBuild earlier this year means apple and BuddyBuild could work together to provide painless continuous integration and delivery services for iOS developers. It will be interesting to see the apple/BuddyBuild demo at WWDC 2018. We can guess that Apple will use Xcode Server as its own hosted solution (free) and integrate BuddyBuild cloud-based into Xcode’s solution (paid or free); Or maybe Apple ditches Xcode Server altogether and just keeps BuddyBuild as a free or paid service. None of these possibilities requires an obvious scripting infrastructure unless necessary. This would eliminate the need for tools like Fastlane altogether. The only thing we need to do now is wait until WWDC 2018.

5. Swift option (not ready)

Fastlane recently added support for configuring channels using Swift instead of Ruby. But this is not a true Swift implementation at the moment, because Swift is still used to execute Ruby commands underneath. It adds a number of unrelated Swift files to the project, which ideally should be provided as Swift packages (SDKS) that can be distributed through CocoaPods, Carthage, or Swift Package Manager. I wrote about my first impressions of Fastlane Swift. Another solution is Autobahn, which is fastlane for the pure Swift implementation, but it is still under development and will not be available until development is complete. Unfortunately, we have to wait for these Swift-based solutions, which are not ready for use in the current iOS project. However, sooner or later we expect a workable solution that will allow iOS developers to write configuration code using Swift. Swift is not a scripting language in my opinion, but can be used as a script when needed.

Tips for choosing

At this point, we’ve seen all the options for continuous publishing without using fastlane tools. The next step is to decide which approach to choose, depending on the skill and experience of the engineers on the team.

  • If the team does not have any iOS engineers with CI/CD knowledge at all, there is an option to use cloud-based CI solutions to address all issues.
  • If you have a small number of iOS engineers with CI/CD experience on your team, try Xcode Server because it is fairly simple to configure and use.
  • If the iOS developers on your team are experienced and familiar with native tools, it’s worth building the pipeline with scripts.
  • It’s a good idea to wait for WWDC 2018 to see what apple and BuddyBuild will bring to the stage.

conclusion

By using Apple’s native developer tools, we can write an entire CI/CD pipeline for iOS projects, eliminating the need for third-party tools such as Fastlane in iOS projects. But it takes time and effort to learn apple’s native developer tools. Other options such as Xcode Server or cloud-based CI solutions can avoid the use of scripts.

The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.