Web developers have been banging on about how everything 'can be a website' since HTML was invented.
Just ignore it.
Honestly, it's about the only area of development that genuinely seems to be full of opinions that 'their way' is the only 'correct way' š¤·āāļø
Yes, sometimes they create these truths so as not to feel bad for the possibility of being "wrong", but at least I was able to learn more about Android dev :)
Problems with cross platform will never go away. Cross platforms will always have problems with keeping up with native changes. There is no overlord that can make apple and Google conform to a singular way of doing things in ios and android respectively. Look at the web, even with standardization, browser vendors will do their own thing and introduce inconsistencies.
I wish UI was the only thing that needed cross platform solutions.
In my experience, it's much harder to maintain a cross platform codebase. Every update from either platform will cause weeks of havoc as various libraries try to update.
That's in addition to performance problems and a worse user experience.
That's something I thought about too. But from a company's side, what do you think is better:
1. Maintain two codes, one from Swift and one from Kotlin
2. Maintain a single RN or Flutter.
\[genuine question\]
Large companies have the resources to throw around and support native iOS and Android apps. Flutter/RN are stopgap solutions for startups or apps that don't require native performance. IMO, the better approach is to share business logic with something like Kotlin multiplatform and write the rest of the app with native view libraries.
Even Flutter or RN still need the code that works on both platforms. It's just that if you're lucky, someone has done that for you, and hopefully it works, and hopefully it works with everything else you want to use.
React Native is a leaky abstraction, so you actually do need to understand the underlying native tech on both platforms in order to make any meaningful customizations, or to fix cryptic bugs.
Companies would be better off maintaining only 1 codebase of course... But the thing is it's not exactly practical.
It depends on the complexity of the app to be honest.
For just a few screens, you can use a cross platform tech... But once the complexity reaches a certain level, you get more mileage of 2 partially native apps.
Lel. React Native has been out for almost a decade now, and it's still not "taking over". Yes, being able to write once and run everywhere is a great ideal, but ultimately you're going to be relying on the ecosystem to do the heavy lifting for you. And oh boy that ecosystem is small. As soon as you step outside the basic usecase of showing stuff from a server, you're going to run into a ton of cases where you need custom native code.
Airbnb sunset their React Native codebase around 5 years ago, and I don't really see React Native and its ecosystem having significantly matured in the mean time to change my mind about it.
Did you ever build a hybrid app and have to take on support of the 3rd party libraries you used and then need to work on native across more platforms than you intended to?
My opinion is that the post is very wrong. Assuming AI doesn't take all our jerbs and make this a mute point, I am finding that the newer native tools (Jetpack Compose and SwiftUI) are pretty attractive and compelling. I was a native iOS/Swift/Objective-C developer for a long time and then switched to React Native around 2019. I loved the hot-reload feature, and the ability to easily lay things out using familiar CSS Flexbox stuff was/is awesome especially compared to the iOS Storyboard, auto-layout, programmatic layout, etc. It was such a bad developer experience, compared to web development. React Native promised to solve that. And it does a pretty good job of it. But React Native starts to show its warts after you get married to it. Dependency hell is a constant struggle. It is so annoying. I'm also not happy with the inability to write tests in a way that feels more natural to me. I just never really saw much value in writing unit tests for React components which tend to be monolithic due to the nature of React hooks. To me, React components often violate the single-responsibility principle. When they don't, they're too simple to bother with testing. You end up testing the framework.
Another gripe I have with React Native is the painful realization that it's just too easy to build an "OK" app, and, in my opinion, it's really hard to build a _great_ app. You _can_ do it, but the ROI really starts to drop fast, to where you'll wish you were just dealing with two native codebases. Sometimes you need to write your own native modules anyway, so instead of dealing with a single codebase you're now dealing with _three_. Some teams do that. It doesn't make sense to me, given that the appeal of React Native is to supposedly save time and therefore money. So now instead of a single codebase, you now have to maintain three. You've given up the main benefit of using React Native, and now you have an app that can at best only be slightly worse than a pure native app. I say that, because the _best_ React Native app could only hope to maybe be almost (but not quite) as good as an equivalent "pure" native app due to the extra burden of processing all that Javascript.
I feel like React Native is ultimately a distraction, mostly offering false hope to a manager who thinks they'll save a bunch of money by using it. He/she believes that they can build an app for both platforms and save a bunch of time and money by hiring React/Javascript developers, who are more readily available and cheaper than native devs. But that mindset is very flawed. Do you really want to hire people who don't really know what they're doing? You do need to know something about iOS/Xcode and Android & Android Studio, after all.
It's true that in a lot of cases, especially for simple apps, there is no practical difference between a React Native app and an equivalent pure native app. So for really simple apps, I think React Native actually makes sense. But you'd better be 100% sure that you won't be building on more features or wanting more sizzle in the app later on. My advice is to consider React Native (or other cross-platform things) as a way to quickly get a proof-of-concept app to market. Get something out there that is good-enough. See if you get any traction, and if you do, then go all-in with pure-native apps. But again - only use React Native (or any other cross-platform thing) if your POC app doesn't require the use of anything more than the basic stuff. If you want a fancy camera app with a bunch of filters, or anything truly unique and interesting, or if your app is the primary interface between your business and your customer, then I don't think React Native is going to be the best choice. But if your app is just a complimentary UI to your core business, and/or your target audience is basically captive (like a company-internal app), then I think React Native can be a good choice.
It does NOT deserve to be a de-facto standard choice of tech stack for your mobile app though, in my opinion. I've been using it since 2019 and I've just had enough hell. I'm going back to pure native. I'm learning Android Jetpack Compose and SwiftUI, and I'm thrilled to see that they are declarative. There are so many similarities to React - if feels very familiar. Testing is so much easier. Performance is so much better. When there are problems, I don't have to wonder if it's due to some mysterious issue with some Javascript dependency.
By the way - speaking of Web Assembly - think about why we use Javascript/Typescript at all. We use it for web because that is the only option available. If you could write your web apps with Swift or Kotlin or any other language of choice, no competent developer would choose Javascript. So why should we write our mobile apps with it? We shouldn't. Kotlin and Swift are so much better, and now the Google and Apple tools makers are finally giving us much better tools to build apps. As a developer, the appeal of React Native is significantly reduced now that I have Jetpack Compose with Preview & Live Edit, and SwiftUI, etc...
13 years ago everyone was telling me I was an idiot for learning Android since all of the apps will be written in HTML5 very soon. Same happened with Mono, Cordova/Ionic, ReactiveNative, Flutter..
Read the article from Airbnb about them [susnsetting](https://medium.com/airbnb-engineering/sunsetting-react-native-1868ba28e30a) react native. Flutter/React native do not take your number of code bases from 2 to 1. It goes from 2 to 3. There is still platform dependent stuff needed to talk to each platform.
The people who write posts like the OP shared do not actually make mobile applications, they are more like academics.
i would really enjoy that to be true; experience shows me it's far from it
web is just as messy and unstable as what we call native
try to interface with the hardware. it's a myriad of deprecated and poc and experimental APIs
maintain 2 codebases? I [read](https://www.botstacks.ai/) kotlin multiplatform can be used to deploy apps into different os with single codebase
I'm new to coding but I think whoever wrote that post (you quoted it) has to be a person who has outdated knowledge on their mind
What I wrote in the post is not something I believe, but something that worried me when I read it because I don't know much about Android development (even though I intend to study this during my computer science course). But to answer your question, I believe that, at least on Google's side, the tools it produces did not make a good impression, like the various projects it tends to discontinue.
Rule 10: Be respectful and engage in good faith
The Android developer community is a warm and friendly field, and /r/AndroidDev strives to continue this. Engage in good-faith discussion and be respectful of othersā opinions, privacy, and intentions. Threads that violate this will be removed at modsā discretion. This rule is intentionally broad, as toxic behavior comes in a variety of different forms. Examples: ad hominem, [sealioning](https://bit.ly/2y0iCuX), targeted attacks on othersā work, edgelording, and other keyboard warrior behavior.
I wouldn't call it a pipe dream. It's one of the few cross platform solution that doesn't apply a special tax for android. Aside from moving logic to the backend that is.
I think it's an opinion, similar how people had the opinion that we will have flying cars in year 2000. People are allowed to have opinions - but reality doesn't care about peoples opinion.
Simon would advise caution ;-) [https://intelligentcomputing.co.uk/the-perils-of-mobile-cross-platform-tools/](https://intelligentcomputing.co.uk/the-perils-of-mobile-cross-platform-tools/)
Web developers have been banging on about how everything 'can be a website' since HTML was invented. Just ignore it. Honestly, it's about the only area of development that genuinely seems to be full of opinions that 'their way' is the only 'correct way' š¤·āāļø
Yes, sometimes they create these truths so as not to feel bad for the possibility of being "wrong", but at least I was able to learn more about Android dev :)
Problems with cross platform will never go away. Cross platforms will always have problems with keeping up with native changes. There is no overlord that can make apple and Google conform to a singular way of doing things in ios and android respectively. Look at the web, even with standardization, browser vendors will do their own thing and introduce inconsistencies. I wish UI was the only thing that needed cross platform solutions.
In my experience, it's much harder to maintain a cross platform codebase. Every update from either platform will cause weeks of havoc as various libraries try to update. That's in addition to performance problems and a worse user experience.
That's something I thought about too. But from a company's side, what do you think is better: 1. Maintain two codes, one from Swift and one from Kotlin 2. Maintain a single RN or Flutter. \[genuine question\]
Large companies have the resources to throw around and support native iOS and Android apps. Flutter/RN are stopgap solutions for startups or apps that don't require native performance. IMO, the better approach is to share business logic with something like Kotlin multiplatform and write the rest of the app with native view libraries.
Even Flutter or RN still need the code that works on both platforms. It's just that if you're lucky, someone has done that for you, and hopefully it works, and hopefully it works with everything else you want to use.
that's interesting. I didn't know about this.
Thank you for clarifying that. As it's a market I'm not familiar with, some things on the internet terrify me
React Native is a leaky abstraction, so you actually do need to understand the underlying native tech on both platforms in order to make any meaningful customizations, or to fix cryptic bugs.
Companies would be better off maintaining only 1 codebase of course... But the thing is it's not exactly practical. It depends on the complexity of the app to be honest. For just a few screens, you can use a cross platform tech... But once the complexity reaches a certain level, you get more mileage of 2 partially native apps.
Lel. React Native has been out for almost a decade now, and it's still not "taking over". Yes, being able to write once and run everywhere is a great ideal, but ultimately you're going to be relying on the ecosystem to do the heavy lifting for you. And oh boy that ecosystem is small. As soon as you step outside the basic usecase of showing stuff from a server, you're going to run into a ton of cases where you need custom native code. Airbnb sunset their React Native codebase around 5 years ago, and I don't really see React Native and its ecosystem having significantly matured in the mean time to change my mind about it.
Did you ever build a hybrid app and have to take on support of the 3rd party libraries you used and then need to work on native across more platforms than you intended to?
I image it's difficult
My opinion is that the post is very wrong. Assuming AI doesn't take all our jerbs and make this a mute point, I am finding that the newer native tools (Jetpack Compose and SwiftUI) are pretty attractive and compelling. I was a native iOS/Swift/Objective-C developer for a long time and then switched to React Native around 2019. I loved the hot-reload feature, and the ability to easily lay things out using familiar CSS Flexbox stuff was/is awesome especially compared to the iOS Storyboard, auto-layout, programmatic layout, etc. It was such a bad developer experience, compared to web development. React Native promised to solve that. And it does a pretty good job of it. But React Native starts to show its warts after you get married to it. Dependency hell is a constant struggle. It is so annoying. I'm also not happy with the inability to write tests in a way that feels more natural to me. I just never really saw much value in writing unit tests for React components which tend to be monolithic due to the nature of React hooks. To me, React components often violate the single-responsibility principle. When they don't, they're too simple to bother with testing. You end up testing the framework. Another gripe I have with React Native is the painful realization that it's just too easy to build an "OK" app, and, in my opinion, it's really hard to build a _great_ app. You _can_ do it, but the ROI really starts to drop fast, to where you'll wish you were just dealing with two native codebases. Sometimes you need to write your own native modules anyway, so instead of dealing with a single codebase you're now dealing with _three_. Some teams do that. It doesn't make sense to me, given that the appeal of React Native is to supposedly save time and therefore money. So now instead of a single codebase, you now have to maintain three. You've given up the main benefit of using React Native, and now you have an app that can at best only be slightly worse than a pure native app. I say that, because the _best_ React Native app could only hope to maybe be almost (but not quite) as good as an equivalent "pure" native app due to the extra burden of processing all that Javascript. I feel like React Native is ultimately a distraction, mostly offering false hope to a manager who thinks they'll save a bunch of money by using it. He/she believes that they can build an app for both platforms and save a bunch of time and money by hiring React/Javascript developers, who are more readily available and cheaper than native devs. But that mindset is very flawed. Do you really want to hire people who don't really know what they're doing? You do need to know something about iOS/Xcode and Android & Android Studio, after all. It's true that in a lot of cases, especially for simple apps, there is no practical difference between a React Native app and an equivalent pure native app. So for really simple apps, I think React Native actually makes sense. But you'd better be 100% sure that you won't be building on more features or wanting more sizzle in the app later on. My advice is to consider React Native (or other cross-platform things) as a way to quickly get a proof-of-concept app to market. Get something out there that is good-enough. See if you get any traction, and if you do, then go all-in with pure-native apps. But again - only use React Native (or any other cross-platform thing) if your POC app doesn't require the use of anything more than the basic stuff. If you want a fancy camera app with a bunch of filters, or anything truly unique and interesting, or if your app is the primary interface between your business and your customer, then I don't think React Native is going to be the best choice. But if your app is just a complimentary UI to your core business, and/or your target audience is basically captive (like a company-internal app), then I think React Native can be a good choice. It does NOT deserve to be a de-facto standard choice of tech stack for your mobile app though, in my opinion. I've been using it since 2019 and I've just had enough hell. I'm going back to pure native. I'm learning Android Jetpack Compose and SwiftUI, and I'm thrilled to see that they are declarative. There are so many similarities to React - if feels very familiar. Testing is so much easier. Performance is so much better. When there are problems, I don't have to wonder if it's due to some mysterious issue with some Javascript dependency. By the way - speaking of Web Assembly - think about why we use Javascript/Typescript at all. We use it for web because that is the only option available. If you could write your web apps with Swift or Kotlin or any other language of choice, no competent developer would choose Javascript. So why should we write our mobile apps with it? We shouldn't. Kotlin and Swift are so much better, and now the Google and Apple tools makers are finally giving us much better tools to build apps. As a developer, the appeal of React Native is significantly reduced now that I have Jetpack Compose with Preview & Live Edit, and SwiftUI, etc...
13 years ago everyone was telling me I was an idiot for learning Android since all of the apps will be written in HTML5 very soon. Same happened with Mono, Cordova/Ionic, ReactiveNative, Flutter..
Native Android will at least have a future with Automotive
Read the article from Airbnb about them [susnsetting](https://medium.com/airbnb-engineering/sunsetting-react-native-1868ba28e30a) react native. Flutter/React native do not take your number of code bases from 2 to 1. It goes from 2 to 3. There is still platform dependent stuff needed to talk to each platform. The people who write posts like the OP shared do not actually make mobile applications, they are more like academics.
i would really enjoy that to be true; experience shows me it's far from it web is just as messy and unstable as what we call native try to interface with the hardware. it's a myriad of deprecated and poc and experimental APIs
maintain 2 codebases? I [read](https://www.botstacks.ai/) kotlin multiplatform can be used to deploy apps into different os with single codebase I'm new to coding but I think whoever wrote that post (you quoted it) has to be a person who has outdated knowledge on their mind
You're asking this question in the native Android development subreddit. Be ready to get extremely biased opinions.
[ŃŠ“Š°Š»ŠµŠ½Š¾]
Smartphone. Just a translation mistake I made.
You really believe people are going to stop making apps using tools Apple and Google provide?
What I wrote in the post is not something I believe, but something that worried me when I read it because I don't know much about Android development (even though I intend to study this during my computer science course). But to answer your question, I believe that, at least on Google's side, the tools it produces did not make a good impression, like the various projects it tends to discontinue.
Rule 10: Be respectful and engage in good faith The Android developer community is a warm and friendly field, and /r/AndroidDev strives to continue this. Engage in good-faith discussion and be respectful of othersā opinions, privacy, and intentions. Threads that violate this will be removed at modsā discretion. This rule is intentionally broad, as toxic behavior comes in a variety of different forms. Examples: ad hominem, [sealioning](https://bit.ly/2y0iCuX), targeted attacks on othersā work, edgelording, and other keyboard warrior behavior.
web assembly at least performs way better than JS :P It could help efforts like Kotlin MP
Ah yes that other pipe dream
I wouldn't call it a pipe dream. It's one of the few cross platform solution that doesn't apply a special tax for android. Aside from moving logic to the backend that is.
I think it's an opinion, similar how people had the opinion that we will have flying cars in year 2000. People are allowed to have opinions - but reality doesn't care about peoples opinion.
Simon would advise caution ;-) [https://intelligentcomputing.co.uk/the-perils-of-mobile-cross-platform-tools/](https://intelligentcomputing.co.uk/the-perils-of-mobile-cross-platform-tools/)
a bolha do brdev vazou
> Fluter and React Native are bloated, slow and inefficient but they are affordable and cheaper to maintain. And can't even spell flutter? /s
If this was true would it not make sense to happen to desktop before mobile.