Bundler is a best friend of iOS developer

IMPORTANT: SUPPORT UKRAINE NOW 🇺🇦

Please, spend few minutes reading through the website:

Abstract

Bundler is a simple and powerful dependency manager for Ruby gems. Wait, why Ruby, the title says “iOS developer”? The answer is simple — two of most popular iOS development tools (cocoapods and fastlane) are written almost entirely in ruby and are distributed as Ruby gems. While you might not use fastlane yet, you’ve definitely heard about cocoapods and I’m 99,99% sure use it (or used it, but stopped in favour of Carthage) in your development process.

Story 1

I recently realized that I have a real mess of XCode playgrounds on my machine:

  1. Create a Podfile in a root folder. Fill it with necessary pods (ex. Alamofire)
  2. run pod install
  3. run open *.xcworkspace to open freshly created workspace
  4. Create a new Playground, place it somewhere inside project folder (in my case it was $PROJECT_DIR/Playgrounds/MyPlayground.playground)
  5. Drag created Playground into XCode.You’ll see something like this:
  6. Cmd+B to build all Pods and project
  7. You’re done, you can now use import Alamofire in a playground.
error: Couldn’t lookup symbols: __T09Alamofire7requestAA11DataRequestCAA14URLConvertible_p_AA10HTTPMethodO6methods10DictionaryVySSypGSg10parametersAA17ParameterEncoding_p8encodingAJyS2SGSg7headerstFfA3_

Story 2

My fellow developer asked me few days ago whether I faced a weird issue he’s struggling right now — on CI build while exporting an archive he had a build failure on “Lottie.framework does not support provisioning profiles.”

Story 3

About a year ago, I also had an issue with CI archive build. We ran on a big TeamCity cluster with few workers and I suddenly realized that all the time build is run on a random worker machine from a given pool in a bit different environment — cocoapods version, fastlane version… It was fine, until some transporter issues arised when submitting a build to ITunesConnect.

Here comes bundler

Integrating bundler into your development/deployment workflow is simple as ABC:

# frozen_string_literal: true
source "https://rubygems.org"
gem "cocoapods", "1.4.0"
  1. Easy versions change. Playgrounds not working with cocoapods 1.5.2?
    gem "cocoapods", "1.4.0", bundle install, bundle exec pod install, Cmd+B
    Wanna check whether project works on cocoapods-prerelease? gem "cocoapods", "1.5.0.beta.1". Issue arised on a latest fastlane? gem "fastlane", "2.94.0"
  2. In advance to p.1, you and your project fellows stop fighting pod install diffs from different cocoapods versions, just because you share Gemfile / Gemfile.lock and have the same development environment.
No more weird diffs after pod install
  • Reasonable version changes → better control over 3d-party codebase, because developers would need to study changelog / release notes before the update

Few summary thoughts and further reading

In software development versioning is one of the most important concept, often overlooked even by engineers with decent seniority level. If you want feel safer and produce more reliable and stable software, please pay more attention to dependencies and versions.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store