[McDev]

I'm a self taught programmer and started developing for Android in 2012. It took me a while before I realised that you needed third party libraries to do absolutely anything useful as the platform APIs were so poor and undocumented. There were gaps everywhere and you needed to write tons of boilerplate code to do things properly.

Image loading was often a huge source of crashes due to out-of-memory errors and doing it properly wasn't trivial [0]. Libraries like "Glide" and "Picasso" solved this.

Using the camera hardware was awful. Device manufacturers would implement things differently, and break the camera API unexpectedly. Only recently [1] are we starting to see sane, consistent camera APIs.

Making network requests felt extremely clunky, and the platform JSON implementation wasn't performant, or easy to use as you had to manually parse everything. Retrofit [2] made talking to REST services much easier.

I could go on and on, but I'm sure there's plenty others here who can do that here. These days Android development is much, much more enjoyable. Kotlin has pretty much replaced Java in the Android ecosystem, and there's great reasources around on how to architect your app to make everything testable and easily scalable such as the architecture samples [3]. I've worked on a few React Native projects in the last year. I'm not a fan of it, but I definitely see the industry heading to some cross platform solution eventually.

[0]. https://developer.android.com/topic/performance/graphics/loa...

[1]. https://developer.android.com/training/camerax

[2]. https://square.github.io/retrofit/

[3]. https://github.com/android/architecture-samples

[applecrazy]

Personally I think that Flutter is the future for cross-platform UI toolkits. As a React dev (in my spare time, I’m still a student), using RN was a pain due to the need to install native extensions for almost everything. The batteries-included approach of Flutter and just the polish around the dev workflow made it more attractive to a beginner mobile dev.

[mdocherty]

I would be hesitant to recommend seriously pursuing cross-platform. Most serious applications generally run into scaling issues as they get more complicated and demands require more than the abstractions the cross-platform tool can provide.

[freehunter]

On the other hand, very few applications need to scale to the point where it matters. If the options are "ship something now and refactor later" versus "ship something in six months that's perfect but too late", most people here would benefit from cross platform solutions.

Very few companies have ever failed because their tech stack didn't scale well.

[SquishyPanda23]

This is a nit, but there's a pretty big difference between refactoring and rearchitecting.

If you plan for an eventual migration of the app from a cross-platform toolkit to native, then often you're committing to a significant rewrite of the app. This means either you dedicate a team to the rewrite or you stop adding features while it gets rewritten.

Plus it will take a while for the native version to get feature parity with the cross-platform version, and you typically can't roll out the native version until you have parity.

I'm sure there are tools and strategies for getting this right, but I've seen this basically kill startups.

[K0SM0S]

> “I'm sure there are tools and strategies for getting this right, but I've seen this basically kill startups.”

Well if they're doing it like that, it's indeed not much better than hara-kiri. There are better ways :)

How you do it is incrementally, avoiding too-major changes at once, and progressively moving from codebase A (cross-platform framework) towards codebase B (new native thing). But it happens at the integration level, i.e. you build with increasingly more % from B, but during the whole A->B transition it'll be a hybrid build.

E.g. part Flutter / part native.

1. You begin with "let's take camera stuff out of Flutter and re-implement our related features using native APIs": this instantly makes two apps (iOS, Android) with 90-99% code in common, just a fork to handle camera APIs separately (by the way, the state of API affairs often forced you to do this to some extent for any non-trivial use-case; I'd wager it used to be the state of most feature-rich apps in the 2010s).

2. Then you proceed with another component of your app. Rinse and repeat until you've got 90% from B and the remaining stuff is structural.

3. All that remains is to remove Flutter entirely from the equation and rewrite your core app logic: what glues all of the above components together; all of which at that stage are already rewritten for native and tested independently (critical to your success).

Along the way you never truly break UX, it's more of a classic "ongoing development" thing with details changing here and there, and hopefully better UX each step since your move to native must be motivated by something worth it for the client-side (otherwise it's likely your server API model that needs refactoring).

That's how the now-default-consensual approach to how you change stacks without breaking UX, nor your company. Full rewrites on wholly new tech is just asking for cataclysm: you literally do that to yourself, to your own code and users. It's also the only reasonable way I know for small teams, one-man shows, etc.

