Today, the 24th Feb marks 25th birthday of Ruby programming language since it named by Yukihiro “Matz” Matsumoto in Japan. Since released in 1993, it becomes most dynamic, easy to learn and most fashionable programming language. In the world of iOS development, Ruby has been used almost everywhere from package management, automating releases or managing Xcode projects using scripts. Why is that? What Ruby is doing there in the world of iOS development even there is nothing common in iOS and Ruby. In this post, we will try to find out some of the historical reasons for Ruby’s existence in iOS development and deployment.
What Made Ruby Popular
If you are not worked with Ruby, there might be situations that you might found libraries, best practices, design patterns, tools or frameworks in your languages that are heavily inspired by Ruby’s best practices. I have witnessed so many Swift, PHP, JavaScripts libraries that are implemented from the original Ruby libraries as it is. Some common examples are RSpec has implemented in PHP (PHPSpec), JavaScript (Jasmine) and Swift(Quick). There might be many more examples that have been implemented in other languages from Ruby. Not sure why Ruby became so popular but it’s because of simplicity of language, community and ecosystem made Ruby excellent programming as well as the scripting language.
Now, we will cover what sort of the Ruby-based tools being used in iOS development.
Ruby Tools in iOS Development
There are various Ruby-based tools being used actively in the iOS app development for various reasons. Recently, someone asked a genuine question on twitter,
Why is it that iOS Developer often use Ruby?
This is the valid question as there is hardly any iOS project which doesn’t have Ruby inside it, apart from those developed at Apple. Now that, we will list few tools which became very popular among iOS developers and became core part of iOS development.
These are just a few selected ruby-based tools but there might be much more used in iOS app development under the hood. Now, we will look into the little bit of background of these tools in short.
nomad-cli
The nomad-cli is not actively used in the recent days as it been superceded by Fastlane tools, however, Fastlane tools have been inspired by nomad-cli which is written using Ruby. This was one of the early players when ruby-based tools started to appear in iOS development. This project built the solid base for the command line tools that can be written on top of nomad-cli. This is pure command line interface used for distributing iOS apps to App store. You can read more about nomad-cli here
Rise of nomad-cli
Before nomad-cli, apps normally used to archived using local Xcode or there needs to be complex scripting using xcodebuild tools. The scripts produced by xcodebuild are usually very lengthy and hard to maintain. It accepts a lot of parameters and each parameter needs to be configured in the script which is tedious. The author of nomad-cli, Matt who skilled in Ruby build this tool to solve iOS binary distribution problem using the command line.
Why nomad-cli wrote in Ruby
Not sure why the author of nomad-cli started using Ruby for building the wrapper on Apple’s native technologies. Looking at the mattt’s Github repos, he looks well versed with Ruby that might be the reason he chose Ruby for nomad-cli.
CocoaPods
CocoaPods is the project where Ruby sets foot inside an iOS app development. CocoaPods is dependency management system for Xcode projects. Its been used to create and distribute Swift and Objective-C packages and reused in other projects. CocoaPods has the centralised repository of all packages that can be used in Xcode project. CocoaPods is not a single project but collection of projects written using Ruby. The projects include Xcodeproj, CLAide, Molinillo, CocoaPods Core, Master Repo etc. You can find the details of the projects here.
Rise of CocoaPods
Before CocoaPods, managing the dependencies inside Xcode project was real pain. An iOS Engineers has to link the frameworks manually within Xcode build phases. Cocoapods solved this problem by automating all these tasks internally.
Why CocoaPods Written in Ruby?
The main author of CocoaPods Eloy Duran, answered the question in this tweet, why he chose Ruby for writing CocoaPods. According to him Objective-C and Ruby are both influenced by Smalltalk, It’s also why he worked on various Ruby implementations on top of the Objective-C runtime. The reasons specified for selection of Ruby includes
- Easy to share code with Bundler/RubyGems
- In early stages leverage MacRuby (Ruby on Objective-C runtime) so we could use native PropertyList (de)serialization APIs to read/generate Xcode projects and defer pure Ruby solutions to later.
- Dependency management is in general hard to get right for everybody’s situations, definitely when just starting out, and even more so in complicated native envs like Xcode projects. Ruby was a good choice to let users monkey-patch whatever they needed for their projects.
- Ruby is an excellent language for CLI tools that do a lot of string manipulation.
- They made an effort to make sure
@CocoaPods would work with the Ruby that shipped with OS X, even when not having the Xcode CLI Tools installed.
CocoaPods uses Xcodeproj gem to modify Xcode project. After Xcodeproj, there are loads of ruby libraries built to which deals with Xcode projects using command line or scripts.
Fastlane
Fastlane is widely used these days to automate build, test and distribution of iOS apps. Fastlane is being used to script the infrastructure as code which can be run on any Continuous Integration server. It has set of tool to automate various iOS development tasks. You can read more about Fastlane here. All the Fastlane tools are built using Ruby. Recently Fastlane team at Google is building Fastlane-CI using Ruby which would be very interesting.
Rise of Fastlane
As mentioned earlier, Fastlane tools are heavily inspired by nomad-cli. Fastlane has automated most of the iOS development and deployment activities like building, testing, code signing, screenshots, test flight and many more. Fastlane has built extensive and scalable wrappers on Apple’s native technologies and usually very quick to adopt any changes made by Apple in the native tools.
Why is Fastlane Written in Ruby?
As per the Fastlane tools author, Felix, he also ended up using Ruby, to be able to directly access & use the classes they already wrote to support Xcode projects in the previous tools e.g CocoaPods and nomad-cli. Felix thinks that there a few reasons:
- mattt was an early player in the iOS tooling scene, and he built nomad-cli in Ruby (big inspiration for him)
- CocoaPods was written in Ruby So when starting Fastlane, he wanted to integrate with both toolsets from day 1
Danger System
The Danger is another very popular tool built-in, Ruby, to make code review process faster by automating the simple rules on pull requests. Danger has been then implemented in Javascript and Swift as well but original inspiration was Ruby.
The main author of Danger, Orta who also contributed to many other open-source tools including CocoaPods, Fastlane and also built libraries. The most of the interesting Ruby based libraries being developed at the company called Artsy. You can follow Artsy on Github or follow their blogs for interesting projects.
xcpretty
The xcpretty is a formatter for xcodebuild which can be used to generate nice looking reports in different formats. Currently, it supports junit, html and json format. It also helps to make xcodebuild logs more readable. We are not going into the details of why the author chose to build this tool in Ruby. We can safely assume that major tools were built in ruby so they probably want to align all the tooling in the ruby.
xcov
The xcov is a tool to display code coverage reports in the user-friendly format. It generates reports in HTML, JSON and Markdown format. The xcov is also written in Ruby. You can read more xcov here. We are not going into the details of why the author chose to build this tool in Ruby. We can safely assume that major tools were built in ruby so they probably want to align all the tooling in the ruby.
Can iOS Development be a Ruby-less?
The answer is YES and NO. If iOS developers spend the time to understand and use the native iOS tooling from Apple into their own workflow then YES. However, I don’t think it’s going to happen very soon. Apple’s native tools are complex and hard to learn. Apple is continuously trying to make developers happy by introducing some GUI based features in Xcode on top of the native technologies but so far no success.
In order to be Ruby-less iOS project, someone needs to write the alternative tool for CocoaPods and Fastlane which seems very much of hard work.
There are projects like Carthage, Swift Project manager which can be used instead of CoacoPods but both having some limitations to be fully adopted in the iOS workflow. Carthage has too much of manual steps and Swift Package manager is still not ready to work iOS projects. One of the possible alternatives for Fastlane tools would be writing custom scripts on top of Apple’s native command line tools. This requires the deep understanding of Apple’s technologies and amazing scripting skills. It would be rare for iOS developers to have that skills by default. Fastlane tools have already done too much of work to automate most of the iOS development workflows so can be used as it is without pain.
You can remove Ruby completely from iOS projects but you need to learn more about Apple’s native technologies, work hard and reinvent the wheels. It’s worth doing if you have time and money to do it.
Conclusion
Ruby has solved complex Apple developer tools problems by creating tools like CocoaPods, Fastlanes and many more. Most of the iOS developers already accepted Ruby in their own workflows so Ruby isn’t going away from iOS app development anytime sooner. So it would be worth for every iOS developer to find some time to learn Ruby. It would be interesting to see how Apple developer tools can deal with Ruby’s dominance in the iOS world. What are your experiences using Ruby inside iOS projects? share in the comments below