Ruby within iOS development realm
So, today, February 24th, Ruby turns 30 years old! It was first born in Japan back in 1993, thanks to Yukihiro «Matz» Matsumoto, and it’s been swiftly taking over the world of ours ever since!
It was designed with the idea that programming should be fun for programmers. It emphasizes the necessity for software to be understood by humans first and computers second. Even though right now there are a bunch of other languages that are faster/safer/more efficient, they lack the magic and charm of Ruby, you know?
Ruby has been and probably always will be my favourite language. It just brings me joy every time I use it. So yeah, take everything I say below with a pinch of salt =)
Anyways, I’d like to reflect on how Ruby has made a thing in the iOS development realm, became a role model and, at the same time, begun to lose the ground…
Are Ruby gems the actual gems?
Storytelling
Ruby is a language of careful balance. Its creator, Yukihiro «Matz» Matsumoto, blended parts of his favorite languages (Perl, Smalltalk, Eiffel, Ada, and Lisp) to form a new one that balanced functional programming with imperative programming.
He has often said:
I am trying to make Ruby natural, not simple, in a way that mirrors life.
Building on this, he adds:
Ruby is simple in appearance, but is very complex inside, just like our human body.
© ruby-lang.org
But what brought Ruby to iOS realm?
Well, it was the RubyCocoa framework which was started in 2001 by Hisakuni Fujimoto when he implemented a Ruby extension module to wrap NSObject and NSClassFromString function.
It provided a bridge between the Ruby and the Objective-C programming languages, allowing the user to manipulate Objective-C objects from Ruby, and vice versa.
In turn, it made it possible to write a Cocoa («SwiftUI of those days») application completely in Ruby as well as to write an application that mixes Ruby and Objective-C code.
An Apple project called MacRuby was under development to replace RubyCocoa in 2008. A proprietary spin-off called RubyMotion was subsequently released in 2012, available for iOS, macOS and Android. It was a commercial product that allowed developers to write native applications in Ruby.
I guess this literally untied the hands of indie contributors in the Apple community, and since then Ruby began to take a firm foothold in the iOS world, gradually introducing and developing new revolutionary tools and frameworks that were supposed to make the iOS development process easier and much more enjoyable.
I’m going to mention the most notable ones and briefly compare them with their native alternatives that have started joining the party in the last couple of years with the rise of Swift development.
Name-dropping
Automation in general
Ruby:
- nomad-cli (2012-2021, archived)
- fastlane (2014, still
#1automation tool for iOS development. Don’t forget to vote here, so it doesn’t end up in the Google graveyard)
Native alternatives:
- xcodebuild (2003, it’s been included with the Xcode development environment since its first release. Unfortunately, super clumsy and complex)
- Fastlane.swift (2017, still in beta. The wrapper on top of its Ruby ancestor)
puts "Ruby wins. Flawless victory! 🚀"
puts "fastlane has already done an incredible amount work to automate most of the iOS development workflows. It's really hard to compete with it. Fastlane.swift? Eh, will see..."
Package management
Ruby:
Native alternatives:
echo "Draw 🤝"
echo "Even though CocoaPods still is more common these days, it's clearly a legacy. Swift Package Manager has some limitations but already looks promising and starts to pull the blanket"
Management of executable packages
Ruby:
Native alternatives:
echo "Draw 🤝"
echo "Even though brew is much more popular than Mint, it's already not that obvious in the iOS development realm"
Docs generation
Ruby:
Native alternatives:
echo "Draw 🤝"
echo "This couple looks very similar to CocoaPods and SPM. One is mature and widespread, another one is more modern and simpler, but not as commonly used yet"
Logs decoration
Ruby:
Native alternatives:
puts "Ruby wins 🎉"
puts "Almost every automation tool or script around iOS realm uses xcpretty. At least to date. Will see how it goes in the future"
Project management
Ruby:
Native alternatives:
print("Swift wins 👍")
print("It wasn't an easy decision, but we have to face the music. Swift tools here are just too good to ignore")
Project modification
Ruby:
Native alternatives:
echo "Draw 🤝"
echo "It was easy. One is copy-pasta of another. Both are pretty good, all depends on the use case"
Automation of Xcode installation
Ruby:
- xcode-install (2015-2022, archived)
Native alternatives:
print("Swift wins. Flawless victory! 🚀")
print("Community made a decision. xcode-install is not maintained anymore, xcodes is the way to go")
Test automation
Ruby:
Native alternatives:
print("Swift wins. Flawless victory! 🚂")
print("No comments, XCTest is the best 🤠")
Test coverage reports generation
Ruby:
Native alternatives:
puts "Ruby wins 🎉"
puts "These are a little different tools around the same thing. When xccov just parses and prints, slather and xcov generate and beautify"
Monkey testing
Ruby:
Native alternatives:
- SwiftMonkey (2016-2022, archived)
puts "Ruby wins 🥳"
puts "It was easy indeed, wasn't it? "
Summing-up
| Domain | Ruby | Native alternatives |
|---|---|---|
| Automation in general | 👍 | |
| Package management | 👍 | 👍 |
| Management of executable packages | 👍 | 👍 |
| Docs generation | 👍 | 👍 |
| Logs decoration | 👍 | |
| Project modification | 👍 | |
| Automation of Xcode installation | 👍 | |
| Test automation | 👍 | |
| Test coverage reports generation | 👍 | |
| Monkey testing | 👍 | |
| Whose birthday is this? | 🎂 | 🥳 |
Thoughts
Apple let Ruby into its ecosystem of its own free will, and we can see firsthand how Ruby plugs holes within and around iOS workflows with its stunning frameworks and tooling for so many years in a row.
Time flies by, and Swift is gaining more and more traction and is becoming a more viable alternative to Ruby not only for direct iOS development, but also for development of executable and server-side tools. It is the future of iOS development and it’s only a matter of time before it becomes the future of iOS tooling as well.
With projects such as Tuist, which kind of took aim to copy-paste (and improve) the best of the best schtuff from Ruby to Swift, it becomes even more obvious. No matter how sad I am, it makes perfect sense. Swift is a more powerful language than Ruby and it’s much more convenient for iOS developers to use it for workflow automation as well as for software development.
After all, there is no smoke without fire:
Scripting language runtimes such as Python, Ruby, and Perl are included in macOS for compatibility with legacy software. Future versions of macOS won’t include scripting language runtimes by default, and might require you to install additional packages. If your software depends on scripting languages, it’s recommended that you bundle the runtime within the app.
© Apple
Anyways, I hope you enjoyed this post and found it helpful. If you, like me, don’t believe that Ruby will leave the iOS development realm anytime soon, and you’d like to improve your Ruby skills, I recommend you to play around with tools like:
They’re all great and will make your life so much easier while you cross the Rubicon and become a Rubyist 🤠
