An Ode To Cocoapods And Realm
An Ode To Cocoapods And Realm
Honoring two of the most game-changing iOS SDKs in light of their recent announcements
Recently, two of the most influential SDK’s in iOS history made major announcements that they were entering maintenance mode (one with intention to enter End-Of-Life).
As I approach my own milestone of a decade of iOS development, it felt personally prudent to honor these legends and briefly discuss their impact on iOS. Therefore, this is a special post compared with the others. I’ll also discuss my understandings of what drove them to this point and what developers can turn to, instead.
Cocoapods Brought Brilliant Code Together
CocoaPods is a dependency manager for Swift and Objective-C Cocoa projects. It has over 101 thousand libraries and is used in over 3 million apps. CocoaPods can help you scale your projects elegantly.
Thirteen years ago, in the year 2011, Objective-C was THE programming language for iOS. This period in time also saw the words “open source” become a rapidly growing buzzword. Github (years before it was bought by Microsoft), SourceForge, and other online repository hosts became hotspots for developers to share more and more useful chunks of code and/or to consume code into their own projects.
For iOS Developers eager to try a cool new library, the process was manual and tedious. They would need to decide if they should:
Copy/paste the code directly into their project
Create special sub-folders in their project to place downloaded code
Build static libraries and pass them around into their projects (mind you Apple bundled frameworks didn’t come until 2014 with iOS 8)
While the excitement was real and growing, manually managing dependencies, their versioning, and code conflicts was still a hill to climb. A developer would really need to count the cost before taking the leap of including another item to track in their project.
The Dawn of a New Day
The idea of “package managers” had already begun (Javascript got npm, .NET got NuGet, both in 2010). Since mobile app development was one of the hottest and most profitable spaces in software development, it only made sense that one would emerge for iOS.
And boy did Cocoapods change everything.
The project streamlined adding and managing dependencies (Pods), making it easier for developers to test-drive and decide to include libraries in their project with greater ease and reduced stress/risk. It even helped teams better consider more modular approaches to their own in-house projects, breaking up code into shareable and maintainable private libraries and frameworks.
In the quote I shared from the Cocoapods site, "over 101 thousand libraries and is used in over 3 million apps" are incredible stats. Bearing in mind that Cocoapods works for Swift and Objective-C projects across the Apple ecosystem, there are over 2 million apps in the App Store. That’s tremendous reach and demonstrates the impact Pods have had.
SPM and the Decade-Long Rivalry
Swift would be released in 2014 and Cocoapods was there to help new Swift code be shared around the community as it slowly, but surely, began to adopt Apple’s latest language. This was especially essential as Pods helped share libraries that closed key gaps in Swift at the time (e.g. AlamoFire for networking, SwiftyJSON for encoding/decoding).
Just a year later, in 2015, Apple announced Swift Package Manager. While Cocoapods had the initial advantage of being more mature, known, and language agnostic, SPM was a first-party contender with the support of the language’s owner and maintainer. It was a clear rival with actual teeth, a sign that Cocoapods was (potentially) doomed to be Sherlocked.
In 2019, Xcode 11 released with SPM integrated directly into the IDE, giving it an unmatched edge over Cocoapods. Libraries that had previously been exclusive setup with Pod support now offered SPM (and Carthage) support, as well.
Declaring Maintenance-Mode
Last month, on the Cocoapods blog, the team addressed the long running rumors and speculation directly by stating “We're still keeping it ticking, but we're being more up-front that CocoaPods is in maintenance mode.”
It’s clear that SPM is the main cause for Cocoapods reaching this stage. It’s hard to compete when:
It’s first- vs third-party
You’re excluded from built-in IDE features
You’re team is “Volunteer Driven, Community Powered” vs a “Trillion Dollar Company”
That last part is not meant to be a dig. After all, it was the budding open source community that drove the value of having package managers in the first place. But ultimately, as Swift’s first-party, Apple has a vested stake in the success of Swift and the tools that support it (the combination is important, as having a company backing a product does not ensure success as we’ll see with Realm).
Cocoapods won’t just disappear, though. Millions of apps literally use Cocoapods, and until they switch over to SPM or some other solution, there’ll be a need for maintenance. Some libraries/SDKs still recognize Cocoapods as the traditional package manager of choice. One example I’ve seen was how Kotlin Multiplatform only exported frameworks, xcframeworks, and Cocoapod-driven projects for years before recently adding SPM support.
Realm Challenged “The Man” And “The Status Quo”With Actual Better Storage
It’s 2014. Persisting organized data on mobile had a few solutions: some SQL-based solution (e.g. SQLlite) or Apple’s Core Data. While they all got the job done, they had a common problem: they were slow and bulky.
By recognizing the need on the mobile field and starting from the ground up, Realm developed a secret sauce that allowed them to boast incredible storage speeds. Equally as awesome, it was lightweight, meaning it didn’t have such a hard impact on overall app build sizes (a burden that many SQL-like frameworks packed on to bundles).
Breaking From Tradition
Database solutions like SQL or Oracle grew in popularity (and size) because they offered enterprise-sized solutions to massive data needs. Today, it’s common to think about setting up data on a cloud-based solution with the ability to scale storage and features to needs. But traditionally, database solutions NEED to handle data-sources, permissions, groups, serialization, all while usually running from in-house resources. The features that these solutions come with are incredibly complex and intertwined.
When applying these solutions to mobile, the thinking was to bring these solutions over. There was some consideration about how to scale them down (hence SQLlite). However, they usually came with some of the huge overhead that served network based solutions best, but were often really unnecessary for simpler, local storage needs. Making things worse, there was a hardware drawback, as well. The read/write of persistent data “on to disk” was not nearly as quick on devices as it is, today, creating a deadly combo for any data operations.
Realm capitalized on this by thinking this way: let’s start from scratch, prioritizing local storage, and write it in a universal/optimized language like C++. This gave them a significant edge over the other bloated solutions (yes, even Core Data). The speed was noticeable and, because it didn’t require so much bloat code, left app bundle sizes relatively unscathed. After getting the attention of the mobile community, including big companies like IBM, Realm went 1.0 in 2016.
The eventually released a mobile platform solution, allowing for real-time syncing of updates, as well as a Node.js SDK to create a seamless server-side solution.
In 2019 they were acquired by MongoDB.
The Easygoing Cool Kid
I remember Realm being quite popular. They had a great tech blog, recordings of tech talks at their offices, and a cool logo that quickly ended up as stickers on laptops and water bottles of mobile devs everywhere. Somehow, someway, even if you didn’t use Realm in a project, you knew of them.
At the time, being only a few years into mobile development, myself, Realm felt incredibly more accessible, simple, and low impact for my side-projects than anything else. It felt so powerful and flexible that I even used them in Server-side Swift projects I had made, too. I was so enamored that I wrote an article on one of my earlier blogs about them: Realm.
The Road to Planned EOL
Other competitors would begin to emerge, such as Firebase Realtime Database and Supabase. And ever since being acquired, MongoDB’s own brand began to overshadow Realm’s. Just last year, Realm was renamed as Atlas Device SDK, officially dropping the Realm brand to become a MongoDB product proper.
This month, MongoDB announced that Atlas Device SDK (Realm) would reach end-of-life next year on September 30. The announcement seemed to come out of nowhere (as expressed in this Reddit post) and, unlike Cocoapods plan to enter maintenance mode for the long term, leaves developers who had choosen Atlas in need of a new solution.
As mentioned, there are already a few alternatives out there. And with the announcement of Swift Data, there’s even a first-party solution that offers tremendous integration benefits with SwiftUI based apps. But to see such a strong, game-changing library meet it’s demise like this leaves this fan feeling nostalgic about the early days (and wondering wear that one unused logo sticker might be in my office).
We Salute You
There have been many framework, libraries, companies who have come and gone over the years. It’s the natural evolution of things (yes, even Sherlocking counts within there). Evolution can be a good thing, but it’s also important to “know our roots” and the important lessons we can learn from them.
For two legendary titans of iOS development to make their announcements so close together, I couldn’t let that pass without taking notice. So no SwiftUI tips, tricks, or oddities this week. Instead, the Captain asks that flags fly at half-mast and that we salute those who blew such strong winds into the community and technology we love.
Here’s to you, Cocoapods and Realm. Thank you.