The not so hidden cost of sharing code between iOS and Android

+1 for Clang. It integrates with everything. But like most open source options, it plays second fiddle to each company’s primary languages, and so thee’s no one IDE so perfectly integrated into these mobile dev C++ use cases as to make it easy to work with, the way, say, you can be productive on .NET framework with either C# or C++. Google and Apple are both C++ compatible, or have native bindings, but... they target their examples and ease of use at the languages that best integrate with the respective IDEs. (Swift for Xcode, Kotlin for Android Studio) The end result is possible, but it’s like picking Cordova/PhoneGap/Electron for your native app. You’re going to struggle to use native technologies at some point, and there are few examples to follow. Allowing for the realization that 80% of your app code is likely platform-specific even if the UI doesn’t vary much means you can adopt new approaches and native UI conventions faster. It’s like the difference in programming speed when you simply target Chrome for your web development vs when you’re trying to write code that runs on Internet Explorer also. It’s getting to the point where platform functionality diverges so much that writing it but from the same design/spec/data model is faster than trying to maintain compatibility. Especially if you need to support multiple versions of iOS and Android in a backwards compatible way and with different UI conventions in different OS releases. Native is native, nothing else looks or feels like native, when that’s what you need, and there’s more hand-holding for apps when they follow the latest spec from the platform, rather than try to chase it with their custom bindings/implementation...

Note re. targeting a platform — often learning and reading some C++ is inescapable. For me, reading Chrome source code makes it easier to work with Puppeteer in JS, or deliver a better web app because I know how things work under the hood and it’s easier to read the C++ than the read the web standards themselves. Similarly, C++ really is portable and fast, so it shows up in many places. But on mobile, the mix of C++ to Swift/Kotlin should be 90%-platform native if your app is a traditional CRUD app that deeply integrates with the platform. If it’s simpler than that, build a website, or if it’s a game engine or some custom UI, use that, sure, but if you want to benefit the most from Apple and Google implementations, native (with shared spec/data models) is the way to go...

I think many of the best programmers would jump at the opportunity to work with Rust. That might change if the language de jour changes but working with rust is a positive for many of the best people right now.

I see you haven't worked on that level (or maybe you are young)....

First, unreal/unity work at a different level of the hardware, and they have to deal with different graphic drivers, in the same type of the OS.

But keep in mind that they are not the end product! The end product is the game that run on them.

So, the cost to building a multiplatform game, is having a whole Game Framework (which are whole companies), to deal with the lower level details and help abstracting out the differences of the platforms.

Dropbox is the end product. So, to make the code shareable, they have to build something like the equivalent of a game engine....

which is not a simple task....

I have worked at Spotify, and we had a lower level library to help (built in C++) to help out with some of the common features across platforms. It was ported from the desktop app, to iOS and Android, and it was a separate project. Over time, as features kept piling in, it turned into a giant un-manageable mess. It got so bad at some point, that we had to skip a couple of scheduled releases to clean up/fix some of its issues.

The problem became even worse when Spotify tried to build a unified UI on top of it (HTML 5 based), with a bridge layer to the C++. The idea was to write once, and (haha) run it everywhere. It failed, for the reasons many of them failed in other companies as well (facebook was doing HTML5 at the time as well).

That got removed, but the problem still remains that "Core" got overly complex as many platforms had their own features, which often were "one off", A/B testing, to see if it works or not. And separate teams (iOS, Android, and Desktop) had their own schedule on this. (It makes perfectly sense to A/B test one feature in Android, and another one in iOS, to see if people even like that feature before making is x-ross platform.

Common platform code, massively slowed down A/B testing of new experimental features, and thus it was a huge cost to the company.

The only solution to this was to keep the common "Core" (as it was called), to the most minimal features needed, and mostly related to playback (ie. song retrieval, caching, retrieval, decryption, playback, and some account features).

Do, the A/B testing on the platform level (iOS, or Android), of it was successful then roll what made sense to the rest (but still trying to keep core as lean as possible).

But since I left few years ago, things might have changed again....

OK, but they didn't attempt to use Qt.

I'm currently working on a project where we have indeed decided we needed to go Swift/Kotlin native on each platform, but with the long-term goal of building a cross-platform app with Qt.

Qt certainly has its issues, but I respect what its developers have accomplished. And it appears to offer adequate ways to do common things like parse JSON, and it abstracts things like Bluetooth usage and file storage in the apps' sandboxes; so I don't see some of the hurdles cited in this article.

Xamarin is open source now.