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".
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.
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.
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.
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.
[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...
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.
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.
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.
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
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.)
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.
> 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.
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.
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.
> 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'.
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.
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.
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 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.
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.
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.
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.
> 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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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/
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.
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.
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.
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 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
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.
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.
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.
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:
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.
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.
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.
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.
>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).
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?
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.
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 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.
> 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).
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.
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.
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.
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.
"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.
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.
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.
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.
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.
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.
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..
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.
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.
> 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'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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
> 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.
> 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.
> 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.
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).
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.
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.
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.
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
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.
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.
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.
Readit News
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".
[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.
...and it's intentional. By having an app store, mobile OS distributors know that they have control over a massive revenue stream.
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.
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.
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.
Deleted Comment
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.
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.
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.
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.
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'.
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.
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.
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.
- 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.
They talk about the process of building it here: https://blog.twitter.com/engineering/en_us/topics/open-sourc...
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.
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.
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.
> 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.
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.
Web apps should really have the option to cache the page entirely for offline use.
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
e.g. https://developer.apple.com/documentation/authenticationserv...
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.
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.
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.
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.
The future is getting paid to make the app that actual is useful
Hmmm... What are these "ads"? Says the uBlock kid....
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)
- 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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'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
You need to pay the cut to Apple/Google but in certain scenarios it's preferable than asking for payment details.
Deleted Comment
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 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.
Deleted Comment
Speaking personally I like the division between highly sandboxed websites (no GPS access, no notifications, etc...) and trusted apps.
Maps is also much more responsive even on older phones than it is on a web page on a modern PC.
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....
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.
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).
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.
I would like all of my applications to be sandboxed by a browser I have control over.
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.
Dead Comment
Dead Comment
Dead Comment
"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?
Seems like a fantastic experiment IMO.
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.
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 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?
> 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.
> 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?
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.
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.
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 Comment
> JavaScript developers are cheap to hire
There’s your problem. Go hire JS devs that know what they’re doing.
They can certainly afford to have separate teams doing web, iOS and Android development and optimize for each environment.
Yes, but I not so sure if it works the other way round.
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.
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.
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.
Do you think they had to go on a hiring spree because they went back to native?
I'm skeptical there is a correlation.
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.
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.
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.
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.
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).
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.
https://www.cozydate.com
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.
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
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?"
Deleted Comment
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.
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.
Facebook engineering promised synchronous layout will come at some point, which will open the door to that.