Building all of our new mobile apps using React Native
engineering.shopify.com
engineering.shopify.com
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".
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.
iOS is native: https://twitter.com/SlackHQ/status/931599784137363459?s=20
Android is native, too (no source)
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.
They talk about the process of building it here: https://blog.twitter.com/engineering/en_us/topics/open-sourc...
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.
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....
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).
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).
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.
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.
When you know that the features you're interested in can be made easily available by a simple web app.
Sorry, it just seems unnecessarily negative to me.
Besides, I do find fancy pens cringey, but that's another story :)
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. 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.
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,...
So should we now measure who wins in arcane knowledge counts?
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.
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?
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?
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.
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.
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.
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.
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.
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.
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 would like all of my applications to be sandboxed by a browser I have control over.
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.
The important part is that they go through the app store, so that apple has complete control of what goes through.
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).
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).
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.
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.
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
Tangentially related, iOS mail app has a VIP setting.
Anytime I'm using a peice of small business software I'd probably like it to be able to give me notifications
(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.)
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.
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.
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.)
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 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.
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.
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?
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.
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 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.
Speaking personally I like the division between highly sandboxed websites (no GPS access, no notifications, etc...) and trusted apps.
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.
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.
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.
[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.
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%.
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.
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.
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.
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.
Also, you don’t have to buy a Mac. You could always pay Mac Mini Colo $80 a month and develop remotely.
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...
Yes.
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.
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.
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.
The current version of OS X runs on the 2012 Mac Mini. I see one on eBay for $145.
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?
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.
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'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.
But, a niche product where people aren’t willing to spend money is a business model problem.
But do you know how many businesses would die to be able to sell products that had a 70% gross profit margin?
The only fixed cost imposed by Apple is the $100 developer fee and whatever it cost to buy a Mac.
The services provided by the App Store would have to be present for the business exist at all.
So without the 30% Apple charges those businesses would certainly not survive unless they paid someone else for the services.
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.
Just maybe it’s a product market fit issue?
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.
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's so much money out there searching for an investment. It's a shame really.
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.
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’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.
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.
Not that the current situation is idyllic, but I fear a post-wasm web would be even more opaque and less inspectable.
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 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.
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.
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.
https://github.com/gopherjs/vecty
Like React but in Go. Not quite mature yet but getting there.
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.
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.
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.
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.
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.
I'm referring to the 2020 iPhone Pro and the Galaxy S20 both being rumored to have 120Hz displays, massive changes in the market.
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 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.
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...
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.
https://developer.mozilla.org/en-US/docs/Web/API/Service_Wor...
Maps is also much more responsive even on older phones than it is on a web page on a modern PC.
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.
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'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:
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....
You need to pay the cut to Apple/Google but in certain scenarios it's preferable than asking for payment details.
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.
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.
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.
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).
"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?
Based on AirBnB's experience, now you need to find React Native devs in addition to Java devs.
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.
So you can’t be a startup/small shop if you want to do this well.
The ones I’ve known personally hated it so much they moved to backend or full stack jobs.
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.
> 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".
Probably because that's not what the article says.
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.
Seems like a fantastic experiment IMO.
PS I know it's becoming less and less of an issue these days, but you get my 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.
[1] https://github.com/react-native-community/discussions-and-pr... [2] https://www.youtube.com/watch?v=7gm0owyO8HU
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.
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.
Or do they have the same issue?
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.
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.
OP is pretty much saying that.
> JavaScript developers are cheap to hire
There’s your problem. Go hire JS devs that know what they’re doing.
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.
Yes, but I not so sure if it works the other way round.
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?
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.
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.
They can certainly afford to have separate teams doing web, iOS and Android development and optimize for each environment.
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.
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.
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.
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.
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?
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.
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.
Of course, Facebook does benefit by owning that abstraction making it exactly what they need. For everyone else, the risk is a bit different.
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 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.
> 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.
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.
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 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.
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.
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.
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).
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.
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.
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.
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'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.
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.
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.
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?"
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
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.
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.
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 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 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...)
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.
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.)
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.
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.
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 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).
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...
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.
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?
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.
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).
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 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.
And that's not counting the small startups. There are countless ones of those too.
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 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.
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)
Text has to be in a <Text>
import {Text as View} from 'react-native';
All good!
https://cdn.shopify.com/s/files/1/0779/4361/files/React_Nati...
I’m not sure what this is based on, but Airbnb uses Java pretty extensively.
All the native frameworks are also React inspired.
I personally love the work done by Airbnb for its Android MvRx framework. Again, React inspired
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.
[1]https://mobile.twitter.com/tobi/status/1222551057798090752
This is a pictographic sunk cost fallacy.
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...
https://devrant.com/rants/320156/i-hate-react-js-with-a-fuck...
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.
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.
Seems like if you try to proclaim the future you end up eating your words
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.
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.
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.
The vast majority of the app is implemented natively.
[1] https://instagram-engineering.com/react-native-at-instagram-...
It's much less exciting, however, to say "React Native Is What's Next at Shopify".
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.
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
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 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?
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.
It's currently the best maintained successor to PhoneGap/Cordova.
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 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.)
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.
Fiddling with React Native tooling on day 0 is just as terrible. I may argue it's worse.
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.
* except for POS for Android which apparently has been rewritten, but not yet released, in RN.
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
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 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.
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.
Hopefully, React Native is not a nosedive ;)
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.
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.
As a C developer, man, Flutter looks pretty damn logical!
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.
With all of these platform abstractions you just need to understand the trade-offs they're making.
Flutter has its bugs but they're certainly not that fundamental issues.
A bug in React Native and fundamental issues in Flutter.
In short, the future isn't React Native, unless you have a time machine that will allow you to go back and rewrite it.
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.
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).
I know that there exists ClojureScript bindings to React-Native...does anyone here have any experience working with them?
DHH [1] said they will reveal a major new technical direction for building web apps.
Unbelievable, really. The previous paragraph literally mentions the importance of performance.
facepalm
gee what happens when Android Fuchsia hits oem devices this year? CES surprise coming..