For UI, react-native is really good for sharing code between platforms
If your a sadist maybe
/your/you're/
and I think you meant masochist
The not so hidden cost of sharing code between iOS and Android
151–160 of 335 posts
Re: The not so hidden cost of sharing code between iOS and Android
#152Earlier 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…
God I wish it was only twice the memory. Twice would be acceptable. Discord by itself likes to push to a full gigabyte to show me 50 lines of text with avatars and 0-5 thumbnails of images.
Even worse it's using significant amounts of video card memory, and I have a tenth as much of that.
Re: The not so hidden cost of sharing code between iOS and Android
#153Add 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.
Could you tell why you would not recommend react native?
Re: The not so hidden cost of sharing code between iOS and Android
#154I'm also in that approach for the same reasons. Currently I have an app I'm cross-developing with separate iOS / Android codebase. the only 'shared-code' is Firebase libs for each platform (which seems to be written in itself cpp and bind to Kotlin / Swift).
C++ itself is pretty portable. There are actually frameworks (QT / JUCE) that allow true cross-platform builds. They work, but you'll eventually end up having a lot of branches for specific platform.
Still if you just need basic algorithms (signal processing or anything expensive CPU based) C++ might be good enough to write simple callbacks with bindings.
Evil UX/UI: -----------
Xamarin, Flutter, React Native - It really depends on the app. but if the app needs to be in the "device" UX and the unique APIs provided by the platform. people can glorify the cross-platform all they want but, You'll eventually end up with branches for each platform in the good case and bad performance in the worse case.
Re: The not so hidden cost of sharing code between iOS and Android
#155Current state of sharing code between platforms is quite terrible. Most languages support only C FFI, so if you write shared code in C++, will require bridge from C++ to C and then bridges from C to native platforms.
For CRUD core, this kind of overhead makes no sense.
I think this situation could be improved with automated generation of bridges. Apple implemented this pretty well for their own purposes, you can call Swift from ObjC and ObjC from Swift quite easily.
Re: The not so hidden cost of sharing code between iOS and Android
#156Interesting post. I wonder if the major pain point was the fact that they were doing dev with a language that had nothing to do with either platform.
We’re currently investigating Kotlin/native and it looks really promising. We don’t have to write stuff in a foreign language, but can repurpose our existing Kotlin code and share with iOS. This model seems promising.
Does anyone have any experience with Kotlin/native?
Re: The not so hidden cost of sharing code between iOS and Android
#157This is wild. So Unreal/Unity and others somehow get to run their arguably vastly more complex engines on mobile desktop and consoles, but sharing some logic between iOS and Android is too complicated for Dropbox. What are they smoking?
Re: The not so hidden cost of sharing code between iOS and Android
#158We'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…
“Our core "business logic" lives in Rust.”
Uh oh. So immediately you do understand that you have taken on the risk of potentially being unable to find any good(or bad) Rust engineers in the future, correct? Also they won’t be cheap as there won’t be many of them.
A smarter, business-friendly, future-proof approach would be to have done that in Java. Future you will want you to have done that in Java, but if you’re trying to retain good engineers maybe I get the Rust thing.
Re: The not so hidden cost of sharing code between iOS and Android
#159This is wild. So Unreal/Unity and others somehow get to run their arguably vastly more complex engines on mobile desktop and consoles, but sharing some logic between iOS and Android is too complicated for Dropbox. What are they smoking?
Games are wholly enclosed binaries that render everything in open gl or whatever, their entire ui is written in the 3d space, so there's less layers I'd imagine.
Re: The not so hidden cost of sharing code between iOS and Android
#160Having done this quite a few times, it looks more like they are having issues to retain C++ developers, are too picky on their hiring process and the original devs have left, than anything else.
And given some of the macOS client practices, the engineering quality is also to wonder.
For me, C++ with native views, or Xamarin, will keep on being the way to do mobile apps that can't be done as PWAs.