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

271–280 of 335 posts

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

#271

Post by morcutt »

Scarbutt wrote: post #101
morcutt wrote: post #98

Earlier quoted context omitted.

Most cross-platform solutions are great in the beginning and then the problems start to come to surface as teams grow, requirements change, bugs are harder to track down, code needs to be updated, the next hot cross-platform framework comes along with new promises, etc.

You seem to be describing problems with all software that has to grow.

Sure but, these issues come to surface much quicker.

Every time I've started a new iOS project in the past ~2 years, I've reached out to a handful of developers and managers on how cross-platform is going for them. None have been completely sold on it. The ones that are, are the ones that have been doing it for a few months. I've come back around to talk to them months later and they aren't so confident in the decision anymore.

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

#272

Post by mmastrac »

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

“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 _amazing_ things with keeping memory management out of mind (while still giving you the the "backdoors" to make things work well if you need a non-gc approach), but thread safety continues to be a glaring hole.

From a former Java super-fan, I honestly think the future is Go + Rust.

FWIW we also evaluated Go as a shared language, but there were risks around integrating our Go shared library with apps that may include some pre-existing Go code.

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

#274

Post by mmastrac »

bobajeff wrote: post #189
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?

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.

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

#275

Post by phonebanshee »

charlesdm wrote: post #249
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 e…

As a first approximation, there are no C++ developers available. You're probably right that there are more of them than there are Rust devs, but filling a team with either one is going to be a very hard problem.

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

#276

Post by yittcvz »

wilsonnb3 wrote: post #248
m0dest wrote: post #174

Earlier quoted context omitted.

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

I used to work for them. Great company, great technical talent. If anyone wants to move to Charlottesville or Durham I encourage you to apply! I live in CVille and I love it.

The Xamarin folks are native platform engineers first. Xamarin teams comprise Android experts and iOS experts who did then went on to learn Xamarin on top.

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

#277

Post by shmerl »

pjmlp wrote: post #193
shmerl wrote: post #187

Earlier quoted context omitted.

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.

Go learn about the industry business practices to start with, an advice you keep ignoring. Some people never get tired to fight windmills.

You repeating the same thing won't change the fact that lock-in is a foul practice that simply taxes developers for the benefit of those who want to hamper competition. Only shills support such approaches. You perfectly well know it yourself.

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

#278

Post by s_y_n_t_a_x »

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

There's a lot of valid points from native advocates though. Like differences in touch features, various sensor APIs, Firebase etc. These may not be serious considerations in simple apps but they make major difference to both the end user as well as the codebase/developer in larger scale / more serious apps. That said, myself I still write Flutter too, having jumped ship from React Native.

I use React Native so there is no difference in touch features etc. It's native components bridged by JS.

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

#279

Post by s_y_n_t_a_x »

matchbok wrote: post #104
s_y_n_t_a_x wrote: post #43

Earlier quoted context omitted.

React Native

Done correctly != react native. I've had to shut down and migrate 3 RN projects because of how much of a mess it is. It's not even 1.0 and is a horrible choice for important apps.

Then you used it wrong, sorry.

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

#280

Post by s_y_n_t_a_x »

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…

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 it to prevent having to learn X different languages for each platform.

- 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

In no way are any of these things so bad where I would duplicate my code 6 times and then maintain them throughout the life of the project. That's just crazy.

Post reply on HN