In the age of AI slop, it’s worth noting that this article is not AI-generated and is based entirely on my own thoughts and experiences.
Modern iOS development has changed dramatically in recent years, and by 2026 the ecosystem feels very different from what many of us learned even a few years ago.
As much as we love to hate Apple's decisions lately (Swift concurrency and liquid glass, for example), there has also been a buildup of quality-of-life improvements over the past few years. Let's go over a few of them.
Swift Format
- First, we had the community-maintained SwiftFormat, introduced in 2016. Later, Apple introduced swift-format in 2019.
What was the issue?
- Both needed manual installation steps, and a way to manage their versions, so choosing one over the other was a matter of personal preference.
How did Apple fix it?
- With Swift 6 (Xcode 16), Apple now ships its formatter as part of the official Swift toolchain, which made the choice obvious for me.
Buildable Folders
What was the issue?
- Xcode used to use groups (references) to handle the project structure (its files and folders).
- Imagine running into one of those real it works on my machine™ situations where the project builds only because it references a file on someone’s desktop. What a mess!
Why were project generators needed?
- Teams needed a reliable way to ensure the project would build consistently across machines and CI environments.
- So, we used third-party packages like XcodeGen to ignore the
.xcodeprojfile from the source control and generate it locally or in CI. - This ended up saving time fixing the dreaded
.xcodeprojconflicts that slowed development and required constant manual fixes.
How did Apple fix it?
- Xcode 16 introduced buildable folders as the default project management method, allowing Xcode to map the exact directory structure of your project as you see it in the Finder—no more surprises.
- Existing projects can be migrated to this folder-based model, enabling teams to remove third-party project generators.
Asset Catalog Symbols Generation
What was the issue?
- Assets like images and colors used to be accessed in code via strings, making them very error-prone and offering no code completion or compile-time errors. If you misspelled a resource's name, good luck catching that at runtime.
Why were code generators needed?
- Teams used SwiftGen and R.swift, and these are the benefits straight from SwiftGen's repo:
- Avoid any risk of typo when using a String.
- Free auto-completion.
- Avoid the risk of using a non-existing asset name.
- All this will be ensured by the compiler and thus avoid the risk of crashing at runtime.
How did Apple fix it?
- Xcode 15 introduced Asset Catalog Symbols Generation, which provides Swift and Objective-C symbols for each color and image in the asset catalog.
- But there is a gotcha here: these symbols are internal and can only be used within the same target. They can’t be accessed by other apps or packages.
- It’s worth mentioning that all of this is a no-brainer for the Android guys, as they have had their type-safe resources (R class) since the beginning of time (Android SDK 1.0).
String Catalog Symbols Generation
What was the issue?
- Localizations had the same exact issues as the other resources (no code completion or compile-time errors), plus they had unique challenges, like incomplete translations for some languages.
Why were code generators needed?
- Again, same as the other resources, so I won't repeat myself here.
How did Apple fix it?
- It took some time from the introduction of String Catalogs in Xcode 15, replacing the old
.stringsfiles, to the arrival of type-safe Swift symbols generation in Xcode 26. - But now we have what the old generators did and then some, including visual indications for incomplete translations and auto-generated comments to better understand the context of each localization key.
- For a complete rundown of what’s new in localizations, I recommend watching this WWDC video.
Swift Package Manager
Why were dependency managers needed?
- Of course, I was going to talk about SPM; this is by far the most drastic change in the ecosystem. For years, Apple did not offer any way to consume third-party dependencies in our projects.
What was the issue?
- Whether you liked CocoaPods or leaned towards Carthage, you must have used one of them at some point.
- Most of the projects I worked with used CocoaPods, so get ready for a jump down the rabbit hole:
- CocoaPods was a dependency manager for your Xcode projects.
- CocoaPods is written in Ruby.
- So CocoaPods itself as a dependency is managed by RubyGems.
- RubyGems is distributed as part of Ruby.
- Ruby has to be managed to avoid version mismatches using tools like rbenv.
- But ... rbenv itself is written in shell.
- So it is managed through Homebrew.
- See?
- You had to install a dependency manager for macOS (Homebrew).
- To install a Ruby version manager (rbenv).
- To install Ruby.
- To install CocoaPods.
- To install the dependency that you forgot by now why you needed it in the first place.
- I will stop at this point because it is getting personal for me.
How did Apple fix it?
- Like doing what should have been there since the beginning.
And that's it. For me, this is what qualifies as a complete replacement for old tools or dependencies, but there are still some honorable mentions to keep your eyes on:
- Swift Testing as a replacement for the BDD testing framework Quick.
- AsyncImage as a replacement for Kingfisher and SDWebImage (once it supports caching).
- Compilation caching to finally make the Xcode build system as efficient as Bazel.
- swift-configuration as a replacement for arkana.
- Xcode Cloud as a replacement for Bitrise.
In the end, I want to pay my respects to the people behind all the tools mentioned, built by the community, for the community. You were there and continued to enrich the ecosystem where Apple was lacking.
I know it’s not an easy feeling to get sherlocked. I truly appreciate you and all the hard work you’ve put in.
