Do people still regularly try to ship common platform code as a shared C++ library to minimise unique code bases for their mobile apps? I recall reading years ago Dropbox trying this, but in 2018 is this really the best approach we have?
I can see why it might potentially be attractive in purely architectural terms, but I wonder if the “savings” meaningfully materialise in practice when so little pure native development occurs in C++ on iOS and Android.
Regardless, there’s still a complexity cost - unique native platform UI code is still unique native code, plus all the localisation, QA testing, etc, etc fun that will entail for an app the size of Slack.
> Do people still regularly try to ship common platform code as a shared C++ library to minimise unique code bases for their mobile apps?
I think Microsoft Office does this too, and I’m pretty pleased with the results, performance and UI wise. In my opinion, this is probably the best way to actually do decent cross-platform development. One of the projects that I am tangentially involved in is doing this, but swapping out C++ with Rust.
> I recall reading years ago Dropbox trying this
Last I heard, Dropbox has moved towards using Python for everything, which gives them kinda horrible performance IMO.
> I can see why it might potentially be attractive in purely architectural terms, but I wonder if the “savings” meaningfully materialise in practice when so little pure native development occurs in C++ on iOS and Android.
Generally, all the cross-platform, UI independent bits go into the framework, and then you write a thin UI layer on top of it using your platform’s native UI APIs. The benefit of using C++ is that you can call it easily from most languages.
> Regardless, there’s still a complexity cost - unique native platform UI code is still unique native code, plus all the localisation, QA testing, etc, etc fun that will entail for an app the size of Slack.
Ok, sure, but most of this work has already been done for their iOS app. I’m making a shot in the dark here, but I’d think that given access to their iOS project I could whip up something passable within a couple of months, if not less.
> Last I heard, Dropbox has moved towards using Python for everything, which gives them kinda horrible performance IMO.
The opposite is the case. New components are typically written in Go on the backend, Rust in the sync engine and the respective native toolchains on mobile platforms.
I was tech lead for a project that did this, about 7 years ago. C and C++ for all the business logic and core functionality. Objective-C, Java, and Qt for native bits. Worked great and was the obvious solution that allowed for shared code. I don’t see why you wouldn’t do the same thing today. The capability is still there.
I’ve lived through decades of promises of “write once run everywhere” development technologies but they have always come with significant drawbacks vs native applications. Performance, memory footprint, native look and feel, ability to take advantage of os specifics.
Facebook shares a huge chunk of core code between Android and iOS with C++. Even with Electron, VS Code also writes a lot of the core modules in C++. At the end of the day, it's just a clever way to write performant code that can be shared.
I can see why it might potentially be attractive in purely architectural terms, but I wonder if the “savings” meaningfully materialise in practice when so little pure native development occurs in C++ on iOS and Android.
Regardless, there’s still a complexity cost - unique native platform UI code is still unique native code, plus all the localisation, QA testing, etc, etc fun that will entail for an app the size of Slack.