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

301–310 of 335 posts

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

#301

Post by robocat »

mmastrac wrote: post #270
K0nserv wrote: post #237

Earlier quoted context omitted.

That’s super interesting. I really like Rust, definitely my favourite language recently. I’ve been thinking a lot about the pattern you are using with Rust for the shared layer. Have you got an engineering blog or something with more details?

There is a FullStory engineering blog, but as we've been pretty much heads down for a while on our product we've been unable to write up some of our internal discoveries. I'm hoping that we can open-source some of the mobile Rust glue (iOS + Android), and write up what we believe is effective sharing of business logic between platforms.

I would love GitHub to have a way to publish "example" code that is for reading, but not for using or branching.

I have code that contains useful parts that are worth publishing, but it also contains horrorshow code and library/tooling specific dependencies that are useless to anyone else.

I don't want to make the code useful for others, but I would remove comments/keys/PI, and parts of the code would remain useful to others to copy or use as a reference for how to do something.

The main issue is avoiding getting roasted by some random dev blogger for some of the technical debt (the embarrassing code you remove or fix if publishing properly). Maybe a click-through agreement before you can read the code?

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

#302

Post by K0nserv »

scarlac wrote: post #282
K0nserv wrote: post #245

Earlier quoted context omitted.

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 accessibilit…

> I have working examples of fairly complex production applications that are Fair, the problem isn't as bad for RN, for Flutter it's still very bad though.

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

The ability to tag elements is only a very simple basic requirment to get accessibility right. My point was more that if you use UIKit you get significant levels of accessibility for free.

Just as a quick example I did a quick ddg search for "react native how to create custom button" and all 5-7 top results that I looked at failed to set the appropriate accessibility roles so the button actually appears as button to a user with the screen reader. Yes you can still do accessibility right with RN, but it's not the easy to get it right be default and most app developers will not do this on their own.

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

#303

Post by K0nserv »

s_y_n_t_a_x wrote: post #280
K0nserv wrote: post #245

Earlier quoted context omitted.

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…

React Native can wrap any native component and bridge it into your app. If you had bad experience with a 3rd party component, that's not RN's fault, build your own extensions you need, but for the most part you just need the core. It's still easier than rebuilding your app X times. - React Native you most certainly do get accessibility. - Running a JS VM isn't that bad, but it is a tradeoff. Imo it's completely worth…

> React Native can wrap any native component and bridge it into your app. If you had bad experience with a 3rd party component, that's not RN's fault, build your own extensions you need, but for the most part you just need the core. It's still easier than rebuilding your app X times.

Yes a great strength of React Native is that it still leverages the native UI kits and makes it possible to do so when building custom components. My comment wasn't about my experience, in fact I've built numerous bridged components in RN, but and observation about the react native community. In fact one of the most crucial lessons I've gathered when working with RN is that you must have both iOS and Android experts in your team to build good apps with RN successfully.

Here's just a few examples of popular 3rd party components(from awesome-react-native[0]) that are problematic in my eyes:

- react-native-swiper[1]. Completely custom JS implementation with a "iOS"y look. 8k stars

- react-native-gifted-chat[2]. Large completely custom JS implementation of chat UI. 8k stars

- react-native-slider[3]: A pure JS implementation of a slider. 1k stars

> - React Native you most certainly do get accessibility.

My point wasn't that it can't be done, but that it requires significantly more work that, let's face it, most developers will not do. With native UI you get a lot more for free which results in a better user experience for everyone.

See https://news.ycombinator.com/item?id=20709259

> - Running a JS VM isn't that bad, but it is a tradeoff. Imo it's completely worth it to prevent having to learn X different languages for each platform.

I agree it's a tradeoff and to be fair I don't have more than a hunch that running a JS VM is bad for energy and resource usage. The tradeoff is distinctively on the user's expense in favour of the developers. As developers shouldn't we be making tradeoffs that benefit our users instead?

> - The app size evens out, but yes the minimal is higher. However many apps are much larger than 20MB, it's better than other cross platform solutions

Yes many native apps do grow quite large too, my point is the default. The most basic RN, but especially Flutter, app is much larger than the native counterpart. Again a distinct tradeoff on the user's experience in favour of the developer.

0: https://github.com/jondot/awesome-react-native#components

1: https://github.com/leecade/react-native-swiper

2: https://github.com/FaridSafi/react-native-gifted-chat

3: https://github.com/jeanregisser/react-native-slider

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

#304

Post by eecc »

wpietri wrote: post #267
eecc wrote: post #178

Earlier quoted context omitted.

Nobody says you have to write the spec beforehand. As long as you don’t blurt a lazy “use the source Luke” and take the effort to document and edit the spec during or right after implementing something, it’s ok.

Well, I think the comment I'm responding to expects the spec first. And almost anything that encourages writing a spec says to do it first. What's the point of writing the spec after? At best, it's duplicative. At worst, it diverges, making it incorrect.

Nah, it’s just this whole manichean polemic between two grotesque caricatures of processes; agile improvisation vs upfront waterfall planning à la nazi wehrmacht going to Russia.

One just has to have an idea where to go before starting, and a good description where one went when you’re done.

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

#305

Post by eridius »

pjmlp wrote: post #262
eridius wrote: post #177

Earlier quoted context omitted.

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.

Metal and driver SDKs require C++.

Metal is Obj-C.

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

#306

Post by kdaker »

As someone who has built a C++ library to share across iOS and Android I completely agree. The biggest issue for us was finding developers willing to learn and adopt C++.

For our use case we weren’t writing UI or user flow logic, it was an ‘engine’ that handled complex business logic. It used JSON as input and output.

If I were to do that same project again I would use mostly native code and write our engine in Javascript.

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

#307

Post by abacadaba »

bobthepanda wrote: post #294
abacadaba wrote: post #63

Earlier quoted context omitted.

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'…

That's great from a dev perspective. Not so much from a product perspective, particularly if you operate at AirBNB scale and your issue could be costing lots of money for every second of failed debugging.

i don't remember exactly how long this cost me, but it sure as fsck wasn't days. ymmv.

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

#308

Post by emsy »

psyclobe wrote: post #159
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?

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.

The Unreal Engine is a complex beast with anything but few layers. Yes the games are just packages, but the engine itself is an multiplatform engineering feat.

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

#310

Post by pjmlp »

shmerl wrote: post #297
pjmlp wrote: post #293

Earlier quoted context omitted.

Somehow it makes you feel good to call me and others that enjoy the productivity of better tooling shills. Do you think it matters at all to us with actual experience passing by the soap box?

Enjoying lock-in - that's a new one. Instead, I enjoy breaking it (for example by using dxvk).

What you call lock in, we in the industry call productivity of being able to use SDKs not stuck in 80's UNIX world, full of endless extensions.

Instead of shouting from a soap box that no one cares to listen to, get Khronos to actually provide a 21st SDK tooling.

Then Sony, Microsoft, Nintendo (Vulkan is 2nd class on the Switch), Apple, Hollywood and all their partners might care.

Until then, the wind takes it all.

Post reply on HN