Hacker News Reader

Comment by toast0 | Hacker News Reader

Since no one else has said it, I'll be the voice of reason.

Share your design specs only, and let each platform team write the implementation in the language that they think best.

Yes, you'll have two teams spending time on doing the same thing. However, you'll get important benefits.

Each team will be able to implement appropriately for their platform. While iPhones and Android phones are rather similar in terms of capability, the interaction models have a lot of differences, and forcing a common component often results in non-native feeling apps. Users will be at best confused, and at worst insulted by this.

Additionally, when you have two teams working on similar problems, they can help each other. Training on this interaction with things known to be pretty much the same helps people realize they can do it with things that aren't obvious. Meeting on a regular basis to discuss things that worked/didn't on the various platforms will help them all.

View on HN

This is a UI-centric take.

There are lots of internals that could/should be shared between apps. Recently relevant examples: a customized WebRTC stack, a websocket client with extra authentication and delivery rules.

FWIW, my take on this has been to embrace Conway's law: if you have enough shared work to form a team around it, then break off a c++/whatever library and a team to maintain it. But if the hope is just to save 200LOC here and there, just bite the bullet and write it twice.

Big thanks to whoever pointed out Kotlin Native: seems interesting enough to poke around with.

This is exactly what Dropbox has just abandoned. https://blogs.dropbox.com/tech/2019/08/the-not-so-hidden-cos...

In this case they lost there C++ team, so following Conways law they went back to separate code based.

Also the open source C++ ecosystem has advanced quite a bit since when they did there project. You would be able to spend much more time on the problem domain, and zero time on writing a JSON library for example.

I have a react native app published as part of our SaaS software suite. I don’t think users notice or even care if things feel marginally non-native.

I’d agree optimizing user experience by developing in native code might be important if you have a game or social media app where the worth of your company is directly correlated with your app install metrics.

Do you have any anecdotes or data that illustrates that users will be “confused” or “insulted” by non native apps?

The poster is talking about data processing code, and not UI code.

> The app is responsible for processing data, submitting to ML models, and then displaying results in a UI

There is not need to handle this logic seperately. And lots of reasons not to.

Having attempted this in the past let me say: I’m in violent agreement.

Attempting to “share code” between Swift/Kotlin is folly at this point. I’m not going to close the door on Kotlin Native some day. But for now just say, “No”.

Users will be at best confused, and at worst insulted by this.

However... Don't assume that a user has an exclusive affinity with one platform at a time. Users will load the app on different phones, sometimes at the same time, so if there are any differences in the way the apps handle data you'll soon see things getting corrupted. Make sure you have lots, and lots, and LOTS of tests.

That's the ideal way of solving the problem, but it is a luxury not everyone can afford.

Reply on news.ycombinator.com