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 the architecture I went with.
The not so hidden cost of sharing code between iOS and Android
21–30 of 335 posts
Re: The not so hidden cost of sharing code between iOS and Android
#22Recently 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 in the compilers, there was a rats nest of dependencies, thousands of #ifdef’s to cover differing OS implementations, and we had to use some of the oldest versions of C++ to be compatible with both XCode and Visual Studio.
As the article states, we had custom background job libraries and debugging them was a nightmare.
Also similar to the article, we spent more time than one ever should setting up builds to handle our ludicrously complicated build configurations.
And lastly, as the article stated, we had a hard time finding new talent to cover the growing amount of work required to deliver our product. There just aren’t many C++/JS devs out there.
Re: The not so hidden cost of sharing code between iOS and Android
#23This is precisely the experience of my startup trying to rely on flutter. It's a constant battle. Moreover Android and iOS are different implementation with different capability with constantly evolving API. It's hard to keep cross platform code in sync many #ifdef with edge cases.
Moreover with REST API architecture majority of the common code is in back-end. So building in Swift and kotlin for respective platform is not as tedious.
Re: The not so hidden cost of sharing code between iOS and Android
#24There's quite a few places that are still dealing with 4 codebases with varying degrees of shared code. Desktop, mobile web, native Android, native iOS. A shame, since many of them don't really need more than one responsive web codebase. Native apps do add value for many use cases, but not all.
They add value in all cases by not needing 200mb memory to run what would be a 20mb app for native. It's crazy how my phone runs perfectly fine on 2gb ram but my laptop is swapping with 16gb just because slack, vscode and whatever else election app is running.
Re: The not so hidden cost of sharing code between iOS and Android
#25The overhead of C++ adoption actually prevented us from ever moving fully in this direction. Today, unlike in 2013 when they started, there are other options. For others considering code-sharing, another option not mentioned in their article is Rust for the core with Swift and Kotlin. Between bindgen, futures, serde_json and non-nullable pointers in Rust, those would satisfy their stated subcategories today. Companio…
How does Rust differ significantly from C++, other than the fact that neither platform's toolchain can compile it out of the box?
I don't know enough details to say for sure, but some possibilities:
1. People may be more willing to learn Rust. I much prefer the language itself, but also it's clearly on the rise, so it may feel like a better learning investment.
2. The standard library is broader and the package ecosystem is easier to work with, so you might be able to have a more standard stack with fewer proprietary bits.
3. One complication with integrating multiple languages is making different memory management strategies coexist. Rust's type system seems to have ways of making that easier, e.g. neon-bindings.com
Re: The not so hidden cost of sharing code between iOS and Android
#26It's funny that they have a hard time hiring experienced senior C++ devs even though the language has been around so long. Presumably it would have been easier to find someone really good at something newer like, say, Vue.
Its probably more along the lines of they can't/weren't willing to pay for the experienced senior C++ devs.
There are plenty of C++ devs out there (myself among them) that will jump ship for the right offer.
Re: The not so hidden cost of sharing code between iOS and Android
#27I 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…
So you didn't launch an app at all; you launched a web page and submitted a single-site web browser to both app stores.
Re: The not so hidden cost of sharing code between iOS and Android
#28another code-sharing solution that everyone enjoy to ignore is Adobe AIR
in 2013, AIR was v3.6, now in 2019, AIR is v33.0
not only you share code via ActionScript 3 (something like TypeScript just available 10+ years ago)
but you can also develop ActionScript Native Extension (ANE) in C, C++, Objective-C, Java, C#, Swift, etc.
and it does not only publish to mobile it also publish to desktop
but that's OK, keep ignoring it
Re: The not so hidden cost of sharing code between iOS and Android
#29It baffles me that people think duplicating application code for every device is the way to go. Cross platform can be done correctly. I'm working on a stack that can natively target Windows, Mac, Linux, Android, iOS, MacOS, and Web. I couldn't imagine duplicating my code for each one of these devices. If something special needs to be done, I write an extension.
I have a feeling posts like these get upvoted because developers who make the native apps want to keep their jobs. But those developers will always be needed for the native bridges, just not as many of them.
Re: The not so hidden cost of sharing code between iOS and Android
#30Earlier quoted context omitted.
I wonder if that is a symptom of C++ having many recent revisions, thereby influencing, misleadingly, the definition of "experienced".
I tried using C++ and Objective C several years ago. Compilation was incredibly slow. Maybe when C++ modules finally arrive things will improve.
I used to maintain a couple of systems that between them were around 4 million lines of C++. Initially, in 2004, it would take about 16 hours to do a clean build. By the time I left that job, due to better hardware, precompiled headers and reduced dependencies, and smaller code for same functionality, clean build was down to 45 minutes.
The biggest winner, in my experience, was reducing dependencies in headers. Use forword declarations, etc. Precompiled headers helped a lot on Windows, but less so on Linux for the same code (but it still helped).
Incremental builds were fairly snappy, a minute or two (pretty good for a large C++ project).