Write Once, Run Anywhere
Recently someone asked me: “what’s a hill in software that you’re willing to die on?”
After thinking for a minute, my answer was that “write once, run anywhere” solutions are almost never worth the compromises. When I first started writing iPhone OS apps (in summer of 2008), I was working with someone who was advocating for a javascript and HTML solution to writing mobile apps, that would allow us to get “near native” appearance and performance without the overhead of learning Objective-C, and the potential payoff of deploying the app to other mobile platforms if it was desired down the line.
Let’s break that down.
Pros:
- Developers don’t need to learn a new programming language
- Developers can potentially port the application to another platform with little work
Cons:
- Consumers receive an application that doesn’t quite work like they’re expecting based on environment norms
- Consumers receive an application that doesn’t meet the performance of a native alternative, leading to potential battery and resource drain
In this hypothetical scenario, the consumer is the one making all of the compromises, while the developers reap all the [marginal] rewards. In our case, we experimented with the cross-platform solution, but as we looked objectively at the app from a consumer perspective, we decided the trade-offs in application performance and UI/UX consistency weren’t worth the potential benefits to our workflows.
Now I’ll be the first to admit that cross-platform solutions have come a long way since 2008, with React Native, SwiftUI, Flutter, Electron, Xamarin, and others all competing in the space and delivering closer to native performance. Often, the pros and cons are much longer lists than the ones I presented above, but I’d contend that the benefits are still largely inherited by the company/team/developers, and the compromises are generally passed on to the consumer.
I fundamentally believe that’s a bad tradeoff.