[ngcc_hk]

Make sense. And may be should start with this thinking when I started to avoid the first pain.

[freehunter]

You're right, I didn't use the correct terminology and I appreciate the correction.

On the other hand, using information from Facebook themselves (creators of React Native), the cross-platform solution seems to be able to scale pretty darn well [1]. Facebook, Instagram, Bloomberg, Skype, Walmart, Uber... these are some pretty big names with some pretty big audiences. If React Native can get your company from a startup to the size of any of these companies, I'd say you're doing pretty well on the technology front.

Kind of like how Twitter had to do a major rewrite from Rails, but Rails got them to the point where they needed that rewrite.

[1] https://facebook.github.io/react-native/showcase

[K0SM0S]

I think you'd indeed have to look at more demanding applications, more "bleeding edge" stuff computationally: 3D gaming is probably as good a candidate as ever, maybe some in-app AI workflows, idk. Truth is, I know how to bring a desktop/server to its knees because there are valid use-cases for that, but on mobile I struggle to find many examples indeed. I guess any heavy data crunching app might fit the bill, but when don't you run that remotely? On-premises offline pro apps maybe, like tools for e.g. plumbers and electricians? All of that stuff is in embedded afaik. Dedicated devices, rugged cases, it's a whole other market/target.

So cross-platform solutions on mobile indeed seem to fit most-if-not-all of the 'normal' use-cases, assuming there's server resource available. The Twitter/Rails example is one perfect illustration, and there are many such examples throughout big names we know today.

[davnicwil]

> Very few companies have ever failed because their tech stack didn't scale well

Just out of interest, are there any clear examples where this happened, ever? Can anyone name any?

What I mean specifically is - a company with a well known product that was growing in popularity but then hit a ceiling because of technical scale issues and couldn't support any more customers, growth halted, and they couldn't fix it in time to keep the momentum going (or got overtaken by a competitor) and failed?

[zmj]

It happens all the time. When it does, though, the narrative is usually "scrappy upstart takes over" and not "segment leader fossilizes".

[rwallace]

So what would be some examples of when a scrappy upstart took over because the segment leader ran into tech stack scaling issues? (As opposed to the segment leader running into corrupt or incompetent management, failing to notice a new market opportunity etc.)

[amimetic]

Today is a weird time to get into mobile app dev. The standard 'native' UI frameworks are pretty terrible in terms of how they cope with complexity and their ability to change over time with their dated OOP APIs. Though on both platforms the tooling has been climbing ever upwards towards local maxima.

The best options available for most Apps today (even if just for a single platform) are typically React Native or Flutter. With their React(-ish) UI approaches you can both quickly build and iterate in the future.

