A reflection of migrating from Swift to Objective-C
Last week was WWDC 2019. I still watched most videos although I have migrated myself off the iOS career for almost 1 year and half ( I am still using all Apple devices).
When I moved away from the iOS team, we also started a company wide migration to get off Swift. The reason to have such a migration is not primarily because Swift sucked, but more:
- On the business side: we want a smaller app. Swift bloats the app size and that slows down the growth of app activation. We also want the app to launch faster. Apps written with Swift < 3.0 is 20% — 30% slower than its equivalent Objective C apps.
- On the technical side: we want to rearchitect the app to bring in a couple innovations from the frontend services and this would also requirement an overhaul of the client architecture. Another reason is apparently — Swift sucked at its tooling and IDE support.
So the question the team answered, at the end of 2017, was: if we wanted to choose a language to overhaul the app, what would we choose?
The conclusion was Objective C.
What I want to reflect here is — if we were to make a decision now, in 2019 instead of 2017, on the language choice, what would that be? How could we do better back in 2017?
There are a couple questions I want to discuss on in the post:
- Which language would I choose to use now?
- Which language would I choose back in 2017?
- How could we do better back in 2017?
Which language would I choose to use now?
If we were to build a new app scratch now, I would choose Swift. However, it still would not be a no brainer decision, because Swift is still immature. I would form a tiger team and meticulously perform another round of evaluation for feasibility of using this language at scale, but it is slightly easier than before since —
Apple is clearly committed to Swift.
The ecosystem around Swift is evolving much faster than I’d expect. There was a debate if Swift is just an experimental project that Apple would eventually dump Swift and revert back on Objective C. One of the reasons is Apple doesn’t write any of its main iOS apps in Swift, the other reason is there is no new foundation libraries written in Swift. There were also rumors that folks inside Apple don’t like Swift.
No longer true, Apple is committing more and more resources into Swift. The language is stepping out of its infancy and moving to adolescence. Why? There are more and more focus on language performance / stability / usability and tooling.
- ABI is there since Swift 5. Besides it makes it possible to run apps & libraries with built by different version of compilers, it also improves apps loading speed by 5% (source from Apple) since we no longer need to load language runtime during app launching. This also vastly reduce the App size by 10% — 15% (from Apple).
- Apple has started building the foundation and a slew of supporting libraries with and for Swift, like SwiftNIO, SwiftUI, Combine, Advances; Apple is cleaning baking more and more modern design patterns and language choices into Swift.
- Productivity & Stability are emphasized. It is a bit surprised to see SourceKit mentioned in WWDC and a sourcekitd Stress Tester tool introduced. Even though this should have been built on Day 1, but it is better than never happened. SourceKit was the main culprit of Xcode crashes and index failures. Running verbose mode SourceKit in Xcode against our code base used to surface more than 3000+ errors. A lot were caused by incompatibility of the understanding of Swift language between compiler & sourcekitd — it compiles (either correct or wrong), SourceKit could not interpret what is going on, although they live in the same code base.
Other reasons to use Swift?
- Talent
If there is one thing is that prevails any other priorities, that would be HIRING. Attracting the best talents is definitely a #1 priority for any team, organization or company. Selling Swift to candidate is a clear win to compete with other companies. When I used to interview iOS candidates, I always sell people that we are building the largest ever Swift apps, join us and embrace the future.. now we avoid talking about that. This also hurts talents retention.
2. Apple Owns the Platform
Apple owns the platform, working against the platform provider as a user won’t work. It is also clear that Apple doesn’t give a s*** about enterprise users. Unless you want to dump the whole Apple platform, we would have to conform to the Apple way. Apple also deprecates things fast and move people its way at all means. So there is a possibility of Apple providing less and less support for building apps with Objective C.
We could tell this from its high latest OS adoption — 95% of iOS users are on iOS 11+, 85% of the users are on iOS 12, comparing with Android’s miserable 10% adoption of its latest OS. One reason is Apple would try all ways to upgrade you to latest iOS — frequent prompts, automatic upgrade, etc.. The other reason is Jail Break is no longer popular. I am a bit surprised its promotion of iCloud storage hasn’t led to any antitrust investigation btw..
Apple also upgrades Xcode aggressively by forcing developers to upgrade to latest Xcode. You can’t upload iOS to App Store with older version of Xcode. If Apple made the determination to move away from Objective C, it might deprecate existing UIKit just like CarbonKit.
3. Community is moving to Swift
The force is strong with Swift. From TIOBE index, Swift climbed 4 ranks higher Y/Y:
Community owns open source and dictates the prosperity of a language.
When would it be a no brainer call to use Swift?
I would argue ~2 years later, after more foundation level libraries built for Swift becomes stable, like SwiftUI.
Which language would I choose back in 2017?
At this point, some folks might blame the previous decision to move to Objective C, since the team is still migrating our old Swift code to Objective C. In the meantime, Swift is becoming more and more mature. However, that is base on current observation, there are many things we didn’t know back in 2017:
- Apple’s commitment for Swift.
- Effort to migrate of Swift to Objective C. Migration half a million lines of Swift to Objective C is hard.
- Learning curve of Objective C. Most iOS new hires since 2015 only know Swift. They never learnt Objective C and the learning curve for Objective C is huge. Standardizing the code style for Objective C is also hard since we didn’t have enough Objective C gurus.
I don’t have a good answer for this but there are definitely lessons learnt.
How could we do better?
There are a lot of learnings for this exercise:
- Avoid Immature Language
We chose Swift for the new app without enough investigation. The conclusion was drawn based on the success of using Swift for a much smaller application (2–3 developers). We also didn’t expect the team to grow from ~10–20 iOS engineers to a scale of ~150 iOS developers. If we knew the iOS engineering scale would be 100+ engineers, perhaps a more thoughtful decision would be made. Apple could be blamed for launching Swift 1.x while the version should be 0.1 or 0.0.1, but picking a new language at our scale could have been more thoughtful.
This leads to another discussion of Java vs Kotlin for Android. Should we embrace Kotlin now if we write a new app? Maybe, since it comes out of an IDE company (JetBrain) so tooling is insured. Google announces Kotlin as first class citizen so it is certified by Google. There are many big heads using Kotlin: Pinterest, Evernote, Coursera, Uber, etc.. an analysis before making a call is anyway needed.
- More Investment in Tooling and Swift Compiler
I don’t think we invested enough in the language. The infrastructure team should have taken a lead to look deeper into the open source Swift project and collaborate with Apple to improve Swift. If 50% of the productivity was lost due to the language, we could spend at least 25% of the resources to fix Swift.
Since Swift is open sourced, we could even send a tiger team to set up weekly syncs with Apple compiler team and evolve Swift faster. Folks might argue Apple won’t allow that due to its secretive culture, I disagree with this since as an open source project, there aren’t many secrets we could not discuss — the evolvement plan is in GitHub.
Still ❤ iOS.