We don’t hold on to a decision just because it was successful at the time. When a core assumption changes, we’re willing to go back and ask whether it’s still the right call. LLMs changed one of the core assumptions behind our 2020 decision, so we reevaluated our mobile stack from first principles.
What we found led us back to native.
I suspect we'll see a lot of large orgs doing this in the next year.
Thanks for the write-up. I'm curious if there's a shared core between the iOS and Android apps (e.g. KMP or Rust), and if so, what that looks like.
Also, any plans to open source Helix?
Thanks Mustafa! This was a great article—I'm curious, did you consider the non-technical / organizational costs in keeping the two codebases in sync as a separate factor? Do you foresee more organizational overhead as part of this decision? How are you planning to manage that? E.g. small implementation difference between the iOS and Android app increasing the support burden or bug burden and causing duplicated team effort.
Any education required for engineers to switch to native or the agents are handling the details on their own? Wondering if architecture or the new languages require ramp up.
Did you switch to SwiftUI or UIKit?
They created a mess in 2020 and hopped on over to a job at FAANG and now a fresh batch of Waterloo graduates want to do the same - maintaining somebody else's turds is beneath a Waterloo graduate on his way to becoming a manager who never touches code ever again :)
So it goes.
Yes, AI have changed the game, and now you can build and maintain two separate projects in Swift & Kotlin instead of one on React