Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blogs.dropbox.com

Post reply on HN
Print view View original

1–10 of 335 posts

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

#3

Post by alexashka »

Having worked in multiple places that ship iOS and Android, the real thing to focus on is cross-platform requirements, not code.

Writing mobile apps is fairly trivial - writing good requirement documents is black magic I have yet to see in the real world.

Trying to share code is like trying scratch your left foot when your right foot itches. The issue with two codebases that are supposed to do the same thing is keeping them in sync over time. The only way to do that is by having actual requirement documents.

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

#4

Post by draw_down »

> Even before the core group moved on, mobile engineers were generally not interested in learning C++, so finding people to train was a big issue

Yeah, I probably wouldn't be super interested in mastering the arcane details of one company's bespoke stack; that knowledge would be really difficult to leverage elsewhere. Most places that need mobile engineers won't care about the bespoke C++ stuff, and most places that want people to write C++ wouldn't know what to do with someone who wrote C++ for a mobile app.

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

#6

Post by kelnos »

tomovo wrote: post #2

Hard to take any of the arguments seriously when looking at the Electron app they just released on desktop.

I initially had a similar thought, but I don't think that applies here.

With Electron, you don't write a cross-platform base and then write all the platform-specific goo on top of it. You just write your app using web technologies, press the build button, and ship it on all the platforms you want to support.

Since web technologies are popular, you don't end up with the same issues hiring and training developers like you do when you need to teach a new hire about your bespoke cross-platform mobile solution.

With Electron, essentially your users pay for all of this by being forced to adopt a resource-hungry platform, while the development team gets a mostly-free pass.

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

#7

Post by kelnos »

alexashka wrote: post #3

Having worked in multiple places that ship iOS and Android, the real thing to focus on is cross-platform requirements, not code. Writing mobile apps is fairly trivial - writing good requirement documents is black magic I have yet to see in the real world. Trying to share code is like trying scratch your left foot when your right foot itches. The issue with two codebases that are supposed to do the same thing is keepi…

This made me think: I've found it hard enough to share code effectively on the backend, even when we're all using the same language and frameworks.

And people think it'll be easy to share code when you're targeting two completely different platforms with completely different frameworks in completely different languages?

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

#8

Post by jjtheblunt »

asdfman123 wrote: post #5

It'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.

I wonder if that is a symptom of C++ having many recent revisions, thereby influencing, misleadingly, the definition of "experienced".

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

#9

Post by dpezely »

The 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.

Companion templates are explained here: (January 2019)

Medium.com/visly/rust-on-ios-39f799b3c1dd

Medium.com/visly/rust-on-android-19f34a2fb43

(No affiliation other than starting to proceed down this path myself.)

For Common Lisp heads, there's also MOCL, which seemed quite reasonable when I explored it years ago: wukix.com/mocl

Post reply on HN