Live data from Hacker News

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

blogs.dropbox.com

221–230 of 335 posts

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

#221
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…

Xamarin is indeed the closest there is to the holy grail of cross-mobile development. I too had some success with it for a small project at first, but just like the theme of the blog post, the challenge is in the long-term maintenance being cost-effective, not just the initial development. Especially in the face of these adversarial platforms constantly changing things underfoot. For example in Android recently I've…

there is a difference between Xamarin and Xamarin.Forms, one thing is just C# => ObjC binding / C# => Java binding (C# to AOT native shared libraries and binds it into the native things), which basically SUPPORTS ALL of the native features.

so basically you can either have one application on top of a custom ui framework (xamarin.forms) or you can only share business logic, and write controllers, which feels native in c# or the native language.

i.e. without forms you can build a controller with objc or you can have the implementation in c#, and call into a shared business logic library. unfortunatly the docs are really really weak when you consider what you really can do with xamarin.

with forms you can build a ui that works on both platforms so basically you have 100% shared code.

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

#222
post #191
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.

What specifically isn't elegant about Dart in your opinion? Seems like a perfectly good language to me, and although it's nothing fancy, it does have a bit of sugar, and a solid standard library. I also like how codegen and static analysis are so accessible through the build libraries. It's evolving pretty quickly, too. Non-nullable by default is coming up, along with extension methods, FFI. Possibly implicit convers…

I think I've been spoiled by algebraic data types and pattern matching. I really miss them.

Non-nullable by default will be a huge win. It does feel like a huge step backwards having to deal with nulls again.

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

#223

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

[deleted]

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

#224
post #204

Earlier quoted context omitted.

Could you describe your experience more in details? What exactly didn't work out? I would like to know to understand whether it makes sense for me to invest my time in Flutter/Dart instead of a more mature solution like React Native.

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.

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

#225

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

Dropbox was able to ship two mobile applications for 5-6 years using this strategy, so it's premature to dismiss it.

Furthermore, it looks like their team changed a lot and they were unable to retain the C++ talent that implemented the original strategy, nor were they able to find interested developers.

The mobile landscape has also changed enormously during those 5 years, even the official programming languages have changed.

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

#226
post #135

Earlier quoted context omitted.

Their hinted opinion on that: > That being said, C/C++ are the only languages with a compiler supported by both Google and Apple, so using a different language would have created a whole host of other problems to deal with.

I'm not sure why "supported by both Google and Apple" is supposed to matter. Apple doesn't need to ship a Rust compiler for me to use Rust.

1st tier tooling supported by the platform won't break yearly on every new OS version and you don't have to wait until your 2nd tier tooling developers gets around to fixing it.

The platform developers will do their best to keep 1st tier tooling working and fix it when it breaks.

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

#227
I think in the specific case of C++, this is mostly an Android problem, not a general cross-platform problem.

C++ works just fine on iOS, and interoperates very well with Obj-C (not sure about Swift, though).

C++ is a mess on Android. It can certainly be made to work, but the tooling and library support is minimal.

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

#228

It's funny that they have a hard time hiring experienced senior C++ devs even though the language has been around so long. Presumably it would have been easier to find someone really good at something newer like, say, Vue.

Mobile is getting crappier, so I can see why C++ developers would be reluctant to partake.

Google and Apple keep piling feature on top, so mobile has the 2nd biggest churn after front-end. Recently even the preferred programming language changed on both platforms.

It's under pressure from web-applications, which although of inferior quality are easier to develop.

Most apps aren't anything special and require mostly UI and UI framework skills (animations, platform-specific APIs, etc).

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

#229
This comment will probably be viewed as preposterous or based on ignorance.

But from my perspective, you're probably doing it wrong.

And based on my experiences with different dropbox clients, I'm not too surprised, those apps all seem to be very badly built.

Switching language or framework won't help that much, I'm afraid.

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

#230
post #90

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

Not if it results in only this one application feeling snappy and everything else hanging because of resource consumption. That's especially annoying when you work on a shared server. I used to work in a C++ team where many people used CLion (on a shared development server) and it made us all miserable, because the server would hang from time to time, because all the CLions ate all the RAM (sometimes just one instance could consume more than 50GB). Similar things happened with Eclipse, but a lot less often.

And then the IDE of another guy does its indexing really fast zillions of times per second, great, but then another guy sits there waiting for "git status" to complete for several minutes.

Post reply on HN