Thoughts on Cross-platform

Problem statement

  1. I always felt a strange disconnect between the work done in different platforms. In specific, with Android. I am not aware of the challenges they face, open bugs, feature parity, and ultimately care as deeply for their platform as I care for mine.
  2. I don’t like that a feature needs to be implemented, reviewed, debugged and maintained multiple times.
  3. I want the user experience to feel/be native.

Looking at the problem statement, it reminds me of the Speed/Cost/Quality triangle. One can maximise/focus on two, while sacrificing the other.

Personally, I am willing to sacrifice 2) while maximising team dynamics/tightness alongside user experience.

Potential Solutions

  1. Cross-platform technologies like React Native and Flutter.
  2. Polyglot developers doing the same feature across multiple platforms.
  3. Fix at the organisational level.

1. Cross-platform

Cross-platform, does particularly well on team tightness. The same engineer will likely work on the same feature for both iOS and Android. It also means there is no distinction between an iOS or Android developer: they are within the same mobile team. Depending on the technology used, there might be a need for an Android engineer to do particular parts natively. Because of that 2) is not fully realised. Finally, depending on the app requirements, 3) can be solved. From the whole range of technologies, there are different degrees of how much is covered by the technology. For instance, one can use Kotlin/Native to just target the model layer, while Flutter could cover the entire app.

This is an anecdotal example, but I know a team using Flutter that can fill all 3 requirements, given their app requirements.

2. Polyglot developers doing the same feature across multiple platforms

This approach does particularly well with 1) and 3). There’s a sacrifice over code reusability , but we can fully commit to given the best experience to the end-user, while strengthening team dynamics. This also implies that an engineer is proficient in two distinct platforms and languages. I rarely seen this, although pair-programming can mitigate the problem.

3. Organisational fix

This fix is aimed at problem 1). It doesn’t touch problem 2), since codebases are still separate and implicitly solves problem 3). Aligning architecture, nomenclature, data flows, code reviews can help. It does however require higher number of sync-ups. Alignment within the same team, as it grows, can become a full-time job. An iOS engineer under these conditions, is not doing Android development. Code-reviews cross platform, if they exist, are likely shallow. Breaking silos, as per the thread’s discourse, is a truism. It’s difficult to understand what an organisational fix entails tho. Cultural? Processes? Documentation? A mix of everything? Independently of what it entails, I do not believe it touches the crux of the problem. If there’s a bug on the Android app, am I able to fix it? Am I as concerned, or annoyed as if it was with iOS? Solution 1) and 2) do that implicitly, since we are directly touching the code.

As usual, there is no silver bullet for this problem. When I sent the tweet, it was more as a wishful thinking than a reality we can fully execute these days.