Live data from Hacker News

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

blogs.dropbox.com

61–70 of 335 posts

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

#61
post #32

Earlier quoted context omitted.

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.

Yep. I’ve got a 9 year old Scala repo on Github: https://github.com/melling/scala I actually like the language but stopped using it because it was so slow to compile. I hear that it has gotten better so I’ve been revisiting it. Worksheets seem to help with development.

Personally I find the tooling and documentation around the ecosystem to be very painful. SBT itself is also incredibly slow.

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

#62
post #41
post #28

another 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 ignor…

You are right. I've done a lot of development in AIR myself and it is super impressive. Easy TypeScript like language. The Flex SDK is mature with all the standard stylable controls you need. Dedicated IDE that just works great. Easy deployment. I was able to build a cross platform (iOS/Android/Web/Desktop) video chat application with it and it looked and worked great everywhere. Someone dropped the ball somewhere wi…

Apache Royale is not the same thing it allows to compile ActionScript to JavaScript and so publish for the web

Adobe AIR is a compiler and a runtime

for iOS it compile AOT, for other platforms: Android, Windows, macOS, (and Linux) it compile JIT

the runtimes share the AVM2 (ActionScript Virtual Machine) and the Flash Platform API, which allow to share a lot between platforms

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

#63
post #45

TLDR - it's too hard to find senior C++ mobile devs. I'm more intrigued by AirBNB moving away from React Native - the linked article says "RN was too small a component to bother supporting, and the developer experience wasn't up to par", but I'd like more detail than that. I've been working with Flutter for the past 6 months, and it would definitely be my "go-to" for any mobile application. To be fair, I did spend 2…

AirBnB has a series of in depth blog posts about their decision to abandon RN. In particular this quote seemed extremely worrying to me: > While debugging, React Native attaches to a Chrome Developer Tools instance. This is great because it is a powerful debugger. However, once the debugger is attached, all JavaScript runs within Chrome’s V8 engine. This is fine 99.9% of the time. However, in one instance, we got bit…

Having been bitten by this exact issue one or two times, meh. Par for the course in the life of a Javascript dev, really.

RN would definitely still be my go to tool for the majority of green-field mobile apps. If I'd already invested in learning flutter/Dart I'd probably feel the same about that, but certainly feel no urgent need to go out and learn it. As in, I don't think there's a significant difference in what I'd be able to accomplish, and my time is probably better invested elsewhere.

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

#64
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 rendered HTML is the closest we've come, but that's not cool anymore.

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

#65
Unless you need something very specific for the display UI. Try cordova (open source version of PhoneGap), and stuff like ionic, framework7.io, mithril.js will mostly get your most apps done needed while still sharing the code via JavaScript, HTML5/CSS. for anything native you can always write your own cordova-plugin if it doesn't already exist.

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

#67
We've had a mostly different (positive) experience doing a similar thing at FullStory for mobile instrumentation, though I think I know where some of the key differences are.

Our core "business logic" lives in Rust. This is a shared bit of code between Android & iOS that mainly deals with orchestration, serialization, and server communication. We managed to extract ~1/2 of each platform's native code into this shared orchestration. What's left on each platform is more like a platform driver.

I fully admit that things are different for us because we're not dealing with a bunch of UI that we manage (instead we're dealing with UI that our customers have written in Java/Swift/Objective-C/etc), but I think that there's a few places where we've made this work in a better way:

- We've chosen flatbuffers to serialize most (not all) of the data between the platform drivers and the shared library.

- We're using a language that's a little more hip. It's still not very easy to hire Rust developers, but developers interested in Rust are _very_ interested.

- We built tooling early on to make this pretty seamless. Our Rust code builds in XCode and gradle, so there's no real friction to a developer getting up and running.

Our team is about a year in on this transition to Rust and so far it's helped us move far quicker, especially given the size of our team.

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

#68

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.

Let's be clear that senior C++ developers are masters of their domains because they enjoy solving a particular set of problems that a low overhead systems language requires.

However, in the mobile world, from my experience, hiring good senior mobile engineers means they come with a specific skillsets already. They can take a view, animate it a certain way, and then respond to touches. Those are things that are entirely platform specific domains. So they will come from Swift/Kotlin or ObjC/Java backgrounds. The ultimate problem here is those same engineers are typically turned off by C++ nor have the desire to learn it.

You can throw C++ engineers at the problem, but they will most likely be turned off by having to solve animation timing issues or custom navigation stack designs.

If you have a venn diagram of the two sets, there would probably be very little overlap.

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

#69

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…

wxWidgets does actually get close to that mark. But regardless of the library/programming environment, there will always be platform-specific code you have to deal with.

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

#70
Find and hire candidates with this very specific skillset (we tried to hire for this role for over a year with no success)

Really? You weren't able to fill this role? I can almost guarantee that you could throw an extra 25-50k at someone competent to fill it.

In the end we no longer share mobile code via C++ (or any other non-standard way) and instead write code in the platform native languages.

I've started to comment on this across the interwebs. If you are a cross-platform (native) mobile developer, and haven't taken a look at Xamarin, you _need_ to give it some attention. Xamarin.Native specifically is the best solution I've come across that mostly gets out of your way, and has robust library ecosystems and sane interop.

Post reply on HN