We don’t self-identify as software developers but as web developers, backend developers, Android developers, or iOS developers. Many factors reinforce this specialization.
I’m a Droid
Building systems builds experience. Android developers learn technologies that have no analog on other platforms: activities, intents, and XML layouts. Once we’ve mastered the quirks of Android’s lifecycles that’s a superpower for writing even more Android code.
We build communities around these common skills. We’ve got conferences, meetups, Slack channels, and open source. These communities aren’t strictly technical; we also make friends and even get jobs through them.
And we’ve been tribal. Years ago it wasn’t clear how many mobile platforms would thrive. Windows Mobile, Palm, and Blackberry all had a chance. We didn’t want to develop for iPhone’s confined sandbox. Android is open!
iOS and Android have Converged
Our steady state is iOS and Android. Kotlin and Swift are more similar than Java and Objective-C. Our UIs were flattened and we’ve even stopped complaining about apps that look like iOS.
But our two platform steady-state sucks. Product teams have to build everything twice. Not only do the two apps need to work, they also need to be consistent with one another. Have you ever held a feature back because it wasn’t ready on the other platform? Yuck.
Avoiding Platform Imperialism
Kotlin Multiplatform is very promising. Android developers can write persistence, network, and model code that’ll run on iOS. With the right frameworks only the widget code needs to be done twice.
But I think we’re going to fail if we write a bunch of multiplatform-ready code and throw it over the wall. We’re going to make mistakes in modeling, packaging, and in recognizing what to share and what to duplicate.
Our iOS-developer teammates aren’t eager for unstable Gradle plugins, classpaths, and edge cases. That’ll earn Kotlin a bad reputation that’ll be difficult to shake.
Redefining our Identity
We need to self-identify as multiplatform developers. This isn’t going to be easy! We need to learn iOS development and the quirks of UIKit, Swift, and Xcode.
I propose that anyone who wants to build a multiplatform feature first build two single-platform features. Building for Android is familiar. Build that first! iOS will be humbling, but by that point we’ll already know how the feature works.
In the process we learn what’s actually duplicated and can be saved by multiplatform code. We develop a skill for anticipating where multiplatform code is best suited. Once we have that skill we should start to use it.
Let’s Multiplatform
Wanna double your impact? Ship to twice as many platforms. Multiplatform is an exciting frontier and I’m eager to explore it.