First Impressions of Fastlane Swift for iOS
First Impressions of Fastlane Swift for iOS
Fastlane, a tool for automating iOS deployments, now has Swift support from version 2.69.0 onward. Here, you'll find one developer's perspective.
Join the DZone community and get the full member experience.Join For Free
Fastlane has just been released, with Swift support from version 2.69.0 onwards, which means iOS developers no longer have to write Ruby code to configure Fastlane in iOS or macOS projects. Fastlane is one of the great tools to automate iOS deployments, releases and all sort of common iOS development tasks like Code Signing, Managing provisioning profiles, certificates and versions from Apple developer portal. Fastlane provided programmatic implementation to automate all these tasks so that we can set up Continuous Integration and Continuous Delivery on any CI server. However, iOS developers have to learn and write some Ruby code in order to configure Fastlane in the project which is one of the obstacles of using Fastlane effectively. Traditionally iOS developers are skilled in Objective-C or Swift but not in scripting languages like Bash, Ruby, Python. Fortunately, Fastlane has announced Swift support so that we can use Apple's Swift programming language to configure CI/CD setup for iOS app. In this post, I will share my first impressions of using the Swift version of Fastlane.
Fastlane has added brief documentation of how to get started with Fastlane Swift here but we will see how it looks in action. The first thing to notice is that even though Fastlane has provided Swift support, it is still packaged as Rubygem; you still have to install Fastlane using Rubygem using the following command:
$ gem install fastlane
This might take few minutes to install all required dependencies. You might need to use
sudo if you are using system Ruby that comes with default macOS. Once installed, we have to make sure you have Fastlane version above 2.69.0 to work with Swift. We can check that using the
fastlane -v command.
Now, let's create a single view iOS project FastlaneSwift-Demo in Xcode. In order to check Cocoapods support let's add some dependencies in Podfile. Now we will initiate Fastlane for this project using the following command:
$ fastlane init swift
This will set up our project as usual by asking some questions about your credentials, app identifiers, and schemes and you should be able to complete setup easily.
Once everything is finished, you will see the message saying to open Xcode project located at:
This is an additional Xcode project in order to configure Fastfile inside Xcode with all the autocompletion and syntax highlighting. At this point, you are good to use Swift for configuring lanes. However, if you want to see what has just happened, you may notice that Fastlane has created 8 directories and 34 Swift files inside the
Now, let's open the Xcode project FastlaneRunner.xcodeproj in order to understand what's inside. We will see a project structure like this:
We can see that all the configurations like Fastfile are now written in Swift. Now we can create lanes using Swift methods. We can all the available Fastlane actions straight withing lanes. Now, let's configure our unit and UI tests to run with Fastlane. As you can see, Fastfile has already created the lane
testlane() to run tests that we can execute directly using
$ fastlane testlane.
This will run all the available tests configured for the specific scheme. As you might remember from Ruby version that, Fastlane uses Scan in order to run unit or UI tests. Let's see how we can configure Scanfile using the Swift version. There are two files created
ScanfileProtocol.swift as a template, having all the options that can be configured and
Scanfile.swift has template code where we can configure our options. Let add following options to Scanfile.
Now that, we have configured our Scanfile and we can run the lane with our configured file.
You can see in the gif above that we have all the autocompletion and syntax highlighted while writing configuration. Also, note that we can run tests using that configured lane, but we have to manually select the scheme each time.
Configure Continuous Integration
We can test this on cloud-based Continuous Integration services like TravisCI if you are using GitHub. We just have to create a file (
.travis.yml) and add the following:
language: objective-c osx_image: xcode9 before_install: - gem install fastlane --no-ri --no-rdoc --no-document install: true script: - fastlane testlane
Now that we can enable project on Travis and start running the builds on TravisCI.
Demo Project and TravisCI
The way I understand how Fastlane Swift is implemented is as follows:
- Fastlane Swift is a Swift wrapper to execute Ruby commands under the hood.
- All the Scan, match Gym options are created using respective protocols and extensions.
- All the Fastlane actions are stubbed into a massive
Fastlane.swiftfile which runs Ruby commands.
- Fastlane logs can clearly show that all the bunder and RubyGems are still executing under the hood.
Fastlane Swift has just been born, so it would be unfair to say pros and cons, but consider this as my first impressions of Fastlane Swift.
- iOS developers no longer have to use Ruby code to configure the CI/CD of iOS apps.
- The Xcode project has provided autocompletion and syntax highlighting for all available Fastlane actions.
- The code is purely in Swift so can be compiled and deployed easily.
- Every iOS developer can now understand Fastlane easily.
It's too early to write about its cons, but what I feel is
- Fastlane Swift is just a wrapper which adds 38 unnecessary Swift files to the iOS project, including the Xcode project.
- Fastlane should have come up with an SDK that can be installed using Cocoapods, Carthage, or Swift Package Manager.
- The little issue is that Scanfile configuration is not respected, as I have to input a scheme manually. Or have I done something wrong/misunderstood?
- When I want to do any Fastlane action, the method takes millions of parameters. It would be great to have a separate config file.
- Having an additional Xcode project might confuse some cloud-based CI services like BuddyBuild or Bitrise, as they build that project as well on top of the normal iOS app.
- It's too early, and it's not purely the Swift implementation of Fastlane, it just wraps up Ruby commands under the hood.
Fastlane has made a great improvement by adding Swift support, and huge thanks to this contributor, it might be game changing in the future. However, my personal opinion is that the configuration has to be configuration and should be written using config files and scripting languages. Unfortunately, Swift isn’t the scripting language, but it’s everyone’s personal choice. Until Fastlane Swift matures, I will stick with the Ruby version. What is your opinion? I would recommend every iOS developer to give it a try. Please correct me if I am missing anything in this post.
Published at DZone with permission of Shashikant Jagtap , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.