SwiftUI is not ready for most uses (I've shipped a small but non trivial app https://apps.apple.com/us/app/pattern-maker/id1484249212 and was surprised by how many bugs there are for very standard things and how many hacks seemed to be required). Jetpack Compose seems to be at an even earlier stage. I expect both will be great but probably not for some time.

[pjmlp]

For those into gamming the standard native UI never mattered.

Then there are several kinds of workflows that are quite doable as mobile Web. One just has to take into consideration that 3G isn't broadband, nor a mobile display a last generation 25" screen.

[rubber_duck]

There are plenty of "serious" applications written with cross platform tools. Flutter, React Native even ionic/cordova - it depends entirely on what your application does.

[jmull]

Flutter is DOA for anything but short-term projects.

For one thing, it’s tied to a custom language. That means there’s significant overhead for developers which shows itself directly as a learning curve, or indirectly in terms of hiring or retention of developers.

At least as significantly, they chose to implement custom controls (rather than wrap native controls). With that approach there’s really no way for them to implement native expectations for controls in the first place, much less keep up with native functionality across platforms.

[Qasaur]

I disagree strongly with this.

I'm currently writing a cross-platform app in Flutter that is launching soon, and I found that the developer experience is world-class and I've had very few issues so far. The language is incredibly easy to pick up with close to zero overhead if you are a somewhat competent programmer as it is essentially a very lightweight OOP language. My main languages are otherwise Go and Rust, and picking up Dart was not difficult at all for me and I don't think you need to be a wizard to figure it out. I suspect JS devs will find it even easier to pick up as many of the constructs are similar.

It took only a couple of days to get up to speed with Flutter-specific functionality as well as the native API bindings, and I was already writing production code for the app the first week of exposure to the language. The UI framework is declarative and very easy to reason about and design, and the tooling is also incredibly seamless and easy to use, although I do agree that it needs some polishing as there are some edge cases that you sometimes need to trawl the Github issues page to fix.

Yes, sometimes it is frustrating as there are some things that are lacking in the standard library, but the third-party library scene is picking up and you can do 95% of what you want to do without major issue. I'm convinced that Flutter is going to become bigger in the future and is going to cover most use cases for all but the most performant apps and perhaps games.

[marklubi]

To follow on this, I've had more "wow" moments with Flutter than from any of the tech stacks I've ever worked with.

Flutter is a breath of fresh air after building and maintaining the same app over and over again for several platforms.

[self_awareness]

I've released two Flutter apps on Google Play and I don't see Flutter in such pink colors. Every SDK update makes some users change their ratings because the app starts crashing for them, even when I'll make trivial changes. Cupertino theme is bugged on Android. Flutter team is OK with doing breaking changes to widgets, so when you update, prepare your self that you may need to rewrite some parts of your app, because some widget has changed, etc.

[pjmlp]

Flutter will be to Dart as Rails to Ruby, if the political wars between Chrome, Android and Flutter don't kill it first, that it the only thing Dart will be relevant for.

[preommr]

> For one thing, it’s tied to a custom language.

Are you talking about Dart?

If so, that's absolutely savage, lmao. To not only call it a "custom" language but not even name it. The amount of disrespect - and the worst thing is I don't even think it was intended. Even if this is one person, I think this speaks volumes about how much of a joke the language is.

It's just so sad. And to think that the team behind flutter purposefully chose it after considering a bunch of other languages.

[literallycancer]

Well they did add the compiler half way through.

You can write idiomatic Dart code that won't run because Flutter asserts crash it at runtime. And you fix it by writing code that the Dart compiler complains about but lets you run and it works (even though it shouldn't). Is there another compiled language where this is the norm?

What's the point of dealing with a half baked ecosystem when there are much better languages available?

[fctorial]

I don't think he meant it that way. He's probably trying to say that depending on a "custom language" is a bad thing in itself.

I personally don't feel that dart is tied in any way to flutter. It was originally meant to be compiled to js, and that shows in vm architecture, but that doesn't look like a con.

[pjmlp]

I bet that Chrome and Android team would have more political muscle than the Flutter team.

PWAs will keep being pushed by Chrome team, alongside Microsoft, and I wouldn't be surprised to see a Kotlin/Native variant of Jetpack Composer by Google IO 2020.

[billfruit]

Perhaps Xamarin is a good choice as well for who want to transition from development of desktop apps. Also support for F# on Xamarin is also a plus.

[graydsl]

I was waiting for someone to mention Xamarin. :D

I haven't worked with the platform for 2 to 3 years. In my old job we had massive problems at the end hence we switched to native (we were an agency).

Problems we had:

* Deploying to devices was painfully slow compared to native stack.

* We all had Macs and the tooling (Visual Studio for Mac/MonoDevelop) was pretty bad compared to Android Studio.

* Wrapping 3rd party native libs was a pain, if not impossible. Especially in a stressful agency environment.

When we heard about the acquisition of Xamarin by Microsoft I was hopeful things would change to the better. But month later they rebranded MonoDevelop and focused on integrating Azure.

Did it get any better?

[pjmlp]

Visual Studio for Mac has suffered quite a refactoring after the acquisition, as many of the MonoDevelop internals have been refactored into common libraries shared between Visual Studio and Visual Studio for Mac, one of the reasons why the new plugin infrastructure is based on .NET instead of COM.

There a release event happening next month, https://visualstudio.microsoft.com/vs/mac/event/

[elevenoh]

How is flutter's open source widget community?

[rofrol]

>Even Google's own Pixel devices do not support this. The image quality from CameraX API is not ass good as the stock camera. And there is no support for Night Sight. I do not get this.

From the comment 2 months ago https://www.youtube.com/watch?v=QYkTXJ2TuiA&lc=UgwBlx_R3eL4k...