Adopting New Languages and Frameworks
When should we onboard to a new language? Should we start to use a new and promising framework? Unfortunately, there are no simple answers and even when you do your research, you might regret the decision you take.
In 2016, Swift was at version 2.2. The engineering team at Uber decided to go 100% with Swift when rewriting Uber’s Rider app. The decision turned out to be an almost disaster - mainly because the team did not expect the binary size for Swift to be multiple times that of Objective C. Former mobile platform manager Chris Brauchli explains the problems in more detail in this post.
Having learned from the experience, Uber took far more care to evaluate every aspect of adopting a new language. For Kotlin, the team did extensive evaluations and performance measurements - and as of summer of 2020, Uber still did not adopt the language, as not all reservations were resolved.
You’ll want to invest effort to evaluate a new language or framework that is in line with the work adoption would mean, and the risk it carries. Uber spent a large effort to evaluate Kotlin, as rolling it out would have impacted hundreds of Android engineers, and apps that generate billions of dollars of monthly revenue.
Areas you’ll want to evaluate are similar to how you’d evaluate cross-platform frameworks. On top of those considerations, areas worth taking into account are:
- The maturity of the language/framework. How stable is the API? Are there success stories of using the language or framework in the wild that are relatable to what you’re trying to build?
- Migrations coming up in the future. If you’d adopt this language or framework, would you need to migrate existing code over? How large would the effort be?
- Engineering enthusiasm. Is this a technology engineers would be excited to work with? Is there enough support in the team to go ahead with potentially adopting this technology? What rate of the team is sceptical of the technology and why?
- Risks. What are the things that could go wrong? How could these impact the app, customers or the business?
Building a smaller “pilot” project with the new language or framework is a great way to get a better feel for it, and to answer questions about usability, obvious issues and tooling.
My personal approach is supportive of trying out anything new - but in a way that limits the “blast radius”. Can we use the new technology in a less important part of the app? Can we experiment in an app that has smaller usage numbers? Could we start by making a change in a way that only company employees test this new setup, before we move further?
Mobile engineering keeps evolving, and so will the languages, frameworks and tools that we use. We should be unafraid to try out new approaches - but stories like Uber’s Swift rewrite should serve as reminders of what can happen when you have no “plan B”.
You are reading an early draft from the book Building Mobile Apps at Scale. For the final, expanded and improved content, grab the book now - it's free to download as a PDF until 31 May.
Building Mobile Apps at Scale
"An essential read for anyone working with mobile apps. Not just for mobile engineers - but also on the backend or web teams. The book is full of insights coming from someone who has done engineering at scale."
- Ruj Sabya, formerly Sr Engineering Manager @ Flipkart