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

241–250 of 335 posts

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

#241

Post by vlozko »

wsc981 wrote: post #77
dmitrybrant wrote: post #74

Earlier quoted context omitted.

How about running a background service to synchronize a local folder of content with a remote server? Making sure the background service is launched correctly upon startup? Integrating with the OS's native sharing features with other apps? And so on. In my experience, using a "cross-platform" framework means that you'll write the code not once, but three times: once for the cross-platform framework, and once per plat…

For platform specific stuff it's easy to write a wrapper. Most of the time Xamarin is very closely up to date with Apple's SDK, due to some automated tooling that generates the C# classes, interfaces and such. So you should be able to either use the C# wrappers for platform specific functionality, or alternatively can quite easily create your own binding using the Sharpie tool [0]. The last 2 apps I've been working o…

I wonder how well Xamarin will work with Swift-only frameworks, like the upcoming SwiftUI and Combine frameworks. They make heavy use of Swift generics. It’s been a long time since I’ve touched Xamarin so it’s a genuine curiosity.

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

#242

Post by K0nserv »

bstar77 wrote: post #44

I shudder to think how many people will read this headline and immediately takeaway that React Native/Flutter/Electron are terrible cross platform solutions.

React Native, Flutter, and Electron have a lot of problems in between them. They are fairly good cross platform solutions, whether cross platform UI is actually a good idea is much more dubious, I lean towards no it's not.

I'm more excited about leveraging native platform UI with shared code in a common language like Rust. C++ as described in the blog is problematic for this.

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

#243

Post by eejjjj82 »

The best way I've seen this work (inside Google Apps) is to write shared business-logic in a common layer (here it (often) gets written in Java, then transpiled to Obj->C and Javascript, other teams go from C++ -> Java & JS, and other other teams embed JS inside of everything.. and other other other teams write everything in a native language (there is no one single way at Google))

then use a data-definition-language (like protobuffers) to define a bridge from inside of transpiled code land to your native layer, and compile native language bindings for your UI to read & write data models.

then stack a mechanism like GRPC which takes the DDL to the next level and makes services a declarative, language agnostic definition... and compile your service stubs for each platform.

...then write the UI in a native layer for each platform, using the native service stubs and data models compiled from your DDL.

Once you start trying to abstract the UI models between iOS, Android, and web you are stuck with a shitty status quo solution that leads to terrible hacks or boring concessions that ignore platform differences.

However abstracting the common (non-ui) mechanisms like asynchronous data structures, sockets, and storage is a relatively solved problem.

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

#244

Post by verttii »

mk89 wrote: post #224
verttii wrote: post #211

Earlier quoted context omitted.

Actually, I don't think we should consider React Native more mature. It's been around for longer sure, but it's significantly more fragile, keeps releasing with regressions, has poor tooling around it except for as far as React is concerned etc. I don't know what you are trying to build on mobile but I'd definitely learn Flutter instead of RN, which I have. Others here have said you should just go full native instead…

I wasn't aware of the fact that react native is fragile - it seems I did the right choice by learning Flutter. I hope it evolves even better, and also the criticism to Dart for me is so far quite irrelevant, as there are already tons of libraries and it's really easy to learn.

May I ask what kind of stuff are you developing with it? I've been working on a WebRTC app myself with it, basically porting my app from RN to Flutter. So far I've encountered no major obstacles, just a little friction which is a part of the learning curve.

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

#245

Post by K0nserv »

s_y_n_t_a_x wrote: post #29

It baffles me that people think duplicating application code for every device is the way to go. Cross platform can be done correctly. I'm working on a stack that can natively target Windows, Mac, Linux, Android, iOS, MacOS, and Web. I couldn't imagine duplicating my code for each one of these devices. If something special needs to be done, I write an extension. I have a feeling posts like these get upvoted because de…

I'm very much in the cross platform is a bad idea camp. It's fine for sharing business logic and other non-UI code, but having tried several cross platform UI kits I've never found it to work well. Cross platform UI always ends up compromising on the native UIs strengths and uniqueness resulting in poor UX, poor accessibility, unaccceptable resource usage, bloated binary size etc. Just a few concrete examples:

- Non standard UI/UX is super common because cross platform UI targets the lowest common denominator. Flutter is the quintessential example of this, it throws away all native UI support and renders everything from scratch with low level graphics. In React Native I've observed several cases where iOS UI has been re-implemented, poorly, in Javascript and shipped on Android and iOS.

- Poor accessibility. Native iOS apps get a lot of accessibility for free because Apple has done a great job, with RN and especially Flutter you don't get this benefit.

- Resource consumption. Electron is terrible in this regard as is the common meme. React Native runs a JS VM for every app which surely has a negative impact on both battery and performance.

- Binary size. A basic Flutter/RN app easily pushes you past 20MB in app size on iOS, whereas a complex and complete app like Tweetbot is ~7MB.

It's certainly possible to build great UX with cross platform UI frameworks, but the amount of work required to do it well starts to get into the territory where you are better of just doing it natively in the first place.

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

#246

Post by Narishma »

emsy wrote: post #157

This 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?

I think it's exactly because they are so complex that those engines can afford to share a lot of code between platforms. For smaller and/or simpler applications, it's probably not worth it to deal with the cross-platform complexities.

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

#247

Post by NateEag »

ad404b8a372f2b9 wrote: post #139
NateEag wrote: post #125

Earlier quoted context omitted.

Huh. My laptop has 8 gigs of RAM, and I run many programs simultaneously (usually including several codebase analysis servers behind Emacs, a VirtualBox VM or two, Slack, and of course tens of Chrome tabs, several in development mode), but I don't have anything like the problems you describe. I do use The Great Suspender aggressively in Chrome and that does help a lot. My Emacs instance itself is extremely tricked ou…

I'm impressed you can run all that especially multiple VMs on 8gb, I have to close Firefox when I need VMs. I'm on windows 7, on a Dell Inspiron with a RAM and disk upgrade, no special configuration or software. I didn't think to look for an addon to do that, that's pretty cool, I downloaded the Firefox equivalent, might do the trick!

I double-checked now that I'm back at work, and I was flat-out wrong. This machine has 16 GB.

No wonder I don't have issues.

I hope tab suspension helps you. It certainly made Chrome more usable for me (but I do have a bad habit of getting to fifty or seventy tabs open).

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

#248

Post by wilsonnb3 »

m0dest wrote: post #174
weq wrote: post #88

Earlier quoted context omitted.

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…

I took a look at Xamarin recently to see how far it had come, and the tooling is really impressive. They seem to do a great job of keeping up to date with iOS/Android SDK changes, too. But when trying to find an example of a native-feeling Xamarin-based app for iOS, I was really underwhelmed. I tried to find one that was (a) well-known and (b) third-party (not developed by Xamarin or Microsoft). The 4 contenders were…

I believe the Fox Sports app was done by a company called WillowTree.

https://willowtreeapps.com/company

They specifically mentioned when I was interviewing there that the reason their Xamarin apps are so good is because they already know how to make good native iOS apps.

Also, I specifically asked about whether or not they would be using more technologies like Xamarin in the future and they didn't seem too keen on it.

According to them, making a truly native seeming app in Xamarin isn't much less work than making two separate native apps.

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

#249

Post by charlesdm »

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…

As someone with plenty of C++ knowledge on mobile, I would expect there to be more C++ devs available with good mobile skills than there are rust devs?

Maybe my own viewpoint is twisting the amount of devs I think are available, but I don't think the choice dropbox originally made was crazy. C++ is a great way to share complex code over multiple platforms (i.e. desktop + mobile) if you're running a relatively small engineering team with limited resources.

Now, if you have semi unlimited resources, it makes sense to rebuild things natively for each platform in many cases. But Dropbox might not have been around, had they not maken the choice to share part of their codebase cross platforms.

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

#250

Post by bena »

commanderjroc wrote: post #240

I don't understand why someone at Dropbox's size and scale would go after C++ on mobile and blaze their own trail, when its probably more pragmatic to go native. With that being said, I worked for a firm that extended the life of old ERP systems and we had to do a few mobile apps, we chose Xamarin because we were a shop of 7ish devs that had many projects to maintain and the cost of code sharing and familiarity with…

Isn't Xamarin the IDE and cross-compiler? Last I saw, it took C# and cross-compiled to native Android and iOS apps.

Or had a .net runtime that ran on both.

Regardless, you need a C# developer if you're choosing Xamarin as your tooling.

Post reply on HN