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

281–290 of 335 posts

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

#281

Post by bobajeff »

mmastrac wrote: post #274
bobajeff wrote: post #189

Earlier quoted context omitted.

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?

So far we haven't hit any roadblocks with the platforms being unsupported. I'm not sure exactly what others referred to, but in our case, our Rust code is effectively "headless". Under the hood, Android is very much a Linux-looking system and iOS is very much a Darwin/OSX-looking system, so as long as you avoid moving too far into the UI layers, they'll behave exactly as you expect.

Oh I'm glad to hear that.

BTW I'm pretty sure I simply just misunderstood their platform support page. https://forge.rust-lang.org/platform-support.html

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

#282

Post by scarlac »

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

Some of your statements are partially correct, but a few of these assertions are flat out false for React Native. Let's look at them:

> - 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.

I have working examples of fairly complex production applications that are > - 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.

False statement. React Native provides you with ability to tag elements so you can use accessibility-tools to navigate the app. I have recently tested this with a RN app running on iOS 13 using the new voice control feature. Several testing frameworks also rely on these features being available.

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

#283

Post by saagarjha »

rapsey wrote: post #133
saagarjha wrote: post #13

Earlier quoted context omitted.

How does Rust differ significantly from C++, other than the fact that neither platform's toolchain can compile it out of the box?

It is really easy to make a blunder in c++ that will require a lot of effort to find. Debugging that on mobile platforms is not fun. Like they mention a deadlocking issue that was difficult to solve. Rust is built for memory and thread safety. Also the much better build system and open source ecosystem.

> Debugging that on mobile platforms is not fun

That's debatable ;)

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

#284

Post by amaccuish »

bena wrote: post #250
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.

iOS requires AOT compilation as interpreted/bytecode languages AFAIK are restricted to the Nitro JS engine. With Android it compiles with a .NET runtime included IIRC.

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

#285

Post by mmastrac »

bobajeff wrote: post #281
mmastrac wrote: post #274

Earlier quoted context omitted.

So far we haven't hit any roadblocks with the platforms being unsupported. I'm not sure exactly what others referred to, but in our case, our Rust code is effectively "headless". Under the hood, Android is very much a Linux-looking system and iOS is very much a Darwin/OSX-looking system, so as long as you avoid moving too far into the UI layers, they'll behave exactly as you expect.

Oh I'm glad to hear that. BTW I'm pretty sure I simply just misunderstood their platform support page. https://forge.rust-lang.org/platform-support.html

Oh yeah! Thanks for linking that. You are correct that Android/iOS are second tier, but TBH we have never seen anything to suggest that the stdlib is anything but 100% stable on those platforms.

I did run into a bug with the rand crate running out of randomness on Android, but that's a different story. :)

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

#286

Post by whalabi »

eejjjj82 wrote: post #243

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…

Well that sounds.. intricate.

Wouldn't it be dramatically simpler to just build the app twice?

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

#287

Post by whalabi »

root_axis wrote: post #269
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.

The nice thing about React Native compared to Flutter is that RN uses native UI widgets whereas Flutter implements its own rendering system. Flutter engineers basically reinvent a large portion of the work already done by Apple and Google in their UI kits and ultimately you have to rely on them to keep doing that work whenever changes are introduced to iOS and Android UI kits. Since RN uses native widgets they get th…

Wasn't one of the main points with flutter having really good fps?

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

#288

Post by commanderjroc »

amaccuish wrote: post #284
bena wrote: post #250

Earlier quoted context omitted.

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.

iOS requires AOT compilation as interpreted/bytecode languages AFAIK are restricted to the Nitro JS engine. With Android it compiles with a .NET runtime included IIRC.

Yes, it uses Mono under the hood as the .NET runtime.

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

#289

Post by WorldMaker »

pjmlp wrote: post #260
htormey wrote: post #239

Earlier quoted context omitted.

Microsoft Office has gone all in with React Native as well. Here is a recent comment from Andy Coates talking about MS Office Android performance: https://news.ycombinator.com/item?id=20413046 Other article talking about it: https://blog.appfigures.com/microsoft-goes-all-in-on-react-n...

They have addressed this at BUILD. Xamarin for .NET devs, React Native for C++ devs (a bit like QML/Qt). Office naturally fits the C++ devs way.

Office also has to make sure that things work on the web given they also support all the Office.com O365 versions of their apps. That's another reason they'd prefer React Native (for React Native Web) to Xamarin.

But the Office team is also a right tool for each job group and has both Xamarin and React Native apps and telling the difference between them is getting tougher to do. You can already integrate React Native components inside a Xamarin app and vice versa because they each can look like native components to each other, and it's not entirely an either/or decision.

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

#290

Post by PunksATawnyFill »

mmastrac wrote: post #272
debt wrote: post #158

Earlier quoted context omitted.

“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 tr…

I see you got downvoted here, but I think it is worth replying. We evaluated using Java on both iOS + Android (transpiled to iOS in some form), but what tipped the scales towards Rust was the "fearless concurrency" (that turned out to match the marketing) and the risk around the current state of transpilers. I was a fan of Java for a very long time. It was my language of choice from early 2000s to mid 2010s. It does…

Why not Kotlin? Isn't it Google's anointed successor to Java?
Post reply on HN