I just launched (like, an hour ago: https://news.ycombinator.com/item?id=20700196 ) a cross-platform app that is almost all shared code. In my case, the solution is a web app with very lightweight native wrappers, and I'm quite happy with it. Obviously that wouldn't be the perfect fit for all apps, but none of Dropbox's "(not so) hidden costs" are relevant in my case, and I suspect many apps would be a good fit for t…
Most cross-platform solutions are great in the beginning and then the problems start to come to surface as teams grow, requirements change, bugs are harder to track down, code needs to be updated, the next hot cross-platform framework comes along with new promises, etc.
The not so hidden cost of sharing code between iOS and Android
101–110 of 335 posts
Re: The not so hidden cost of sharing code between iOS and Android
#102Earlier quoted context omitted.
Yeah, I have 15 years of C++ experience, but not since 2012. So with C++11 and C++17 (and soon C++20) my skills have not aged well, even though I can still write C++03 just fine. It's no wonder 'senior' devs prefer to use plain C, where even C11 is not that different from C99.
> my skills have not aged well I don't think that's necessarily the case. C++'s famed backwards compatibility, source of so many issues, is also a fabulous strength. There's nothing stopping one from writing C++03, while gradually adapting C++11 and beyond as time/circumstances permit (which is what I'm doing at my job, maintaining a massive legacy codebase while stymied by slow uptake on newer compilers by my corpor…
Re: The not so hidden cost of sharing code between iOS and Android
#103Recently worked at a company doing similar to this to support Windows and macOS. To add to the difficulty, they used Chromium as a UI front end much like Electron. All built in house though. They hired me as a JS/HTML/CSS dev, but same as the article states, the C++ work was the true bottleneck. They knew I had some C++ chops and set me to work doing C++ with a sprinkle of JS here and there. Due to incompatibilities…
My current work has me on a single C++ code-base for Linux, Windows and MacOS (not electron though, just native). You can avoid a lot of headaches by avoiding the platform specific tools and instead cross compile using clang with a build system that works on all platforms (eg. ninja + meson).
Re: The not so hidden cost of sharing code between iOS and Android
#104Re: The not so hidden cost of sharing code between iOS and Android
#105I have come to this same conclusion after many years. It's not cost-effective to have any bespoke business logic (models, controllers, etc.) shared between the two mobile platforms (don't get me started on sharing UI code). If you have some incredibly tricky low-level algorithm/library and/or need for speed, think database, crypto, intense graphics, etc., then fine, you may be able to swing a shared module in C++ or…
The article says it all - they chose the wrong language with no community support for the trail they were blazing and that technical debt destroyed their productivity. I achieved 90+% code share in Xamarin including UI across windows - ios - andriod. 100% buisness logic shared. You can write cross-platform UIs, and swap out to native code on a widget by widget basis. Threading is seemless. Sure it has its own set of…
I'd be happy to hear if the project you worked on has been cost-effective to maintain in the long term. Then at least someone has seen the mountain top!
Re: The not so hidden cost of sharing code between iOS and Android
#106The overhead of the JNI interface is quite a lot of work too. Luckily I had a UML model that I generated the interfaces out of, so adding JNI was just a matter of templating this out of the UML, but it was still quite a bit of work.
On iOS the situation has gotten worse in that the interface between Swift and C++ has to go through C, so if you are using C++ you need a special interface layer, which is almost like the JNI situation on Android.
So you have the trade-off of on one hand having two code bases (Swift, Kotlin) and the associated headache of keeping them in sync, versus the extra work of maintaining the C++ interface layers and testing and debugging on each platform. In the end I now believe that it is better to work with the platform native development tools rather than trying to share C++.
As far as finding developers goes, because of the rarity of using C++ on mobile there will not be a lot of developers with this experience. I work remotely and have found that any remote C++ work is very rare, Swift and Kotlin are a lot easier to find work with (it's still more difficult that you would think to get remote work of any type).
Re: The not so hidden cost of sharing code between iOS and Android
#107Until very recently, Dropbox had a technical strategy on mobile of sharing code between iOS and Android via C++. The idea behind this strategy was simple—write the code once in C++ instead of twice in Java and Objective C.
A lot of people will stop reading after this, for those interested they could continue with the details.
Re: The not so hidden cost of sharing code between iOS and Android
#108Earlier quoted context omitted.
I wonder if that is a symptom of C++ having many recent revisions, thereby influencing, misleadingly, the definition of "experienced".
Yeah, I have 15 years of C++ experience, but not since 2012. So with C++11 and C++17 (and soon C++20) my skills have not aged well, even though I can still write C++03 just fine. It's no wonder 'senior' devs prefer to use plain C, where even C11 is not that different from C99.
Re: The not so hidden cost of sharing code between iOS and Android
#109Re: The not so hidden cost of sharing code between iOS and Android
#110Airbnb admits if they were able to greenfield React Native then there's a world where it would have worked.
Separately, the complexity of Airbnb and Dropbox as apps is very high compared to what I believe are the ideal use cases - simple interface apps that are thin wrappers on top of APIs.