The not so hidden cost of sharing code between iOS and Android • Hacker News Board

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

#181

Post by zZorgz » Thu, Aug 15, 2019, 6:45 AM UTC

eridius wrote: post #177

zZorgz wrote: post #144

Earlier quoted context omitted.

Likely too much friction. Native environments benefit from using the expected IDE and tooling integration to build UI apps on respective platform. C or C++ is the best common supported language, and they didn't even like that. Also the UI frameworks are being written in said preferred language these days, eg SwiftUI, and adding one additional language could be perceived as a pain.

Apple ships a C++ compiler but you can't use C++ with Apple's platform SDKs. IF you want to use C++ you need to write Obj-C++ glue code to access most of the system frameworks, including UI code.

I would look at it differently, i.e, obj-c++ is a valid supported language environment, that makes interopt with C++ pleasant at least compared to other interopt choices. Developers may choose to target Obj-C++ even out of preference.

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

#182

Post by pjmlp » Thu, Aug 15, 2019, 6:46 AM UTC

mleonhard wrote: post #140

jacobsenscott wrote: post #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 rendere…

I'm using Flutter successfully. It has the potential to become a really great platform. Java is a good language, as long as you rarely use implementation inheritance. I would not recommend using React Native or C++ for any project.

React Native - JavaScript, plenty of jobs outside mobile dev.

C++, plenty of jobs outside mobile dev, and a very nice pay to come along.

Flutter - Dart, death silence outside Flutter use cases.

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

#183

Post by therockhead » Thu, Aug 15, 2019, 6:53 AM UTC

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.

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

#184

Post by pjmlp » Thu, Aug 15, 2019, 7:02 AM UTC

shmerl wrote: post #130

Apple also still refuse to support Vulkan natively. They are one of the worst lock-in offenders today.

Unreal, Unity, Adobe, Disney, OTOY, Fusion, Cinema4D, ... are pretty fine with it.

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

#185

Post by therockhead » Thu, Aug 15, 2019, 7:02 AM UTC

petters wrote: post #175

Hasn't Microsoft successfully written their mobile Office apps in C++ in a single codebase?

Indeed they have. What’s missing in some of the discussion here is the size of the application. For large applications like Office, a shared code base is often the correct strategy.

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

#186

Post by chadaustin » Thu, Aug 15, 2019, 7:05 AM UTC

cbsks wrote: post #131

It seems like the real issue was that Dropbox lost all of their senior C++ engineers. That’s a real mistake on their part, losing the only people who truly understand your product can be a death sentence for a company. I know my employer is very conscious of who knows what part of our products, and does their best to ensure that we never have any knowledge gaps.

You’re definitely warm. I worked at Dropbox around this time and there was very little C++ or systems experience in the building. I think it’s expertise they tried to build but for whatever reason didn’t. I work at Facebook now and the difference is night and day. FB does share a ton of code across platforms, and it doesn’t even feel controversial.

I don’t think Dropbox made a mistake in cutting out their shared C++ code, but I would caution against generalizing code sharing as a bad idea.

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

#187

Post by shmerl » Thu, Aug 15, 2019, 7:07 AM UTC

pjmlp wrote: post #184

shmerl wrote: post #130

Apple also still refuse to support Vulkan natively. They are one of the worst lock-in offenders today.

Unreal, Unity, Adobe, Disney, OTOY, Fusion, Cinema4D, ... are pretty fine with it.

What's fine with wasting effort on pointless duplication? You made this false claim many times in the past, but it's as false as it was before. And your support of lock-in practices is strange to begin with.

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

#188

Post by realusername » Thu, Aug 15, 2019, 7:08 AM UTC

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.

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.

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

#189

Post by bobajeff » Thu, Aug 15, 2019, 7:12 AM UTC

mmastrac wrote: post #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…

I'm planning on learning and writing mobile apps in Rust. I remember reading that some things aren't supported on Android and iOS. Has that caused you any issues?

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

#190

Post by dragonsh » Thu, Aug 15, 2019, 7:16 AM UTC

The_rationalist wrote: post #82

dragonsh wrote: post #23

This is precisely the experience of my startup trying to rely on flutter. It's a constant battle. Moreover Android and iOS are different implementation with different capability with constantly evolving API. It's hard to keep cross platform code in sync many #ifdef with edge cases. Moreover with REST API architecture majority of the common code is in back-end. So building in Swift and kotlin for respective platform i…

Could you explain what you think of the pros and cons of flutter VS IONIC? I think flutter and it's astonishing number of issues on github + their lack of manpower + their lack of major features + the presence of major performance and behavior bugs + the extremely small lib ecosystem (dart) is a major, useless risk for a startup for the benefit of tech hype. (just my point of view, don't take it personally)

I build a small ionic app when it was based on angularjs with dependency on Cordova and later moved to webview. I didn't like the experience and personally I still prefer Python syntax over Javascript, so that was another factor. Now I think IONIC has moved to web components using stencil.js as the base. Web Components is still an evolving standard and will still take time to gain traction, moreover the available documentation and help is limited.

So if you compare ionic vs flutter I will still go with flutter given it generate binary app store package file by compiling dart code into native platform code. But given choice between native vs flutter I think except few use cases native still makes more sense.