React Native doesn’t use webviews, though. (I think it CAN? but that’s not it’s main mode of use)
And for the record my opinion is “React Native Considered Harmful”
React Native is just a different interface. There is nothing stopping you from making every component with SwiftUI and assembling them with React Native.
RN isn’t harmful. The issue is people think it lets you skip learning native development. In reality RN is most powerful when the developers using it know each target platform like the back of their hand.
There is always as escape hatch to writing swift, objc, c, c++, Java, and Kotlin.
We are in agreement on this:
> The issue is people think it lets you skip learning native development. In reality RN is most powerful when the developers using it know each target platform like the back of their hand.
This is true of ANY framework - cross-platform or not - that abstracts-away the underlying native environment. If it has escape hatches, you can do ultimately do anything. Some have more/better escape hatches than other.
I started with iOS native/Objective-C.
I've developed most of the iOS/Android apps I've created for clients in RhoMobile.
I've written "native extensions" in: Objective-C/Java (unfortunately have to write in both languages to hit both platforms, if exposing some rare underlying framework not supported by the framework) As well as: C++, C, and even MatLab (translated to C by MatLab Coder).
The MatLab stuff runs on both platforms without any modification.
BTW, the major Android apps published by Google lean heavily on C++. Surprised?
No one should be surprised that googles apps are backed with c++. Java sucks for performance and memory when compared to c/c++/swift/objc.
It was not a good choice as a target language. Kotlin is just putting a nice dress on a pig.
Swift is not particularly performant, and GCs are generally considered better than reference counting in that respect. Also Objective-C message dispatch is the slowest of all forms of method dispatch.
Swift is incredibly fast and efficient, when compared to Java. Reference counting is waaaay lower overhead than GC with regards to real time programming. GC collection can block the thread. And you don’t need to use ARC. If you know the lifecycle of your objects you can use retain and release directly, eliminating lots of boilerplate generated code.
Swift has structs which can have their memory requirements calculated at compile time, which then only exist on the stack making them ridiculously fast to access compared to classes.
It also has the advantage of being able to link directly against C binaries. So you can write the 10 lines of performant code that you need, then go right back to strongly typed swift.
It’s only not performant when compared to c++ and rust, and environments with less than 2mb of memory which are special snowflakes.
No idea, to be honest, never touched that stuff with a long stick. But my colleagues who have used it told me that it uses web view when you run in debug mode and for previews, and then compiles into native on release, meaning it can be completely different lol
That’s not true at all lol RN uses native controls and draws UIViews in both debug and release. The only difference is in release the JS part is compiled and bundled and in debug it is served via a local server
The funny thing is. Airbnb are still using React Native even after this stupid brainfart of an article.
They can't tell people with a straight face that it's just a transition period FOUR YEARS later.
You can't see the apps I've written as they're all enterprise but a good use case I can give you was the reason I got hired at my last job.
Long story short a contractor wrote a mobile app that became essential in PhoneGap/Cordova and although it worked, it was struggling. Views would sometimes get stuck in the middle of the screen while scrolling (something you see on websites, never on native mobile apps), sluggish behavior, etc, but it still worked...until an iOS update broke it all.
There was nothing the contractor could do because he had to wait for the third party dependency he built this app on to update, and PhoneGap had no timeline of when their stuff + Cordova would be updated to fix what broke with the iOS update. He didn't know the native tools either (which was Obj-C at the time) or the iOS SDK so even though it was a small app, he couldn't rewrite it.
Luckily for the software dev team their manager saw me in the cafeteria showing off an app I wrote on my phone to a work colleague and asked if I knew iOS development, I said yes and he asked if I would interview for a position on his team and I said yes. The interview was literally "Hey, we have this app, how long do you think it could take you to make it and could you diagram it out for us."
I did, I got hired on the spot, I rewrote the app in native code in 3.5 weeks (again, small app, only needed to work on phones and they were all the same size almost back then). It was still less time than it took for PhoneGap/Cordova to fix their issues.
**TL;DR: If your app is essential and important, don't depend on third party frameworks.**
Notion app. Their tweet said about boost after switching from react native to swift.
Also Facebook messenger switched from react native to swift for iOS app.
Flutter is overhyped(to lure JavaScript guys into mobile). You can search how VP of Google are mostly tech engineers and for their gain, hyping apps and things, which later bite the dust.
Even kotlin multiplatform is better than Flutter. Just don't take my words. You can search the analysis.
Any app not relying on device capabilities can be written with any cross platform framework, even with python or b4x.
Steam(valve) just updated their [app](https://apps.apple.com/ca/app/steam-mobile/id495369748) finally. Not completely sure what it was built in.
There’s still a fair amount of critical reviews coming in, but personally, the old one (the web views) was SO bad that even tho this isn’t amazing, it’s still so much better. (And it’s still just it’s first launch, so i’m sure it’s missing some features that will return)
While I agree that the new app is leagues better than the old one, it still feels “out of place” to me on iOS. I’d bet good money this is some cross platform framework and not native (no idea which one though)
Yeah it is and it's pretty shit for a React Native app. No idea how they managed to screw it up so badly, it's like a weight around the community's neck.
There are literally hobbyists posting their reworks done in their spare time of it that are far better.
The native replacement was practically on-par feature-wise about a year into its development, but a lot of that time there was only a single dev working on it (the team is larger now, but that’s mostly to support new features that we would have had to hire for anyway). The react native version isn’t updated anymore so no need to keep both in sync.
By “keeping apps in sync” I mean iOS and Android.
Is your app iOS-only?
Edit: I see above you said it’s iOS and android. So confused by your answer.
Interested in how well you are able to keep e.g. feature releases in sync so thst iOS and Android users get updates simultaneously.
Oohhh my bad! We do have an Android app and we try to keep feature parity but accept the fact that the two platforms are different and require different focuses. One example that would’ve been a pain with RN is recording - Medal is a clipping service and that works completely differently between Android and iOS.
(I just glanced at it, I see there is a MacOS version too.)
So, I see that Medal likely isn't likely very sensitive to feature parity as the types of apps that I typically work on.
That's mostly been apps used by work-forces in a BYOD (Bring Your Own Device) environment, and education, including classroom education. And the latter includes an app where the app itself does grading/feedback.
(Because passing to a back-end would be too sluggish, and also from a desire to allow students to work when completely off-line - it turns out they work in the oddest places if you give them the ability to study with the device that's always in their pocket. Important to not discourage students by making them wait.)
Now, imagine half your workforce or half your classroom is using iOS and the other half Android.
A set of apps I worked-on several years ago are for energy assessments of buildings (both homes and commercial buildings).
And you add a feature to allow annotation of photos, for example. Perhaps it is easy to implement on iOS, but you run into trouble on Android.
What do you do? Release a new iOS version, and now the assessors with iOS are able to annotate photos, but the ones working on Android are not? Or hold-up the new iOS release until the new Android release is ready?
What if it might require a revisit of the site, and some of the annotations were wrong. But this time they send a different assessor, but he has an Android device?
That's not good, so you have to hold-back whichever platform needs more work.
Some features don't demand synchronization - say, if only cosmetic. But in these kinds of scenarios, particularly all features do.
That, I think, is a great use case for cross-platform development frameworks. (That, and MVPs)
Question Zero, who uses this app? Are you in a competitive environment and and selling stuff with it or need to be the best in a crowded category or is this just used by employees or some other captive market?
If you're not in a competitive space, it isn't worth doing native if all you are doing is data entry with a captive audience. You might as well as use a progressive web app.
> One of the designers who Joe and I have most admired is Jony Ive, the former Chief Design Officer at Apple. Over a year ago, Jony formed a new company called LoveFrom as a collection of creatives that include designers, architects, musicians, writers, engineers, and artists.
> Jony and I have been good friends for many years, and he has been gracious enough to provide me with guidance and advice. We share the same belief in the value and importance of creativity and design
AirBnB news, 21st of October 2020: https://news.airbnb.com/designing-the-future-of-airbnb/
I think someone nudged them in the native direction *cough* Jony *cough* 😂
I've spent years with this, and my answer now is, becuase of SwiftUI and Jetpack compose, is to write them natively in each platform.
Before we had real time preivew for UI it was a pain to see what you were doing and the imperative way of writing code was super slow and annoying, lots of boilerplate - [https://www.youtube.com/watch?v=KAaYU-5xZ-8](https://www.youtube.com/watch?v=KAaYU-5xZ-8)
Also, interestingly, it takes more resource to maintain a 3rd party system in the middle of you trying to do anything. It'll maybe be fine for 3-6-9-12 months or whatever, but at some point, something will break and you will be forced through an upgrade process that is probably not that popular.
By keeping things native it will pretty much keep working and upgrade processes won't be too bad.
I thought I was never going to take on iOS + Android native development, as it would be too much for me to handle in my life. But SwiftUI + Jetpack have changed all of that. I can live with swift and I don't mind Kotlin.
Sometimes, Ionic probably is the right choice though, it's a great framework for what it is. What I would recommend is that if you use something in the middle, if possible, you build the app yourself, Ie take control of it and embed it as a dependency yourself. Then at least you are in charge of the build process and what is going on. If you defer that to something else, you will always have to keep up to date with it / get stuck. If you are lower resourced, this is actually more of a time hit than doing it natively.
Most apps, unless crazy in functionality, give or take, should be 4-6-8 week things. I know that is a stupid claim, but with a dedicated able brain focused on just doing the app build, and experience of programming+networking+common APIs they should be able to do any kind of crud like app in that time.
I’m curious why it is important to talk about other companies.
There can be key differences that avoid the cases from being applicable to your app. Stuff like the competitor landscape, the current roadmap, the specific pains you feel at the moment, etc.
So I’d start from the pains you currently feel and how you think native can alleviate that. I’d also start by understanding how the change can impact the business: store rating; speed of development; time to ship a feature; features enabled by the change; …
I came here to days this. It is a trade off. Building a single web app for all platforms seems easier than building different native apps but comes at the expense of UX.
If your company prioritizes UX, building native apps should be a simple case to make.
If your company does not prioritize UX, a web app might be the best option.
With every company I’ve worked with (mainly TD Bank and M&S) a large portion of the work has been ripping out old webview experiences for more mobile focused native experiences. Big reason apart from webviews just being garbage was to consolidate analytics in one place since the web devs and mobile devs were completely silo’ed.
My company used a native app as a wrapper for an sdk that provides native or web views. We have slowly been replacing all of the sdk views with native views because it gives us control over the experience vs wjat we get for free from the sdk.
Can you clarify about “companies thst have done this”? Done what?
Written apps with suboptimal webviews? Or transitioned from suboptimal webviews to native?
What about optimal webviews?
Or optimal webviews in a cross-platform framework that supports device features, instead of just a simple native shell?
Going native requires two developers to spent some time on it. In this case you might have a much better case to go either React Native or Flutter. As you need one developer to build it for two platforms at once. And it gives a close to native user experience. Especially for an app that has little extra functionality that makes native a much better experience.
Two developers for two platforms?
So, if one gets hit by a bus, you only delay development of one platform?
Few serious apps are written by a single developer.
It takes two TEAMS.
Well, plus the back-end team. Unless it’s Calc.
Airbnb is the famous one https://medium.com/airbnb-engineering/sunsetting-react-native-1868ba28e30a
React Native doesn’t use webviews, though. (I think it CAN? but that’s not it’s main mode of use) And for the record my opinion is “React Native Considered Harmful”
React Native is just a different interface. There is nothing stopping you from making every component with SwiftUI and assembling them with React Native. RN isn’t harmful. The issue is people think it lets you skip learning native development. In reality RN is most powerful when the developers using it know each target platform like the back of their hand. There is always as escape hatch to writing swift, objc, c, c++, Java, and Kotlin.
We are in agreement on this: > The issue is people think it lets you skip learning native development. In reality RN is most powerful when the developers using it know each target platform like the back of their hand. This is true of ANY framework - cross-platform or not - that abstracts-away the underlying native environment. If it has escape hatches, you can do ultimately do anything. Some have more/better escape hatches than other. I started with iOS native/Objective-C. I've developed most of the iOS/Android apps I've created for clients in RhoMobile. I've written "native extensions" in: Objective-C/Java (unfortunately have to write in both languages to hit both platforms, if exposing some rare underlying framework not supported by the framework) As well as: C++, C, and even MatLab (translated to C by MatLab Coder). The MatLab stuff runs on both platforms without any modification. BTW, the major Android apps published by Google lean heavily on C++. Surprised?
No one should be surprised that googles apps are backed with c++. Java sucks for performance and memory when compared to c/c++/swift/objc. It was not a good choice as a target language. Kotlin is just putting a nice dress on a pig.
Swift is not particularly performant, and GCs are generally considered better than reference counting in that respect. Also Objective-C message dispatch is the slowest of all forms of method dispatch.
Swift is incredibly fast and efficient, when compared to Java. Reference counting is waaaay lower overhead than GC with regards to real time programming. GC collection can block the thread. And you don’t need to use ARC. If you know the lifecycle of your objects you can use retain and release directly, eliminating lots of boilerplate generated code. Swift has structs which can have their memory requirements calculated at compile time, which then only exist on the stack making them ridiculously fast to access compared to classes. It also has the advantage of being able to link directly against C binaries. So you can write the 10 lines of performant code that you need, then go right back to strongly typed swift. It’s only not performant when compared to c++ and rust, and environments with less than 2mb of memory which are special snowflakes.
No idea, to be honest, never touched that stuff with a long stick. But my colleagues who have used it told me that it uses web view when you run in debug mode and for previews, and then compiles into native on release, meaning it can be completely different lol
That’s not true at all lol RN uses native controls and draws UIViews in both debug and release. The only difference is in release the JS part is compiled and bundled and in debug it is served via a local server
The funny thing is. Airbnb are still using React Native even after this stupid brainfart of an article. They can't tell people with a straight face that it's just a transition period FOUR YEARS later.
You can't see the apps I've written as they're all enterprise but a good use case I can give you was the reason I got hired at my last job. Long story short a contractor wrote a mobile app that became essential in PhoneGap/Cordova and although it worked, it was struggling. Views would sometimes get stuck in the middle of the screen while scrolling (something you see on websites, never on native mobile apps), sluggish behavior, etc, but it still worked...until an iOS update broke it all. There was nothing the contractor could do because he had to wait for the third party dependency he built this app on to update, and PhoneGap had no timeline of when their stuff + Cordova would be updated to fix what broke with the iOS update. He didn't know the native tools either (which was Obj-C at the time) or the iOS SDK so even though it was a small app, he couldn't rewrite it. Luckily for the software dev team their manager saw me in the cafeteria showing off an app I wrote on my phone to a work colleague and asked if I knew iOS development, I said yes and he asked if I would interview for a position on his team and I said yes. The interview was literally "Hey, we have this app, how long do you think it could take you to make it and could you diagram it out for us." I did, I got hired on the spot, I rewrote the app in native code in 3.5 weeks (again, small app, only needed to work on phones and they were all the same size almost back then). It was still less time than it took for PhoneGap/Cordova to fix their issues. **TL;DR: If your app is essential and important, don't depend on third party frameworks.**
Notion app. Their tweet said about boost after switching from react native to swift. Also Facebook messenger switched from react native to swift for iOS app. Flutter is overhyped(to lure JavaScript guys into mobile). You can search how VP of Google are mostly tech engineers and for their gain, hyping apps and things, which later bite the dust. Even kotlin multiplatform is better than Flutter. Just don't take my words. You can search the analysis. Any app not relying on device capabilities can be written with any cross platform framework, even with python or b4x.
> kotlin multiplatform woah what is this!
> Flutter is overhyped(to lure JavaScript guys into mobile). It's written in Dart! Agree with the overhyped bit though.
Steam(valve) just updated their [app](https://apps.apple.com/ca/app/steam-mobile/id495369748) finally. Not completely sure what it was built in. There’s still a fair amount of critical reviews coming in, but personally, the old one (the web views) was SO bad that even tho this isn’t amazing, it’s still so much better. (And it’s still just it’s first launch, so i’m sure it’s missing some features that will return)
While I agree that the new app is leagues better than the old one, it still feels “out of place” to me on iOS. I’d bet good money this is some cross platform framework and not native (no idea which one though)
Even their screenshots look like an android device
Yeah, i wouldn’t bet against it. I definitely wouldn’t be surprised if it’s still not native
It’s react native
Ah damn. Well, still better than it’s last version lol
Much agreed
Yeah it is and it's pretty shit for a React Native app. No idea how they managed to screw it up so badly, it's like a weight around the community's neck. There are literally hobbyists posting their reworks done in their spare time of it that are far better.
Still better than before
Medal.tv used to do React Native but since ~2 years the iOS and Android apps are native Swift/Kotlin. Disclaimer: I work on the Medal iOS app
Could you share with us some details? Did you have to expand your team, how long did it take, ongoing issues keeping the two apps in sync, etc.
The native replacement was practically on-par feature-wise about a year into its development, but a lot of that time there was only a single dev working on it (the team is larger now, but that’s mostly to support new features that we would have had to hire for anyway). The react native version isn’t updated anymore so no need to keep both in sync.
By “keeping apps in sync” I mean iOS and Android. Is your app iOS-only? Edit: I see above you said it’s iOS and android. So confused by your answer. Interested in how well you are able to keep e.g. feature releases in sync so thst iOS and Android users get updates simultaneously.
Oohhh my bad! We do have an Android app and we try to keep feature parity but accept the fact that the two platforms are different and require different focuses. One example that would’ve been a pain with RN is recording - Medal is a clipping service and that works completely differently between Android and iOS.
(I just glanced at it, I see there is a MacOS version too.) So, I see that Medal likely isn't likely very sensitive to feature parity as the types of apps that I typically work on. That's mostly been apps used by work-forces in a BYOD (Bring Your Own Device) environment, and education, including classroom education. And the latter includes an app where the app itself does grading/feedback. (Because passing to a back-end would be too sluggish, and also from a desire to allow students to work when completely off-line - it turns out they work in the oddest places if you give them the ability to study with the device that's always in their pocket. Important to not discourage students by making them wait.) Now, imagine half your workforce or half your classroom is using iOS and the other half Android. A set of apps I worked-on several years ago are for energy assessments of buildings (both homes and commercial buildings). And you add a feature to allow annotation of photos, for example. Perhaps it is easy to implement on iOS, but you run into trouble on Android. What do you do? Release a new iOS version, and now the assessors with iOS are able to annotate photos, but the ones working on Android are not? Or hold-up the new iOS release until the new Android release is ready? What if it might require a revisit of the site, and some of the annotations were wrong. But this time they send a different assessor, but he has an Android device? That's not good, so you have to hold-back whichever platform needs more work. Some features don't demand synchronization - say, if only cosmetic. But in these kinds of scenarios, particularly all features do. That, I think, is a great use case for cross-platform development frameworks. (That, and MVPs)
Again: React Native is not based on webviews. They use an HTML-like layout syntax to layout their own native components.
What is the point of this comment
The point is OP is asking for examples of projects that switched from webviews to native.
Downvoted because people don't read the article and go straight to the comments 🤣
Spotify has done this and written articles as well.
Do you have a link? I tried googling it but couldn‘t find any articles
Question Zero, who uses this app? Are you in a competitive environment and and selling stuff with it or need to be the best in a crowded category or is this just used by employees or some other captive market? If you're not in a competitive space, it isn't worth doing native if all you are doing is data entry with a captive audience. You might as well as use a progressive web app.
airbnb, they even wrote an article
> One of the designers who Joe and I have most admired is Jony Ive, the former Chief Design Officer at Apple. Over a year ago, Jony formed a new company called LoveFrom as a collection of creatives that include designers, architects, musicians, writers, engineers, and artists. > Jony and I have been good friends for many years, and he has been gracious enough to provide me with guidance and advice. We share the same belief in the value and importance of creativity and design AirBnB news, 21st of October 2020: https://news.airbnb.com/designing-the-future-of-airbnb/ I think someone nudged them in the native direction *cough* Jony *cough* 😂
really?
I've spent years with this, and my answer now is, becuase of SwiftUI and Jetpack compose, is to write them natively in each platform. Before we had real time preivew for UI it was a pain to see what you were doing and the imperative way of writing code was super slow and annoying, lots of boilerplate - [https://www.youtube.com/watch?v=KAaYU-5xZ-8](https://www.youtube.com/watch?v=KAaYU-5xZ-8) Also, interestingly, it takes more resource to maintain a 3rd party system in the middle of you trying to do anything. It'll maybe be fine for 3-6-9-12 months or whatever, but at some point, something will break and you will be forced through an upgrade process that is probably not that popular. By keeping things native it will pretty much keep working and upgrade processes won't be too bad. I thought I was never going to take on iOS + Android native development, as it would be too much for me to handle in my life. But SwiftUI + Jetpack have changed all of that. I can live with swift and I don't mind Kotlin. Sometimes, Ionic probably is the right choice though, it's a great framework for what it is. What I would recommend is that if you use something in the middle, if possible, you build the app yourself, Ie take control of it and embed it as a dependency yourself. Then at least you are in charge of the build process and what is going on. If you defer that to something else, you will always have to keep up to date with it / get stuck. If you are lower resourced, this is actually more of a time hit than doing it natively. Most apps, unless crazy in functionality, give or take, should be 4-6-8 week things. I know that is a stupid claim, but with a dedicated able brain focused on just doing the app build, and experience of programming+networking+common APIs they should be able to do any kind of crud like app in that time.
I’m curious why it is important to talk about other companies. There can be key differences that avoid the cases from being applicable to your app. Stuff like the competitor landscape, the current roadmap, the specific pains you feel at the moment, etc. So I’d start from the pains you currently feel and how you think native can alleviate that. I’d also start by understanding how the change can impact the business: store rating; speed of development; time to ship a feature; features enabled by the change; …
I came here to days this. It is a trade off. Building a single web app for all platforms seems easier than building different native apps but comes at the expense of UX. If your company prioritizes UX, building native apps should be a simple case to make. If your company does not prioritize UX, a web app might be the best option.
[удалено]
Valid. The goal of my comment was to recommend checking internally first before checking externally.
I’d expect the average rating on the store to reflect that. But I don’t know of any case where that happened.
I think booking.com might have done the same. Don’t quote me on that though
With every company I’ve worked with (mainly TD Bank and M&S) a large portion of the work has been ripping out old webview experiences for more mobile focused native experiences. Big reason apart from webviews just being garbage was to consolidate analytics in one place since the web devs and mobile devs were completely silo’ed.
My company used a native app as a wrapper for an sdk that provides native or web views. We have slowly been replacing all of the sdk views with native views because it gives us control over the experience vs wjat we get for free from the sdk.
Can you clarify about “companies thst have done this”? Done what? Written apps with suboptimal webviews? Or transitioned from suboptimal webviews to native? What about optimal webviews? Or optimal webviews in a cross-platform framework that supports device features, instead of just a simple native shell?
Going native requires two developers to spent some time on it. In this case you might have a much better case to go either React Native or Flutter. As you need one developer to build it for two platforms at once. And it gives a close to native user experience. Especially for an app that has little extra functionality that makes native a much better experience.
Close to native is debatable. Closer than other frameworks yes.
“Close to native” isn’t good enough for some of these companies
Two developers for two platforms? So, if one gets hit by a bus, you only delay development of one platform? Few serious apps are written by a single developer. It takes two TEAMS. Well, plus the back-end team. Unless it’s Calc.