/ fastlane

Using Fastlane to distribute private frameworks

At HyperTrack we are building APIs and SDKs which enable developers to track and trace local deliveries. Developers integrate HyperTrack’s tracking SDK into the app that drivers use to mark the start and end of their pickup and delivery tasks. We deploy our SDKs as frameworks and distribute it via Cocoapods – a popular dependency management tool. Having lost few hours every time we deployed our SDK we gave Fastlane a spin and found ourselves pleasantly surprised with the result.

Breaking down the deployment

Deploying a framework to a private CocoaPods repo is an involved process with many moving parts which can prove to be erroneous and time consuming. Moreover if we wanted to test our changes we would have to repeat these steps and that meant longer iteration cycles. Take a look at the steps involved in releasing our SDKs manually.

Manual Deployment Steps

  1. Bump version no. for HTCommon``HTTransmitter & HTConsumer
  2. Bump version no. for HTSDKVersion constant in HyperTrack.h
  3. Build universal frameworks for each of using build script
  4. Zip frameworks
  5. Upload the framework to s3
  6. Update podspec and push it to private pod repo
  7. Build the example app
  8. Upload example app to Crashlytics
  9. Create documentation and upload them

Although we used a script to build universal frameworks (#3) we felt the need to automate the entire deployment process. Writing rakefiles or shell scripts seemed to be a good option but that meant dedicating engineering resources and felt like reinventing the wheel. We wanted to lower our barrier for shipping so we could focus on building.

Enter Fastlane

Fastlane is the cool new kid on the block who everyone wants to be friends with. Its an open source collection of tools for automating iOS (and some of Android) deployment process.

Diving in

Let’s see few examples of how the manual deployment steps corresponds to private lanes in our Fastfile.

Bump version no. for HTCommon, HTTransmitter & HTConsumer

Here we’ve defined a private lane named increment_framework_version which takes in framework and version as inputs and increments the version no. in the plist file.

Zip frameworks

In the package_framework lane we use FileUtils methods to delete previous frameworks copy the built framework to new directory and zip it. This allows us to later push the zipped framework on S3.

Upload framework to S3

Fastlane comes with an out-of-box solution for uploading .ipa files to S3 but none for uploading a zip file. So we wrote a custom action which uploaded the zipped framework to S3 using ruby gem aws.

You can find rest of the lanes in our Fastfile. Link below.

Putting it all together

So how does it all orchestrate together? Take a look at our Fastfile.

To release our SDK in production we simply run fastlane release_production bump_type:major or fastlane release_production version:"0.2.1" and all the manual steps mentioned previously is taken care automagically within seconds. The frameworks get deployed an example is released on Crashlytics and notifications are sent to our slack channels.

You can find our Fastfile``custom actions and helpershere.

Contributing to Fastlane

When deploying a podspec with internal dependencies to a private repo a source needs to be specified for linting. Fastlane didn’t have a solution to mention a private repo as source while pushing pod. For our needs the HTTransmitter and HTConsumer SDKs have dependency HTCommon – a repo with common code used by both libraries. So we wrote a custom action which took sources as one of the inputs which fixed the broken pod_push action. Later we contributed back to Fastlane by adding support for sources in the pod_push action. Here is the merged pull request.

Fastlane has saved us lot of engineering time that keeps us focused on building cool stuff for you. We are passing along the favor. With HyperTrack save yourself a lot of engineering time to build tracking so you can focus on building cool stuff for your customers.