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

201–210 of 335 posts

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

#201

Post by jdswain »

therockhead wrote: post #183
jdswain wrote: post #106

I've been using C++ to share code between iOS and Android for years and have come to the same conclusion. I developed the C++ code on desktop operating systems which was easier to debug, but once you move it to mobile then the debugging gets a lot harder (on Android at least). The 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…

>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. I’m curious why you don’t add an Objective c layer for C++ interoperability, I’ve done this in the past and it works a great.

It's mainly because I'm trying to write everything in Swift now rather than Objective-C. I still think Objective-C is a great language, but Swift is the future of iOS development.

It was easier in Objective-C as you could just rename your code file with an extension .mm rather than .m and that made it Objective-C++ and then you could import your C++ headers and use your library as you should. With Swift you don't have that option, and even the interface to C is more difficult.

Even with Objective-C there is still some work in converting data formats (NSString to std::string etc.) and you need to be careful of C++ exceptions and NSException.

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

#202

Post by mk89 »

leppr wrote: post #172
mk89 wrote: post #153

Earlier quoted context omitted.

Could you tell why you would not recommend react native?

Pretty certain it's the unstability. In my experience, while Flutter may not be elegant because of Dart, it more or less just works. Developing in React Native is mostly just debugging the framework itself and browsing through React Native Github issues.

wow! I didn't know that. I am currently learning Flutter, because I think it has a strong potential to unify mobile and desktop development, however, I didn't know that React Native was "so bad".

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

#203

Post by trilila »

eridius wrote: post #52

1.5 years ago Dropbox was looking into rewriting their shared mobile codebase in Rust. It's a shame this blog post doesn't touch upon that at all, instead focusing on C++.

1.5 years from now they will dread the moment they moved to Rust. membe' guys, just because it's cool and trendy on HN it doesn't mean it's good.

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

#204

Post by mk89 »

realusername wrote: post #188
leppr wrote: post #172

Earlier quoted context omitted.

Pretty certain it's the unstability. In my experience, while Flutter may not be elegant because of Dart, it more or less just works. Developing in React Native is mostly just debugging the framework itself and browsing through React Native Github issues.

I had the opposite experience with Flutter personally, the problem is that Dart is a niche language with limited exposure (Flutter is basically the only big project in Dart realistically) and it's also a new project as well, it makes a bad combination.

Could you describe your experience more in details? What exactly didn't work out? I would like to know to understand whether it makes sense for me to invest my time in Flutter/Dart instead of a more mature solution like React Native.

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

#205

Post by taurath »

Over time as well, you cannot keep up with features. You will always be lowest common denominator, because if a system handles 6 platforms, and you want the feature of 1 platform on that platform, it will triple or more your amount of effort to implement it.

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

#206

Post by taurath »

reallydontask wrote: post #179
jugg1es wrote: post #120

I often struggle trying to explain to more junior developers that there are times when it's OK to write code more than once. There is a mindset that you should only ever write code once. It exists for (very) good reason. But if you follow it dogmatically, you may end up with an unmaintainable tangle of dependencies that can only be resolved with a rewrite. Sometimes, it's OK to write the same thing twice if the alter…

You are fortunate if you only have to explain it to juniors. This seems pretty prevalent among senior developers too, in my experience. The most egregious case was, this guy I worked with, who would just straight up start with abstractions to avoid any duplication and enable other use cases. Now, 9 out 10 times the use cases catered for by the abstraction failed to materialise (bloody customers) but boy did he let yo…

Duplication is always more extensible and maintainable than a bad abstraction.

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

#207

Post by rtpg »

rkagerer wrote: post #95
rtpg wrote: post #81

Earlier quoted context omitted.

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?

I'm not a fan of them, but they do make desktop linux a bit more viable insofar as you will have desktop binaries for a lot more services than you otherwise would without electron

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

#208

Post by aedron »

Does anyone have experience trying to do this kind of thing with LibGDX?

LibGDX is a layer on top of OpenGL (lwjgl actually), and used a lot for game development. It is based on Java, and is able to package the application for Android, iOS, Windows, Linux, Mac, and even web (targeting WebGL). For iOS it uses RoboVM, and for the web export it uses GWT to compile to JavaScript.

Obviously this is best suited for custom UIs (like games), but with some frameworks on top it seems it would be possible to build a decent interface. The framework already has support for most platform specific functionality (like text input). Performance should be great because it runs close to the metal, so to speak.

Just curious if anyone has tried this, as I am considering the approach.

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

#209

Post by Roritharr »

reallydontask wrote: post #179
jugg1es wrote: post #120

I often struggle trying to explain to more junior developers that there are times when it's OK to write code more than once. There is a mindset that you should only ever write code once. It exists for (very) good reason. But if you follow it dogmatically, you may end up with an unmaintainable tangle of dependencies that can only be resolved with a rewrite. Sometimes, it's OK to write the same thing twice if the alter…

You are fortunate if you only have to explain it to juniors. This seems pretty prevalent among senior developers too, in my experience. The most egregious case was, this guy I worked with, who would just straight up start with abstractions to avoid any duplication and enable other use cases. Now, 9 out 10 times the use cases catered for by the abstraction failed to materialise (bloody customers) but boy did he let yo…

>hit the abstraction lottery

Thanks, I'll use that from now on. A lot of wisdom in those 4 words.

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

#210

Post by verttii »

leppr wrote: post #172
mk89 wrote: post #153

Earlier quoted context omitted.

Could you tell why you would not recommend react native?

Pretty certain it's the unstability. In my experience, while Flutter may not be elegant because of Dart, it more or less just works. Developing in React Native is mostly just debugging the framework itself and browsing through React Native Github issues.

This has been exactly my experience. I don't particularly like Dart, but as an SDK Flutter is clearly ahead of RN. RN just keeps feeling too fragile. And the tooling is simply not there whereas Flutter has excellent tooling considering how new it is.
Post reply on HN