Building all of our new mobile apps using React Native(engineering.shopify.com)
engineering.shopify.com
Building all of our new mobile apps using React Native
https://engineering.shopify.com/blogs/engineering/react-native-future-mobile-shopify
576 comments
oh no, how will anyone understand the graphic now?
they changed it I think to be more incorrect, you can't put text in a View.
You cannot see the imports.
import {Text as View} from 'react-native';
All good!
import {Text as View} from 'react-native';
All good!
this is truly evil
It seems they fixed it!
https://cdn.shopify.com/s/files/1/0779/4361/files/React_Nati...
https://cdn.shopify.com/s/files/1/0779/4361/files/React_Nati...
Airbnb said the same back in the day. Guess what happened then? https://medium.com/airbnb-engineering/sunsetting-react-nativ...
And in a couple of years, "Why we are moving away from React Native at Shopify".
Not slamming React Native but the sensationalistic headline. Anyone with a bit of experience in software should know better than making this kind of silly proclamation about the future of your software stack.
Not slamming React Native but the sensationalistic headline. Anyone with a bit of experience in software should know better than making this kind of silly proclamation about the future of your software stack.
Man first thing I thought of.
Seems like if you try to proclaim the future you end up eating your words
Seems like if you try to proclaim the future you end up eating your words
My first thought was the Airbnb article "React Native at Airbnb" https://medium.com/airbnb-engineering/react-native-at-airbnb...
I understand how examples like this stick in people's minds, however, just because one company decided not to move forward with a technology doesn't mean that all companies will do the same.
Facebook has continued to use it, Microsoft has begun using it heavily, Twitter uses it on the web[0], Discord has been very happy with it -- and countless other examples.
[0] https://github.com/necolas/react-native-web
Facebook has continued to use it, Microsoft has begun using it heavily, Twitter uses it on the web[0], Discord has been very happy with it -- and countless other examples.
[0] https://github.com/necolas/react-native-web
[deleted]
I don't think anybody read the headline and assumed that no other technology would ever be used at Shopify.
The company I've been contracting for lasted just over a year on react native before heading back to native. Even though the product was still a prototype, we were spending way too much time updating libraries and trying to decipher all the breaking dependencies. Some easy, some very cryptic.
On a side note, I'm not a big fan of people shoehorning stateless web development patterns into application environments that support stateful development. The solutions appropriate for development inside a web page are often not helpful inside an application binary.
On a side note, I'm not a big fan of people shoehorning stateless web development patterns into application environments that support stateful development. The solutions appropriate for development inside a web page are often not helpful inside an application binary.
I have not seen one good app for android that has been written in react native. Can anyone show me one that doesn't suck in performance?
From my understanding, it does exist in popular Android apps, but usually for larger apps its used for only parts of the app and not the entire app.
Discord is an interesting case. They were using React Native for iOS and not Android. In their defense, this probably makes sense since substantial code sharing could be achieved between their desktop/web app and their iPhone app with this approach.
Discord is an interesting case. They were using React Native for iOS and not Android. In their defense, this probably makes sense since substantial code sharing could be achieved between their desktop/web app and their iPhone app with this approach.
I'm pretty okay with the Spotify app nowadays. It used to be worse, I think, now I'm rather annoyed by the not that great UI/UX design (everything is way too large, I don't see shit, man).
Instagram.
Instagram has very limited parts of the application written in RN, like 'Edit Profile'. [1]
The vast majority of the app is implemented natively.
[1] https://instagram-engineering.com/react-native-at-instagram-...
The vast majority of the app is implemented natively.
[1] https://instagram-engineering.com/react-native-at-instagram-...
That article is 3 years old, but it mentions "Photos Of view", "Post Promote", "Save Posts", "Checkpoints", "Comment Moderation", "Lead Gen Ads", "Push Notification Settings", and "SMS Captcha Checkpoint". At any rate, I'm curious to see how this has evolved over the past 3 years and I remain impressed with their seamless integration of RN and native.
My app is incredibly simple but its performance is good. HopeWaves on the play store.
Seems consistent with your comment, IMO, given that "the future" is by definition something which never arrives.
It's much less exciting, however, to say "React Native Is What's Next at Shopify".
It's much less exciting, however, to say "React Native Is What's Next at Shopify".
Sadly, this sort of public PR campaign is surely related to an internal PR campaign. Often followed by a declaration of Totally Amazing Success, shortly after which the person who led the campaign will use the victory to move to a higher position, possibly at a new company.
Saw it happening a few times in my 12 year of industry. I suppose it's specifically common in companies that use social media (and other media) presence as a recruitment boosting tool.
Twice the "leader" of the "Totally Amazing Success" left the company to "be totally amazing" somewhere else. In both cases the team was made mostly of very young engineers, the level of amazingness was strongly overestimated. It was also declared very early, before the "novelty" of the "new thing" faded, and also before the downsides appeared while maintaining the product.
Twice the "leader" of the "Totally Amazing Success" left the company to "be totally amazing" somewhere else. In both cases the team was made mostly of very young engineers, the level of amazingness was strongly overestimated. It was also declared very early, before the "novelty" of the "new thing" faded, and also before the downsides appeared while maintaining the product.
RDD: Resume-Driven Development
You often see this kind of stack rank of developer priorities:
1. What’s good for my career
2. What makes my boss look good
3. What is convenient for the development team
4. What is good for the company
...
99. What’s good for users
You often see this kind of stack rank of developer priorities:
1. What’s good for my career
2. What makes my boss look good
3. What is convenient for the development team
4. What is good for the company
...
99. What’s good for users
Honestly I think the future of mobile will just be... mobile websites.
What's missing until regular websites have parity with mobile apps in functionality?
- Accelerometer and all sensor support (some of these are already supported on various browsers on various OSes)
- Background support
- Bluetooth
- WiFi
- Better notifications
- etc.
Sure there will always be a need for native, but 99% of apps don't need any of that stuff, really. Though I suppose both Apple and Google have an inherent interest to gatekeep.
Looking at my own most used apps:
- Messenger
- Mail
- White Noise
- Teams
- Google Maps
Literally all of them could be implemented as responsive pages with acceptable performance. There are a small number of companies that don't bother with mobile apps, Craigslist being the most notable of them until a few months ago. Part of the issue though is that the app stores give you a lot of visibility and to get that visibility you need to be in the app store. Sure you can use a web view, but in some ways that's even worse than just a responsive website because now you have to deal with the abstraction of your site that is a WebView. Not to mention the temptation to try for "best of both worlds".
What's missing until regular websites have parity with mobile apps in functionality?
- Accelerometer and all sensor support (some of these are already supported on various browsers on various OSes)
- Background support
- Bluetooth
- WiFi
- Better notifications
- etc.
Sure there will always be a need for native, but 99% of apps don't need any of that stuff, really. Though I suppose both Apple and Google have an inherent interest to gatekeep.
Looking at my own most used apps:
- Messenger
- White Noise
- Teams
- Google Maps
Literally all of them could be implemented as responsive pages with acceptable performance. There are a small number of companies that don't bother with mobile apps, Craigslist being the most notable of them until a few months ago. Part of the issue though is that the app stores give you a lot of visibility and to get that visibility you need to be in the app store. Sure you can use a web view, but in some ways that's even worse than just a responsive website because now you have to deal with the abstraction of your site that is a WebView. Not to mention the temptation to try for "best of both worlds".
Look at your most used apps - none of them are "responsive pages". That should tell you something. Folks who have tried responsive pages haven't done that well.
I am curious - what is the most popular responsive webpage on iphone would people say? I'd like to check out the current leader in this space.
I am curious - what is the most popular responsive webpage on iphone would people say? I'd like to check out the current leader in this space.
Google?
I use Facebook's as I don't want Facebook's grubby hands using private APIs on my phone to get every bit of data they can. At least the browser limits them.
None of my most used apps are responsive pages because Safari neuters the functionality.
- White Noise -> Safari can't play background sounds once closed.
- Messenger -> Notification trouble, not to mention Facebook won't let you use the mobile version of Messenger without a lot of effort.
- Google Maps -> Close, but a lot of the functionality, like reminders require notifications which isn't up-to-par with just Safari
- Teams -> See messenger.
- White Noise -> Safari can't play background sounds once closed.
- Messenger -> Notification trouble, not to mention Facebook won't let you use the mobile version of Messenger without a lot of effort.
- Google Maps -> Close, but a lot of the functionality, like reminders require notifications which isn't up-to-par with just Safari
- Teams -> See messenger.
Apple does some fairly beautiful responsive webpages... Albeit rather heavy! https://www.apple.com/apple-arcade/
Whats the slack app written in?
The iOS app is native UIKit I believe.
Desktop apps are (in)famously Electron.js
iOS is native: https://twitter.com/SlackHQ/status/931599784137363459?s=20
Android is native, too (no source)
iOS is native: https://twitter.com/SlackHQ/status/931599784137363459?s=20
Android is native, too (no source)
Because once a company is invested in the native side, they probably aren't going to look at greenfield solutions anytime soon?
If you're considering building a new app, a responsive site with JS is definitely a contender. Take a look at the performance numbers. https://twitter.com/dhh/status/1174802413548474368
And they're only increasing, making it a more viable choice with each year passing.
If you're considering building a new app, a responsive site with JS is definitely a contender. Take a look at the performance numbers. https://twitter.com/dhh/status/1174802413548474368
And they're only increasing, making it a more viable choice with each year passing.
I haven't tried it on iOS, but Twitter's web app is quite good on Android/Firefox and Android/Chrome. Not quite as good as native, and prone to developing lag if I don't occasionally restart the browser. But surprisingly good.
They talk about the process of building it here: https://blog.twitter.com/engineering/en_us/topics/open-sourc...
They talk about the process of building it here: https://blog.twitter.com/engineering/en_us/topics/open-sourc...
It's unusable on Firefox Focus though. Trying to expand anything completely breaks scrolling on the page.
No just focus. And I've run into issues even if I don't expand anything. Around 40% of pages have a point below which I can't scroll (I'm jumped to the top of the page if I try). And then there's the unspecified error you get on around 60% of page loads that requires a refresh to fix.
I tried it, it's pretty close honestly, but the performance just feels off and it does weird stuff all the time. The iOS app is just better.
I use the web app on iOS. Feature parity is 100% for me because I don't use push notifications at app on Twitter. The performance is a little worse (mostly touch targeting is not as good) but once you get used to it it is not noticeable. This is an acceptable tradeoff to me because it allows me to block almost all promoted tweets with Safari content blockers. I also think the Twitter native app may do devious things that are less likely to be permitted by Safari.
The fact that Facebook themselves will never be able to replace their native iOS and Android apps with RN implementations says it all imo.
It just says that web apps can't steal enough data from your phone.
But RN apps are not web apps...?
Tricky question. They start as web apps since they're built with mostly web technologies, but then they're compiled as native apps with native components and they don't run in the browser. So, I'd lean towards "no" -- they're not web apps at runtime.
React Native apps do not use web technologies.
That depends on what you include in your definition of web technologies. React and Javascript at this point mostly fall under mine.
I guess we can agree to disagree -- I consider JavaScript a web technology.
React Native is widely used in both Instagram and the main Facebook app (market places). It’s also used in a number of other apps they make (oculus, ads manager).
this is the dumbest take on here. You think that because Facebook hasn't rewrote their apps in RN that RN must suck? What kind of evaluation for software is that.
They haven't rewrote in RN because it's unnecessary. Its not worth the engineering resources. There is so many things on the global product roadmap to build then rewrite something that already exists and works fine.
Like all software, RN is great for certain use cases. Just because someone isn't using it for X doesn't mean it also sucks for Y.
They haven't rewrote in RN because it's unnecessary. Its not worth the engineering resources. There is so many things on the global product roadmap to build then rewrite something that already exists and works fine.
Like all software, RN is great for certain use cases. Just because someone isn't using it for X doesn't mean it also sucks for Y.
I thought this too. You know recent TWA with PWA makes the website accessible with anything on the system level. Like the location and other information.
I just wish with PWAs ... there was some more love as far as how they're handled.
Last time I looked at them it was really wonky to install a PWA from Chrome.
Developer advocacy at the time from Google was big on PWAs, but they were second class citizens everywhere in Google land....
Last time I looked at them it was really wonky to install a PWA from Chrome.
Developer advocacy at the time from Google was big on PWAs, but they were second class citizens everywhere in Google land....
They are first class on UWP since Microsoft decided to drop WinJS in favour of PWAs.
It is also one of the ways they are pushing for cross platform development on their upcoming foldable devices (Other being React Native and Xamarin, depending where one is coming from).
It is also one of the ways they are pushing for cross platform development on their upcoming foldable devices (Other being React Native and Xamarin, depending where one is coming from).
Yeah I really liked MS's support that way.
> What's missing until regular websites have parity with mobile apps in functionality?
The desire to build web apps instead of mobile apps.
> Literally all of them could be implemented as responsive pages with acceptable performance.
Exactly. It's not a technical issue as much as an issue of focus/interest. Unfortunately, this has been a losing battle since 2008.
The desire to build web apps instead of mobile apps.
> Literally all of them could be implemented as responsive pages with acceptable performance.
Exactly. It's not a technical issue as much as an issue of focus/interest. Unfortunately, this has been a losing battle since 2008.
> Exactly. It's not a technical issue as much as an issue of focus/interest. Unfortunately, this has been a losing battle since 2008.
This is true, but there are a lot of features missing from a responsive site that apps have. Of course, I'd argue that all of the missing functionality can easily be added to Safari and Chrome (to name the big two mobile browsers).
This is true, but there are a lot of features missing from a responsive site that apps have. Of course, I'd argue that all of the missing functionality can easily be added to Safari and Chrome (to name the big two mobile browsers).
I feel quite the opposite, most of the phone apps will likely to be thick client variants of the web apps, given that the hosts have so much power and storage available. Privacy concerns are gonna force this model where almost every activity having minimal network overhead. We are going back to the desktop app era, is what I feel.
> We are going back to the desktop app era, is what I feel.
Can't wait, to be honest. This era of everything as a service is great for developer convenience but is incredibly user-hostile in that it enables and encourages surveillance capitalism and the erosion of privacy.
Can't wait, to be honest. This era of everything as a service is great for developer convenience but is incredibly user-hostile in that it enables and encourages surveillance capitalism and the erosion of privacy.
No mobile website has match the performance of native though
No 2D renderer has matched the rendering engine of chromium aka skia.
Show benchmarcks otherwise, instead of hearsay evidence.
> Honestly I think the future of mobile will just be... mobile websites.
This.
Having to install software on my phone to use a service is cringy as hell and is a huge red flag for me. Like when trying to order food from a restaurant or shop somewhere.
It's almost always going to be a automatic no. I just don't trust them. They always want permissions to access things on my phone, which is just pure nonsense.
It's going to take a while for businesses to realize that in order to get a wide audience for the software they are paying for the last thing they want to do is force people to jump through hoops in order to use it.
For every one of 'google maps' there is going to be ten thousand other apps that simply have no benefit from being 'native'.
This.
Having to install software on my phone to use a service is cringy as hell and is a huge red flag for me. Like when trying to order food from a restaurant or shop somewhere.
It's almost always going to be a automatic no. I just don't trust them. They always want permissions to access things on my phone, which is just pure nonsense.
It's going to take a while for businesses to realize that in order to get a wide audience for the software they are paying for the last thing they want to do is force people to jump through hoops in order to use it.
For every one of 'google maps' there is going to be ten thousand other apps that simply have no benefit from being 'native'.
I agree with the overall points, less so the pointless vitriol. Installing software is cringey as hell now?
The main issue here isn't native apps. It's the existing framework for installing them.
For instance, would it be that far-fetched to be able to open an app in a single click?
Current extended process: 1) Click link that takes me to app store page 2) Find and click install button 3) wait 4) Click "open app" button
Streamlined process that accomplishes the same: 1) click link 2) wait 3) app opens up (download/install hidden behind spinner)
Even if you have to add a pop-up in there to display permission requests, it's still a much smoother experience.
You'd have to worry about app sizes but that's a solveable problem as well.
The main issue here isn't native apps. It's the existing framework for installing them.
For instance, would it be that far-fetched to be able to open an app in a single click?
Current extended process: 1) Click link that takes me to app store page 2) Find and click install button 3) wait 4) Click "open app" button
Streamlined process that accomplishes the same: 1) click link 2) wait 3) app opens up (download/install hidden behind spinner)
Even if you have to add a pop-up in there to display permission requests, it's still a much smoother experience.
You'd have to worry about app sizes but that's a solveable problem as well.
> Installing software is cringey as hell now?
When you know that the features you're interested in can be made easily available by a simple web app.
When you know that the features you're interested in can be made easily available by a simple web app.
Perhaps I'm misunderstanding the logic but doesn't that mean using a fancy pen is "cringey as hell" since you can just use a simple ballpoint pen?
Sorry, it just seems unnecessarily negative to me.
Sorry, it just seems unnecessarily negative to me.
Yes, you are misunderstanding the logic. A normal web app doesn't need to be installed, disappears each time you close it, runs in a tight sandbox. Much better and lighter than have an app installed.
Besides, I do find fancy pens cringey, but that's another story :)
Besides, I do find fancy pens cringey, but that's another story :)
haha fair enough. Thanks for the clarification!
It's cringy when you see how reddit does it. Or far worse, yelp. I would personally love to meet whoever approved the yelp mobile website and app so I could shake their hand and thank them for making the world just a little bit more horrible in their own small way.
Apps are dominant on web because, well, the web sucks. We can gloss over this on desktop because of raw processing power but still, layout if html is just plain terrible.
Of course mobile processors will continue to improve but on mobile you’re making a trade off between performance and battery life and battery life will probably never be not a concern.
Of course mobile processors will continue to improve but on mobile you’re making a trade off between performance and battery life and battery life will probably never be not a concern.
The mobile web sucks because of ads and bloated websites not because some inherent technological flaw.
And because of the "separate sites" approach to mobile web development. Good for some media-focused applications, but usually the separate mobile site has an oversimplified interface that can't be zoomed in or out.
I thought that native mobile would be out 4 years ago and not much has changed, my only conclusion now is that I don't want to do android/ios apps for startups, but I'll do it for large organizations that are actually leveraging all the technology.
> What's missing until regular websites have parity with mobile apps in functionality?
Performance. But we're beginning to approach performance parity - not by the web becoming an faster, mind you, but by apps becoming slower. It used to be only cheap/poor-quality apps that felt like glorified web pages, but now even many high-profile apps are just parts of a web stack embedded into an app.
Performance. But we're beginning to approach performance parity - not by the web becoming an faster, mind you, but by apps becoming slower. It used to be only cheap/poor-quality apps that felt like glorified web pages, but now even many high-profile apps are just parts of a web stack embedded into an app.
Absolutely this. Native apps are just so much smoother, and I say this as someone who really wants the web to win, and who used web apps almost exclusively because my 16GB iPhone 6 had very little space for apps. Also, the quality of native apps was much higher (e.g., Twitter feed doesn’t abruptly jump all over on mobile) although this could just be due to more budget allocation into native apps for whatever reason.
Not just smoother, native apps done right are interactive at the visual element level.
Can you elaborate on this? I’m not following.
Native iOS developer here (10 years). Knowing how to leverage UIKit and CoreAnimation properly can give a very smooth UX. SwiftUI has significantly upped the ante on iOS13 and future versions; it's reactive without the middleware layers, and it lets you get your app done (with live view previews) and not have to drag in a pant-load of external frameworks.
It depends pretty much on what the app is all about.
CRUD mobile apps can be made pretty fast when not doing an SPA bigger than Quake just for displaying text.
SSR, pure CSS3, caching, server workers, mobile first, can go a long way.
Naturally there are other kind of apps where native wins hands down, e.g. WebGL vs GL ES 3.2/Vulkan/Metal/DX.
CRUD mobile apps can be made pretty fast when not doing an SPA bigger than Quake just for displaying text.
SSR, pure CSS3, caching, server workers, mobile first, can go a long way.
Naturally there are other kind of apps where native wins hands down, e.g. WebGL vs GL ES 3.2/Vulkan/Metal/DX.
It certainly possible, but there is a lot of arcane knowledge that goes in to the techniques listed. Native apps, generally, has better performance “built in”.
Arcane knowledge? That is pretty basic stuff for anyone doing Web since the HTML 3 days.
Have you ever done native Android, including using the NDK?
It is full of arcane knowledge, scattered about commit comments, medium, G+ and Twitter posts from Android team instead of being on developer.android.com, APIs introduced in one IO are deprecated/replaced by the next IO, OEMs (cough Samsung) that change AOSP behaviours,...
Have you ever done native Android, including using the NDK?
It is full of arcane knowledge, scattered about commit comments, medium, G+ and Twitter posts from Android team instead of being on developer.android.com, APIs introduced in one IO are deprecated/replaced by the next IO, OEMs (cough Samsung) that change AOSP behaviours,...
Yes. Web is full of arcane knowledge. Take virtual lists for example: https://news.ycombinator.com/item?id=22186827
Unfortunately I can also provide several items of arcane knowledge for Android and iOS.
So should we now measure who wins in arcane knowledge counts?
So should we now measure who wins in arcane knowledge counts?
Yes. We could. The web would lose hands down.
The Web lacks even the most primitive of UI primitives that desktop and mobile UI kits have had for decades. Virtual lists is the prime example.
You can't even reliably animate an element independently of other elements without breaking your entire page.
You can't pick an arbitrary group of components and place them in a different location of the page without them breaking in subtle and not-so-subtle ways unless you are extremely careful with your flat global namespace that is CSS. WebComponents solve some of that, extremely poorly.
And the list of things that are taken for granted in the desktop/mobile world is near-infinite. All of them have to be re-created from scratch, poorly, on the web.
The Web lacks even the most primitive of UI primitives that desktop and mobile UI kits have had for decades. Virtual lists is the prime example.
You can't even reliably animate an element independently of other elements without breaking your entire page.
You can't pick an arbitrary group of components and place them in a different location of the page without them breaking in subtle and not-so-subtle ways unless you are extremely careful with your flat global namespace that is CSS. WebComponents solve some of that, extremely poorly.
And the list of things that are taken for granted in the desktop/mobile world is near-infinite. All of them have to be re-created from scratch, poorly, on the web.
Sure you can animate, that is what WebGL and SVG allow for.
Ah, like breaking Android UIs when dealing with fragment management or misplaced constraints on ConstraintLayout, usually only solvable after one finds the golden post on medium?
Ah, like breaking Android UIs when dealing with fragment management or misplaced constraints on ConstraintLayout, usually only solvable after one finds the golden post on medium?
That's not really a fair comparison. I don't think WebGL and SVG allow you to do the type of animation OP is referring to.
Furthermore, ConstraintLayout is a brand-new layout manager. Totally agree that there's bugs in it but nothing that could be called arcane knowledge. Do you have any examples for the actually arcane layout managers? Relative, Layout, etc?
Furthermore, ConstraintLayout is a brand-new layout manager. Totally agree that there's bugs in it but nothing that could be called arcane knowledge. Do you have any examples for the actually arcane layout managers? Relative, Layout, etc?
> Sure you can animate, that is what WebGL and SVG allow for.
Yeah, sure. Try animating an element without breaking layout. Trying animating an element that gets destroyed (oh, it's impossible, there are no events for when element gets removed). Try smooth animation while changing layout. And so on and so on.
Yeah, sure. If you constrain your entire animation to just the one box of a single SVG/Canvas/WebGL, then you can pretend that everything is fine. In reality when you try to animate anything, you're really constrained to animations that don't force re-flow. So, about 3 of them. And you have to be really careful (transposing an element's position will leave gaps).
Meanwhile both desktop and mobile have hundreds of animations big and small that are either impossible or extremely hard to do in a consistent manner on the web.
Yeah, sure. Try animating an element without breaking layout. Trying animating an element that gets destroyed (oh, it's impossible, there are no events for when element gets removed). Try smooth animation while changing layout. And so on and so on.
Yeah, sure. If you constrain your entire animation to just the one box of a single SVG/Canvas/WebGL, then you can pretend that everything is fine. In reality when you try to animate anything, you're really constrained to animations that don't force re-flow. So, about 3 of them. And you have to be really careful (transposing an element's position will leave gaps).
Meanwhile both desktop and mobile have hundreds of animations big and small that are either impossible or extremely hard to do in a consistent manner on the web.
Performance is about a lot more than speed. I want low battery, CPU, data, and memory usage. That's a lot harder to do in a web app.
Plenty of native apps are also not the best example of that, and not being able to control when they really die, including background running tasks, doesn't help.
Agreed. Map performance especially on native is night and day -- 60fps smooth scrolling even with React Native, vs choppy shitiness on the web.
You make a fair point but it's one about the current state of apps rather than the future of apps. In the future phones will be more powerful and apps will do mostly the same stuff. In theory that should mean the apps will be faster.
> In the future phones will be more powerful
Single-core performance is largely topping out. The gains are incremental at best.
Mobile SoCs have gone incredibly multi-core incredibly quickly (6-8 cores are common!). Meanwhile the web is incredibly bad at handling that. JavaScript code still has to fight with the GC for CPU time on the single thread they both occupy. WebWorkers are incredibly heavy & limited.
WebAssembly might have threads eventually (it's on their roadmap), but then how long until that happens and will the typical webapp ever even migrate to webasm?
Meanwhile CSS & DOM performance continues to be poor, so webapps are left in this awkward state of needing to re-write part of the browser.
Hardware isn't fixing any of this. It's been almost a decade of hardware not fixing this at this point.
Single-core performance is largely topping out. The gains are incremental at best.
Mobile SoCs have gone incredibly multi-core incredibly quickly (6-8 cores are common!). Meanwhile the web is incredibly bad at handling that. JavaScript code still has to fight with the GC for CPU time on the single thread they both occupy. WebWorkers are incredibly heavy & limited.
WebAssembly might have threads eventually (it's on their roadmap), but then how long until that happens and will the typical webapp ever even migrate to webasm?
Meanwhile CSS & DOM performance continues to be poor, so webapps are left in this awkward state of needing to re-write part of the browser.
Hardware isn't fixing any of this. It's been almost a decade of hardware not fixing this at this point.
Web apps need a parallel layout engine, and such a thing exists with Mozilla’s Servo, but they’re for some reason Mozilla using it for WebVR rather than building a functional browser.
> Meanwhile CSS & DOM performance continues to be poor
The DOM is not slow, that is brain washing from React developpers to justify your VDOM.
Most Reactive app performance issue nowadays comes from library bloat loading, network saturation or data dependencies.
The main problem with the DOM is not the performance but the API. The DOM API is not appropriate anymore for a reactive usage with transactional reflows. And this triggers a lot of quirks damaging performance.
The DOM is not slow, that is brain washing from React developpers to justify your VDOM.
Most Reactive app performance issue nowadays comes from library bloat loading, network saturation or data dependencies.
The main problem with the DOM is not the performance but the API. The DOM API is not appropriate anymore for a reactive usage with transactional reflows. And this triggers a lot of quirks damaging performance.
> The DOM is not slow, that is brain washing from React developpers to justify your VDOM.
I'm comparing against native apps, not React VDOM vs. DOM. Direct fiddling of widget properties is common & perfectly fast in native apps, even when done naively. The same is not true of the DOM, especially with all its synchronous layout & style resolution foot-guns.
I'm comparing against native apps, not React VDOM vs. DOM. Direct fiddling of widget properties is common & perfectly fast in native apps, even when done naively. The same is not true of the DOM, especially with all its synchronous layout & style resolution foot-guns.
You're viewing it through the lens of a developer.
The user wants the best experience. Because software costs 0$ to distribute, the best user experience will always win out.
The future of all software is faster, better software. Websites are shitty, arcane technology - the opposite of the future.
The user wants the best experience. Because software costs 0$ to distribute, the best user experience will always win out.
The future of all software is faster, better software. Websites are shitty, arcane technology - the opposite of the future.
If a website is popular and does the basics well, it doesn't matter how 'shitty' the technology is.
Amazon.com has easily the most hideously designed product pages out there. Because sellers can "customize" the product page, you get their content (usually hero images with tiny text) mixed in with text-only product details, "users also bought" carousels, Q&A and Reviews all jammed together.
And they're still doing better than most large ecommerce stores (Walmart, Best Buy etc.) because the stuff that matters (pricing, delivery time) is better than the competition.
Switching to the Amazon app doesn't fix any of these problems because it's primarily a content and UX issue.
Amazon.com has easily the most hideously designed product pages out there. Because sellers can "customize" the product page, you get their content (usually hero images with tiny text) mixed in with text-only product details, "users also bought" carousels, Q&A and Reviews all jammed together.
And they're still doing better than most large ecommerce stores (Walmart, Best Buy etc.) because the stuff that matters (pricing, delivery time) is better than the competition.
Switching to the Amazon app doesn't fix any of these problems because it's primarily a content and UX issue.
Of course if a store is just plain cheaper and over all quality wise better, it it's not that important that it looks hideous and abandoned. But to some people it matters. And if two stores provide the same product at the same price, I think I'll prefer the one that looks nicer.
It doesn't decide everything, but it's pretty certainly a factor (although Amazon must have determined that it's a small one to them, as they are still micro-optimizing for other page-related aspects like loading speed).
It doesn't decide everything, but it's pretty certainly a factor (although Amazon must have determined that it's a small one to them, as they are still micro-optimizing for other page-related aspects like loading speed).
I don't know, I get to use uBlock when I use web apps and I have some control over the client even on my phone. Native apps can basically do whatever they want and users are waking up to this.
I would like all of my applications to be sandboxed by a browser I have control over.
I would like all of my applications to be sandboxed by a browser I have control over.
It's times like this where it becomes painfully clear that FirefoxOS was (1) ahead of its time and (2) woefully poorly managed.
Actually Symbian Web Runtime and WebOS were ahead of their time.
I was really impressed recently by Wealthfront's mobile site. It's so good and fast, they don't even push you to download their native app. You just don't need it when the website works that well on mobile.
[deleted]
It can't be overstated how many apps are absolutely dependent on working push notifications (all chat for example) and can't be replicated as websites. And that's not yet implemented for iOS so we're all at Apple's mercy until it is, which may never be.
There's no reason why a web app can't work with push notifications. Won't? ya. Can't? no.
The sites I build at work have proper push notifications. This problem has already been solved.
How did you solve the lack of push notifications on iOS?
For iOS, can't you just wrap your web application in a thin native app layer that provides the push functionality?
From the app store guidelines:
4.2 Minimum Functionality
Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or “app-like,” it doesn’t belong on the App Store.
4.2 Minimum Functionality
Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or “app-like,” it doesn’t belong on the App Store.
Perhaps the main distinguishing app-like thing is distracting notifications.
Right! I ran in to this when I wanted our app to “portal” to the website and just move Bluetooth data along. Apple thought about this and doesn’t like it.
4.3 We'll continue to get away with this until the EU makes us stop.
Would push notification support not be exactly the kind of feature that would qualify for this rule? In practice there are hundreds of apps like this on the app store.
You can, you just can't publish it on the appstore.
Yes you can and we are exactly doing this since quite a while. Actually a lot of companies do this.
Yes you can and there tons of apps that do just that.
The important part is that they go through the app store, so that apple has complete control of what goes through.
The important part is that they go through the app store, so that apple has complete control of what goes through.
They probably embedded the browser in a client.
Short answer: He didn't. You cannot do it without your app being in the App Store.
for iOS you can have a work around. The users using the web based app in safari, then whenever a notification needs to be sent, twilio api will send a SMS message to alert the user. Of course it will only send an sms message if the user allows it and enters the mobile number.
I will never enable push notifications from websites. This problem has not been solved. It also doesn't hold across devices or if the browser isn't open.
Why not? You do, for apps, right?
App PNs also don't "hold" across devices. You don't need to have the browser "open", whatever that means.
BTW there are tons of apps that do push notifications wrong. There are many apps which keep sending you PNs after you log out or switch accounts. This can be really sensitive content (e.g. chat apps).
App PNs also don't "hold" across devices. You don't need to have the browser "open", whatever that means.
BTW there are tons of apps that do push notifications wrong. There are many apps which keep sending you PNs after you log out or switch accounts. This can be really sensitive content (e.g. chat apps).
Replying to myself, here is a NSFW example:
https://www.reddit.com/r/tifu/comments/e8ux6j/tifu_by_lettin...
I can’t stand push notifications, I disable them all except for a couple (like signal). They are usually only part of the app to manipulate you into using it constantly
several applications require them to be useful. Security events from my home cameras, messages from clients, timers, email
Anytime I'm using a peice of small business software I'd probably like it to be able to give me notifications
Anytime I'm using a peice of small business software I'd probably like it to be able to give me notifications
Honestly curious and hopefully not rude, but how can you concentrate on anything? Or does your work/life not require you to concentrate ever/most of the time on anything?
(I have turned all but phone call and sms notifications off on my phone. I will check my email/whatsapp when I want and see notifications there as needed. If someone has something urgent, they know how to call.)
(I have turned all but phone call and sms notifications off on my phone. I will check my email/whatsapp when I want and see notifications there as needed. If someone has something urgent, they know how to call.)
Simply, it doesn't affect me adversely at all. I think you have a misunderstanding as to how many notifications are generated.
Today I received:
* 3 reminders to eat
* 1 security alert (delivery)
* about two dozen instant messages between myself and clients
* a couple of dozen CI alerts
* 3 emails
Its easy to have different levels of notifications, and filter message channels. I have less distraction now than I had in an office by several orders of magnitude.
Everything is either immediately relevant or very important. The notifications I have make me more effective.
Today I received:
* 3 reminders to eat
* 1 security alert (delivery)
* about two dozen instant messages between myself and clients
* a couple of dozen CI alerts
* 3 emails
Its easy to have different levels of notifications, and filter message channels. I have less distraction now than I had in an office by several orders of magnitude.
Everything is either immediately relevant or very important. The notifications I have make me more effective.
What kind of reminders to eat are you getting? Like "don't forget to eat?" or "don't forget, this is your plan for lunch"?
I'd assume some sort of "go eat now, it's time" scheme, so he can stay in deep flow without neglecting his food intake.
You got it!
For me neglecting food intake means:
If I don't eat enough I get grumpy. This lowers the quality of life of myself and my loved ones. Alternatively if I get hungry it can cause me to over-snack (justified by anti-grumps thoughts); then I get fat and lower my quality of life slightly slower.
So these notifications are perhaps the most important ones.
For me neglecting food intake means:
If I don't eat enough I get grumpy. This lowers the quality of life of myself and my loved ones. Alternatively if I get hungry it can cause me to over-snack (justified by anti-grumps thoughts); then I get fat and lower my quality of life slightly slower.
So these notifications are perhaps the most important ones.
Do you use Whatsapp / Messenger regularly for social stuff? Coincidentally I was looking at my Digital Well-being settings in Android today and was told that I get over 170 notifications from Messenger a day.
I do. But I can't say I'm that popular! They are also muted and don't vibrate.
Most people I talk to work at the same time as me, so to get a social message during the day would be unusual.
Everyone knows to call if it matters.
Note: also be aware that the digital wellbeing count counts updates to an existing notification as a notification. As such my morning alarm counts a few dozen notifications (alarm in 8hrs, alarm in 7hrs, 30mins, 2 mins, etc.)
Most people I talk to work at the same time as me, so to get a social message during the day would be unusual.
Everyone knows to call if it matters.
Note: also be aware that the digital wellbeing count counts updates to an existing notification as a notification. As such my morning alarm counts a few dozen notifications (alarm in 8hrs, alarm in 7hrs, 30mins, 2 mins, etc.)
Not grandparent but for me:
1) only certain notifications that are important have unique sound, vibrate, etc.
2) other semi important notifications flash. Light is not that bright to notice.
3) other notifications have numbers on app so there are some despite not seeing any notifications.
Result: I stopped checking every hour. It's actually been an improvement for me to stay away from phone.
I noticed that some apps abuse you for disabling notifications and Viber is biggest example. I don't care about holiday wishes or viber news but I need app to stay in touch with some people. Sadly, I only check at most once a fortnight because of this disabled notification nagging.
1) only certain notifications that are important have unique sound, vibrate, etc.
2) other semi important notifications flash. Light is not that bright to notice.
3) other notifications have numbers on app so there are some despite not seeing any notifications.
Result: I stopped checking every hour. It's actually been an improvement for me to stay away from phone.
I noticed that some apps abuse you for disabling notifications and Viber is biggest example. I don't care about holiday wishes or viber news but I need app to stay in touch with some people. Sadly, I only check at most once a fortnight because of this disabled notification nagging.
I wish there was a standardized or common methodology for classifying notifications. App developers could adopt this and consumers could take the pattern with them across all types of interfaces - desktop, smartphone, speakers, tv. Maybe someone knows if any government entity or force has a methodology for this?
What's your point? Do you think you represent most people? Can you not just turn it off?
Notifications have fine tuned controls on both iOS and Android with schedule Do Not Disturb features and varying levels of priority (iOS has 3 tiers). Plus per-app controls to disable them from annoying apps, which in newer versions of iOS prompt you before they turn on, making them opt-in.
It's essential for communication apps (texting, email) and useful for breaking news or a simple highlight of big news on WSJ/NYT on your activity feed, so you don't need to open either app to stay on top of big events if you're a news junkie like me.
I'd personally go as far as saying push-notifications + the activity feed is very underrated feature of smart phones and has become a core part of people's day-to-day lives (which plenty of technologies can't say).
Notifications have fine tuned controls on both iOS and Android with schedule Do Not Disturb features and varying levels of priority (iOS has 3 tiers). Plus per-app controls to disable them from annoying apps, which in newer versions of iOS prompt you before they turn on, making them opt-in.
It's essential for communication apps (texting, email) and useful for breaking news or a simple highlight of big news on WSJ/NYT on your activity feed, so you don't need to open either app to stay on top of big events if you're a news junkie like me.
I'd personally go as far as saying push-notifications + the activity feed is very underrated feature of smart phones and has become a core part of people's day-to-day lives (which plenty of technologies can't say).
> Do you think you represent most people?
I've seen poor push notification quality increase uninstall and churn rates. I think the lesson is that many people are quickly annoyed with push notifications.
I've seen poor push notification quality increase uninstall and churn rates. I think the lesson is that many people are quickly annoyed with push notifications.
I think that's inaccurate. There are plenty of push notifications that don't annoy people, that are often the primary basis for how people interact with certain apps — Facebook, Messenger, WhatsApp, Slack, Discord, etc.
Let's not assume that all push notifications are cynical attempts to get people engaged with the app or to push DLC. For things like mail, messaging, and plenty of other online services, push notifications are not just an important interface to the app; they can be the interface.
Let's not assume that all push notifications are cynical attempts to get people engaged with the app or to push DLC. For things like mail, messaging, and plenty of other online services, push notifications are not just an important interface to the app; they can be the interface.
Its true that tons of news sites ask for permission just to spam you, or outright sell notifications to advertisers. I think the web notif channel has already been abused beyond repair. It may be time to redo the concept from scratch
Killer feature for email: add an email header that turns an email to notification. Then email apps would push the notification to the user, bypassing apple’s block. Websites already have the user’s email, so no need for more subscriptions. If gmail implemented this, it might push for adoption
Killer feature for email: add an email header that turns an email to notification. Then email apps would push the notification to the user, bypassing apple’s block. Websites already have the user’s email, so no need for more subscriptions. If gmail implemented this, it might push for adoption
That's a novel thought. I imagine then the native mail apps would expand in settings in order to block some bad senders from abusing that email header.
Tangentially related, iOS mail app has a VIP setting.
[1] https://support.apple.com/lv-lv/HT207213#vip
Tangentially related, iOS mail app has a VIP setting.
[1] https://support.apple.com/lv-lv/HT207213#vip
The apps don’t even need to think of spam, that would be handled by the mail server just like all other spam.
I love push notifications. Its honestly how I stay up to date on whatever is happening. I aint got time to scroll through everything
are you the one exception that makes us all suffer from notification induced FOMO ? :)
No one makes you suffer through anything. You can’t get push notifications without specifically opting into them, and you can disable them forever for any app with about 3 taps.
their existence annoys
This is exactly what I was thinking a while ago. Most apps won't give you good notifications, just spam you so there could be an app that lets you have some good notifications instead of disabling them all through a filter.
I never looked into whether this is possible to do on android or iOS. I thought it might not be given the power available to hijack all the notifications available.
I never looked into whether this is possible to do on android or iOS. I thought it might not be given the power available to hijack all the notifications available.
While the web notification story on android is much better than on iOS, it still has it's own share of issues.
The biggest one that i've run into is how exact timing of notifications is difficult. Sometimes notifications can be delayed for hours and there's not really much you can do to fix it, other times they will arrive minutes later.
I previously worked on a PWA which had to be converted into a thinly wrapped webview for Android because we needed notifications to pop within seconds of their scheduled time, and we just couldn't achieve that with web notifications at the time.
The biggest one that i've run into is how exact timing of notifications is difficult. Sometimes notifications can be delayed for hours and there's not really much you can do to fix it, other times they will arrive minutes later.
I previously worked on a PWA which had to be converted into a thinly wrapped webview for Android because we needed notifications to pop within seconds of their scheduled time, and we just couldn't achieve that with web notifications at the time.
Apple will never give in and implement webpush on mobile safari because that would affect their precious app store. How will they extort developers then? That's also the reason mobile safari is so limited in other features.
[deleted]
You mean extort developers who are mostly publishing free apps backed by services or advertising?
How many apps do you use on a daily basis that you paid money for, find notifications useful, and would have been suitable as a web app?
How many apps do you use on a daily basis that you paid money for, find notifications useful, and would have been suitable as a web app?
Apple changes their mind fairly often, so I wouldn't say never. And in general, predictions based on incentives are often good bets but they are less reliable than many people pretend.
Is it possible that they haven't figured out how to sandbox the little bit of code that handles the notification from the rest of the webpage? Maybe this is solved already by the webpush standard but some websites are a ridiculously overcomplicated hot mess of javascript ads which make my phone heat up, I don't want them waking up my phone all the time and draining the battery.
Honest question: is there some reason you can't use standard web tech for push notifications? ie polling, WebSockets, etc?
You can use polling or sockets when the browser is open; the problem is showing those notifications on the phone's lock screen or when you're in another app.
Oh duh. And it sounds like iOS doesn't support that for PWAs yet?
Correct, many websites say that such support is "coming soon" but I've been hearing that for years now.
Sometimes I wonder if Apple wouldn't support web apps at all if they could get away with it. A fully functioning PWA could essentially sidestep the app store for a huge class of applications. The incentives really just aren't aligned.
I was under the impression that under memory pressure all of the tabs in every mobile browser (Firefox/Safari/Edge) I have ever used is unloaded by iOS.
There is an edge mobile browser?
Even if you think your app depends on push notifications, your customers don't necessarily want them. I would bet that in 98% of the cases you have in mind, I would be perfectly happy to use the functionality without push notifications. (For example, "all chat". Even if your app is capable of chatting with me, I doubt I actually want it to.)
They were likely referring to chat apps. Good luck building a messaging or chat app without notifications.
Yes, apps over-use notifications for marketing and engagement metrics just like email has been overused. They’re still remarkably useful for a large swath of other use cases, and downright necessary for many others. If you don’t like them, don’t enable them for a given app. Easy.
Yes, apps over-use notifications for marketing and engagement metrics just like email has been overused. They’re still remarkably useful for a large swath of other use cases, and downright necessary for many others. If you don’t like them, don’t enable them for a given app. Easy.
Building a chat app without notifications is a good way to get exactly zero users.
Only if mobile web can jump the hurdle of feel. Even the best mobile web apps still feel kinda clunky/laggy in subtle ways that the average native app doesn’t.
It’s actually pretty comparable to the situation with desktop Linux where the gaps between the layers are subtly perceptible, which leads to a sort of slipshod/duct tape impression that isn’t great.
It’s actually pretty comparable to the situation with desktop Linux where the gaps between the layers are subtly perceptible, which leads to a sort of slipshod/duct tape impression that isn’t great.
A lot of native apps feel clunky because they are poorly coded and thought out. As OP said, 90% of cases are where companies don't need native apps, because they simply don't require that performance level or permission set.
This is the right answer. You've got the web paradigm of the nav bar showing up when you scroll up (among other oddities). I think it would be very easy to have a mobile browser extension to show pages full screen in a special interactivity mode to make most mobile apps work on the web.
I'd believe you for some of those apps. But definitely not for Google Maps. Even on their own OS and their own hardware, they are clearly pushing performance limits for the Google Maps app. And have been for years.
I think you're definitely right about gatekeeping, though. Apple's app store gross revenue is ~$50 billion/year. That's an incredible incentive to make sure that web apps will never be as good.
I think you're definitely right about gatekeeping, though. Apple's app store gross revenue is ~$50 billion/year. That's an incredible incentive to make sure that web apps will never be as good.
Shopify's growth model relies on bringing people into an app dependent ecosystem. They're not looking to be a one app company. They want users to locked into having many Shopify apps. When people are using mobile sites, the sense of dependency just isn't there. Not to mention it feels terribly inconvenient and the tracking can be stymied.
Offline is still a thing.
But website can be packed up and saved as PWAs, also "offline sites" have been a thing since the 90s.
pwa are one thing, but safari based web apps are nothing more than a bookmark that happens to sit on your home screen. should they and could they be catched? absolutely. does apple care enough about us nerds with our web apps to implement a 30 year old feature? not at all.
>Literally all of them could be implemented as responsive pages with acceptable performance.
Speaking personally I like the division between highly sandboxed websites (no GPS access, no notifications, etc...) and trusted apps.
Speaking personally I like the division between highly sandboxed websites (no GPS access, no notifications, etc...) and trusted apps.
This is only because the trust given to apps is insane. No distinction between foreground GPS and background GPS? Sure, I wouldn't want web sites to work that way either. But if permissions were sane there would be no reason not to have native apps and web apps ask for the same permissions in the same way.
I don't ever want to give a website access to microphone because someone could turn it on via an XSS. Websites on the whole seem to be far more vulnerable than mobile apps because:
1. their code is refreshed on every load,
2. their software is often updated on a daily if not hourly basis,
3. they will often pull code from remote sources on every page load,
4. they don't even have to pass the minimal review and code signing of an app store,
5. and it is very likely that they are written in javascript.
I agree with your general point that better permissions would improve the situation. For instance asking each time it wants to use the microphone, rather than an approve once model.
1. their code is refreshed on every load,
2. their software is often updated on a daily if not hourly basis,
3. they will often pull code from remote sources on every page load,
4. they don't even have to pass the minimal review and code signing of an app store,
5. and it is very likely that they are written in javascript.
I agree with your general point that better permissions would improve the situation. For instance asking each time it wants to use the microphone, rather than an approve once model.
There has been a distinction between the two on iOS for at least two years.
> What's missing until regular websites have parity with mobile apps in functionality?
Performance.
> Literally all of them could be implemented as responsive pages with acceptable performance
But not with great performance. A user feels the slight stutters, glitches and slow-downs.
Performance.
> Literally all of them could be implemented as responsive pages with acceptable performance
But not with great performance. A user feels the slight stutters, glitches and slow-downs.
Technically, and from user experience point of view, this makes perfect sense. Native apps are rarely actually needed.
However, Apple is making a huge pile of money out of app store sales, and it has huge leverage as long as the 'app' model lives on. They are strong enough to prevent this from happening.
Ever ask yourself why mobile iOS web doesn't support push notifications like Android does? It's because that will be a shift in the wrong direction from Apple's standpoint.
However, Apple is making a huge pile of money out of app store sales, and it has huge leverage as long as the 'app' model lives on. They are strong enough to prevent this from happening.
Ever ask yourself why mobile iOS web doesn't support push notifications like Android does? It's because that will be a shift in the wrong direction from Apple's standpoint.
As I asked before, which apps have you paid for, that would have been better as a web app, and that needed push notifications?
Ten years ago Facebook fought this battle and lost. [1] [2] [3]
[1]: https://www.facebook.com/notes/facebook-engineering/using-ht... "Using HTML5 Today"
[2]: https://appleinsider.com/articles/12/09/11/facebook_admits_h... "Facebook admits HTML5 not competitive with Cocoa Touch"
[3]: https://techcrunch.com/2012/12/13/facebook-android-faster/ "Facebook Speeds Up Android App By Ditching HTML5 And Rebuilding It Natively Just Like The iOS Version"
I have always rooted for mobile web apps, but the lack of feature parity and distribution challenge (“Add to Home Screen”) puts them at a constant disadvantage and companies who control mobile OS’s have little incentive to change this.
[1]: https://www.facebook.com/notes/facebook-engineering/using-ht... "Using HTML5 Today"
[2]: https://appleinsider.com/articles/12/09/11/facebook_admits_h... "Facebook admits HTML5 not competitive with Cocoa Touch"
[3]: https://techcrunch.com/2012/12/13/facebook-android-faster/ "Facebook Speeds Up Android App By Ditching HTML5 And Rebuilding It Natively Just Like The iOS Version"
I have always rooted for mobile web apps, but the lack of feature parity and distribution challenge (“Add to Home Screen”) puts them at a constant disadvantage and companies who control mobile OS’s have little incentive to change this.
In re: distribution challenge, PWAs can already be published to the Google Play store.
Yeah, and those are called TWAs-as in Trusted Web Activities. As much as I dislike Google in general, they have been good at bringing web development and native apps closer than ever.
I think this is only another reason to dislike them. Google created the PWA as a way to encapsulate the market on their terms. As my other comments will belie me, I do not disapprove of this behaviour necessarily -- Apple do it too -- but they have the polar opposite attitude to my privacy and data protection.
As you said yourself though, this was 10 years ago.
It strikes me that, more than anything, it is the lack of an efficient "Add to Home Screen" flow, that has doomed mobile websites.
...and it's intentional. By having an app store, mobile OS distributors know that they have control over a massive revenue stream.
...and it's intentional. By having an app store, mobile OS distributors know that they have control over a massive revenue stream.
A good part of it is their absolutely massive 30% cut. The only reason they get away with it is that when Apple's app store first came out, most of the online casual applications were games. Hosted by a few gargantuan aggregators (cough newgrounds cough) who charged 70%+ of the revenue for their ... service.
Against a backdrop of above-criminal-rates extortion, 30% must have looked like a bargain.
To put these numbers in context, very good agents get 15%.
Against a backdrop of above-criminal-rates extortion, 30% must have looked like a bargain.
To put these numbers in context, very good agents get 15%.
Forgive me a bit, since I haven't been on Newgrounds since before the iPhone came out, but did Newgrounds ever charge to host on their site? Did they allow you to monetize your games?
Most of the money being made on the App Store is for in app consumables from pay to win games. You’ll have to forgive me for not shedding a tear for them. I hope Apple Arcade takes a huge chunk of their revenue.
It’s not indy developers trying to make a living.
The other types of apps that use to make Apple a lot of money are streaming services. But most of those are now not allowing you to do in app purchases.
I’m looking through all of my apps, and I only have two or three that I actually paid money via in app purchases and those were to turn off ads.
All of the rest I had to buy subscriptions on the app makers websites or buy content in the case of Amazon for Kindle books.
It’s not indy developers trying to make a living.
The other types of apps that use to make Apple a lot of money are streaming services. But most of those are now not allowing you to do in app purchases.
I’m looking through all of my apps, and I only have two or three that I actually paid money via in app purchases and those were to turn off ads.
All of the rest I had to buy subscriptions on the app makers websites or buy content in the case of Amazon for Kindle books.
Though we should shed some tears for those who just try to sell their apps and make a living, after already being ripped off for expensive equipment and an annual developer account fee.
If Apple would care, it would be possible to charge a smaller commission based on the app category, and to vaive annual developer account fees for verified open source developers.
If Apple would care, it would be possible to charge a smaller commission based on the app category, and to vaive annual developer account fees for verified open source developers.
Apple gear is no longer as comparatively expensive as it used to be -- they aren't ripping you off, they have put a lot of work into delivering different 'gear' to what's available in the rest of the market. Shed a tear for people who buy HP and need a new laptop every year or two. I'm typing this on a 7-year old MacBook Pro, which works better than the day I bought it.
Hosting an app marketplace is not a free endeavour either. They host infrastructure to facilitate all of this, and they review app code in an attempt to prevent malware being distributed by underhanded developers. Maybe they could vary the price based on the use case, but why should they? No one is compelled to publish on the App Store, why complicate their business model to give themselves more work for less money.
Hosting an app marketplace is not a free endeavour either. They host infrastructure to facilitate all of this, and they review app code in an attempt to prevent malware being distributed by underhanded developers. Maybe they could vary the price based on the use case, but why should they? No one is compelled to publish on the App Store, why complicate their business model to give themselves more work for less money.
> Apple gear is no longer as comparatively expensive as it used to be
It still is if one can't afford it. Apple could provide macOS and iOS VirtualBox images for developers to build and test their apps.
> why complicate their business model to give themselves more work for less money.
Because that's the right thing to do when you shut out indie developers using expensive equipment and annual developer fees.
Developers who aren't affluent or don't get into app development solely for profit may stay away from the Apple ecosystem, and that's a loss for everyone.
Apple is now also selling access to their user base on macOS. Apps distributed outside the Mac App Store must be notarized to run on macOS, which requires a developer account ($99/yr). Yes, workarounds do exist for now, but all of them are inconvenient enough that they seriously hurt the distribution of open source apps, unless maintainers pay up.
It still is if one can't afford it. Apple could provide macOS and iOS VirtualBox images for developers to build and test their apps.
> why complicate their business model to give themselves more work for less money.
Because that's the right thing to do when you shut out indie developers using expensive equipment and annual developer fees.
Developers who aren't affluent or don't get into app development solely for profit may stay away from the Apple ecosystem, and that's a loss for everyone.
Apple is now also selling access to their user base on macOS. Apps distributed outside the Mac App Store must be notarized to run on macOS, which requires a developer account ($99/yr). Yes, workarounds do exist for now, but all of them are inconvenient enough that they seriously hurt the distribution of open source apps, unless maintainers pay up.
If you can’t afford $900 for a Mac Mini and a 1 year developer license and can’t sell anyone on letting you borrow the money, is it really a great idea that would stand out among the million of apps out there?
Also, you don’t have to buy a Mac. You could always pay Mac Mini Colo $80 a month and develop remotely.
Also, you don’t have to buy a Mac. You could always pay Mac Mini Colo $80 a month and develop remotely.
There are places where people make less than $80/mo, but they still have dreams and awesome ideas, and to deny them the opportunity to start programming and share their work because they can't afford to pay up is apalling.
A quick Google search shows you can buy a perfectly usable 2014 refurbished Mac Mini for $300 and you would still need at least one iPhone to test on.
How much would a PC cost that could hypothetically run MscOS in a VM well enough to run XCode?
Is it also “appalling” that if I had a great idea for a PS4 game I would have to pay at least $2500 if Sony would even let me buy one?
https://www.polygon.com/2013/7/24/4553842/so-how-much-does-i...
How much would a PC cost that could hypothetically run MscOS in a VM well enough to run XCode?
Is it also “appalling” that if I had a great idea for a PS4 game I would have to pay at least $2500 if Sony would even let me buy one?
https://www.polygon.com/2013/7/24/4553842/so-how-much-does-i...
> Is it also “appalling” that if I had a great idea for a PS4 game I would have to pay at least $2500 if Sony would even let me buy one?
Yes.
Yes.
> You could always pay Mac Mini Colo $80 a month and develop remotely.
In my country, one of the electronics stores has this thing where you pay about 35 USD per month, each month for 24 months, to have a MacBook Air in your possession, but which you don't own. So I guess in a way it is sort of rent/leasing. But the nice thing is that after the 24 months are up, you will be able to exchange it for a new model.
It's sort of like how mobile carriers do with mobile phones also sometimes. Except in this case of the MacBook Air that you are paying to have in your possession, there is no additional subscription to anything (unlike with the cellphones that mobile carriers charge you in a similar way for, but where in addition to paying for the phone you also need a to pay for subscription to a carrier plan).
I looked at the deal, considered it, and took it. My reasoning went that, over the span of 2 years battery life will probably degrade to the point that I want to replace the laptop after that. (Battery life was one of the major reasons I was looking to replace my previous laptop in the first place). And for the amount of money that you'd sell a two year old laptop, it will probably have lost about as much in value as what I am paying these guys to rent/lease the thing. (Obviously not quite the same, since they are making money from this deal. But close enough.)
So I went ahead and took the deal. They tried to sell me on insurance for it too. Guess that is one way for them to make a bit extra on the deal. I am generally careful with my stuff and I do have some home insurance plan already that should cover at least a bit of it if I do end up accidentally damaging the laptop.
I was very happy with that decision and continue to be so. It might not be for everyone, but for me it was a very suitable deal.
In my country, one of the electronics stores has this thing where you pay about 35 USD per month, each month for 24 months, to have a MacBook Air in your possession, but which you don't own. So I guess in a way it is sort of rent/leasing. But the nice thing is that after the 24 months are up, you will be able to exchange it for a new model.
It's sort of like how mobile carriers do with mobile phones also sometimes. Except in this case of the MacBook Air that you are paying to have in your possession, there is no additional subscription to anything (unlike with the cellphones that mobile carriers charge you in a similar way for, but where in addition to paying for the phone you also need a to pay for subscription to a carrier plan).
I looked at the deal, considered it, and took it. My reasoning went that, over the span of 2 years battery life will probably degrade to the point that I want to replace the laptop after that. (Battery life was one of the major reasons I was looking to replace my previous laptop in the first place). And for the amount of money that you'd sell a two year old laptop, it will probably have lost about as much in value as what I am paying these guys to rent/lease the thing. (Obviously not quite the same, since they are making money from this deal. But close enough.)
So I went ahead and took the deal. They tried to sell me on insurance for it too. Guess that is one way for them to make a bit extra on the deal. I am generally careful with my stuff and I do have some home insurance plan already that should cover at least a bit of it if I do end up accidentally damaging the laptop.
I was very happy with that decision and continue to be so. It might not be for everyone, but for me it was a very suitable deal.
>In my country, one of the electronics stores has this thing where you pay about 35 USD per month, each month for 24 months, to have a MacBook Air in your possession, but which you don't own. So I guess in a way it is sort of rent/leasing. But the nice thing is that after the 24 months are up, you will be able to exchange it for a new model.
Interesting. That sounds like a so-called operating lease, which is quite common in my country for business technology purchases, and other operating assets that become outdated quickly and need to be rolled over every few years. It's similar to a regular financing arrangement (where a customer may spread the full cost of acquiring some asset over X months instead of paying in full up front), but the customer never actually owns the asset.
Instead of paying the full cost gradually via monthly payments, an operating lease is structured so that there will be a somewhat large residual payment due if the customer wants to keep the asset at the end, which allows for lower monthly payments. And, as you mentioned, encourages the usual situation where the customer returns the items at the end of the term, and immediately takes out a fresh lease on some new technology.
Since the customer taking out the lease never owns the asset, they needn't depreciate it or worry about other long-term asset concerns, and can treat the payments as deductible operating expenses rather than as the purchase of a fixed asset that would go on the balance sheet. Paying a predictable expense every month for your equipment can often be more manageable than making one big capital outlay every few years, and sometimes has tax advantages too.
Interesting. That sounds like a so-called operating lease, which is quite common in my country for business technology purchases, and other operating assets that become outdated quickly and need to be rolled over every few years. It's similar to a regular financing arrangement (where a customer may spread the full cost of acquiring some asset over X months instead of paying in full up front), but the customer never actually owns the asset.
Instead of paying the full cost gradually via monthly payments, an operating lease is structured so that there will be a somewhat large residual payment due if the customer wants to keep the asset at the end, which allows for lower monthly payments. And, as you mentioned, encourages the usual situation where the customer returns the items at the end of the term, and immediately takes out a fresh lease on some new technology.
Since the customer taking out the lease never owns the asset, they needn't depreciate it or worry about other long-term asset concerns, and can treat the payments as deductible operating expenses rather than as the purchase of a fixed asset that would go on the balance sheet. Paying a predictable expense every month for your equipment can often be more manageable than making one big capital outlay every few years, and sometimes has tax advantages too.
There are places in the world where developer labour (especially if the developer is trying to work for himself) is far cheaper than the 900$ capital investment of what essentially is 500-600$ worth of hardware with a shiny aluminum case. Don't forget that not everywhere in the world developers have to choose between several jobs that pay tens to hundreds of thousands of dollars a year.
So these same people couldn’t spend $300 on a used 2014 Mac Mini but could buy a PC?
In those places, old Apple hardware isn't significantly cheaper than new hardware. You might get a 25% discount for a degraded experience (security updates may end in ~3 years) or buy much older hardware (e.g. 9 year old models) that cannot run current macOS and Xcode, etc.
And yes, a local PC can work out to lower prices due to specific tax arrangements, sourcing components straight from manufacturers and assembling them locally.
And yes, a local PC can work out to lower prices due to specific tax arrangements, sourcing components straight from manufacturers and assembling them locally.
Ypu don't need to buy a PC - you already have one.
And how many of those developers would have “made a living” if it Apple lowered their fee to 15%, cut the price of a Mac Mini by $300 and waived the $99 a year?
As a developer of a pro app in a niche market trying to make a living on the app store, i can tell you those 30% are what prevents me from working full time on my app.
Could you elaborate on this a little? I understand that Apple only takes 30% the first year and then they drop their commission to 15%. Is the commission on the purchase price of the app what makes it too expensive, or is it too great a cut out of your in app revenue?
If your app was such a great one, you couldn’t convince your customers to pay enough to make up the difference?
Marking things up 43% generally impacts sales.
If it is a “specialized”,”pro” niche app people are usually willing to spend more.
It’s hard to make a living selling a niche app to price sensitive people.
Also if it is a niche app, with a small addressable market, how do you continue making money on it since their is no facility for upgrade pricing - especially since you have to keep releasing updates to support newer devices and new screen sizes?
It’s hard to make a living selling a niche app to price sensitive people.
Also if it is a niche app, with a small addressable market, how do you continue making money on it since their is no facility for upgrade pricing - especially since you have to keep releasing updates to support newer devices and new screen sizes?
If it's a niche app, I'd imagine you would monetize it differently than a 99c clicker game (eg. sell a subscription to the app on your website, or supply it as a companion to hardware you sell, or something) and the app itself would most likely be free to install off the web store.
I've seen companies get around the upgrade pricing question by just releasing a new version of their app every year and deprecating the old one.
I've seen companies get around the upgrade pricing question by just releasing a new version of their app every year and deprecating the old one.
"people are usually willing to spend more" : not in my case ( and probably many other)
when i say it is a niche market i mean it not only in terms of number of customers, but also in term of potential generated revenues. there are businesses , especially in artistic fields, where people simply aren't willing to spend a lot of money on accessories, even if they are useful to their job.
now i'm not saying i will never be able to be profitable enough. just that with my current marketshare ( which is very good on a local scale, but not yet worldwide), those 30% are what makes the difference.
ps : as for the revenue model, i had to invent some kind of pay per use model, based on in app purchases.
when i say it is a niche market i mean it not only in terms of number of customers, but also in term of potential generated revenues. there are businesses , especially in artistic fields, where people simply aren't willing to spend a lot of money on accessories, even if they are useful to their job.
now i'm not saying i will never be able to be profitable enough. just that with my current marketshare ( which is very good on a local scale, but not yet worldwide), those 30% are what makes the difference.
ps : as for the revenue model, i had to invent some kind of pay per use model, based on in app purchases.
I think perhaps your business model isn't as solid as you might think. Producing an app is not a free pass to live on the revenue, and the market capture is an important part.
I'm not an app developer, I'm in the music industry (day job in IT infra), but it seems to me there are some people projecting their bad business sense onto Apple. As per my other comment in this thread, and the reply someone made for me, the commission drops on subscription based apps, could you not use a subscription, rather than your pay-per-use system (which sounds like a creative workaround, kudos) and then you'll get the benefit of the tax rolloff.
Trying to make your own way in this world is damn hard work, and if a business model falls apart because one needs to "pay taxes," Apple will not be the biggest problem for very long. I'm sure most here would agree that it stinks that Apple are demanding a 30% tax whilst paying ~0% to the U.S. Government, but that is the way of things for now.
I'm not an app developer, I'm in the music industry (day job in IT infra), but it seems to me there are some people projecting their bad business sense onto Apple. As per my other comment in this thread, and the reply someone made for me, the commission drops on subscription based apps, could you not use a subscription, rather than your pay-per-use system (which sounds like a creative workaround, kudos) and then you'll get the benefit of the tax rolloff.
Trying to make your own way in this world is damn hard work, and if a business model falls apart because one needs to "pay taxes," Apple will not be the biggest problem for very long. I'm sure most here would agree that it stinks that Apple are demanding a 30% tax whilst paying ~0% to the U.S. Government, but that is the way of things for now.
I don’t understand your comment. I have other sources of revenue, mainly doing development for customers. I didn’t bet everything on that app and raised money on the expectation this would be a gold mine. I’m just stating a fact : without those 30%, in my present situation, i could live only based on this app revenues. With the 30% cut, i can’t.
There are thousands of desktop app developers that never got out of the hobby stage because they couldn’t get past the costs of processing payments, managing refunds, managing download servers, implementing licensing frameworks, implementing a smooth upgrade process, search engine optimization, establishing enough trust with users that they are confident they aren’t installing malware infected software, marketing, push notification infrastructure, and probably a few other things I’m not thinking of.
It’s probable that 30% is too much to pay for help with all of that, but people too often act like Apple’s just taxing them and providing no commensurate value at all.
It’s probable that 30% is too much to pay for help with all of that, but people too often act like Apple’s just taxing them and providing no commensurate value at all.
i think you also forget that many people buy ipads because of apps created by developers ( in my case, i believe my app is the direct reason for the sale of my customer's ipad pro). and that developpers need to buy apple hardware to build and distribute on the store. those 30% come in addition to all the revenue generated by hardware sales, because of independant app developers.
So your customers are willing to pay at minimum $799 for an iPad Pro but don’t value your product enough for you to charge enough to make it a sustainable business?
Just maybe it’s a product market fit issue?
Just maybe it’s a product market fit issue?
Over the life of the ipad, they'll have paid me more than the ipad. But it'll be over a few years. It's a market with a few hundreds potential users (maybe a thousand) per country, not more.
Part of what makes it so galling is because Apple has those competencies in spades anyway (SREs, designers, datacenters, bizdev.)
Another aspect is that the App Store feels like a value-add for the actual marketed products — iPhones and iPads — and not something you are ever explicitly buying. It doesn’t show up on the receipt. People talk about buying a new iPhone, or getting then latest iPad. No one ever goes to the Apple store to buy the lates access to the App Store.
As such, Apple’s cut feels like it’s everything from cheeky to an abuse of their “monopoly” in the providers of iOS devices marketplace.
Another aspect is that the App Store feels like a value-add for the actual marketed products — iPhones and iPads — and not something you are ever explicitly buying. It doesn’t show up on the receipt. People talk about buying a new iPhone, or getting then latest iPad. No one ever goes to the Apple store to buy the lates access to the App Store.
As such, Apple’s cut feels like it’s everything from cheeky to an abuse of their “monopoly” in the providers of iOS devices marketplace.
> Part of what makes it so galling is because Apple has those competencies in spades anyway (SREs, designers, datacenters, bizdev.)
But what do you mean 'anyway'? If Apple suddenly said 'you know what, App Store is EoL, do your own distribution' (because of legal or whatever reason) surely there would be a spade or two of those competencies that were consequently redundant?
I don't imagine they're hiring people to work on say Apple Maps; who subsequently say 'cor, good thing I'm here, someone should take a look at that unstaffed app store project'!
But what do you mean 'anyway'? If Apple suddenly said 'you know what, App Store is EoL, do your own distribution' (because of legal or whatever reason) surely there would be a spade or two of those competencies that were consequently redundant?
I don't imagine they're hiring people to work on say Apple Maps; who subsequently say 'cor, good thing I'm here, someone should take a look at that unstaffed app store project'!
> There are thousands of desktop app developers that never got out of the hobby stage
There's so much money out there searching for an investment. It's a shame really.
There's so much money out there searching for an investment. It's a shame really.
Trust and payments being the largest.
I download any random crap on my iOS devices trusting that the sandbox and permissions model will keep the app from doing too many things I don’t expect. I’m not downloading a random app on my computer.
I can also pay a lot easier on my phone than digging out my credit card.
I download any random crap on my iOS devices trusting that the sandbox and permissions model will keep the app from doing too many things I don’t expect. I’m not downloading a random app on my computer.
I can also pay a lot easier on my phone than digging out my credit card.
There has been an add to home screen shortcut on iOS since day 1.
Oh, 100%!
It is absolutely intentional that iOS Safari on iPhones does not have support for fullscreen api, for example, whereas both WatchOS (somewhat) and iPadOS do. Apple is quite anti-competitive when it comes to letting web apps utilize the full potential of modern web standards.
And they often use "industry advocates" driven psy-op tactics to manoeuvre public opinion such as the following:
[1] https://stackoverflow.com/questions/49589861/is-there-a-non-...
It is absolutely intentional that iOS Safari on iPhones does not have support for fullscreen api, for example, whereas both WatchOS (somewhat) and iPadOS do. Apple is quite anti-competitive when it comes to letting web apps utilize the full potential of modern web standards.
And they often use "industry advocates" driven psy-op tactics to manoeuvre public opinion such as the following:
[1] https://stackoverflow.com/questions/49589861/is-there-a-non-...
> more than anything, it is the lack of an efficient "Add to Home Screen" flow, that has doomed mobile websites...and it's intentional
It’s literally a default option on the safari “share” button: “Add to Home Screen”. I’m not sure how Apple could have made it easier.
It’s literally a default option on the safari “share” button: “Add to Home Screen”. I’m not sure how Apple could have made it easier.
Because it's not very intuitive that the share button would allow you to add something to your home screen.
TBF that icon is kind of apple's system hamburger as it contains sharing, sending the current "thing" to other apps, searching etc. If you don't know that (and I agree it's terrible, but at least it's consistent) you probably don't know you can add a page to the homepage at all.
The other downside is that even if mobile websites encouraged people to use the “Add to Home Screen” ability to the point it became somewhat popular, Apple and Google could just remove the ability all together in an OS release for “reasons” leaving users SOL.
Apple has an "add to home screen" option. Its in Safari.
That's true along with proper notification support. Firefox for Android has 'Add to Home Screen' and was one of the reasons along with extension support for my switch from chrome.
that's factually untrue since there have been ways to add web apps to the home screen for while.
Add to home screen is two clicks, how more efficient does it need to be?
[deleted]
Why does everybody think they have to build at the scale of Fb. Most of the apps will do perfectly fine when they are web based.
It makes sense that a company with a business model based on mining and selling personal data would not find mobile web to be acceptable - too many privacy and security protections that can be eschewed on native. For the same reasons, consumers should choose HTML.
Didn't Facebook also want native app access so they could work around OS limits like background processing via shady stuff like leaving the microphone on? I prefer webapps for security reasons because of Facebook's checkered history with native apps.
But what happens if Apple or Google gives web apps more of the capabilities of native apps?
I'd really hate it if browsers are capable to run in background and accessing microphone or camera. Especially if the tab is closed.
Buy why? People use those apps every day and fine with it. Why browser is bad? You'll still need to give your permission to do so anyway.
I'd say bloat is bad. And as the browser comes to encompass more OS functionality it does so more poorly than the underlying OS could.
People will leave hundreds of tabs open. It’s just not few apps, it’s the whole internet and knowing people they will most likely just smash through the ”deny/allow” warnings.
Ten years ago Facebook fought this battle and lost.
That was ten years ago. Phones and web sites have changed a lot since 2010.
If the battle was re-fought today, I'm not sure the winner would be all that clear.
That was ten years ago. Phones and web sites have changed a lot since 2010.
If the battle was re-fought today, I'm not sure the winner would be all that clear.
You still cant crawl through all the local contacts with mobile HTML app. Contrary to native app. So thats a no go for FB from the start i guess.
[2] is from 2012 though, almost a decade ago. The web has come a long way since, and in five years to a decade could be competitive. With wasm and webgpu and what not. And as of today, i dont think the mobile web interfaces for fb and messenger are particularly worse than their native counterparts. They save me the notifications actually...
> The web has come a long way since, and in five years to a decade could be competitive.
The web is always 5 to 10 years away from being competitive.
Meanwhile Twitter struggled to implement such a trivial thing as a virtual list on the web: https://grumpy.website/post/0RQvmdNmN
It took them almost a year after the resign to fix most of these issues. While breaking or half-breaking functionality for almost everything else.
And that's for a website that's nothing but text and pictures. I wouldn't he my breath waiting for web to be competitive.
The web is always 5 to 10 years away from being competitive.
Meanwhile Twitter struggled to implement such a trivial thing as a virtual list on the web: https://grumpy.website/post/0RQvmdNmN
It took them almost a year after the resign to fix most of these issues. While breaking or half-breaking functionality for almost everything else.
And that's for a website that's nothing but text and pictures. I wouldn't he my breath waiting for web to be competitive.
Ten years ago, Facebook tried with HTML5 -- and 10 years before that Java tried with Swing and then JavaFX. There has always been this push for a "write once, run anywhere" application development platform - long before it was the mantra of Java in the late 90's, or QT a bit later, or React today.
The truth is that the platforms change faster than the cross-platform tools. Swing lost out not because it was horrible to work with, but because they couldn't track changes to the platform fast enough; Swing apps looked dated from the very start. I'm pretty confident this will continue to be the case; HTML apps don't look like native apps unless you do a lot of platform-specific work, and then you maybe would have been better off just building native.
In addition to tracking the look, feel and interoperability of the platform, HTML will always be slower than native, simply because there will always be more ways to optimise native apps than HTML apps.
In the end, there is no one-size-fits all solution. There will always be classes of application for which HTML is good enough, classes for which a blend of HTML and native will get you though, and classes for which HTML will not be good enough.
But I suspect that any sufficiently advanced and popular application will almost always move to native eventually. You just cant't integrate with the platform properly, over the long term, any other way.
The truth is that the platforms change faster than the cross-platform tools. Swing lost out not because it was horrible to work with, but because they couldn't track changes to the platform fast enough; Swing apps looked dated from the very start. I'm pretty confident this will continue to be the case; HTML apps don't look like native apps unless you do a lot of platform-specific work, and then you maybe would have been better off just building native.
In addition to tracking the look, feel and interoperability of the platform, HTML will always be slower than native, simply because there will always be more ways to optimise native apps than HTML apps.
In the end, there is no one-size-fits all solution. There will always be classes of application for which HTML is good enough, classes for which a blend of HTML and native will get you though, and classes for which HTML will not be good enough.
But I suspect that any sufficiently advanced and popular application will almost always move to native eventually. You just cant't integrate with the platform properly, over the long term, any other way.
Did you ever heard of WeChat?
The Facebook quivalent of China, which is on its own an operating system serving many miniapps. What's interesting about it it lets other apps access qr scanning and the WeChat wallet for payment.
Is WeChat an example of React Native?
I don't think so, but WeChat hosts so called mini programs that are implemented using Web(ish) technologies. There's a million of those mini programs with 750 million monthly active users. So it's an example of successful mobile Web apps if you will.
If cross-platform tools are always behind because the native platforms change more quickly--and I think you're correct about that--then so are native apps that aren't constantly rewritten for the latest OS version. And then so are the native apps running on not-newly-upgraded client devices.
And since these quickly changing native OSes change in different ways, remaining "fully native" requires your app to have different UIs and feature sets, not just on different OSes but on different versions of those OSes.
If you have the resources to keep upgrading separate native apps for all the latest combinations of hardware and OS while also maintaining older versions, with different UIs and feature sets for each, you can have all the benefits of "native". Anything less, and you are deciding to live with less than "full native" and have to decide which compromises to make.
In that case, you might go for maximum speed with a consistent--therefore non-native--UI (PhotoShop), or good-enough speed with non-native UI that runs consistently and on even more platforms (a web app), or give up all but one OS but support all OS versions on all hardware (some dental office Windows app that hasn't changed for 15 years), or whatever. Or some cross-platform toolkit that will never completely keep up with "native" but might be okay, because you can't keep up with native either.
And since these quickly changing native OSes change in different ways, remaining "fully native" requires your app to have different UIs and feature sets, not just on different OSes but on different versions of those OSes.
If you have the resources to keep upgrading separate native apps for all the latest combinations of hardware and OS while also maintaining older versions, with different UIs and feature sets for each, you can have all the benefits of "native". Anything less, and you are deciding to live with less than "full native" and have to decide which compromises to make.
In that case, you might go for maximum speed with a consistent--therefore non-native--UI (PhotoShop), or good-enough speed with non-native UI that runs consistently and on even more platforms (a web app), or give up all but one OS but support all OS versions on all hardware (some dental office Windows app that hasn't changed for 15 years), or whatever. Or some cross-platform toolkit that will never completely keep up with "native" but might be okay, because you can't keep up with native either.
Native Mobile will be replaced by web in x years (where x is usually 2 to 5) has been uttered since day 1 of mobile apps.
I tend to skip reading these arguments nowadays unless they start by explaining why it hasn't worked so far and how it will be addressed.
edit : also, you can add progressive web apps to the home screen, so this ain't it AFAIK.
I tend to skip reading these arguments nowadays unless they start by explaining why it hasn't worked so far and how it will be addressed.
edit : also, you can add progressive web apps to the home screen, so this ain't it AFAIK.
What if the issue with facebook wasn't HTML5 but rather feature bloat and a focus on Ad placement?
I always thought Sencha debunked that: https://www.sencha.com/blog/the-making-of-fastbook-an-html5-...
I'm convinced that the long-term future of all UI development is web based, at least at the rendering layer. WASM may free us from JavaScript.
IS WASM canvas-based or HTML/CSS? Because canvas is not what comes to mind when thinking in terms of Web UI.
WASM can access the DOM. Check out this:
https://github.com/gopherjs/vecty
Like React but in Go. Not quite mature yet but getting there.
https://github.com/gopherjs/vecty
Like React but in Go. Not quite mature yet but getting there.
Actually the future of the application UI is React.
I m a web fanatic and use only the browser. My other apps are dropbox and skype , a decibel meter and strava, so things that cant exist on the web anyway. I use multiple gmail accounts so webmail is better
Since most content apps use browser links at some point it doesn’t even make sense to e.g. have a twitter app
Now, i wish we could have a better api than web push notifications though
Since most content apps use browser links at some point it doesn’t even make sense to e.g. have a twitter app
Now, i wish we could have a better api than web push notifications though
I'm kind of done with notifications on my phone. Plenty of apps turn approving legitimate notifications into an excuse to push ads or attempts at engagement through os notifications. The most recent offender on my phone was the moovit app, that sent something inane with emojis in the notification. deleted.
I don't even have email notifications anymore. Just texts and calls from contacts. Notifications just serve to divert your attention from the task at hand. If I want to sit down and be distracted by reddit or whatever, it will be on my own time by my own choice damnit.
I don't even have email notifications anymore. Just texts and calls from contacts. Notifications just serve to divert your attention from the task at hand. If I want to sit down and be distracted by reddit or whatever, it will be on my own time by my own choice damnit.
Other things missing: Contacts, Device Identifier, In-app Purchases, and a trustworthy distribution platform with a large base of affluent customers.
One thing I feel is overlooked in these discussions is WebView UI performance isn’t as good as native. You’ll always notice a difference scrolling a list natively vs on web. It just _feels_ different, same goes for all the other micro-interactions if pushing/popping views.
This. And if you compare it with the very best say, iOS has to offer in touch interaction it's just different worlds. Look at the multitasking and swipe interaction on an iPad pro at 120Hz. You just can't even think of that world.
I have a funny feeling that Apple's next big developer move on the iPhone is to enable those types of smooth, cancelable interactions out of the box in Xcode via new SwiftUI components just for it. When they make it easy and clear, people will use it and then the gap will widen.
I have a funny feeling that Apple's next big developer move on the iPhone is to enable those types of smooth, cancelable interactions out of the box in Xcode via new SwiftUI components just for it. When they make it easy and clear, people will use it and then the gap will widen.
The power of websites is that they run cross-platform. If your website works on chrome on windows it’ll work (for the most part) on Firefox on Mac and safari on iOS. Apple is against this philosophically because it doesn’t take advantage of the unique capabilities their devices provide. It’s the same reason why Apple stopped supporting flash https://www.apple.com/hotnews/thoughts-on-flash/
That’s not true.
Back in 2007, Adobe claimed that they could get Flash working on the original iPhone if Apple had allowed them.
When they finally got it to run on Android years later, it required a 1Ghz processor and 1GB of RAM and it still barely ran and was horrible on battery life. The original iPhone had 128Mb of RAM and a 400Mhz processor. It wasn’t until around 2011 when there was an iPhone that met those specs.
Adobe was always late delivering Flash on mobile from Android phones and Palm phones.
It was so bad, that the Motorola Xoom was advertised to be able to browse the “real Internet” because it could support Flash. At launch it didn’t. Leaving it in the embarrassing position that you couldn’t browse the Xoom advertising page that required Flash on a Xoom.
Back in 2007, Adobe claimed that they could get Flash working on the original iPhone if Apple had allowed them.
When they finally got it to run on Android years later, it required a 1Ghz processor and 1GB of RAM and it still barely ran and was horrible on battery life. The original iPhone had 128Mb of RAM and a 400Mhz processor. It wasn’t until around 2011 when there was an iPhone that met those specs.
Adobe was always late delivering Flash on mobile from Android phones and Palm phones.
It was so bad, that the Motorola Xoom was advertised to be able to browse the “real Internet” because it could support Flash. At launch it didn’t. Leaving it in the embarrassing position that you couldn’t browse the Xoom advertising page that required Flash on a Xoom.
This.
I developed a number of Air mobile apps back in 2012-2014 and all the blame is on Adobe. Flash was extremely inefficient and Adobe didn't want to invest the necessary resources to properly bring it to the mobile world.
Adobe cancelled AS4 (aka Flash Next) which would have made Air a very competitive crossplatform solution. They shifted all its resources into HTML5 to throw a bone to the Flash community and it was a complete failure.
https://insights.stackoverflow.com/trends?tags=actionscript-...
Don't get me wrong, it probably made economical sense for Adobe but it was a shame.
I developed a number of Air mobile apps back in 2012-2014 and all the blame is on Adobe. Flash was extremely inefficient and Adobe didn't want to invest the necessary resources to properly bring it to the mobile world.
Adobe cancelled AS4 (aka Flash Next) which would have made Air a very competitive crossplatform solution. They shifted all its resources into HTML5 to throw a bone to the Flash community and it was a complete failure.
https://insights.stackoverflow.com/trends?tags=actionscript-...
Don't get me wrong, it probably made economical sense for Adobe but it was a shame.
Supporting all of Apple's functionality was one of the reasons for not supporting Flash that Steve shared in his post, but I think you're right that Adobe not being able to get Flash working on iPhone was the main reason. Thanks for the correction!
> acceptable performance
Until your competitor shows up. I think you are honestly right for the most cases, but the expectation on mobile, (esp. since the OS is written in native and 120Hz screens are coming) is so freaking high. The touch response rate expected is just going to make hybrid and web apps just seem like trash to the average consumer when compared directly with native apps. They just don't do it and just don't feel right.
Until your competitor shows up. I think you are honestly right for the most cases, but the expectation on mobile, (esp. since the OS is written in native and 120Hz screens are coming) is so freaking high. The touch response rate expected is just going to make hybrid and web apps just seem like trash to the average consumer when compared directly with native apps. They just don't do it and just don't feel right.
> esp. since the OS is written in native and 120Hz screens are coming
High-refresh rate mobile displays already happened. There's more 90Hz than 120Hz on the market at the moment. Typically gamer-focused phones like the Asus ROG Phone or the Razer Phone, but non-gamer-focused flagships are also now 90Hz like the Pixel 4.
And of course on the iOS side of the ecosystem some iPad models already have 120hz displays, too.
High-refresh rate mobile displays already happened. There's more 90Hz than 120Hz on the market at the moment. Typically gamer-focused phones like the Asus ROG Phone or the Razer Phone, but non-gamer-focused flagships are also now 90Hz like the Pixel 4.
And of course on the iOS side of the ecosystem some iPad models already have 120hz displays, too.
Of course there are current examples, but in general the scale is not large at all on phones. Less than 1% of sales. Being first doesn't mean anything if it doesn't sell, being the majority of sales is a much different world.
I'm referring to the 2020 iPhone Pro and the Galaxy S20 both being rumored to have 120Hz displays, massive changes in the market.
I'm referring to the 2020 iPhone Pro and the Galaxy S20 both being rumored to have 120Hz displays, massive changes in the market.
non-native never feels the same. fuck web apps.
[deleted]
Native controls can afford to be richer (in principal) because knowledge transfers across apps. Websites do not enable such transfer: there's too much of a culture of customizing everything. On mobile the problem is somewhat less noticeable because rich native interaction models haven't really emerged.
Good point.
In the mobile and desktop world devs are totally fine with using native GUIs that ship with the OS (even encouraged to do so) but in the web world projects are criticized for using libraries like Bootstrap and devs and designers are expected to reinvent the wheel every time. Also don't use a native alert or you will condemned to hell.
In the mobile and desktop world devs are totally fine with using native GUIs that ship with the OS (even encouraged to do so) but in the web world projects are criticized for using libraries like Bootstrap and devs and designers are expected to reinvent the wheel every time. Also don't use a native alert or you will condemned to hell.
I hope not. I started using flutter recently and it is by far the best development experience I've had creating anything with a UI. Easy to install (even on windows), build, stateful hot reload, and the code is easy to read and write. No HTML/CSS/JavaScript.
I know web devs probably don't agree, but HTML and CSS weren't designed to build responsive, interactive applications, and all that has to be done to make it work makes it a pain in the ass to setup and develop. With stuff like WASM, Flutter, and Blazor, I'm hoping we have viable alternatives to traditional web development.
I know web devs probably don't agree, but HTML and CSS weren't designed to build responsive, interactive applications, and all that has to be done to make it work makes it a pain in the ass to setup and develop. With stuff like WASM, Flutter, and Blazor, I'm hoping we have viable alternatives to traditional web development.
The biggest feature I'd like parity on for mobile web.... is logins.
As the tracking war rages, humble little login cookies are becoming a casualty. For example if someone gets a transactional email (say a new booking notification), opens it on their iphone, it opens safari.... in a new context. No login! So frustrating for them. You can send tokens with the links, but they really need to have an expiry date on them, and if the user forwards the email it risks exposing their whole account. So now you have to start playing with an intermediate 'sort of logged in but don't let them do anything too dangerous' state
And now browsers are using "AI" to magically work out which cookies to delete. That's great, but.. can we not have an explicit UX for the user to say hey, this is a login cookie, I'm logged in because I want to see my data and be authorized on this website every single time I come here (and an equally special logout function that deletes it without trouble).
I'm a pretty heavy user of mobile web and rarely use apps, but logins for power users and tech impaired users is pretty much the main reason we're looking at react-native too
As the tracking war rages, humble little login cookies are becoming a casualty. For example if someone gets a transactional email (say a new booking notification), opens it on their iphone, it opens safari.... in a new context. No login! So frustrating for them. You can send tokens with the links, but they really need to have an expiry date on them, and if the user forwards the email it risks exposing their whole account. So now you have to start playing with an intermediate 'sort of logged in but don't let them do anything too dangerous' state
And now browsers are using "AI" to magically work out which cookies to delete. That's great, but.. can we not have an explicit UX for the user to say hey, this is a login cookie, I'm logged in because I want to see my data and be authorized on this website every single time I come here (and an equally special logout function that deletes it without trouble).
I'm a pretty heavy user of mobile web and rarely use apps, but logins for power users and tech impaired users is pretty much the main reason we're looking at react-native too
Theres native platform support for that now with shared login context between browsers and apps.
e.g. https://developer.apple.com/documentation/authenticationserv...
e.g. https://developer.apple.com/documentation/authenticationserv...
If I’m reading it right that’s for if you control the app though. They still lose login if they follow a link from a mail client or slack app over to a mobile web app, which wouldn’t happen if they were going to an actual app
It should all be shared as long as the sides are using the official cookie storage. I understand it as its essentially an HTTP only cookie stored at the device level (rather than in the brower).
Users hate web apps, especially on mobile, and it has nothing to do with functionality. Web apps on the App Store invariably provoke angry screeds about how the look and feel is not right.
Native apps are even more essential on mobile. On the desktop, web apps just look weird and waste battery life. On mobile, they feel wrong. That difference in feel provokes visceral hatred.
Native apps are even more essential on mobile. On the desktop, web apps just look weird and waste battery life. On mobile, they feel wrong. That difference in feel provokes visceral hatred.
No. Designers and some devs hate web apps for minuscule reasons your average user doesn’t care about and doesn’t notice at all.
If an app helps them to get a task done, it simply doesn’t matter if the thing is native or not. At least, if you use a somewhat reasonable UI approach like Ionic.
If an app helps them to get a task done, it simply doesn’t matter if the thing is native or not. At least, if you use a somewhat reasonable UI approach like Ionic.
Users absolutely want their apps to be as fast and fluid as possible. This is why they buy the newest Apple and Android phones every year, because their web apps are getting slower and slower.
> Users hate web apps, especially on mobile, and it has nothing to do with functionality. Web apps on the App Store invariably provoke angry screeds about how the look and feel is not right.
> Native apps are even more essential on mobile. On the desktop, web apps just look weird and waste battery life. On mobile, they feel wrong. That difference in feel provokes visceral hatred.
They don't have to waste battery life. This is mostly due to poor coding/architecture, instead of "web". Especially with WebGl and Wasm.
> Native apps are even more essential on mobile. On the desktop, web apps just look weird and waste battery life. On mobile, they feel wrong. That difference in feel provokes visceral hatred.
They don't have to waste battery life. This is mostly due to poor coding/architecture, instead of "web". Especially with WebGl and Wasm.
I agree with this. When you are creating a mobile experience for a website, you typically are burdened by the knowledge and existing designs/functionality of the desktop version which was usually built first.
When you are designing for a mobile app, you are free from the shackles that bind you to the desktop.
Of course, there is nothing stopping you from creating a separate web mobile experience, but human nature makes it harder to do so.
When you are designing for a mobile app, you are free from the shackles that bind you to the desktop.
Of course, there is nothing stopping you from creating a separate web mobile experience, but human nature makes it harder to do so.
The biggest problem with mobile apps is that you don't always have a reliable connection to the internet, even when your carrier is claiming you have 4g lte with all the bars.
Web apps should really have the option to cache the page entirely for offline use.
Web apps should really have the option to cache the page entirely for offline use.
They do. It's called a PWA. Service workers cache the assets.
https://developer.mozilla.org/en-US/docs/Web/API/Service_Wor...
https://developer.mozilla.org/en-US/docs/Web/API/Service_Wor...
Seeing that the only apps that make money for either Google or Apple are mostly games with in app purchases, they wouldn’t be appropriate for web apps anyway.
Mail is the last thing I want as a web app. I don’t use web mail on my PC. I definitely wouldn’t want to use it on my phone.
Maps is also much more responsive even on older phones than it is on a web page on a modern PC.
Maps is also much more responsive even on older phones than it is on a web page on a modern PC.
Honestly I think the future of mobile will just be... mobile websites.
That was Steve Jobs' original vision for the iPhone.
The difficulty was that once the App Store launched, people and middle managers thought that if a company didn't have an "app," it wasn't a real company.
Now that the web has matured, there are not that many things outside of games that require an app. But there are still many people (including many in my own company) that think an "app" adds credibility to a company, even if that app does less than the web site.
That was Steve Jobs' original vision for the iPhone.
The difficulty was that once the App Store launched, people and middle managers thought that if a company didn't have an "app," it wasn't a real company.
Now that the web has matured, there are not that many things outside of games that require an app. But there are still many people (including many in my own company) that think an "app" adds credibility to a company, even if that app does less than the web site.
Messenger, Mail, and Teams would be absolutely crippled without background support and notifications. Maps would be somewhat viable, and I'm not familiar with White Noise.
Also, 'native parity' is a moving goalpost. At the point you get support for all those things across all platforms, what else has been added to native that you are now missing?
This isn't even considering the fact that there is no incentive for apple to play nicely without an anti-trust ruling against them.
Also, 'native parity' is a moving goalpost. At the point you get support for all those things across all platforms, what else has been added to native that you are now missing?
This isn't even considering the fact that there is no incentive for apple to play nicely without an anti-trust ruling against them.
Progressive web apps can already receive notifications.
iOS supports push notifications in a PWA context? Thats news to me.
Another feature lacking in the mobile web are touch gestures.
I'm facing this problem right now and the best option for recognizing gestures seems to be HammerJS which adds 7.5kB gzipped to your app.
After that your app still needs to react kinetically (eg: the image moves while dragging it to the left and then the view transitions to the next image). It's a lot of code that needs to be shipped in the JS bundle.
BTW if you have a better solution than HammerJS please comment here:
https://news.ycombinator.com/item?id=22184079
I'm facing this problem right now and the best option for recognizing gestures seems to be HammerJS which adds 7.5kB gzipped to your app.
After that your app still needs to react kinetically (eg: the image moves while dragging it to the left and then the view transitions to the next image). It's a lot of code that needs to be shipped in the JS bundle.
BTW if you have a better solution than HammerJS please comment here:
https://news.ycombinator.com/item?id=22184079
Ads and Exposure.
Ads: Make a native app and a PWA, put a banner at the bottom. You'll get more from the native app.
Exposure: I made some stupid apps and without any SEO I get 10K-50K installs, you can't get that with a PWA and Google Search.
I'm 100% for PWA because I can't take anymore monopole shit from google play and his rules, but that's the reality.
Ads: Make a native app and a PWA, put a banner at the bottom. You'll get more from the native app.
Exposure: I made some stupid apps and without any SEO I get 10K-50K installs, you can't get that with a PWA and Google Search.
I'm 100% for PWA because I can't take anymore monopole shit from google play and his rules, but that's the reality.
Ads are the past.
The future is getting paid to make the app that actual is useful
Hmmm... What are these "ads"? Says the uBlock kid....
The future is getting paid to make the app that actual is useful
Hmmm... What are these "ads"? Says the uBlock kid....
Monetization. Native apps provide app & in-app purchases seamlessly integrated in the platform. Web payment solutions are clumsy in comparison. Sure, there are new APIs that ask for CC number, holder etc. to be prefilled but the friction is still not at the same level IMO.
You need to pay the cut to Apple/Google but in certain scenarios it's preferable than asking for payment details.
You need to pay the cut to Apple/Google but in certain scenarios it's preferable than asking for payment details.
Is there a difference now? Websites in Safari ask me to pay with an Apple ID popup that takes my fingerprint and charges me exactly the same way apps do, I don't see any difference in how it appears or is handled.
> Honestly I think the future of mobile will just be... mobile websites.
Indeed.
A lot of people still think that native is superior than web but the problem is that most websites are bloated pieces of crap.
If anyone doubts this check the Missive email client on iOS which was even featured by Apple on the AppStore and runs on Cordova:
https://medium.com/missive-app/our-dirty-little-secret-cross...
(sorry for the Medium link)
Indeed.
A lot of people still think that native is superior than web but the problem is that most websites are bloated pieces of crap.
If anyone doubts this check the Missive email client on iOS which was even featured by Apple on the AppStore and runs on Cordova:
https://medium.com/missive-app/our-dirty-little-secret-cross...
(sorry for the Medium link)
I didn’t have to go any further than the login and signup screens to see that it doesn’t feel native.
- No transitions between screens, just jumps
- Tapping field brings up keyboard, then whole screen jumps up about 30 pixels instead of smoothly animating
- Scrolling while there’s a blinking cursor has cursor detach from field until you lift your finger
- Doesn’t respect dark mode
- Doesn’t respect dynamic type consistently (text size)
- Other weird little display artifacts
Not saying it’s terrible, but it’s a good example of why native is still the way to go if you can afford it. It’s just a better user experience.
- No transitions between screens, just jumps
- Tapping field brings up keyboard, then whole screen jumps up about 30 pixels instead of smoothly animating
- Scrolling while there’s a blinking cursor has cursor detach from field until you lift your finger
- Doesn’t respect dark mode
- Doesn’t respect dynamic type consistently (text size)
- Other weird little display artifacts
Not saying it’s terrible, but it’s a good example of why native is still the way to go if you can afford it. It’s just a better user experience.
You think all of those are inherent flaws of using a webview?
Some of those are because the developer didn't implement them (transitions, dark mode) and others are because Apple didn't implement them in WKWebView to follow the OS behaviors (cursor, keyboard). Not sure about your comment about the text size or the display artifacts.
Some of those are because the developer didn't implement them (transitions, dark mode) and others are because Apple didn't implement them in WKWebView to follow the OS behaviors (cursor, keyboard). Not sure about your comment about the text size or the display artifacts.
Not really interested in tracking down who is responsible for what. My point is that literally every single time someone comes along claiming that their hybrid framework or app is indistinguishable from native and I go check it out, it’s obvious within 30 seconds that it’s a poor substitute.
We are in a conversation about the future, most of which seems to be being held back by players who have a vested interest in keeping people using native apps; so while you might have the "we are already there" conversation a lot, your knee jerk response doesn't really have a place here.
My response wasn’t knee jerk. I went and downloaded the app in question and played with it. I disagree that the main reason we haven’t gotten to a better place is vested interests. The “write once, deploy anywhere” fantasy has been going on for thirty years now. It’s not that it doesn’t work at all, of course it does. But it comes with many downsides vs software written with one platform in mind, and that’s unlikely to ever change.
I really like the idea of PWAs, but I've tried a few of them and I always come away being annoyed at the app launch latency. They still feel like they're hitting a remote server when starting up for.... something? My uneducated hunch is that they're over-zealously checking their server for updates.
The other issue I have with their implementation is the opaqueness of how offline caching works. How much space do apps get? When does the offline cache get invalidated? I care about that because of that terrible launch latency.
I think these issues can be attributed to PWAs being second-class citizens in Android and iOS.
The other issue I have with their implementation is the opaqueness of how offline caching works. How much space do apps get? When does the offline cache get invalidated? I care about that because of that terrible launch latency.
I think these issues can be attributed to PWAs being second-class citizens in Android and iOS.
Developers love the idea of PWAs. Users are less enthusiastic.
I for one personally like that Apple does some rudimentary vetting of apps in their store. I really have no interest in running a web app that could be great today and loaded with malware and trackers tomorrow.
I for one personally like that Apple does some rudimentary vetting of apps in their store. I really have no interest in running a web app that could be great today and loaded with malware and trackers tomorrow.
This is a solved problem via service workers. They can cache all the app's content and you can choose to cache whatever you like including api responses from any service. They could also be configured to serve cache first and replace the content in background. At this point if the app is slow to start, it's 100% on devs/architecture. The only problem is if you exceed the quota for cache, which is varied by browser/platform, you risk the browser just nuking all your cache/localstorage/indexeddb.
With all of your most used apps, you could just switch to using web apps. You can save any mobile site to the home screen of your iphone with safari.
>What's missing until regular websites have parity with mobile apps in functionality?
Some means of preventing users from blocking ads and tracking? Sure, there are ways around this for native apps but they're not nearly as trivial as installing an ad blocker (provided the mobile browser supports extensions).
Some means of preventing users from blocking ads and tracking? Sure, there are ways around this for native apps but they're not nearly as trivial as installing an ad blocker (provided the mobile browser supports extensions).
I was going to build a mobile web app but I don’t like the way iOS handles button clicks on the bottom of the screen. The first click is ignored and it slides up your bottom menu bar, then you can click the button.
You don’t have as much control in the browser.
This would be great if HTTP, HTML and co would have been designed as a stateful low-latency application platform and not a distributed encyclopaedia. Retrofitting state and all of the things you listed into it resulted in the Javascript mayhem which is quite pathetic for several reasons including security and energy consumption. I think the future should be native applications that can be optimized for data transfer and latency, have much better security and stateful behaviour by default.
And what happens when I don't have any signal? Writing an offline-first mobile website is INCREDIBLY hard. Where are you going to store the data? How are you going to detect the network connectivity without polling and hosing the battery because the radio doesn't timeout? Geo-fencing events?
Yes! This is something that would greatly benefit the app world.
Arguably the biggest concern with React Native is that it is controlled by a single entity, Facebook, and that they are not one of the leading mobile platforms who from a business perspective have strong incentives to ensure the future of their respective app eco systems.
Facebook's incentives with React Native are somewhat unclear. This is a big, yet often unspoken, reason companies are vary of depending on React Native for their mobile stacks. With more large companies such as Microsoft, and now Shopify getting behind React Native those incentives will have to please a larger group and should become much more aligned with mobile developer communities at large - and not just Facebook's desires.
If Shopify manages to play an active role in the development of React Native and expand the project beyond the sole control of Facebook then React Native will become a much more viable option for companies who for political reasons have refrained from using the technology.
Facebook's incentives with React Native are somewhat unclear. This is a big, yet often unspoken, reason companies are vary of depending on React Native for their mobile stacks. With more large companies such as Microsoft, and now Shopify getting behind React Native those incentives will have to please a larger group and should become much more aligned with mobile developer communities at large - and not just Facebook's desires.
If Shopify manages to play an active role in the development of React Native and expand the project beyond the sole control of Facebook then React Native will become a much more viable option for companies who for political reasons have refrained from using the technology.
>>> Facebook's incentives with React Native are somewhat unclear
I always figured this conversation happened:
1: "We have all these engineers who write javascript but users are switching to native apps. what do we do?"
2: "We could retrain them all."
1: "That would be expensive and time consuming."
2: "We could fire them all."
1: "Also expensive and time consuming."
2: "Wait, what if we made it so you could write native apps in javascript?"
I always figured this conversation happened:
1: "We have all these engineers who write javascript but users are switching to native apps. what do we do?"
2: "We could retrain them all."
1: "That would be expensive and time consuming."
2: "We could fire them all."
1: "Also expensive and time consuming."
2: "Wait, what if we made it so you could write native apps in javascript?"
1: "Great idea. Which version of Electron should we use?"
[deleted]
The second/third paragraphs of your comment could be find/replaced Shopify for Airbnb from 2-3 years ago and fit right in.
It is no longer the case that Facebook is the only major contributor to React Native. Facebook and Microsoft now just started formalising their collaboration on the project with monthly(ish) meetings[0]. Other large companies like Twitter are using React Native Web (different than ReactJS) for their main progressive web app[1].
Other large companies using React Native are:
- JD.com
- Skype
- Uber
- Tesla
- Discord
You do have a point about _control_ of the React Native project though. That's still all with Facebook. The Github repo is currently setup as a mirror of part of the internal Facebook monorepo. Therefore, all pull requests need to be merged by a Facebook employee before it becomes part of "core". This is enough of a barrier that "non-core" part of React Native were split out so they could be managed and released independently[2]. It is also true that while other major companies are _using_ React Native, they might not be actively contributing.
It would be good if Facebook put some proper structure around React Native as an open source project, however, for now the project is running along fine.
[0] https://github.com/react-native-community/discussions-and-pr... [1] https://mobile.twitter.com/ [2] https://github.com/facebook/react-native/issues/23313
edited: not sure how to make this list correctly formatted
Other large companies using React Native are:
- JD.com
- Skype
- Uber
- Tesla
- Discord
You do have a point about _control_ of the React Native project though. That's still all with Facebook. The Github repo is currently setup as a mirror of part of the internal Facebook monorepo. Therefore, all pull requests need to be merged by a Facebook employee before it becomes part of "core". This is enough of a barrier that "non-core" part of React Native were split out so they could be managed and released independently[2]. It is also true that while other major companies are _using_ React Native, they might not be actively contributing.
It would be good if Facebook put some proper structure around React Native as an open source project, however, for now the project is running along fine.
[0] https://github.com/react-native-community/discussions-and-pr... [1] https://mobile.twitter.com/ [2] https://github.com/facebook/react-native/issues/23313
edited: not sure how to make this list correctly formatted
Microsoft should be on that list as well.
I missed it off as I mentioned them in the paragraph above. They seem to be investing more and more into React Native with support for Windows and using it in Office.
It is a bit more than that.
They are also supporting React Native for macOS, and most of their teams that are in the C++ side of "C++ vs .NET" eternal politics seem to want to go with React Native for the managed layer.
They are also supporting React Native for macOS, and most of their teams that are in the C++ side of "C++ vs .NET" eternal politics seem to want to go with React Native for the managed layer.
It is interesting that React's detractors have seemingly abandoned technical arguments, and now it's all about how evil Facebook is. A while back, the argument was about how the license for React was scary and evil and they would steal all your patents, but they changed the license. So now I guess it has to be just FB = evil
React is also controlled by Facebook, and yet is one of the most popular Javascript frameworks. I don't see how React Native would be any different.
It's open source. If you don't like the direction, fork it and do something new with the project.
Good luck, lol
Is there a reason that the web is not a target of react native?
It seems somewhat insane to have a cross platform approach and leave out the biggest platform of all, the web.
Or - looking at it the other way round - what approaches are there to take a working pwa website and turn it into an app? What advantages over such an approach can react native bring to the table?
It seems somewhat insane to have a cross platform approach and leave out the biggest platform of all, the web.
Or - looking at it the other way round - what approaches are there to take a working pwa website and turn it into an app? What advantages over such an approach can react native bring to the table?
react-native-web exists: https://github.com/necolas/react-native-web
Maybe you've heard of ReactJS?
It is, and it's even mentioned and linked to in the article.
There has been a large push to support web as a target in react-native by expo.
https://docs.expo.io/versions/latest/
Depending on the complexity of your app - expo is the best place to start with react-native. Their managed workflows allow you to write in 100% javascript w/ a lot of the native libraries already linked an exposed in JS. If you need something they haven't bundled already then you can eject and have a good starting point.
Expo web is still fairly new but they seem to have prioritized it as highly as support for Android and iOS.
https://docs.expo.io/versions/latest/
Depending on the complexity of your app - expo is the best place to start with react-native. Their managed workflows allow you to write in 100% javascript w/ a lot of the native libraries already linked an exposed in JS. If you need something they haven't bundled already then you can eject and have a good starting point.
Expo web is still fairly new but they seem to have prioritized it as highly as support for Android and iOS.
The Ionic team recently released React support so you can build a PWA using React and target iOS, Android, web, and electron. Uses Capacitor under the hood for full native access. It’s been getting a lot of usage since the release: https://ionicframework.com/blog/announcing-ionic-react/
Also you can use Capacitor with any PWA-style web application without using any of the rest of the Ionic Framework. https://capacitor.ionicframework.com/
It's currently the best maintained successor to PhoneGap/Cordova.
It's currently the best maintained successor to PhoneGap/Cordova.
Anyone know where React Native stands in modern development - especially when compared to Flutter and the upcoming Compose.
All the native frameworks are also React inspired.
I personally love the work done by Airbnb for its Android MvRx framework. Again, React inspired
All the native frameworks are also React inspired.
I personally love the work done by Airbnb for its Android MvRx framework. Again, React inspired
React and it's model are great. React Native on the other hand is leaky, heavy and you'll spend a bunch of time fiddling with packages, upgrading them, tracking down weird linking issues and ultimately writing some Objective-C / Java code to debug / glue / fix whatever native API you're dealing with. Thats only from my experience though. I would much rather the Compose / SwiftUI direction.
This is exactly my experience too. It’s an absolute nightmare juggling three package managers at once.
I had a similar experience.
I was also frustrated by the Redux stack, which was odd because I quite like it on web. But in RN, I kept thinking over to how networking and data work in Cocoa Touch and Swift and wondering why we were building these byzantine solutions to problems that iOS already had built-in, elegant solutions for.
Now I’m digging in to SwiftUI, which seems to take best from AppKit and React... I don’t think I’ll be doing another RN project.
I was also frustrated by the Redux stack, which was odd because I quite like it on web. But in RN, I kept thinking over to how networking and data work in Cocoa Touch and Swift and wondering why we were building these byzantine solutions to problems that iOS already had built-in, elegant solutions for.
Now I’m digging in to SwiftUI, which seems to take best from AppKit and React... I don’t think I’ll be doing another RN project.
[deleted]
Translation: we don’t see mobile experiences driving our growth.
Why is that an equivalent statement?
If mobile was important enough for them, they would have invested in proper mobile development. Clearly it is not.
Companies invest in growth areas. Mobile experiences are driven largely by interactive native elements using the latest platform specific API.
"In order to best serve our retail merchants and learn about React Native in a physical retail setting, we decided to build out the new POS natively for iOS and use React Native for Android."
Unbelievable, really. The previous paragraph literally mentions the importance of performance.
facepalm
Unbelievable, really. The previous paragraph literally mentions the importance of performance.
facepalm
Why do they use RN for Android but not for iOS?
Can anyone from Shopify directly address the points brought up in the Airbnb posts.
Shopify CEO expressed his thoughts on the matter quite succinctly https://twitter.com/tobi/status/1222551057798090752
Cool, though I'd argue *too succinctly. Go into it please, for the sake of the community.
The Shopify CEO is going to be pretty disappointed when he finds out all of those diamonds are actually just npm audit fixes, dramatically out of date packages, and strange platform specific behavior regardless of the "write once, run everywhere" tagline.
I'm always scared of these headlines for companies who aren't greenfield.
Shopify is a perfect case for RN. Write once deploy both platforms. The issue that gets glossed over is for existing apps that have to do the data and abstraction layer on top of native codes. It starts to become prohibitively expensive to maintain the native, RN, and data layers unless you're willing to rewrite the native side.
Airbnb fell into this problem[0] and so did my old company.
I love RN for what it is and can do, but big companies that hop on and then are forced to hop off because of internal politics makes it a difficult case for RN because then it becomes "look, RN didn't work out for Airbnb or Shopify..."
I hope for the best of luck and success to the RN engineers.
[0] https://medium.com/airbnb-engineering/react-native-at-airbnb...
Shopify is a perfect case for RN. Write once deploy both platforms. The issue that gets glossed over is for existing apps that have to do the data and abstraction layer on top of native codes. It starts to become prohibitively expensive to maintain the native, RN, and data layers unless you're willing to rewrite the native side.
Airbnb fell into this problem[0] and so did my old company.
I love RN for what it is and can do, but big companies that hop on and then are forced to hop off because of internal politics makes it a difficult case for RN because then it becomes "look, RN didn't work out for Airbnb or Shopify..."
I hope for the best of luck and success to the RN engineers.
[0] https://medium.com/airbnb-engineering/react-native-at-airbnb...
Curious to hear more about their deep dive into Native, Flutter and React Native as possible technology choices.
Hopefully, React Native is not a nosedive ;)
Hopefully, React Native is not a nosedive ;)
Flutter and React-Native are different directions, I think.
For higly customized UIs (think Ableton Live, Photoshop, Excel, etc.), I'd say use Flutter, because of the non-native rendering, it will look the same everywhere. Otherwise use React-Native.
For higly customized UIs (think Ableton Live, Photoshop, Excel, etc.), I'd say use Flutter, because of the non-native rendering, it will look the same everywhere. Otherwise use React-Native.
Exactly this. They are very different systems.
Flutter renders onto a "canvas" and has a completely custom implementation of "native-like" views for each platform. They need to reimplement everything about platform views from scratch.
React Native lets the native OS render actual native views, but lays them out and controls their properties using Javascript. You get the native behaviours "for free", but you do sometimes end up in the lowest common denominator position.
Flutter renders onto a "canvas" and has a completely custom implementation of "native-like" views for each platform. They need to reimplement everything about platform views from scratch.
React Native lets the native OS render actual native views, but lays them out and controls their properties using Javascript. You get the native behaviours "for free", but you do sometimes end up in the lowest common denominator position.
Yes. The common denominator isn't as low as one might expect. I'd guess at least 90% of all apps could be easily done with React-Native.
Sure. But what if the entire world doesn’t want to learn JavaScript? What if you don’t already know HTML, CSS, and JS? RN makes ZERO sense at that point.
As a C developer, man, Flutter looks pretty damn logical!
As a C developer, man, Flutter looks pretty damn logical!
I don't know if you read your own link or not, but he's first off complaining about a community plugin and not an official one.
There is some truth that overlapping isn't well supported in Flutter CURRENTLY, but I can think of things that were well supported in RN 4 years ago either.
I can't think of a single reason I would want an overlay EXCEPT an alert, and even then, I don't think he's right.
There is some truth that overlapping isn't well supported in Flutter CURRENTLY, but I can think of things that were well supported in RN 4 years ago either.
I can't think of a single reason I would want an overlay EXCEPT an alert, and even then, I don't think he's right.
If it makes more sense, then go for it.
With all of these platform abstractions you just need to understand the trade-offs they're making.
With all of these platform abstractions you just need to understand the trade-offs they're making.
In my experience Flutter is not any less productive than RN is, I'd prefer the former in every case now.
The last time I was using React Native even text input was broken on Android. It made any app using it basically unusable. Android profiler didn't work either, opening it crashed the runtime.
Flutter has its bugs but they're certainly not that fundamental issues.
Flutter has its bugs but they're certainly not that fundamental issues.
Hahaha ahaahah
gee what happens when Android Fuchsia hits oem devices this year? CES surprise coming..
gee what happens when Android Fuchsia hits oem devices this year? CES surprise coming..
In the unlikely event that Fuchsia ever makes it out without being strangled by the rest of the Android organization, or someone high-up waking up and taking a look at it (eye of mordor style)... absolutely nothing? For the next 5-10 years at least as Android devices are slowly replaced in the marketplace with Fuchsia through device turnover rates alone. You think Android version upgrade stats are abysmal today? And you want to replace the whole base OS? Good luck with that.
I don't understand why so many large companies use platform abstractions. At a certain size you're big enough to have an iOS team that develops natively in Swift/ObjC and an Android team developing natively in Kotlin or Java. Developing directly for the platform, with expertise in that platform, is a proven long term bet. Screwing around with platform abstractions seems much riskier.
The situation is a lot different if you're a small organization (or individual) and just don't have the resources for platform specific experts.
The situation is a lot different if you're a small organization (or individual) and just don't have the resources for platform specific experts.
Headcount is the biggest expense in almost all companies. Larger companies also have larger and more complex apps, so while a small company may have a small iOS development team, large companies have massive iOS development teams. Massive team * number of platforms = serious money.
You also get into all kinds of platform and feature parity issues. "Why can't we do X on Android but only on iOS?", "Well because they're two different teams, with different PMs, developers and release schedules. And please don't ask about the web team, who are in <different city>".
Using abstractions you can have one massive "core" team, and several smaller platform expert teams. On the face of it, it makes sense.
You also get into all kinds of platform and feature parity issues. "Why can't we do X on Android but only on iOS?", "Well because they're two different teams, with different PMs, developers and release schedules. And please don't ask about the web team, who are in <different city>".
Using abstractions you can have one massive "core" team, and several smaller platform expert teams. On the face of it, it makes sense.
But developer headcount doesn't scale to the size of the installed base. Whether you have hundred-thousand users or a million users, you don't need a larger development team. Once you have a reasonable-sized team that can make the app, you don't need any more developers, no matter how successful your app is.
Having different teams for different platforms might result in a slightly larger headcount my point is that risk isn't worth that meager benefit if you can afford it. You're still going to need platform-specific knowledge, and then the abstraction knowledge, and you're still deploying to multiple platforms!
You also don't need to let the technology choices drive the team structure. You can share a huge number of resources between iOS and Android including planning, management, assets, etc. Sure you're building two different apps but you don't need to keep those teams in different cities.
Having different teams for different platforms might result in a slightly larger headcount my point is that risk isn't worth that meager benefit if you can afford it. You're still going to need platform-specific knowledge, and then the abstraction knowledge, and you're still deploying to multiple platforms!
You also don't need to let the technology choices drive the team structure. You can share a huge number of resources between iOS and Android including planning, management, assets, etc. Sure you're building two different apps but you don't need to keep those teams in different cities.
But the question was why large companies use platform abstractions. Because they are large in headcount, by definition. Because the apps are already large. Because they have massive platform specific teams, and they would like not to. Because the teams are geographically spread out, for a myriad of reasons.
The large companies are what they are, and you cannot apply the same type of thinking to their problems as if you were designing the organization from scratch. There's problems they have, and the team structure they would like to have, and based on that the technology choice to favor abstraction makes sense.
The large companies are what they are, and you cannot apply the same type of thinking to their problems as if you were designing the organization from scratch. There's problems they have, and the team structure they would like to have, and based on that the technology choice to favor abstraction makes sense.
Yes, many large companies seek technological solutions to political problems. I've worked for dysfunctional organizations; they want technology to provide the decisions bottom-up because, for whatever reason, nobody wants to make any hard calls. These projects fail because you simply can't have success that way.
If this is a political and organizational problem, then this choice of technology is entirely not about the pros and cons that have probably been debated to death in this topic. I agree. I think you've added some really good insight in this conversation. But I think that solution is dumb.
It's especially dumb for a software company because software is their core competency. That's where they should be spending their resources on. They should be minimizing costs but not at the cost of their core product.
If this is a political and organizational problem, then this choice of technology is entirely not about the pros and cons that have probably been debated to death in this topic. I agree. I think you've added some really good insight in this conversation. But I think that solution is dumb.
It's especially dumb for a software company because software is their core competency. That's where they should be spending their resources on. They should be minimizing costs but not at the cost of their core product.
I wouldn't class this as political problems. Is Facebook having a gazillion developers on their app a political problem, or necessary given what they want it to do? How is replicating that for each platform a good solution, in any sense (political or technical)?
Tech companies core competencies are the service or product that they provide. Making it N times for N platforms is a hurdle that doesn't improve on the core, it's a cost of the fragmented market. I'm arguing that it makes perfect sense both technically and politically to focus your vast majority of developers on your core, and only having specialized platform teams were necessary as a cost of doing business. How is developers re-implementing every UI screen and feature across iOS and Android helping Shopify customers sell more merch?
Tech companies core competencies are the service or product that they provide. Making it N times for N platforms is a hurdle that doesn't improve on the core, it's a cost of the fragmented market. I'm arguing that it makes perfect sense both technically and politically to focus your vast majority of developers on your core, and only having specialized platform teams were necessary as a cost of doing business. How is developers re-implementing every UI screen and feature across iOS and Android helping Shopify customers sell more merch?
> Is Facebook having a gazillion developers on their app a political problem, or necessary given what they want it to do?
Yes. How is it not a political problem? It's not a technological one.
> How is replicating that for each platform a good solution, in any sense (political or technical)?
It doesn't change anything politically but technologically platform abstractions are never 100%. You always need an expert for each platform anyway and by targeting the abstraction rather than the platform you're just targeting a crappier experience for your end users and often your developers as well. React Native is not without it's issues.
So what's the benefit? You're not saving expertise. Even sharing code isn't that important -- once decisions have been made, features planned out in detail, server APIs created, the actual platform specific code is a pretty small part overall. You still have to test on each platform individually. Fix platform specific bugs even in non-platform specific code. And you're not creating a dependency on a 3rd party that you don't control.
> How is developers re-implementing every UI screen and feature across iOS and Android helping Shopify customers sell more merch?
How is it not? I mean the argument here is that there is a huge savings to justify the risk but I don't think that's true.
Yes. How is it not a political problem? It's not a technological one.
> How is replicating that for each platform a good solution, in any sense (political or technical)?
It doesn't change anything politically but technologically platform abstractions are never 100%. You always need an expert for each platform anyway and by targeting the abstraction rather than the platform you're just targeting a crappier experience for your end users and often your developers as well. React Native is not without it's issues.
So what's the benefit? You're not saving expertise. Even sharing code isn't that important -- once decisions have been made, features planned out in detail, server APIs created, the actual platform specific code is a pretty small part overall. You still have to test on each platform individually. Fix platform specific bugs even in non-platform specific code. And you're not creating a dependency on a 3rd party that you don't control.
> How is developers re-implementing every UI screen and feature across iOS and Android helping Shopify customers sell more merch?
How is it not? I mean the argument here is that there is a huge savings to justify the risk but I don't think that's true.
> Because they have massive platform specific teams, and they would like not to.
I'm somewhat shocked at the size of some of the mobile app development teams at some of these companies. There's no way they need that many developers. What are 100's of developers doing on a single app for a single platform? How is there enough work for that many people? The overhead must be unbelievable.
I can't imagine that adding a platform abstraction is going to fundamentally change the headcount if your headcount is already ridiculous. It just doesn't remove that much effort.
I'm somewhat shocked at the size of some of the mobile app development teams at some of these companies. There's no way they need that many developers. What are 100's of developers doing on a single app for a single platform? How is there enough work for that many people? The overhead must be unbelievable.
I can't imagine that adding a platform abstraction is going to fundamentally change the headcount if your headcount is already ridiculous. It just doesn't remove that much effort.
The Facebook app is like Microsoft Word. Everyone only uses 20%, but it's a different 20% for each. The app is a hojillion megabytes, and serves literally billions of users. There's features in there that addresses some specific niche in Africa for "only" 50 million users, that some sub-team of a sub-team is tasked with maintaining.
Microsoft doesn't use an abstraction to create Word for Mac OS. They have shared code, yes. But they are different products with different user interfaces to match their respective platforms. I'm not sure why mobile is so different that one needs a platform abstraction if you've already got a bazillion developers working on the product.
Of course, Facebook does benefit by owning that abstraction making it exactly what they need. For everyone else, the risk is a bit different.
Of course, Facebook does benefit by owning that abstraction making it exactly what they need. For everyone else, the risk is a bit different.
Microsoft has been building Word on Windows since the 80's, so it's never going to be re-written. I'm not that familiar with the Mac version of Word, but I find the Mac Excel version lacking compared to its Windows counterpart.
For Word and Excel for iOS and Android they use... React Native [1].
[1] https://blog.appfigures.com/microsoft-goes-all-in-on-react-n...
For Word and Excel for iOS and Android they use... React Native [1].
[1] https://blog.appfigures.com/microsoft-goes-all-in-on-react-n...
As someone leading a team that does releases to clients, this is a pretty naive take.
As you scale you get quite a few constraints that require additional manpower
1. Scaling generally means revenue, which means more internal teams pumping out more business products/features.
Those features often need some sort of mobile integration. So you not only have your planned features, you have the features other teams would like you to work on.
The larger the company, the more requests like this you get. Feature velocity MATTERS.
2. As you scale you almost always have to rework your backend to some extent to keep up with load/feature growth. This means existing features are at risk of using deprecated & older APIs/Tools and need attention in order to keep working and allow scaling.
3. By the time you're scaling into the millions, you're almost certainly acquiring enterprise users. You can skate by in the individual/small/medium business with some pretty glaring bugs (things like 2% of all android users see crashes at startup). This wiggle rooms goes away when you start working with enterprise customers (or at least gets considerably tighter). It's an inconvenience when your 15 person org has that one phone that doesn't work right. It's a showstopper when the 10,000 seat org has 600+ users who can't use the product.
Those are just a few of the differences that happen at scale.
----
Long story short, you're not really wrong from a technical side - A small dev team can absolutely make a small & focused app and manage to scale.
You're just glossing over the politics of working in an org that's successfully scaling.
It turns out being able to get additional employees that don't need extensive mobile experience and can just crank out features is a huge pressure release. It lets that original tiny dev team (the folks who could write a fine native app without any issue) focus on bigger/harder problems.
As you scale you get quite a few constraints that require additional manpower
1. Scaling generally means revenue, which means more internal teams pumping out more business products/features.
Those features often need some sort of mobile integration. So you not only have your planned features, you have the features other teams would like you to work on.
The larger the company, the more requests like this you get. Feature velocity MATTERS.
2. As you scale you almost always have to rework your backend to some extent to keep up with load/feature growth. This means existing features are at risk of using deprecated & older APIs/Tools and need attention in order to keep working and allow scaling.
3. By the time you're scaling into the millions, you're almost certainly acquiring enterprise users. You can skate by in the individual/small/medium business with some pretty glaring bugs (things like 2% of all android users see crashes at startup). This wiggle rooms goes away when you start working with enterprise customers (or at least gets considerably tighter). It's an inconvenience when your 15 person org has that one phone that doesn't work right. It's a showstopper when the 10,000 seat org has 600+ users who can't use the product.
Those are just a few of the differences that happen at scale.
----
Long story short, you're not really wrong from a technical side - A small dev team can absolutely make a small & focused app and manage to scale.
You're just glossing over the politics of working in an org that's successfully scaling.
It turns out being able to get additional employees that don't need extensive mobile experience and can just crank out features is a huge pressure release. It lets that original tiny dev team (the folks who could write a fine native app without any issue) focus on bigger/harder problems.
You have what I'm saying backwards. I'm not talking about a small dev team. My whole point is that when you have a large dev team, that you don't need that platform abstraction because you have the manpower to handle multiple platforms natively. Especially if you are a software company and not just a widget company that also has an app.
> It turns out being able to get additional employees that don't need extensive mobile experience and can just crank out features is a huge pressure release.
The idea that because you're using React Native you can throw developers with no mobile experience at problems seems naive to me.
I also don't believe feature velocity scales with the number of developers. This is the whole 9 women making a baby in a month thing. This especially true on a mobile app which is constrained by the interface and user expectations. You're not going to have hundreds of developers working on a far flung features away from everything else because the apps are small and tight even if complex. There are exceptions but most mobile apps are focused on a small critical path.
It seems to me that all these companies with hundreds of mobile developers aren't producing better results than those with dozens. In fact, it usually seems the opposite. There are exceptions but when was the last time a giant company made such extensive changes to their app that justified that number of developers?
A justified use of developers is native versions for each platform.
> It turns out being able to get additional employees that don't need extensive mobile experience and can just crank out features is a huge pressure release.
The idea that because you're using React Native you can throw developers with no mobile experience at problems seems naive to me.
I also don't believe feature velocity scales with the number of developers. This is the whole 9 women making a baby in a month thing. This especially true on a mobile app which is constrained by the interface and user expectations. You're not going to have hundreds of developers working on a far flung features away from everything else because the apps are small and tight even if complex. There are exceptions but most mobile apps are focused on a small critical path.
It seems to me that all these companies with hundreds of mobile developers aren't producing better results than those with dozens. In fact, it usually seems the opposite. There are exceptions but when was the last time a giant company made such extensive changes to their app that justified that number of developers?
A justified use of developers is native versions for each platform.
From what I see, anytime you have separate iOS and Android apps, they will rapidly diverge on features and UX to the point where it feels like different programs working with the same data set.
RN lets you have 1 team working on the same app, so the features are the same.
In theory, you could enforce that all features must be present in all apps, but in practice it never seems to happen.
RN lets you have 1 team working on the same app, so the features are the same.
In theory, you could enforce that all features must be present in all apps, but in practice it never seems to happen.
That's still a management problem, not a technological one.
Many of cross platform apps seem just slightly off compared to native ones. There are exceptions but those exceptions but they have a lot of work put into them to make them seem native -- something you get for free when you actually are native.
Many of cross platform apps seem just slightly off compared to native ones. There are exceptions but those exceptions but they have a lot of work put into them to make them seem native -- something you get for free when you actually are native.
Do you think AirBnB's headcount was smaller when they were all-in on React Native?
Do you think they had to go on a hiring spree because they went back to native?
I'm skeptical there is a correlation.
Do you think they had to go on a hiring spree because they went back to native?
I'm skeptical there is a correlation.
> I don't understand why so many large companies use platform abstractions. At a certain size you're big enough to have an iOS team that develops natively in Swift/ObjC and an Android team developing natively in Kotlin or Java.
Because whoever made the decision to move to an abstraction gets to highlight "eliminated redundancies and saved the company $XMM/year" in their next performance review/resume.
Because whoever made the decision to move to an abstraction gets to highlight "eliminated redundancies and saved the company $XMM/year" in their next performance review/resume.
> I don't understand why so many large companies use platform abstractions
Even large companies can be cheap. Hiring developers is a complicated and costly process. But I'd wager that using a solution that the company or a middle manager X,Y,Z didn't vet before can also be a complicated a costly process. Plenty of language X shops refuse to use language Y for political reasons.
Even large companies can be cheap. Hiring developers is a complicated and costly process. But I'd wager that using a solution that the company or a middle manager X,Y,Z didn't vet before can also be a complicated a costly process. Plenty of language X shops refuse to use language Y for political reasons.
> I don't understand why so many large companies use platform abstractions.
At a certain point you'd rather have your developers focusing on tackling domain complexity, not stack complexity. If I can normalize my developers' skillsets I can shuffle them around at will to address whatever problems the business/product needs to be addressing -- quickly. Can't do that as easily if you need to do a bunch of platform-specific stuff as well.
At a certain point you'd rather have your developers focusing on tackling domain complexity, not stack complexity. If I can normalize my developers' skillsets I can shuffle them around at will to address whatever problems the business/product needs to be addressing -- quickly. Can't do that as easily if you need to do a bunch of platform-specific stuff as well.
I think one of the coolest things that Shopify is doing is this:
We’re sponsoring Software Mansion and Krzysztof Magiera (co-founder of React Native for Android) in their open source efforts around React Native.
and
We are working with Discord to accelerate the open sourcing of FastList for React Native (a library which only renders list items that are in the viewport) and optimizing for Android.
Basically RecyclerView for React Native.
We’re sponsoring Software Mansion and Krzysztof Magiera (co-founder of React Native for Android) in their open source efforts around React Native.
and
We are working with Discord to accelerate the open sourcing of FastList for React Native (a library which only renders list items that are in the viewport) and optimizing for Android.
Basically RecyclerView for React Native.
Without synchronous view layout, it's not really possible to have a truly recycling view without many warts. We've (Wix) been hacking at this for years, and it's not possible. You either block the UI or view flash for the user if fast enough scrolling is performed.
Facebook engineering promised synchronous layout will come at some point, which will open the door to that.
Facebook engineering promised synchronous layout will come at some point, which will open the door to that.
Is Wix moving away from React Native at this point?
No
Thanks for the info - I’m a big fan and very appreciative of Wix’s RN contributions!
Theyve said Fabric comes out probably mid 2020 I think, which I am hopeful for
What about Flipkart's https://github.com/Flipkart/recyclerlistview ?
No web-only solution will give you a fully satisfactory result. It's just not possible. If you scroll fast enough, you will see either flickering or empty zones.
there are demos - https://github.com/Flipkart/recyclerlistview#demo
Apple really needs to start using the stick more with respect to the inferior-to-native cross-platform frameworks. I hope that's the strategy after SwiftUI matures.
Shopify is right to use React Native.
I build an app with React Native Web and we produce Android/iOS/web from the same code base with 3 developers.
No, it's not perfect. Yes, JS can be awkward and confusing. Yes, a truly native app built by expert platform-specific developers would be better.
But I'm able to ship this product with less than half the team size I would need for native development. JavaScript developers are cheap to hire, and they don't need to know any objc/swift/java/kotlin to build the product.
Our product is consistent, because it's the same code across platforms. The business people paying us to build the app are thrilled at how quickly we can turn around features.
We've been shipping this way for 2 years and I would strongly recommend it to everyone.
Also, before people jump in with "But RN is slow and bloated!", it's actually not. The performance is just as good as truly native and the binary is small. The real downside is having the app not feel native, but only developers seem to notice. Pragmatically, most apps are so bad that if your Android app has an iOS look-and-feel nobody seems to care.
I build an app with React Native Web and we produce Android/iOS/web from the same code base with 3 developers.
No, it's not perfect. Yes, JS can be awkward and confusing. Yes, a truly native app built by expert platform-specific developers would be better.
But I'm able to ship this product with less than half the team size I would need for native development. JavaScript developers are cheap to hire, and they don't need to know any objc/swift/java/kotlin to build the product.
Our product is consistent, because it's the same code across platforms. The business people paying us to build the app are thrilled at how quickly we can turn around features.
We've been shipping this way for 2 years and I would strongly recommend it to everyone.
Also, before people jump in with "But RN is slow and bloated!", it's actually not. The performance is just as good as truly native and the binary is small. The real downside is having the app not feel native, but only developers seem to notice. Pragmatically, most apps are so bad that if your Android app has an iOS look-and-feel nobody seems to care.
Don't know last time I tried React Native and wanted to use some cool feature of iOS. I either had to write my own RN plugin in Swift/ObjC or wait for someone else to do it.
You say that like writing plugins is hard or undesirable.
Exactly - this is native code that would need to be written either way, right?
That's what I don't understand when people criticize frameworks like React Native... "I didn't like that I had to build 15% of the app in native code, so I ditched RN and now have to write 100% of the app in native code, but twice and in two different languages"?
React Native isn't the only abstraction out there. You could use Flutter, Ionic or similar.
Or do they have the same issue?
Or do they have the same issue?
They all have the same issues, but RN has the largest community.
Flutter has a larger number of "star" on Github. It also has more issues and more pull requests.
React Native has 3x more followers on Reddit.
So I guess it depends on your definition of community.
Flutter is only in beta for desktop and web.
And it's emulated UI, not true native UI.
RN is ready now and today for all platforms, including Window via react-native-windows.
Microsoft is choosing React, I wouldn't go w/ Flutter.
Why would you choose a Google only language and framework... unless you like rewriting code when it dies.
Also, w/ React you can use TypeScript or JS, you don't have to learn a new language.
From my perspective, it looks like Google pays a lot of money for these tech articles and stars, it's not a really good way to look at things. There's always a Flutter campaign going on.
RN is ready now and today for all platforms, including Window via react-native-windows.
Microsoft is choosing React, I wouldn't go w/ Flutter.
Why would you choose a Google only language and framework... unless you like rewriting code when it dies.
Also, w/ React you can use TypeScript or JS, you don't have to learn a new language.
From my perspective, it looks like Google pays a lot of money for these tech articles and stars, it's not a really good way to look at things. There's always a Flutter campaign going on.
As much as I hate that google kills stuff often, the above comment is missing the fact that facebook also kills stuff often, they just never had any adoption in the first place so you don't notice
But React is more open source and flexible. Microsoft has embraced React and RN via their react-native-windows project, they are currently rewriting it from C# to C++, so it must be important.
They use it for Skype and other products.
Google isn't built on Flutter, not the important parts. Facebook has been building their stuff w/ React. They have over 10,000 components, I doubt they'll abandon it.
Even if they do, React is much more flexible and open, it doesn't have a compiler or language tied to it either. If Google drops Flutter, you're fucked.
They use it for Skype and other products.
Google isn't built on Flutter, not the important parts. Facebook has been building their stuff w/ React. They have over 10,000 components, I doubt they'll abandon it.
Even if they do, React is much more flexible and open, it doesn't have a compiler or language tied to it either. If Google drops Flutter, you're fucked.
Does RN work on macOS ?
Well, React Native always gets a bit advertised as you don't need to know any native programming knowledge but that's not true. That's what I tried to say.
It is a heck lot easier to stick to 1 language with no plugins, then 3 languages with plugins for every native feature
> JavaScript developers are cheap to hire, and they don't need to know any objc/swift/java/kotlin to build the product.
OP is pretty much saying that.
OP is pretty much saying that.
It's actually not too bad. You don't even have to put those native code as a separate plugin. You can simply add the native code directly to the generated ios/android project like you do a native app.
expo is taking care of this, not there yet, but getting better every day.
Thats a benefit of React Native though. Share as much code as possible and write wrappers for the Native features you need for your project. I really love the model.
> JS can be awkward and confusing.
> JavaScript developers are cheap to hire
There’s your problem. Go hire JS devs that know what they’re doing.
> JavaScript developers are cheap to hire
There’s your problem. Go hire JS devs that know what they’re doing.
My point is that it's not a problem. I can take someone fresh out of bootcamp with a basic understanding of react components and css and get them churning out code that works on 3 platforms.
Good luck with that kind of project.
Thanks. I've had pretty good luck so far. I would not want to be managing 3x the team size with 3 different repos to build my crappy CRUD app.
Keep in mind that I'm not trying to do anything revolutionary here. I just work for a company that needs apps on the major platforms with the least effort and expense possible.
Keep in mind that I'm not trying to do anything revolutionary here. I just work for a company that needs apps on the major platforms with the least effort and expense possible.
[deleted]
Hiring good devs doesn't make JS less stupid, you have to recur to third party stuff like lodash and https://github.com/inspect-js to keep it tolerable.
Pretty similar experience here. The rate at which we've been able to get features out the door has doubled since we switch from native.
>Pragmatically, most apps are so bad that if your Android app has an iOS look-and-feel nobody seems to care.
Yes, but I not so sure if it works the other way round.
Yes, but I not so sure if it works the other way round.
Is there an impact on battery vs true native?
> they don't need to know any objc/swift/java/kotlin to build the product.
I have a hard time believing this, and I've been making apps on both platforms for >10 years. And I love react-native. My latest day job is basically forking popular react-native packages, often rewriting them in Swift, fixing numerous bugs, and adding features specific for our company.
And all this experience has taught me that in no way can you expect anything but the most basic, ugly CRUD app from a JS dev. I have tried many times to assign "just" the cross-platform code to a javascript person and it never works.
What do you do when there are native build errors? Xcode needs to be upgraded, or parts of your RN modules are deprecated? Gradle files need to be actively maintained. There are features and UI behaviors that are difficult to grok without some background on the individual platforms (e.g., push-notifications). There's also combinations of packages that can break your app- "react-native-sound" and "react-native-audio", the sound and microphone packages respectively, modify the same singleton on iOS. Adjusting settings in one breaks the behavior in the other! How could a JS dev possibly hope to solve something like that?
I have a hard time believing this, and I've been making apps on both platforms for >10 years. And I love react-native. My latest day job is basically forking popular react-native packages, often rewriting them in Swift, fixing numerous bugs, and adding features specific for our company.
And all this experience has taught me that in no way can you expect anything but the most basic, ugly CRUD app from a JS dev. I have tried many times to assign "just" the cross-platform code to a javascript person and it never works.
What do you do when there are native build errors? Xcode needs to be upgraded, or parts of your RN modules are deprecated? Gradle files need to be actively maintained. There are features and UI behaviors that are difficult to grok without some background on the individual platforms (e.g., push-notifications). There's also combinations of packages that can break your app- "react-native-sound" and "react-native-audio", the sound and microphone packages respectively, modify the same singleton on iOS. Adjusting settings in one breaks the behavior in the other! How could a JS dev possibly hope to solve something like that?
I've only had to dive into the native code a handful of times, but I do basically make an ugly CRUD app. Most apps are ugly CRUD apps though. I haven't used the Shopify app, but it probably falls into that category too.
> What do you do when there are native build errors?
I periodically do suffer through xcode upgrades, bad RN module linking, gradle issues, etc, but it's a couple of days of work every few months to say current. The JS devs don't really have to think about this stuff for the daily work. I think it's totally possible to get away with one person that knows how to do the hard technical stuff when it crops up.
That said, I don't build the most technically sophisticated product. The vast majority of changes we make are for design/marketing or for features that build on what we already have. I think that's true of most apps.
It's not for everything, and I'm glad Firefox (for example) does do native Android development. I couldn't imagine that working with React Native. But look at the apps on any random phone and the ones that couldn't be made in RN is pretty small.
> What do you do when there are native build errors?
I periodically do suffer through xcode upgrades, bad RN module linking, gradle issues, etc, but it's a couple of days of work every few months to say current. The JS devs don't really have to think about this stuff for the daily work. I think it's totally possible to get away with one person that knows how to do the hard technical stuff when it crops up.
That said, I don't build the most technically sophisticated product. The vast majority of changes we make are for design/marketing or for features that build on what we already have. I think that's true of most apps.
It's not for everything, and I'm glad Firefox (for example) does do native Android development. I couldn't imagine that working with React Native. But look at the apps on any random phone and the ones that couldn't be made in RN is pretty small.
Having one dev that knows something about the native side makes this very believable now. I haven't had the pleasure to work on a basic CRUD app that didn't also have some A/V or special file IO work. Your project sounds ideal for an exclusive react-native JS team.
> And all this experience has taught me that in no way can you expect anything but the most basic, ugly CRUD app from a JS dev.
> I've been making apps on both platforms for >10 years. And I love react-native
Doesn't this make you a JS dev too? Or how exactly do you define JS dev?
> I've been making apps on both platforms for >10 years. And I love react-native
Doesn't this make you a JS dev too? Or how exactly do you define JS dev?
"JS dev" is shorthand for "JS-only dev".
I made Android apps in Java and iOS apps in ObjC/Swift for many years. I still mostly write native code, but now I'm writing native code in various react-native packages.
I made Android apps in Java and iOS apps in ObjC/Swift for many years. I still mostly write native code, but now I'm writing native code in various react-native packages.
Maybe it's better phrased as "they don't ALL need to know..", as long as some of them know.
> with 3 developers
There is a fairly large chasm between a small team and a Shopify, AirBnB, or Udacity. These companies have dozens-if-not-hundreds of developers piling on complexity.
These companies don't necessarily feel the pain of building on somebody else's sand on day 1 or day 100, but on day 1000. This is what AirBnB and Udacity ultimately discovered.
There is a fairly large chasm between a small team and a Shopify, AirBnB, or Udacity. These companies have dozens-if-not-hundreds of developers piling on complexity.
These companies don't necessarily feel the pain of building on somebody else's sand on day 1 or day 100, but on day 1000. This is what AirBnB and Udacity ultimately discovered.
I'm sure Shopify has way more than 3 developers working on their mobile apps.
They can certainly afford to have separate teams doing web, iOS and Android development and optimize for each environment.
They can certainly afford to have separate teams doing web, iOS and Android development and optimize for each environment.
> No, it's not perfect. Yes, JS can be awkward and confusing. Yes, a truly native app built by expert platform-specific developers would be better.
This can't be understated. You can always tell when you've opened a React-Native (or similar "portable") app. It always feels like shit.
This can't be understated. You can always tell when you've opened a React-Native (or similar "portable") app. It always feels like shit.
> It always feels like shit.
Yeah, it does, to developers only. They're not the target market.
I used to lobby for my employer to care about the latest iOS feature or fight over what the HIG advises is best practice.
Unfortunately, most business would be perfectly happy if they could have a designer draw a pretty looking app and have it magically pop into existence. Platform features are an afterthought, if a thought at all. I'm not thrilled with the state of the app industry, but it is what it is.
The really elegant solution is to have a passionate team of platform-specific developers pushing the boundaries of what's possible on a mobile device, constantly using the latest features and profiling for battery usage and network usage. Ideally a team that does this would be so proud of the code that it becomes open source to serve as an exemplary model of software engineering actualized.
I know what's "right", but I also know what the market wants. The market wants me to churn out cross-platform CRUD apps as quickly and cheaply as possible.
Yeah, it does, to developers only. They're not the target market.
I used to lobby for my employer to care about the latest iOS feature or fight over what the HIG advises is best practice.
Unfortunately, most business would be perfectly happy if they could have a designer draw a pretty looking app and have it magically pop into existence. Platform features are an afterthought, if a thought at all. I'm not thrilled with the state of the app industry, but it is what it is.
The really elegant solution is to have a passionate team of platform-specific developers pushing the boundaries of what's possible on a mobile device, constantly using the latest features and profiling for battery usage and network usage. Ideally a team that does this would be so proud of the code that it becomes open source to serve as an exemplary model of software engineering actualized.
I know what's "right", but I also know what the market wants. The market wants me to churn out cross-platform CRUD apps as quickly and cheaply as possible.
[deleted]
I keep putting off learning React Native, largely because I don't really do a lot with JS anymore.
I know that there exists ClojureScript bindings to React-Native...does anyone here have any experience working with them?
I know that there exists ClojureScript bindings to React-Native...does anyone here have any experience working with them?
I wonder if Shopify did their homework and looked at Flutter. Flutter seems to meet their objectives more than React Native does.
And as an added bonus, Flutter is easier to reason about, has edit and continue, and is more performant.
Perhaps the use of Dart instead of Javascript was a deal killer though?
And as an added bonus, Flutter is easier to reason about, has edit and continue, and is more performant.
Perhaps the use of Dart instead of Javascript was a deal killer though?
They talk about looking at flutter in the article.
They use the word once to say “we did a deep dive”. It’s never mentioned again.
It would be pants-on-head insane for a company like Shopify to go all-in on Flutter. Is Flutter going to be around 10 years from now? Can Shopify support Flutter on their own if nobody else is using it 10 years from now? I don't mean that technically the license would allow them to, but can they in practice field the manpower and skills to do so across all the platforms they need.
I don’t know much about RN or Flutter; but why is it “insane” that flutter cant exist in 10 years but RN will still be king?
Why can’t RN die within 10 years? Because it’s been around since 2013 vs 2017? Because you like one more than the other?
I have concerns about Google’s commitment to Dart/Flutter, but I’m not sure one scenario is pants on head insane and the other just fact.
Why can’t RN die within 10 years? Because it’s been around since 2013 vs 2017? Because you like one more than the other?
I have concerns about Google’s commitment to Dart/Flutter, but I’m not sure one scenario is pants on head insane and the other just fact.
React Native could very well fall out of favor in the next 10 years, but the amount of companies using it today means there is a sufficient base to share the maintenance burden with, of which Shopify could potentially carry a large amount because of the significant overlap with the rest of their tech stack. If Google becomes disinterested in Dart, could Shopify step up and maintain it? Seems unlikely, and why on Earth would they want to, it's nowhere close to the rest of their competencies?
If for one technology you can extrapolate from today out to the next several years at least, and the other's path is effectively entirely opaque and at the whim of another party, it's a company-killer level risk to bet on the latter. Put it this way, if Google drops Dart/Flutter tomorrow, Google will be just fine as they have very little skin in the game so to speak. Technical reasons one way or another are completely overshadowed by the business risks, as the landscape is today (which will change over the years, but Shopify is making their decision today).
If for one technology you can extrapolate from today out to the next several years at least, and the other's path is effectively entirely opaque and at the whim of another party, it's a company-killer level risk to bet on the latter. Put it this way, if Google drops Dart/Flutter tomorrow, Google will be just fine as they have very little skin in the game so to speak. Technical reasons one way or another are completely overshadowed by the business risks, as the landscape is today (which will change over the years, but Shopify is making their decision today).
Not to be TOO snarky but... I'm sure there are a whole bunch of Angular 1.0 people who said the same thing.
I'm not convinced it's a worse idea to guess lottery numbers than to guess what will be successful languages. To that point however, React isn't a language (or a framework) it's a library.
I would say Google has more to lose by dropping Dart and Flutter as a language and frame work than Facebook has/had by dropping React.
I'm not convinced it's a worse idea to guess lottery numbers than to guess what will be successful languages. To that point however, React isn't a language (or a framework) it's a library.
I would say Google has more to lose by dropping Dart and Flutter as a language and frame work than Facebook has/had by dropping React.
I don't see how it's any crazier than publicly declaring React Native as their future like this.
With React Native, you're betting on a framework. With Flutter, you're betting on both a framework and a new language. Flutter also works on a much lower level than RN, which means it would be harder for them to pick up the development if the need should arise.
Dart is something very similar to Java, not much of a bet to jump into it. Moreover, it has type soundness, something Typescript cannot achieve.
I'm not so sure it would be easy to continue RN core development either. From what I see even just upgrading the JS engine from an ancient version was a major hassle for the core team.
In RN there's simply more moving parts. You work with 3 package managers at the same time, possibly even 3 languages. At least at this stage Flutter just seems overall more productive for the developer.
I'm not so sure it would be easy to continue RN core development either. From what I see even just upgrading the JS engine from an ancient version was a major hassle for the core team.
In RN there's simply more moving parts. You work with 3 package managers at the same time, possibly even 3 languages. At least at this stage Flutter just seems overall more productive for the developer.
Alibaba, Google, Tencent, Capitol One, Square, Baidu, New York Times, and many other large companies have projects on Flutter.
And that's not counting the small startups. There are countless ones of those too.
And that's not counting the small startups. There are countless ones of those too.
Strange that they didn't mention hiring as a reason, it's maybe even the main one. React is for the frontend what PHP was for backends in the 2000s, that's what most frontend devs know. Svelte would be a better fitting comparison to Rails in 2004.
Why do they begin justifying by talking about 70% of buyers using mobile? Completely off topic
Isn’t that them starting by declaring that mobile is really important to them so they didn’t take this choice lightly?
I thought the cool thing to do was declare React Native dead for your org, not the new hotness?!?
I try to re-evaluate my opinion of the mobile ecosystem monthly, and would love to know how people agree / disagree with my rankings:
1. Just make a web page
2. Native iOS & Android
3. Flutter
4. Some ordering of remaining cross-platform tools depending on requirements. (React Native, Vue Native, Xamarin, Ionic, Titanium, PhoneGap, Kony...)
I try to re-evaluate my opinion of the mobile ecosystem monthly, and would love to know how people agree / disagree with my rankings:
1. Just make a web page
2. Native iOS & Android
3. Flutter
4. Some ordering of remaining cross-platform tools depending on requirements. (React Native, Vue Native, Xamarin, Ionic, Titanium, PhoneGap, Kony...)
I have a different order:
1. Just make a web page (specially since many apps are just pretty CRUD ones)
1.1 For certain devices WebGL/WebAssembly can eventually also be an option
2. Native iOS & Android
3. Native iOS & Android with server side driven code for the business logic (maybe even UI layouts)
4. Native iOS & Android for the views with C++ for business logic
5. Your point .4 regarding cross-platform tools
I don't have high hopes for Flutter, with Chrome and Android teams also pushing for their own solutions, and its dependency on Dart.
1. Just make a web page (specially since many apps are just pretty CRUD ones)
1.1 For certain devices WebGL/WebAssembly can eventually also be an option
2. Native iOS & Android
3. Native iOS & Android with server side driven code for the business logic (maybe even UI layouts)
4. Native iOS & Android for the views with C++ for business logic
5. Your point .4 regarding cross-platform tools
I don't have high hopes for Flutter, with Chrome and Android teams also pushing for their own solutions, and its dependency on Dart.
Totally agree with your 3 and 4.
I've had, to my surprise, the most success with Flutter. (I've built multiple React web apps and spent way longer attempting React Native.)
I've had, to my surprise, the most success with Flutter. (I've built multiple React web apps and spent way longer attempting React Native.)
Really depends on what you’re making.
Personally, I find RN much more productive than native iOS, for the areas where it is applicable. The hot reload is quite magical.
Also, you can push JS updates without needing to update the app in the store, which is a huge plus.
Personally, I find RN much more productive than native iOS, for the areas where it is applicable. The hot reload is quite magical.
Also, you can push JS updates without needing to update the app in the store, which is a huge plus.
> I find RN much more productive than native iOS
Give SwiftUI a go, it's buggy right now but you can see the potential, I find Swift a far more productive language than Typescript. However, I agree the hot reloading and updates are a pretty big plus.
Give SwiftUI a go, it's buggy right now but you can see the potential, I find Swift a far more productive language than Typescript. However, I agree the hot reloading and updates are a pretty big plus.
> 1. Just make a web page
This is 100% reasonable for a lot of apps. I for instance uses the web version of Gmail on my phone without any issue, and Gmail is a complicated app.
Trade-off: not easily discoverable in the store of the platform, harder to test because of browser differences, might not be as fast as a native app from a UI perspective.
> 2. If your app involves persistant storage and functions that are not supported by web browsers, or you need optimal performance like games.
Great performances, easy to stick to UI styles for each platform, access to good quality tools for testing, no, leaky abstraction.
trade-off: unless you are using a language supported by all platforms (C/C++), duplicate codebase for business logic.
> 3. Flutter
I don't know flutter because I don't know Dart.
> 4. Some ordering of remaining cross-platform tools depending on requirements. (React Native, Vue Native, Xamarin, Ionic, Titanium, PhoneGap, Kony...)
Phonegap and Ionic apps are essentially webapps.
trade-off: for React Native likes: leaky abstractions which leads to issues when not knowing the underlying platform, the need to write "plugins" in the native language…
This is 100% reasonable for a lot of apps. I for instance uses the web version of Gmail on my phone without any issue, and Gmail is a complicated app.
Trade-off: not easily discoverable in the store of the platform, harder to test because of browser differences, might not be as fast as a native app from a UI perspective.
> 2. If your app involves persistant storage and functions that are not supported by web browsers, or you need optimal performance like games.
Great performances, easy to stick to UI styles for each platform, access to good quality tools for testing, no, leaky abstraction.
trade-off: unless you are using a language supported by all platforms (C/C++), duplicate codebase for business logic.
> 3. Flutter
I don't know flutter because I don't know Dart.
> 4. Some ordering of remaining cross-platform tools depending on requirements. (React Native, Vue Native, Xamarin, Ionic, Titanium, PhoneGap, Kony...)
Phonegap and Ionic apps are essentially webapps.
trade-off: for React Native likes: leaky abstractions which leads to issues when not knowing the underlying platform, the need to write "plugins" in the native language…
I don't know flutter because I don't know Dart.
I don't fully understand this opinion. Learning "new" things can be difficult, but there's little "new" in dart compared to other languages. Maybe you can elaborate?
Installing required tools, setting up a project, including debugger, is just damn easy (VSCode extension FTW). Also, any prior experience in mobile using Kotlin, Swift, or JS, translates well to Flutter and therefore Dart. Bonus knowledge bridge for people with MVVM experience due to first class async Streams API and third party RxDart (following ReactiveX spec).
I don't fully understand this opinion. Learning "new" things can be difficult, but there's little "new" in dart compared to other languages. Maybe you can elaborate?
Installing required tools, setting up a project, including debugger, is just damn easy (VSCode extension FTW). Also, any prior experience in mobile using Kotlin, Swift, or JS, translates well to Flutter and therefore Dart. Bonus knowledge bridge for people with MVVM experience due to first class async Streams API and third party RxDart (following ReactiveX spec).
who is using flutter for their product? something in the wild (production) that has a real user base?
Good luck, you'll need it
I am always wondering what the difference is between writing three differents targets, iOS, Android and Web using RN (even Flutter is a better choice imho).
Basically you want to share the business logic between them. You still need to spend time to write UIs for iOS and Android which following interaction paradigms of the platform.
Personally, I can't stand iOS apps that look like Android.
Currently, I am happily working on a project where I write all the business logic in Swift and share between the web app (WebAssembly) and the iOS and Android app. The only bit that I customise is the UI part. I quite enjoy this approach.
(I have to admit for me writing native mobile app in JavaScript/TypeScript feels wrong. Guess, I don't like that language enough)
Basically you want to share the business logic between them. You still need to spend time to write UIs for iOS and Android which following interaction paradigms of the platform.
Personally, I can't stand iOS apps that look like Android.
Currently, I am happily working on a project where I write all the business logic in Swift and share between the web app (WebAssembly) and the iOS and Android app. The only bit that I customise is the UI part. I quite enjoy this approach.
(I have to admit for me writing native mobile app in JavaScript/TypeScript feels wrong. Guess, I don't like that language enough)
Meanwhile Shopify's CEO. [1]
[1]https://mobile.twitter.com/tobi/status/1222551057798090752
[1]https://mobile.twitter.com/tobi/status/1222551057798090752
Oof, not classy. I think every developer has had the experience where you think you're so close to the finish, just one more thing... and then hours, days, weeks have gone by. How can he be so sure they're going to strike it big?
This is a pictographic sunk cost fallacy.
This is a pictographic sunk cost fallacy.
I read it as "they didn't continue long enough to get to the benefits, as we did", i.e, they already reached the diamonds.
We're moving away from react native at Papa. Too brittle, too cumborsome to iterate with, feels slow and every build required a prayer and small sacrifice to Cthulhu.
We're using Ionic 4 now with capacitor, the dev workflow is much better, literally testing on the browser with autoreloads when code changes. Couldn't be simpler. So far I like it a lot. We're using React so it's just like writing a SPA, only Ionic has a ton of UI elements out of the box like tab navigation.
We're using Ionic 4 now with capacitor, the dev workflow is much better, literally testing on the browser with autoreloads when code changes. Couldn't be simpler. So far I like it a lot. We're using React so it's just like writing a SPA, only Ionic has a ton of UI elements out of the box like tab navigation.
Good for you Shopify, but I fully expect you’ll switch to some new hotness in a year or two.
Why not ionic react? https://ionicframework.com/blog/announcing-ionic-react/
Subset of a subset would be the first reason I would come up with.
> Why not ionic react? https://ionicframework.com/blog/announcing-ionic-react/
React Native uses the Native Components of the platform for UI. Thus Native. Ionic React is basically a web app, this is Ionic with React instead of Angular.
So basically React Native == use native GUI components.
Ionic React = uses HTML/CSS in a webview embedded in a Native App, just like Phone Gap/ Cordova, Ionic is just a framework on top of HTML/CSS, React Native is not.
React Native uses the Native Components of the platform for UI. Thus Native. Ionic React is basically a web app, this is Ionic with React instead of Angular.
So basically React Native == use native GUI components.
Ionic React = uses HTML/CSS in a webview embedded in a Native App, just like Phone Gap/ Cordova, Ionic is just a framework on top of HTML/CSS, React Native is not.
Most react native apps have a custom UX but needs native plugin access.
This is the point of ionic react.
> Most react native apps have a custom UX but needs native plugin access. This is the point of ionic react.
No, most React Native apps use the Native platform UX, that's the point of using React Native. As for plugin access, well I don't see how Ionic React solves anything, since a plugin by definition needs to be developed in the native language of the platform (Java or Swift).
No, most React Native apps use the Native platform UX, that's the point of using React Native. As for plugin access, well I don't see how Ionic React solves anything, since a plugin by definition needs to be developed in the native language of the platform (Java or Swift).
Shopify should stick to making ecommerce sites and leave the mobile engineering evangelical space to those who's businesses are dependent on mobile and have the necessary experience.
In short, the future isn't React Native, unless you have a time machine that will allow you to go back and rewrite it.
In short, the future isn't React Native, unless you have a time machine that will allow you to go back and rewrite it.
So even though they develop apps that have millions of downloads or that businesses rely on for their in-store point of sales, you don't consider Shopify qualified to speak on mobile development?
No, I don't consider an established tech company with "millions of downloads that businesses rely on" choosing a webstack devkit for their mobile development serious.
All I can is, as a RN Developer, I love it. I love being able to use 1 language for both app platforms. The RN community is amazing. Many of the comments here talking about outdated packages were likely burned by RNs early days when it was <0.40. RN has come along way since then. Its been a while since I ran into an issue updating packages or couldn't find a lib for something I needed. There is also great resources when you want to handroll something yourself.
Migrating an existing native stack to RN might not be the answer, but anyone looking to get their startup off the group should consider RN. Its fast development and converting a React web dev is super easy.
Migrating an existing native stack to RN might not be the answer, but anyone looking to get their startup off the group should consider RN. Its fast development and converting a React web dev is super easy.
And I as a mobile native developer for both android and iOS on the other hand now know to skip talking with Shopify for future jobs as I hate RN and the performance hits and non standard UI it introduces. So we both win!
The sad thing is, all* their tier 1 mobile apps are still ios/android native and are not going to be rewritten, so they still need native devs. But after this blog post native devs will be a lot harder for them to find and hire.
* except for POS for Android which apparently has been rewritten, but not yet released, in RN.
* except for POS for Android which apparently has been rewritten, but not yet released, in RN.
I guess I'm old, but I can't believe that many people shop on their phones. You have limited screen space and your ability to input data efficiently is limited. It just seems like a really poor medium for researching a purchase. Guess I'm a dinosaur.
I shop on my phone, mostly Amazon. Probably not for serious/expensive purchases, but there's tons of things that don't qualify for that.
I buy a lot of kids' books, for example, I just look at the cover and description, read some reviews, and pull the trigger. Lots of little electronics too, like cables/adapters.
I buy a lot of kids' books, for example, I just look at the cover and description, read some reviews, and pull the trigger. Lots of little electronics too, like cables/adapters.
Many online marketplace give discount when you purchase via their mobile apps. Kinda make sense as they can harvest a lot more data from installed app (compared to web) and spam push notifications daily to drive up sales, so they push hard to make people shop from their mobile apps instead of desktop web store.
low quality of tooling in mobile has been a reality forever and the vendors are not only unwilling to change, they've doubled down on poo-flavored buildsystems that are impossible for the community to fix
this stuff is life or death, and also impossible without giving up on native:
> React Native on both iOS and Android and shares 95% of the same code
> less crashes on iOS than our native iOS app
> an Android version launched
> team composed of mobile + non-mobile developers.
(impossible on native because of the multi-day process required to build an ios app for the first time)
> The team also came up with this cool way to instantly test work-in-progress pull requests. You simply scan a QR code from an automated Github comment on your phone and the JavaScript bundle is updated in your app
code updating is illegal on the app store, but it's hard to kick out shopify. this is a shot across the bow
this stuff is life or death, and also impossible without giving up on native:
> React Native on both iOS and Android and shares 95% of the same code
> less crashes on iOS than our native iOS app
> an Android version launched
> team composed of mobile + non-mobile developers.
(impossible on native because of the multi-day process required to build an ios app for the first time)
> The team also came up with this cool way to instantly test work-in-progress pull requests. You simply scan a QR code from an automated Github comment on your phone and the JavaScript bundle is updated in your app
code updating is illegal on the app store, but it's hard to kick out shopify. this is a shot across the bow
>code updating is illegal on the app store
This is not true, the restriction is to “download, install, or execute code which introduces or changes features or functionality of the app.”
(And, of course, internal users & builds can do whatever they want.)
This is not true, the restriction is to “download, install, or execute code which introduces or changes features or functionality of the app.”
(And, of course, internal users & builds can do whatever they want.)
"(impossible on native because of the multi-day process required to build an ios app for the first time)"
What??? how is it multiple days to build an app for the first time? It takes minutes and if you are being pedantic by including App Store review it tends to be under 24 hours for new apps and under 6 hours for app updates now. Plus you can distribute to your own team instantly through TestFlight.
What??? how is it multiple days to build an app for the first time? It takes minutes and if you are being pedantic by including App Store review it tends to be under 24 hours for new apps and under 6 hours for app updates now. Plus you can distribute to your own team instantly through TestFlight.
installing the right version of xcode & getting required libraries -- my experience may have been particularly bad because of the ios 13 / swift 5.1 release, but the fact that these tool versions are linked to the xcode version is the root cause here
Devils Advocate:
Fiddling with React Native tooling on day 0 is just as terrible. I may argue it's worse.
Fiddling with React Native tooling on day 0 is just as terrible. I may argue it's worse.
<<
Flutter vs React Native: A detailed Comparison
1. Performance
Mapping down the performance is the best way to find the ideal framework for mobile app development. Flutter is ahead when it comes to performance among other frameworks is due to Dart. Dart code is compiled to native machine code. And also the JavaScript layer is helpful when integrating with native components and eliminates the JavaScript bridge.
React native offers exceptional performance for developers while developing an application in a native environment. But developers sometimes face issues while running the hybrid application architecture. On the other hand, Flutter allows developers to reuse the existing code. Flutter is in the leads in performance in comparison to React Native which uses JavaScript Bridge. >>
Source: https://dev.to/agiratech/flutter-vs-react-native-what-to-cho...
React native offers exceptional performance for developers while developing an application in a native environment. But developers sometimes face issues while running the hybrid application architecture. On the other hand, Flutter allows developers to reuse the existing code. Flutter is in the leads in performance in comparison to React Native which uses JavaScript Bridge. >>
Source: https://dev.to/agiratech/flutter-vs-react-native-what-to-cho...
I'm surprised no one is mentioning this:
"At the beginning of 2019, we did a 6-week experiment on our flagship Point of Sale (POS) app to see if it would be a good candidate for a rewrite in React Native. We learned a lot, including that our retail merchants expect almost 2x the responsiveness in our POS due to the muscle memory of using our app while also talking to customers.
In order to best serve our retail merchants and learn about React Native in a physical retail setting, we decided to build out the new POS natively for iOS and use React Native for Android."
So it's okay to build Android and less important apps using RN, but their flagship iOS POSS is off limits?
"At the beginning of 2019, we did a 6-week experiment on our flagship Point of Sale (POS) app to see if it would be a good candidate for a rewrite in React Native. We learned a lot, including that our retail merchants expect almost 2x the responsiveness in our POS due to the muscle memory of using our app while also talking to customers.
In order to best serve our retail merchants and learn about React Native in a physical retail setting, we decided to build out the new POS natively for iOS and use React Native for Android."
So it's okay to build Android and less important apps using RN, but their flagship iOS POSS is off limits?
That really just says it all doesn't it? It's basically an admission that the use of cross-platform frameworks is worse for customers/users, but they're going to ignore that to optimize for their own software engineering org.
you act like whatever something is right now is the same in the future. It's quite possible they see RN as the future for all products and easing there way into things. Maybe they are struggling to find Java/Kotlin devs and have a surplus of Swift devs. So no, that does not really just say it all.
> Maybe they are struggling to find Java/Kotlin devs and have a surplus of Swift devs.
Based on AirBnB's experience, now you need to find React Native devs in addition to Java devs.
Based on AirBnB's experience, now you need to find React Native devs in addition to Java devs.
I assume it's easier to find a handful of skilled Android developers rather than staffing an entire engineering org with them.
From my experience with RN, you do need to get into the native bits, but most of the development will be not native. So the number of skilled native device engineers required should be less.
From my experience with RN, you do need to get into the native bits, but most of the development will be not native. So the number of skilled native device engineers required should be less.
I can see, if you were a billion dollar company, how you’d have an Android infra team to bridge those performance-intensive items, with the UI team doing all their work in RN.
So you can’t be a startup/small shop if you want to do this well.
So you can’t be a startup/small shop if you want to do this well.
I think you’re touching on something extremely important here. IME, anecdotally, not backed up by data: experienced native Android devs are getting harder and harder to find.
The ones I’ve known personally hated it so much they moved to backend or full stack jobs.
The ones I’ve known personally hated it so much they moved to backend or full stack jobs.
Interesting, I always thought it would be harder to hire iOS devs since the initial cost is higher - you need to buy a more expensive Apple computer and pay an yearly $99 subscription just to get started.
For that reason I thought that there would be way more Android devs. After all, a teenager with a regular computer can start developing Android apps and download the APK in a cheap Android device without paying anything.
On the other hand you mentioned _experienced_ native Android devs, while my thought applies more to junior Android devs, and maybe the two things don't correlate as well as expected.
For that reason I thought that there would be way more Android devs. After all, a teenager with a regular computer can start developing Android apps and download the APK in a cheap Android device without paying anything.
On the other hand you mentioned _experienced_ native Android devs, while my thought applies more to junior Android devs, and maybe the two things don't correlate as well as expected.
you don't need a mac to build ios apps.
All this says to me is that they wanted to limit their risk exposure by doing an experiment on Android while maintaining native on iOS. Why is that hard to comprehend? Their move to RN this year should underscore the success of that experiment.
The thing is, you can rephrase:
> by doing an experiment on Android while maintaining native on iOS
as:
> by throwing their Android users under the bus
It may be a cynical take but it's not an invalid one to take when the thrust of the rest of the paragraph comes down to "the native app's performance is so good, we couldn't dream of changing it".
> by doing an experiment on Android while maintaining native on iOS
as:
> by throwing their Android users under the bus
It may be a cynical take but it's not an invalid one to take when the thrust of the rest of the paragraph comes down to "the native app's performance is so good, we couldn't dream of changing it".
I don't know if you read the article or not but the title is very clearly: "React Native is the Future of Mobile at Shopify". So the Android experiment was successful.
Also, ios is “easy” when it comes to doing react-native. So by doing the hard one first, they have a lot more confidence in the rest.
> Why is that hard to comprehend?
Probably because that's not what the article says.
Probably because that's not what the article says.
This is how I read it too. They can then run the RN app on iOS too (with some modifications I'm sure). Seems like a smart strategy. And that the jury is still out.
Right, but it doesn't really optimize for their engineering team either since the only reason to use something like React Native is the ability to do both platforms at once.
Is that not a tremendous optimization for the team? It probably cuts the team size in half (or, seen another way, doubles its size for free), and it unifies of a lot of the mobile and web stacks behind similar languages and tools, which in turn would allow some unification in the hiring and recruiting pipelines.
This overstates the gains by a lot.
1) Each platform still requires a good amount of special attention.
2) The React Native project introduces breaking changes far more frequently than the underlying platforms
3) Being an abstraction layer, eventually something will break, and you’ll still need someone who understands cryptic linker errors and platform specific quirks.
There are cases where it definitely makes sense, but the hidden costs need to be accounted for.
1) Each platform still requires a good amount of special attention.
2) The React Native project introduces breaking changes far more frequently than the underlying platforms
3) Being an abstraction layer, eventually something will break, and you’ll still need someone who understands cryptic linker errors and platform specific quirks.
There are cases where it definitely makes sense, but the hidden costs need to be accounted for.
I would argue to the contrary that it’s such a large optimization that even accounting for all of that it’s still a big net win from a staffing perspective. It’s far easier to maintain a few Android experts on staff than an entire department of them.
I understand that argument, and it's seductive, and in many cases probably true. But it's advertised as a 2-3x productivity gain and that is simply not the case.
Build RN app on Android, if it's successful then do a light port to iOS and decommission native team.
Seems like a fantastic experiment IMO.
Seems like a fantastic experiment IMO.
I dig it. Doubt they would decommission the native team tho, since all engineers can do RN. Whether they want to... that's a whole different matter.
It doesn't necessarily have to mean that. If performance is generally good enough, then the ability to do things like add critical features, patch bugs, and refine the app much faster is much higher value for the user and Shopify.
I was writing POS applications in the 90s. And ringing up customers needs speed and responsiveness. Windows was way too slow at the time, that's why POS applications even to this day often still work in character mode, or DOS-graphics.
PS I know it's becoming less and less of an issue these days, but you get my point.
PS I know it's becoming less and less of an issue these days, but you get my point.
Really depends on their priorities and customer base. We developed a react native android app and users seem to be happy with it. Would native be smoother? Maybe..
Why couldn't they help contribute to/optimize React Native to be faster?
Because the architecture is the primary source of the performance issues.
React Native is widely used by the many-billion-dollar company that originated it, so major performance opportunities are not likely to be low-hanging fruit at this point.
React Native is widely used by the many-billion-dollar company that originated it, so major performance opportunities are not likely to be low-hanging fruit at this point.
Someone I work with on react-native just sped up large text parsing by 40% or so.
There is a major re-architecture of React Native underway[1]. See Lorenzo Sciandra's excellent conference talk for an explanation of what the current limitations are in React Native and how they are planning on addressing them in the near future [2].
[1] https://github.com/react-native-community/discussions-and-pr... [2] https://www.youtube.com/watch?v=7gm0owyO8HU
[1] https://github.com/react-native-community/discussions-and-pr... [2] https://www.youtube.com/watch?v=7gm0owyO8HU
I just speed read though it, So basically Everything is changed? I am not even sure if that is like a re-architecture, it is more like a a rewrite, literally every apart of the stack, all the way to Javascript Engine. All aiming for 2020 release.
At least the whole stack have many large companies'vested interest in it now so it is unlikely RN will fade out anytime soon. Will be interesting to see how all these played out in 2021/2022.
At least the whole stack have many large companies'vested interest in it now so it is unlikely RN will fade out anytime soon. Will be interesting to see how all these played out in 2021/2022.
They will probably slowly introduce the changes one feature at a time in a backward-compatible way in a similar manner to how core react architectural changes are introduced (eg fiber, suspense, hooks etc).
Isn't the vast majority of their POS systems iOS based? The base iPad is rather fast. Why not just target your market directly and max out performance? Meanwhile the vast majority of their Android POS systems use what, lower end Kindles and such? They know they can't get perfect experience there but they don't want a bad one where it counts. They know their market.
React Native sounds like a mistimed bet now. Maybe 3-4 years ago, but at this time? There are a number of better alternatives.
I spent some time working on a RN project, and even though the whole idea of declarative interface, state update, etc is interesting, it is not exclusive of RN - and there is the whole rest of the story: RN libraries are a mess and usually buggy, there is virtually very little compatibility between native and web, and.. have anyone ever tried updating a RN codebase?
I remember we had to recreate the full project and copy the files manually because everything was broken beyond any hope, this after spending a full week trying to fix the build.
For Shopify seem that even a PWA could fit, and would be much more compatible, reliable, etc.
By the way, one of their justification is "in-house know-how", which I heard so many times before... This is usually how you justify crappy decisions by using inferior technology and then spending 2x the effort to try to fix it. I hope it doesn't happen with them, but it does like like that's the way they are heading to.
I spent some time working on a RN project, and even though the whole idea of declarative interface, state update, etc is interesting, it is not exclusive of RN - and there is the whole rest of the story: RN libraries are a mess and usually buggy, there is virtually very little compatibility between native and web, and.. have anyone ever tried updating a RN codebase?
I remember we had to recreate the full project and copy the files manually because everything was broken beyond any hope, this after spending a full week trying to fix the build.
For Shopify seem that even a PWA could fit, and would be much more compatible, reliable, etc.
By the way, one of their justification is "in-house know-how", which I heard so many times before... This is usually how you justify crappy decisions by using inferior technology and then spending 2x the effort to try to fix it. I hope it doesn't happen with them, but it does like like that's the way they are heading to.
It's interesting how differently you can look at things. I would consider the best time to start a React Native project to be sometime next year, and after 1.0 ideally.
It's exactly when you jump on the bleeding edge that you end up with cuts and bruises. For every new shiny thing you'll be trading your current known problems for a set of unknowns and the inability to even Google-search for the solution. Let the tinkerers do the bleeding, and only once they've buffed the sharp parts can you as a company like Shopify start to bet on it.
It seems module and library handling was just revamped in React Native (not a user myself yet, perhaps next year), so thank you for your sacrifice. Developers picking up RN today will hopefully have a smoother experience.
It's exactly when you jump on the bleeding edge that you end up with cuts and bruises. For every new shiny thing you'll be trading your current known problems for a set of unknowns and the inability to even Google-search for the solution. Let the tinkerers do the bleeding, and only once they've buffed the sharp parts can you as a company like Shopify start to bet on it.
It seems module and library handling was just revamped in React Native (not a user myself yet, perhaps next year), so thank you for your sacrifice. Developers picking up RN today will hopefully have a smoother experience.
I wonder if that mean Rails will be moving to React Native as well?
DHH [1] said they will reveal a major new technical direction for building web apps.
[1] https://twitter.com/dhh/status/1214962255785119744
DHH [1] said they will reveal a major new technical direction for building web apps.
[1] https://twitter.com/dhh/status/1214962255785119744
We did multiple experiments on server driven UI for our mobile apps.
1) Using native app - Sending layouts in JSON and using Flipkart Proteus library in Android to render them. This only enables appearance changes and not behaviors. So we really didn't server driven LOGIC.
2) Using Flutter - Wrote the wrappers for Flutter widgets. Those wrappers basically just converts JSON to Flutter widgets at run time. And also enabled actions to be server driven. The complete app was made server driven using this approach. The only problem is, too much of abstraction in the client made the code base very messy and hard to reason.
3) Using React native - The biggest selling point for using react native is, codepush feature. We didn't have to write dumb client wrappers which expects JSON from server. We can just write normal JS code and deliver it to client devices without making app update. This enables really rapid experimentation for product features. We are currently developing this.
1) Using native app - Sending layouts in JSON and using Flipkart Proteus library in Android to render them. This only enables appearance changes and not behaviors. So we really didn't server driven LOGIC.
2) Using Flutter - Wrote the wrappers for Flutter widgets. Those wrappers basically just converts JSON to Flutter widgets at run time. And also enabled actions to be server driven. The complete app was made server driven using this approach. The only problem is, too much of abstraction in the client made the code base very messy and hard to reason.
3) Using React native - The biggest selling point for using react native is, codepush feature. We didn't have to write dumb client wrappers which expects JSON from server. We can just write normal JS code and deliver it to client devices without making app update. This enables really rapid experimentation for product features. We are currently developing this.
The web and its ecosystem are huge. The browser is essentially the new OS and no matter how complex and quirky js, react and the rest of the tools are, we're gonna stick with them for a long time. Big technological advances like PWA's, WASM and rendering engines like servo and webrender are only gonna shorten the gap between native and web UI experiences. Look at what happened to the desktop. Native UI development became a niche and even apps like photoshop are now just websites(figma) or electron apps. This is eventually gonna happen to mobile development as well. There will be no need to create native apps for most cases and no need to use those centralized app stores to "install" apps on your device.
That being said the web is not quite there yet and that's why solutions like react-native and flutter exist. I don't believe that react-native is the future. Many people have explained in great detail why the idea and the execution behind RN are just flawed and why it makes development hard and complex. Heck, it doesn't even eliminate the need for native developers. React-native is just a transitional tech we'll use until the web and PWA's become good enough for 95% of the cases. The future of RN is the Web.
On the other hand, flutter and dart seem to solve all of the problems we have with UI development. It's an amazing tech that combines all the best ideas from QT, flash, java swing, delphi and react-redux in one project that is completely free and open source. It's what we've always dreamed existed in the UI world. The development experience is great and designers seem to love it as well. Despite its advantages, flutter is still a huge bet and i can't see a world where everybody writes in Dart.
If I had to make a guess, I'm still betting on the web in the long run and hope flutter captures a small market share among frustrated mobile/web devs and designers. I just can't see react-native anywhere in between.
That being said the web is not quite there yet and that's why solutions like react-native and flutter exist. I don't believe that react-native is the future. Many people have explained in great detail why the idea and the execution behind RN are just flawed and why it makes development hard and complex. Heck, it doesn't even eliminate the need for native developers. React-native is just a transitional tech we'll use until the web and PWA's become good enough for 95% of the cases. The future of RN is the Web.
On the other hand, flutter and dart seem to solve all of the problems we have with UI development. It's an amazing tech that combines all the best ideas from QT, flash, java swing, delphi and react-redux in one project that is completely free and open source. It's what we've always dreamed existed in the UI world. The development experience is great and designers seem to love it as well. Despite its advantages, flutter is still a huge bet and i can't see a world where everybody writes in Dart.
If I had to make a guess, I'm still betting on the web in the long run and hope flutter captures a small market share among frustrated mobile/web devs and designers. I just can't see react-native anywhere in between.
Why was the title changed? It differs from the original article's, which I believed was the guideline.
I’m really eager to hear how they deal with data in their RN apps. To me that’s always the place where the most complexity and bugs lay hidden.
This is amazing team for spotiteam and all users! Congrats!
> The first is a tooling team that helps with engineering setup, integration and deployment. The second is a foundations team that focuses on SDKs, code reuse and open source.
They have a whole team to set up tooling for React Native. I wasted many days trying to do this work on my own.
They also have a whole team for evaluating 3rd-party libraries that provide functionality missing from React Native, such as letting the user hide the keyboard on iOS. I wasted weeks on this and finally gave up on React Native and switched to Flutter.
I think React Native needs some attention from user-focused PMs and engineers before it is ready for adoption by small teams.
They have a whole team to set up tooling for React Native. I wasted many days trying to do this work on my own.
They also have a whole team for evaluating 3rd-party libraries that provide functionality missing from React Native, such as letting the user hide the keyboard on iOS. I wasted weeks on this and finally gave up on React Native and switched to Flutter.
I think React Native needs some attention from user-focused PMs and engineers before it is ready for adoption by small teams.
How has flutter compared?
Not OP, but I've tried all of the big SPA frameworks (not specifically react native though) and I decided to use flutter for a non-trivial side project and I don't ever want to touch the big SPA frameworks ever again. Flutter is also fast, pretty lightweight, and good on battery. It feels native on iOS and Android. I have little Android development experience (side project years ago) and no iOS experience.
It's easy to setup, install, and it just works. I develop on Windows and Mac with a .NET Core backend and communicating via GRPC. Deploying the backend to a CentOS server. No issues running anything on Windows, Mac, or Linux, surprisingly. Whenever I have to use node, everything randomly breaks when switching environments. (Maybe I'm just bad with node/webpack and all that, but there is way too much I have to know to just build something).
It's easy to setup, install, and it just works. I develop on Windows and Mac with a .NET Core backend and communicating via GRPC. Deploying the backend to a CentOS server. No issues running anything on Windows, Mac, or Linux, surprisingly. Whenever I have to use node, everything randomly breaks when switching environments. (Maybe I'm just bad with node/webpack and all that, but there is way too much I have to know to just build something).
I'm considering using Flutter (instead of Ionic which Ive been using for mobile up till now).
In terms of Node breaking when switch platforms - are you syncing the node_modules folder between machines somehow? Don't do that. Doing "npm install" will sometimes install binaries specific to a platform that won't work across them. Put node_modules in your.gitignore, and sync between machines using version control rather than something like Dropbox. I used to just put the whole project in Dropbox but ran into too any issues between Mac/Windows.
In terms of Node breaking when switch platforms - are you syncing the node_modules folder between machines somehow? Don't do that. Doing "npm install" will sometimes install binaries specific to a platform that won't work across them. Put node_modules in your.gitignore, and sync between machines using version control rather than something like Dropbox. I used to just put the whole project in Dropbox but ran into too any issues between Mac/Windows.
Yeah, I used git and ignored node_modules. Honestly, most of the problems are related to Windows. Whenever I try to use anything geared towards web dev, there are just more issues on Windows. Tons of dependencies that change all the time doesn't help. Most of the web dev industry is on Linux or Mac. It's not all related to Windows though. Just updating packages/frameworks is scary.
Setting up Jekyll was tough, even on WSL. I've opened issues on projects, and they would update the project to say that Windows is not supported (though IDK if node was the issue there). I bought a Macbook solely to deploy iOS apps, but it is way easier to develop anything related to web on it.
Again, this is coming from someone who doesn't do web dev full time, so I'd probably resolve issues faster if I did, but for my side projects, it's too much maintenance. I just want to be productive if I have an hour or so a day. Flutter lets me do that. I write code, code runs on Android and iOS. It's easy. No react/vue/angular, webpack, bootstrap, scss, typescript definition files, or other 'magic' to worry about.
Again, this is coming from someone who doesn't do web dev full time, so I'd probably resolve issues faster if I did, but for my side projects, it's too much maintenance. I just want to be productive if I have an hour or so a day. Flutter lets me do that. I write code, code runs on Android and iOS. It's easy. No react/vue/angular, webpack, bootstrap, scss, typescript definition files, or other 'magic' to worry about.
If you use "npm ci" instead of "npm install" there's even less chance of breakage.
I am satisfied with Flutter. My app is almost ready for beta testing:
https://www.cozydate.com
https://www.cozydate.com
We rewrote our entire mobile app in flutter (previously native android and iOS) for cronometer. It’s been a mostly great experience, and the worst issues have been worked out as the platform is rapidly maturing.
It emulates the UI, so the fake is noticeable, and it will be hard for them to maintain perfect 1:1.
RN on the other hand bridges the native UI w/ your code via a JS bridge. The downside is the bridge can be a bottleneck so you have to be careful how much you congest it. The result is being able to expose every native functionality and abstract it anyway you want using React extensions.
Flutter plans to target desktop and web, but RN is ready for this today.
Flutter requires you to learn Dart, a Google only language. RN you can use JS or TypeScript.
Are you really going to trust that Flutter & Dart are around tomorrow w/ Google's record? Why oh why would you build your project with something that risky.
RN on the other hand bridges the native UI w/ your code via a JS bridge. The downside is the bridge can be a bottleneck so you have to be careful how much you congest it. The result is being able to expose every native functionality and abstract it anyway you want using React extensions.
Flutter plans to target desktop and web, but RN is ready for this today.
Flutter requires you to learn Dart, a Google only language. RN you can use JS or TypeScript.
Are you really going to trust that Flutter & Dart are around tomorrow w/ Google's record? Why oh why would you build your project with something that risky.
Don't know why you're being downvoted. These all are perfectly reasonable concerns. I've seen many GUI frameworks fail because of a mix of these reasons.
Can you downvote in this website?
Either Google or someone else w/ a vengeance follows me around and downvotes me haha.
> It emulates the UI, so the fake is noticeable, and it will be hard for them to maintain perfect 1:1.
I don't think 'emulate' is the right word. It renders it's UI. I don't get 'how the fake is noticeable'. It might be a little bit different, but the average person won't pick it up.
To me, this is one of it's big upsides. It doesn't have to do all the translation to native. The performance is good. It's easy to write. No quirks of either OS. Though you do have to worry about the individual OS's if you're doing something lower level, but you have the power to do so, so that's still a plus.
I don't think 'emulate' is the right word. It renders it's UI. I don't get 'how the fake is noticeable'. It might be a little bit different, but the average person won't pick it up.
To me, this is one of it's big upsides. It doesn't have to do all the translation to native. The performance is good. It's easy to write. No quirks of either OS. Though you do have to worry about the individual OS's if you're doing something lower level, but you have the power to do so, so that's still a plus.
It renders a UI similar to the native UI by mimicking it, it emulates it. It meets every meaning of the word.
It's a different approach than RN, but in my opinion, it's flawed.
This isn't anything new in the desktop realm at least. QT vs wxWidgets. QT renders it's own UI, which is great if you are going for your own look, same with Flutter. wxWidgets and RN both shine by being able to wrap the native platform and bridge it.
Eventually your "good enough for the average person" implementation will be out-of-date, and you will always be worse than native, because it's "good enough". That's when you start getting into flaws of cross-platform.
With React Native, it's the exact same, not "good enough". You can wrap any native functionality, and you don't have to maintain copies of visuals and physics for each platform you want to fake.
Yes there are some compatibility issues that you have to address when you try to abstract them, but that will come up regardless of which framework you use.
Currently I'm working on a solution that resolves all of these RN issues across platforms.
P.S. users can tell, they just may not be able to point it out.
It's a different approach than RN, but in my opinion, it's flawed.
This isn't anything new in the desktop realm at least. QT vs wxWidgets. QT renders it's own UI, which is great if you are going for your own look, same with Flutter. wxWidgets and RN both shine by being able to wrap the native platform and bridge it.
Eventually your "good enough for the average person" implementation will be out-of-date, and you will always be worse than native, because it's "good enough". That's when you start getting into flaws of cross-platform.
With React Native, it's the exact same, not "good enough". You can wrap any native functionality, and you don't have to maintain copies of visuals and physics for each platform you want to fake.
Yes there are some compatibility issues that you have to address when you try to abstract them, but that will come up regardless of which framework you use.
Currently I'm working on a solution that resolves all of these RN issues across platforms.
P.S. users can tell, they just may not be able to point it out.
Emulate has another meaning in the technology world too though, so it might be confusing.
RN has to keep the bridge up to date with best practices/deprecation, etc... so that seems like a bigger risk if support was lost. Xamarin did the same and had it's fair share of issues. I'd rather use something with it's own rendering engine. Way less 'magic' that can break.
I don't like coding React/HTML/JS/CSS. It's way easier to write UIs in Flutter IMO. And honestly, I don't even like the aesthetic of native iOS either. I prefer material. I see why web devs would prefer RN though, so there's obviously a huge need for it.
RN has to keep the bridge up to date with best practices/deprecation, etc... so that seems like a bigger risk if support was lost. Xamarin did the same and had it's fair share of issues. I'd rather use something with it's own rendering engine. Way less 'magic' that can break.
I don't like coding React/HTML/JS/CSS. It's way easier to write UIs in Flutter IMO. And honestly, I don't even like the aesthetic of native iOS either. I prefer material. I see why web devs would prefer RN though, so there's obviously a huge need for it.
As a solo/indie developer I love React-Native. Attempting to develop for Android and iOS at the same time is absolutely daunting. Maybe someone out there can do it, but it was simply too much for my brain to handle. But with React-Native I don't have to worry about any of that. I just write code and it doesn't matter what device people happen to be using.
This is an interesting read and may be the full story, and a completely justified strategy.
But at the risk of sounding cynical, I'd be interested in any political motivations - if he's a new VP, it wouldn't have been unheard of for unnecessary swashbuckling Transformation Projects to be kicked off under the new regime for no obvious reason.
Complete conjecture, I have no inside knowledge, just have seen this happen time and time again.
But at the risk of sounding cynical, I'd be interested in any political motivations - if he's a new VP, it wouldn't have been unheard of for unnecessary swashbuckling Transformation Projects to be kicked off under the new regime for no obvious reason.
Complete conjecture, I have no inside knowledge, just have seen this happen time and time again.
It happens all the time. At a large corporate place I was working frontend at, our dpmt manager spent almost no time with the teams and all time concerned with outout metrics. When his boss looked to be retiring and the prospect came up to get his job, he started a new year by—seemingly with no knowledge of how things were working—by shuffling all the teams based on how he thought people should be organized. He then kicked off two or three major tight deadline high budget projects with those new teams, and proceeded to take a vacation. Needless to say there was a lot of turnover, I got terminated, projects failed, and he got his promotion somehow.
Yep. I'm more than a little sceptical these days when these big projects are announced - especially with new managers.
> As a contrast, none of the Top 10 most valuable Y Combinator companies use Java; largely considered the battle tested enterprise language.
I’m not sure what this is based on, but Airbnb uses Java pretty extensively.
I’m not sure what this is based on, but Airbnb uses Java pretty extensively.
I used to be a cross-platform framework skeptic (Disclaimer: I have written a LOT of cross-platform, low-level code over my career).
I am less of a skeptic, nowadays. I think that it makes good business sense for most connected apps. Also, the quality and stability of the frameworks has increased.
It really stinks to spend two years training your team on a framework, only to have said framework suddenly float to the top of the tank, belly-up. React seems to have settled in for a long stay. It's kicked its shoes off, and grabbed the remote.
That said, it won't affect me. I tend to write stuff that controls devices, so my code needs to be pretty "bare bones" native.
I am less of a skeptic, nowadays. I think that it makes good business sense for most connected apps. Also, the quality and stability of the frameworks has increased.
It really stinks to spend two years training your team on a framework, only to have said framework suddenly float to the top of the tank, belly-up. React seems to have settled in for a long stay. It's kicked its shoes off, and grabbed the remote.
That said, it won't affect me. I tend to write stuff that controls devices, so my code needs to be pretty "bare bones" native.
I'll just leave this here.
https://devrant.com/rants/320156/i-hate-react-js-with-a-fuck...
https://devrant.com/rants/320156/i-hate-react-js-with-a-fuck...
[deleted]
15 years in the industry has taught me to always have an exit strategy.
React is the cool thing now but it wont be in 5 years. Make sure you can decouple and reuse your APIs with whatever comes next.
And always remember that a native app will always give the best experience. Cross-platform tools aren't perfect and sometimes the cost of 'write once debug everywhere' is higher than 'write everywhere' especially if you suddenly need to do something niche.
React is the cool thing now but it wont be in 5 years. Make sure you can decouple and reuse your APIs with whatever comes next.
And always remember that a native app will always give the best experience. Cross-platform tools aren't perfect and sometimes the cost of 'write once debug everywhere' is higher than 'write everywhere' especially if you suddenly need to do something niche.
I don't know about that. React was the cool thing 5 years ago, and 5 years later it's still the cool thing judging by how many jobs are out there for React and React Native developers.
Shopify is associated with e-commerce shops. It would be much bigger news if this would be about an app for core e-commerce journeys, but Spotify builds Apps mostly for the merchants or in-store use cases where customers physically are already paying for a product. Performance matters less in such use cases as merchants or customers are already locked-in in the purchase flow and a drop out would be more costly for them (no sale). This is in no way comparable to AirBnb use cases.
The use cases they migrated to React Native are rather simple - a list of orders, which customers will choose to use in order to get the status of their order - the customer's need is very high and optimization here does not bring much business value (conversions). The POS use case is stronger due to the expected responsiveness that is required, though it can degrade slowly over time and will not be noticeable (boiling frog) like in phones.
The use cases they migrated to React Native are rather simple - a list of orders, which customers will choose to use in order to get the status of their order - the customer's need is very high and optimization here does not bring much business value (conversions). The POS use case is stronger due to the expected responsiveness that is required, though it can degrade slowly over time and will not be noticeable (boiling frog) like in phones.
So what? A customer facing e-commerce app is nothing but search, a list of results, filtering, a product page, photo gallery and checkout forms. RN has no trouble hitting full native performance all around (I’ve watched multiple apps built in this space).
Notification
Let's see directly couple UI front end to OS updates...yeah that will really speed up cross mobile platform development won't it?
Or one could decouple completely which is Flutter's main mission as a front end framework
Sounds like some CTO-type in over their head
Or one could decouple completely which is Flutter's main mission as a front end framework
Sounds like some CTO-type in over their head
Why emulate facebook’s app strategy? Their apps are a UX nightmare Accessibility is horrendous as is power draw.
There is really no technical reason why mobile can't be predominantly web-based now. Electron applications like vscode and figma show that you can make great software without any native code. Combine this with the fact that newer mobile phones are extremely fast, it just doesn't make any sense from a technical perspective why we need to use native all that often anymore.
I’m a bit bullish on ReactNative. Well on UI controlled by JavaScript that work a consistently across different platforms.
I acknowledge Flutter from Google is making rounds but Dart simply doesn’t have the ecosystem and reach that Javascript does.
Standard web html always seems to be quite laggy in mobile browsers. Basic things are quirky like the location bar is conditionally visible when scrolling up but not scrolling down. This changes the viewport.
Web rendering doesn’t seem to be as efficient and rich as native UI.
I acknowledge Flutter from Google is making rounds but Dart simply doesn’t have the ecosystem and reach that Javascript does.
Standard web html always seems to be quite laggy in mobile browsers. Basic things are quirky like the location bar is conditionally visible when scrolling up but not scrolling down. This changes the viewport.
Web rendering doesn’t seem to be as efficient and rich as native UI.
J'aime beaucoup l'application merci
Text has to be in a <Text>