Live data from Hacker News

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

blogs.dropbox.com

91–100 of 335 posts

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

#91

Add more fuel to the "write once, run anywhere" dumpster fire. Let's peek in there - I see C, C++, Java, JavaScript, stored procedures, wxWidgets, RubyMotion, GTK, QT, object oriented programming, functional programming, PhoneGap, React Native, Flutter, ... It is getting full in there. What's that about the definition of insanity? Doing the same thing over and over and expecting a different result? Sever side rendere…

You've listed a lot of technologies that people have used to create successful products with long life-cycles. In particular C, C++, Java, JavaScript, Qt, OOP... if anything is notably missing from your dumpster it's probably Adobe AIR.

Nothing in this industry lasts forever. I'd certainly rather inherit a Java/Swing or Qt app from the early '00s than an MFC or Carbon dinosaur.

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

#92

Earlier quoted context omitted.

I take it you haven't tried Swift ;)

Or (shudder) Scala. The only time I ever think “oh, this computer is a bit slow” of modern high end laptops is when it comes to Scala. I like the language, but the compiler is painful.

I recently had to use a bit of Scala for some load-testing, I've never had so much trouble doing something seemingly so trivial; in this case, sending a JSON HTTP request. It was honestly a matter of hours. Pretty humbling experience!

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

#93
post #15

I 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…

This is a fascinating idea, and reminds me of the dreaded [1] rewrite, where you rewrite the application because the new system will always be better in the new framework...

But this is different, if you write things simply, so the code can be ported easily. Then you're essentially making the code easier to share, without tightly coupling it to a specific platform... seems like a big win to me

[1] http://wiki.c2.com/?RewriteCodeFromScratch

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

#94
post #90

Earlier quoted context omitted.

> It works pretty well if you're OK with the huge resource usage. Isn't that an oxymoron?

No. If the user interface is usable and snappy, it is probably fine that it consumes twice as many resources as a similar native app would require for the same result. Example: Slack.app is a huge memory hog (though not as bad as it was before their rewrite), but it fits decently into OS X and does not lag on me. I have lots of RAM, so the extra consumption is fine. Sure, it annoys some programmers that it could be m…

I think it's a bit of an unfair characterization. I don't use emac or CLI as my client, I enjoy a beautiful UI as much as the next guy but electron is a real bother to me.

I switched from Sublime to VS Code and went from 20MB of RAM usage to 500. Add slack, add discord, you now have GBs of RAM getting eaten up just for the UIs. Most mid-range laptops still only have 8GB of RAM, add a browser to the mix and it's a constant battle to have everything running smoothly, the programs frequently crash due to memory issues. It's a real problem and not solely programmer efficiency-OCD.

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

#95
post #81

Add more fuel to the "write once, run anywhere" dumpster fire. Let's peek in there - I see C, C++, Java, JavaScript, stored procedures, wxWidgets, RubyMotion, GTK, QT, object oriented programming, functional programming, PhoneGap, React Native, Flutter, ... It is getting full in there. What's that about the definition of insanity? Doing the same thing over and over and expecting a different result? Sever side rendere…

Electron. It works pretty well if you're OK with the huge resource usage.

I really despise Electron apps. They always seem bloated and antagonistic toward the native user experience on my platform (eg. inferior keyboard support, hard to integrate with custom tooling like AutoHotkey, etc.). Have I just not used the right ones?

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

#96
post #90

Earlier quoted context omitted.

No. If the user interface is usable and snappy, it is probably fine that it consumes twice as many resources as a similar native app would require for the same result. Example: Slack.app is a huge memory hog (though not as bad as it was before their rewrite), but it fits decently into OS X and does not lag on me. I have lots of RAM, so the extra consumption is fine. Sure, it annoys some programmers that it could be m…

I think it's a bit of an unfair characterization. I don't use emac or CLI as my client, I enjoy a beautiful UI as much as the next guy but electron is a real bother to me. I switched from Sublime to VS Code and went from 20MB of RAM usage to 500. Add slack, add discord, you now have GBs of RAM getting eaten up just for the UIs. Most mid-range laptops still only have 8GB of RAM, add a browser to the mix and it's a con…

Electron is also using an old version of Chromium, and most electron apps are slow to update, making it more insecure than running the web app.

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

#98
post #21

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.

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

#99
post #88
post #15

I 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…

It was years ago, but Rdio went the Xamarin route, regretted it, and then did exactly what Dropbox just did and went full native.

The reasons for regretting it were similar: lack of available engineers on the market, incompatibilities between runtimes, and lagging support for platform features (although in the Xamarin case it's not even in your hands to fix it)

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

#100
post #98
post #21

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.

[deleted]
Post reply on HN