React Native is not the future
blog.standardnotes.com
blog.standardnotes.com
Among Joplin, Obsidian, FS Notes, Bear and few more Standard Note was the worst experience by a margin. Not to mention they still not allowing local raw files citing “but encryption”, or maybe they’ve moved to another reason now.
Another example of how developers can become blissfully oblivious of what users find good and start confusing it for what is “good” for developers themselves.
>Our mobile app is just our web app
There are limitations that come with this philosophy and if the trade offs aren’t stated it usually means they’re not fully considered.
There are some UX decisions that I disagree with but I feel the underlying tech stack is solid (fast, looks good, feels native, etc)
The iOS Obsidian app doesn't feel native at all, the interface is high latency, syncing is slow and problematic, many plugins don't work, poor touch support and serious performance issues even on the new iPhone 14 Pro.
It feels like a cheap and nasty Electron / JS heavy web frame.
For sync though I can't comment as I use syncthing.
edit: Actually you're right, now that you've pointed it out I do notice slightly higher latency and animation hitches. Goes to show if you know that to look for you'll find the cracks!
I know I'm quite particular / sensitive to both interface latency and design, I'm aware I probably have higher standards than most people.
There are horrible slow or just badly built apps written with native stack as well.
Native is worthwhile for “appstore only” businesses. Mostly. For everyone else, a universal web app is the recommended path forward. Anyone who has a web app should absolutely avoid rewriting the same business logic three times over in native languages just for the appstores. It’s a nightmare to maintain and sync up three teams and codebases, not to mention also insanely expensive.
The future is pwa + webassembly + webview, and there’s no advantage of native over web whatsoever.
The future we should strive for is the best UX for the customer. That’s not achieved through a web stack.
What is it achieved through? Vendor locked, user and developer hostile native app stacks?
> The future we should strive for is the best UX for the customer.
And that’s web stack with access to system APIs.
Yes, there is Vendor-lock in, you can't deny that. I don't know what you mean with "user-hostile" and "developer hostile".
I - as user - personally ignore anything web based, if there is a native alternative, as I prefer apps that follow the HIG and use the native toolkit of the platform. Sure I'm just a single person, so this is anecdotal.
> And that’s web stack with access to system APIs.
No I fully disagree. A good UX is only doable, if you use native components and fully follow the HIG. I have not yet encountered a good webapp that is on par with a native app that does exactly this.
Anything web based is good for "one code base - available - but subpar - for many platforms", while native apps are "One code base - one platform, but a great experience" (Given you follow the HIG and use native components)
One extremely trivial example: I don't want to accidentally delete e.g. my files, just because some app thinks switching e.g. "Ok" and "Cancel" around is nice.
While yes, web apps have their uses, but they can't match good native apps even remotely.
Anything that locks you in is hostile to you as a consumer.
> I - as user - personally ignore anything web based, if there is a native alternative, as I prefer apps that follow the HIG and use the native toolkit of the platform.
Interface guidelines and toolkit are different matters. You can write native apps that don’t follow HIG and you can write web apps that follow it.
> No I fully disagree. A good UX is only doable, if you use native components and fully follow the HIG. I have not yet encountered a good webapp that is on par with a native app that does exactly this.
What is a good UX?
> Anything web based is good for "one code base - available - but subpar - for many platforms", while native apps are "One code base - one platform, but a great experience" (Given you follow the HIG and use native components)
If I write Apple only web that follows HIG like a bible and adheres to all standards, where does it put me?
> One extremely trivial example: I don't want to accidentally delete e.g. my files, just because some app thinks switching e.g. "Ok" and "Cancel" around is nice.
That’s platform guidelines. Nothing stops me from implementing them in web app or disregarding them in native apps.
> While yes, web apps have their uses, but they can't match good native apps even remotely.
Sure they can, and they do. You probably used them at some point but couldn’t even notice they were web.
You can't write a web app that properly follows a single OS's HIGs, much less multiple OSs'.
No you can't.
> we’re back to why vendor lock-in is bad.
Ah yes. There are some unknown theoretical HIGs that you can follow which don't exist and don't reflect the actual platforms that people, you know, actually use.
This has nothing to do with blindly parroting "vendor lock in bad". Because Apple's HIGs for a long time were light years ahead of anything else, and yes, I would expect a well-designed app to follow them on the Mac (anything from accent colors, secondary focus and humane modal dialogs to affordances, accessibility considerations etc.)
Whereas "sure you can" web implementing some bogus HIGs can't even do a modal dialog right.
Why and what you can't achieve from HIG?
> Ah yes. There are some unknown theoretical HIGs that you can follow which don't exist and don't reflect the actual platforms that people, you know, actually use.
Sorry?
> Because Apple's HIGs for a long time were light years ahead of anything else, and yes, I would expect a well-designed app to follow them on the Mac (anything from accent colors, secondary focus and humane modal dialogs to affordances, accessibility considerations etc.)
What does this have to do with native vs web argument? The topic is here what and what you can't achieve with both technologies.
> Whereas "sure you can" web implementing some bogus HIGs can't even do a modal dialog right.
???
I gave you examples, and you dismissed them because "vendor lock in is bad" and "I don't see what this has to do with native vs web".
> ???
There's no modal dialog on the web that conforms to any of the existing HIGs. And while you can implement one, the amount of effort is ridiculous. Compared to native.
And that goes for almost literally everything. For example, there's a reason 99.9999% of the thousands of dropdown re-implementations fail even the simplest of accessibility checks.
IMO it's only "developer hostile" for developers who don't want to have to learn a new OS and languages. This sounds like someone with years of Angular experience who doesn't want to learn React because it'll make all the tricks they've learned getting Angular to behave obsolete. As far as being "user hostile" I've got no idea why that's in there... unless they're just throwing things against the wall to see if they stick, and if that's their intent they picked the wrong forum to do it in.
This take is outright wrong. Non-native/webview-based apps are only a tolerable option if your goal is to maximize the number of platforms you cover with the same code base and skeleton crew dev team, at the expense of forcing users to endure subpar user experiences.
Unless you really exercise system API, I don’t want to hear about your CRUD needing native app to “provide best native experience”.
Plenty of services are simply "good enough" as a web page. I don't need a permanent icon on my phone from the local pizzeria for the once every 3 months I order for pickup. How can you make my experience better with an app? Invent different and weird new checkboxes for the order selection process, or just hope they can poll for tracking data that wouldn't exist inside a browser session?
Apps are also a terrible fragmentation for "transient" interactions where you're starting with a search or other activity, and incidentally brush across the content, rather than starting with a full "I'm going to use an app" mindset. Suddenly the UI changes and flow is broken. (see: any time you search for something and click a Reddit result)
Clubhouse (a native app) said the same thing years ago and ended up becoming irrelevant and its features were absorbed and overtaken by Discord (a React Native app) with its Stage Channels feature, all before Clubhouse could build it's Android app.
By the time Clubhouse released its Android app, their lunch was already eaten and it was too late. It turns out that, after recently looking at their latest app build they are slowly integrating React Native in their app.
This sounds like a quiet way of them admitting that they should have used React Native in the first place for both iOS and Android to release quicker had they done that as I said before. [0]
I know that other people had different experiences, and that my experience is not universal. But I am probably not alone in that experience either.
Yup. They did try to sell to Twitter [0] but that collapsed and Twitter already implemented Clubhouses features using Periscope's infrastructure which I said this before [1] the reports of their acquisition talks happened such as [0] and [2].
So due to Twitter already owning and using Periscope, the avenue for Clubhouse to sell to Twitter already made no sense.
[0] https://www.bloomberg.com/news/articles/2021-04-07/twitter-i...
[1] https://news.ycombinator.com/item?id=26273255
[2] https://screenrant.com/twitter-clubhouse-purchase-buy-talks-...
I’m not convinced their choice of technology was their downfall. On the contrary, maybe it was what allowed them to launch at the right time with the right experience and have a meteoric rise. Building it with the alternative might’ve meant obscurity from the start. Timing and luck are major influences in an app’s success.
I am not sure how the app is unusable for you. I use Standard Notes on my iPhone without any problems.
First you must imagine. Imagine that his device is not your device. Imagine that it is slower. Imagine it is slow enough to pass his threshold of unusable.
I've attributed this to the increased number of notes, but after reading the article, I'm starting to think it might be because of the programming decisions, at least partially
There is, if the only tangible alternative to building a native app is not building a mobile app at all.
Every application deals with some amount of sluggishness. Performance is not a mobile app only problem, it's not a new thing and it's not entirely clear, when it's going to be a big problem and when people will be okay with it.
With all the strides being made, the future is almost certainly not going to be 3 code bases for 90% of simple CRUD apps, because while the problem of maintaining a lot of code is not getting better for developers, the js glue layer so many people long for most certainly is, and rapidly.
So we're just throwing our hands up now and saying it's inevitable that a a notes app is just going to be slow? (In 2023!)
We are lost.
"Thou hast strayed far from the path of the Avatar. Seek now to renew a life of Virtue, lest thy soul pass finally beyond my reach!"
One would be to stop the Apple/Google hostage situation, improve pwa performance and make web apps first class citizens on Mobile (the web apis to make this happen already we exist). Another one is a better translation layer. Right now the second option seems to be winning out.
Asking devs to suck it up and continue down the triple code base insanity for mostly just reasonable feature parity is not one.
PWAs also don't solve the root problem of having to deal with different platforms. Many choose to imagine that Chrome is the only browser that matters, but that's far from true. Like native apps, PWAs are hostages to the platform they run on – browser makers.
I suppose that on mobile they also don't use web technologies
What we noticed is that we’d incur substantial performance bottleneck for anything that needs to move data to/from native because of the number of encode/decode steps and “bridge hops”. For example to read a row from SQLite, count the bridge hops:
Webview JS -> Java: postMessage to read a row from SQLite
Java -> React Native JS: hey, a postMessage happened, what to do?
React Native JS -> Java: please select * from … where …
Java -> C: ok really run this SQL
Then the stack of conversions repeats on the way back to the webview:
SQL C -> Java -> RN JavaScript -> Java -> Webview JavaScript
The other thing that plagued us performance wise was boot-up speed. At the time (before Hermes JS VM for React Native), we’d have to wait for RN’s JS to boot, figure out our cache status, then boot the webview JS. And then the webview JS would do the bridge dance above to pull data from SQLite to render. Slow - 40 seconds on low end Android slow.
Today we are still mostly a web app, but our wrapper is pure native code. We cold start to a native view and boot the web app in the background. Our throughout & latency to native APIs is substantially faster without the extra bridge hops into and out of the RN JavaScript VM. We managed the original architecture swap from RN -> true native wrapper with a team of three - myself, our first iOS engineer, and our first Android engineer. We do have a large mobile team now though.
There’s some more FAQs and answers about this on Twitter here: https://twitter.com/jitl/status/1530326516013342723?s=46&t=x...
One thing I’d add is that deciding to use a webview wrapper is quite common for multiplatform rich text content editors. Google Docs, Dropbox Paper, Quip, Coda, Notion all use this architecture on iOS and Android because implementing an editor is extremely complex. It’s much more expensive to implement an editor 3x than say implementing a few list views and a form 3x.
Does this mean you boot the web app in a native WebView in the background (not visible), while showing a [splash?] screen until the web-app sends a signal from the web-view to java (or swift?) that it's ready?
Or have you started to build out native-views too? eg. Splash screen, some other super top level screens, etc?
Yeah, that's what the RN codebase did, and for our initial switch over to native, we did the same thing there too.
These days we launch into a native "Home tab" view that lists all the pages in the workspace, as well as recently edited pages. Our philosophy is to progressively convert views to native, working from the outside in towards the editor. Soon we'll be launching a beta for native-ifying another of our top-level tabs.
My experience wasn't good before the introduction of the native home tab - I experienced high loading times right on opening the app and degraded usability - which made me quit from that page most of the time. Opening a page from the home tab now still has delay associated and the transition is not yet seamless (for me - I get a blank screen and then the page starts to load). But the home tab helps significantly improve the overall experience as the initial wait time is no longer present. Like mentioned the experience is improving - and I'm looking forward to the beta with more native interfaces!
A while back I was working on a notes app, tying to go the single codebase route with Capacitor. The biggest problem I found was with the text selection cursor on iOS. It sits on a layer above all other elements and even appears outside of scrolling overflow, so it would appear over toolbars, really nasty UX. Did you come up against that? As far as I could tell the only solutions were to have a native UI and only use with webview for the editor (that immediately meant writing the UI twice), or create a custom carrot and selection indicator (nasty!).
I'm interested in WASM+SQLite+OPFS. We currently use native SQLite on iOS, Android, as well as in our Electron app for macOS and Windows. WASM+SQLite+OPFS means we can use the same SQLite schema + caching code in the browser that we use on those other platforms, which would align web more with our native apps. We won't go the other way, and try to replace native SQLite with WASM+SQLite+OPFS on iOS or Android, because we have native code on those platforms that also talks to the same DB; on those platforms we've also moved some sync logic from webview into native land so we can sync in the background when the webview may be paused or destroyed. We want to be more native, not more web.
We might consider replacing the native SQLite in Electron with WASM+SQLite+OPFS if the performance looks good, since we don't have any Electron-side code that interacts with the DB.
> The biggest problem I found was with the text selection cursor on iOS. It sits on a layer above all other elements and even appears outside of scrolling overflow, so it would appear over toolbars, really nasty UX. Did you come up against that?
This only occurs inside an `overflow: scroll` container; it doesn't happen if the body itself scrolls. Here's a possibly-related Webkit bug (opened in 2014): https://bugs.webkit.org/show_bug.cgi?id=138201
That means you can overcome with some clever structuring/styling of the DOM, which is how Dropbox Paper for mobile works IIRC. We also found a different work-around in 2018 but it costs too much performance. So, we still have this issue in Notion because our DOM is too tricky to rework to solve this mostly-unimportant issue.
> create a custom carrot and selection indicator (nasty!).
Google Docs does this and it sucks and feels super janky. None of the nice editing gestures work nicely in Docs. Instead of smoothly moving the cursor around via the long-touch -> trackpad gesture, the cursor jumps around in Docs. I'd rather have some weird render issue with the caret drawing over a toolbar at very specific scroll positions, than force my users to use a jank re-implementation of the native selection UX.
Yes, I found the "overflow: auto" issue with WebKit, unfortunately even scrolling the whole page doesn't solve the cursor above a "position: fixed" toolbar... hopefully one day Safari on iOS will catch up!
I think your way of doing things would provide a better experience for users and I'm not sure what value RN is adding here.
That said I am not a JS or mobile dev so I might be missing something obvious.
An issue we had trying to do that was that we still ended up writing a bunch of platform-specific native code, but instead of doing so in a straight-forward way, we had to fork or vendor abandoned/broken libraries and write React Native flavored native code, then integrate that library into the RN app. If it had an issue, you have a lot more to mentally untangle to debug problems.
Edit: Plus macOS' WKWebView has a different implementation on its own.
Where did you get that impression? Do you have a source?
A WebView may or may not be great for text editing, but it'd definitely be overkill for simple text input. The first iPhone was severely resource constrained, I can't imagine it had the luxury of using a WebView for each and every text input.
Of course, it was not the current multiprocess WKWebView, which requires more resources, and not the legacy UIWebView directly, more likely some of its internals.
That's truly surprising! I stand corrected.
To quote two of the tweets:
> Web browsing on the iPhone was always on the feature list, so WebKit would be there, and the editing code came along with it. We needed to decide how other styled text would work, like in Notes. Should we bring over the AppKit text system?
> Eventually, we decided not to. We were so pressed for memory that fitting two styled text systems was judged too much, so I used WebKit to back UITextField and UITextView. I’m pretty sure it stayed that way until iOS 7.
Amazing stuff which React + Electron + React Native enabled - abstracting JS from Web to App - is so much crooked by folks trying to turn it inside out
React Native is not the future – for folks who don't understand how to use it. In fact they hate using it wrong. For me – it's the future, i can use only one language to create an Android, iOS, Windows, Linux and Mac native apps. (of course, i would never try to fit it into a single front-end codebase, this is pure madness)
If its a single app for multiple platforms, and you are sharing code and views, why wouldnt you fit it in a single codebase? Surely to do otherwise would be unnecessarily complicated?
This is exactly what react native does. It uses native components (there is a cross-platform abstraction, or you can use the platform-specific components directly) and you implement the design guidelines in platform specific files: https://reactnative.dev/docs/platform-specific-code
> but not the views themselves
Without the views, why would it be in react native? React is for building the UI...
> Having one mega-app seems more of a complication to me.
single codebase != mega-app. There is no "mega-app" as the compiler only uses the code for the target platform. You can even target specific architectures and/or devices as it uses the native sdks behind the scenes.
Can you explain in more detail how you’d style a Heading element, block level image element, and a Quote element within the same editable TextInput? The important UX feature is that the user should be able to start a text selection in a Heading, and end the selection in the Quote, so when they press delete, the image is removed and the quote is merged into the heading.
1. Most useful resource for creating this feature would be official TextInput doc [1], no need for googling.
2. Unlike Web, it is possible to nest <Text> elements inside <TextInput>, which is what you need to use for styling your blocks.
3. So finally, you will need your Rich State, and you need a Parser function, which will translate this Rich State into a collection of <Text> elements representing your blocks.
There is a lot of nuance still, say, Image elements cant be nested directly into TextInput, so you need to generate a spacer Text block where you will host your image. Also it requires some bits of excellence to work out the selection and caret logic correctly, but overall – it's not that big of a task, I would do it in few days
- Native editor for IOS - Native editor for Android - Native editor for Web - Electron/Native desktop, etc...
These editor can share code via a clean architecture inspired state plugin hyerachy that's swappable (i.e, a shared provider that swap out state and data routing per platform). Then with metro or esbuild you can selectively prune the code branch. The UI can be done in RN-web if lazy or straight up native code. It doesn't matter at this level.
Then, anyone who wanted to clone Notion can consume this component in their RN app. However, this is against Notion interest atm afaik, since Notion must keeps its advantage (make it harder for people to clone Notion). I'd argue it will try to shutdown such an initiative until it found a better way to have an edge on these competitor (or maybe shift to a new market)
I don’t know how we could possibly shut this initiative down, but I guess I should try!
For us to build such a project without backing it with a webview would probably take an order of magnitude more engineers working on the editor than we have today.
I don't think Notion need to worry about FB. I think Notion might need to be worried about the potential market saturation caused by how easy it will be for a small team of 3 to clone Notion (and all of its integration, API, and so on) on all platform perfectly in a weekends. At that point, it's not the technology bottleneck anymore but more so a battle over branding and minor UX improvement.
My point is that users don't care if just showing a website in a WebView is misused technology. They want an app regardless and telling them "a website is a website" is futile.
And let’s not even think about those cases when a feature is written with not all the platforms in mind. I once had to fix a bug where a developer did not have access to an iOS simulator to test their pull request… so they had merged it in without support for iOS.
> developer did not have access to an iOS simulator to test their pull request
This is clearly a company's fault, just get him iPhone and Mac if he delivers mobile apps LOL
* and you really don't need much, unleast you need to implement a working WebRTC protocol from scratch, haha
too many people don't realize just how non-portable react code can be.
My previous company had probably well over a dozen web engineers and then for our mobile side we had a total of 3, myself included. We also often had to adapt designs ourselves and work with product to fix flows for native. But we still managed to keep up with web.
edit: and not "keep up with web" in the we are working 80 hour weeks type thing, very normal working hours, 9-5. Possibly more normal than the web team.
So in a lot of cases having just 1 engineer per each mobile platform would be enough. And if you spend say 3 years building backend + web frontent, it would take about 6 months for each to replicate user facing experience on mobile. With current average global quality engineering cost of 70k/year, this means it only costs about $70k total to ship both mobile apps.
There are many ways to do it less efficiently, but this is my personal experience (as a CEO, EM and also iOS engineer in different setups) and it's really achievable.
Sure, there are a couple of annoyances mostly related to notifications and how it works when switching between apps, but these are quite minor parts of the app - sure, they're annoying and need to be fixed but it's also important to acknowledge that the other 99% of the app was running correctly and with decent performance on my mid range phone. I think that the remaining issues, including perform, are fixable and will be fixed over the next few years.
You might not write one fully unified code base but you'll at least be able to use 99.9% of the same code with just a little bit of glue on top to make user accounts and notifications work on other platforms.
If you care about UX, you should make native apps.
They're trying to make a useful app for humans, not trying to win the HackerNews Award for Excellence in UX. If accepting a little unfixable edge case jank makes their goal way easier to attain, they're going to end up with a much better app overall
This problem has been solved many times over the last decade or so. So claiming that _this_ is the future and not the more established (and smooth!) solution has to be supported by at least some evidence.
We should however be clear about our trade offs and not pretend that web apps can replace native apps.
We don’t need to pretend. Web apps must and already did replace a whole class of apps that never should’ve been native to start with.
For example: why would you even need native app for HN?
I could imagine a nice native app for Hacker News, too
Don't get me wrong, wikipedia website is also brilliant: fast and reaponsive. The app is simply adjusted to the platform it's on, including all the mobile interactions you've come to expect. For example, there's no hover on mobile. In the app I can tap-hold a link and see the preview that you see on hover on Wikipedia's site.
I’d hate to use a web app for maps, notes, document writing, IDE, messaging, etc. I always prefer a good native app to a good website.
Nothing says “I don’t give a crap about our users or the user experience” like building a web app or using a cross-platform toolkit. It telegraphs you mainly care about doing it as cheap as you can instead of just building a good app.
The only way to build a decent mobile UX is by making an actual native app.
My experience with XP tools is that if you build anything but the most trivial of apps you keep running into issues where you have to do platform specific workarounds. Eventually it becomes an unmaintainable mess of exceptions and workarounds.
In the long run it’s faster and easier to just build a native app for each platform. That way you can provide the native UX a user of each platform expects without compromise.
What a better world we'd have if Apple and Google agreed upon a common UI toolkit baseline.
I'd rather a small, scrappy company spend their limited resources on solving their core competency and value prop than fitting to these two stupid and needlessly different platforms.
Web should have won. It still has a good chance. We should have a "native web" in the future: WASM, hardware renderer access, device control, and more. That'll be the target to develop for.
Building for Apple and Android is a total waste of annual human cognitive resources. I hope every company starts doing cross-platform.
the web has won for a lot, but the companies that want to own their ecosystem, and have learnt from their past mistakes. Mobile is a fresh start, and they specifically made it so that web is a 2nd class citizen.
The fact that platform owners such as apple (or indeed any of them, not just singling out apple) did not make it first class is evidence that they prefer to own the platform rather than operate an open platform.
Microsoft, with windows, did not understand this at the time when they had huge advantage with win32, and thus did not lock down the windows platform. You see them trying now, with windows app stores (which i'm glad is not succeeding).
apple has more foresight, and decided to lockdown their app ecosystem. They deliberately removed flash as a form of application delivery, because they know that it can be good (if only adobe could pull their shit together).
The fact that the web still can remain, and that people still use it, is testament that even for a system being hindered, it provides enough value. Unfortunately, it just cannot complete against platform owners who would preferentially make their own native platforms better than web.
I remember this well, as I was already developing with Cocoa on Mac OS X and was pretty disappointed in the beginning when there was no SDK for iOS.
https://en.wikipedia.org/wiki/IOS_SDK#History
https://9to5mac.com/2011/10/21/jobs-original-vision-for-the-...
> The App Store came later and apparently as a reaction to jailbreakers and developer backlash.
Which doesn’t have any source.
> because web apps sucked so much
Where did you get this?
However I think while web apps can be „good enough“ [1] for many business applications (i.e. basically data entry and reporting), they weren’t good enough for what consumers wanted.
[1] I mean people still accept suffering from stuff like SAP
That is definitely not why they removed it. All the reasons Jobs listed against Flash were 100% true and a year later Android followed suit.
At the same time, Palm decided to redo their own OS and they went all-in on the web stack. They even called it WebOS. Palm were a well known name with momentum and talented staff, but WebOS was a failure partly due to poor performance.
You’re talking about UI part, which hasn’t been a problem on mobile for a good 10 years.
And what is the core competency?
- yet another syncing backend in 2023?
- figuring out another encryption?
- writing yet another web app in the guise of a mobile app?
- writing a notes app that locks the content and doesn’t even let you have raw files on your computer in easily readable format?
This is just absurd reasoning.
But React Native is an actual native app. It is entirely compiled down to native code for your respective platform. I agree that the "hybrid" approaches of days gone by (Ionic, Cordova, Phonegap, et. al) were a terrible mess. But there is fundamentally no reason why RN cannot be equally performant to Swift/Kotlin based apps.
Has this changed recently? It’s been my understanding that react native has corresponding native components for many UI elements and uses them. But your react logic is still executing as JavaScript.
Yes, but this is no different than how native works. On iOS, The JS Bridge compiles to bytecode and talks to the Obj-C runtime for native needs like Cocoa, just as Swift does.
Sure you could get better performance by writing your apps directly in Obj-C, but I don't think many people want to go back to those days.
Some definitions:
- The Obj-C runtime is just a shared library that Swift links to on compilation (/usr/lib/libobjc.A.dylib). The performance to call into it is identical for Swift and Obj-C.
- "Sure you could get better performance by writing your apps directly in Obj-C..." Swift code is native code. Cost to access the runtime is identical.
- There is one "hop" to go from Swift to the Obj-C runtime.
- There are >2 "hops" to go through the JS Bridge. https://hackernoon.com/understanding-react-native-bridge-con...
HN is better without personal attacks and insults.
It could be extended to pretty much anything: "I'm insulting your clothes, not you".
Calling something that a person says, or writes "asinine" is inflammatory. If I were to call your defense of it "naive, brain dead and utterly absurd" are you sure you wouldn't interpret that as a personal attack?
Yes, inflammatory. But personal, no.
> If I were to call your defense of it "naive, brain dead and utterly absurd" are you sure you wouldn't interpret that as a personal attack?
Correct, because it's not personal. That would be attacking the quality of the argument, not me, although it would certainly be inflammatory. I certainly wouldn't take it well — but for a totally different reason than you originally specified.
"Personal" and "inflammatory" are two different things.
Web won’t beat native on mobile phones, I’m sorry this argument has been had every single year it’s just absurd we keep arguing about it.
RN is implemented due to developer productivity at the cost of user experience. Which is fine more power to you, but understand that it doesn’t imply better UX.
The barriers to creating apps is also getting smaller (SwiftUI & Jetpack Compose).
Source: Multiple years working on Core Apple systems at Apple and also multiple years at Google
Honestly, it won't beat anything anywhere, but people do keep on trying to make it work.
RN doesn't "compile" the Javascript to bytecode or machine code. Instead, the closest competition you could get from RN is a JIT. But AFAIK iOS doesn't allow a Javascript JIT to run, so the JavaScript running is not being JITed to Bytecode.
Even if you assume that iOS allows a JS JIT now, you still have a JavaScript->Native bridge to cross. This adds a performance hit that Objective-C does not have.
> just
?
> The only way to build a decent mobile UX is by making an actual native app.
And that’s the problem.
More recently I worked on a team that wrote a lot of business logic in C++ to share across android and iOS. We ended up compiling it to WASM and we were able to build a web interface pretty quickly. A lot of languages are trying to make this easier. Kotlin standing out to me as an easy learning curve and prioritizing this. Challenge there is not using Java platform specific libraries on the shared stuff.
I do think there is something to be said for sharing pieces of the UI too.
I think the future looks bright for multi platform development. There is still some work to be done but it’s all heading in the right direction in my opinion.
I think you’ll have iOS, Android and Web specific code mixed with multi platform pieces. Both business logic and UI.
At the same time web views for YouTube would probably suck.
So many situations and so many options… again I’m very optimistic about the direction things are goin.
That’s only the case because YouTube sucks to start with.
For example, part of the post here is "When web-land wants to access the device keychain, it sends a message to native-land, and native-land responds with a primitive value. Neither native-land or web-land ever have to think about "messages" though. They're just function calls. Web-land has no idea that its function calls are being converted to postMessage calls behind the scenes."
That is very similar to Microsoft COM, DCOM and COM+, which all appeared at the points when Microsoft had to cope with levels of complexity similar to those in the browser and mobile platform diversity observe todday.
ref: https://en.wikipedia.org/wiki/Distributed_Component_Object_M...
Another great option seems to be Flutter web. I was really impressed by the "batteries included" approach to Flutter, and Dart has a pretty comprehensive standard library. This is in contrast to React's "just find a random package on npm and pray it doesn't bite you in the future."
Obviously rewrites are expensive, but I personally think both approaches are worth considering versus abandoning native components completely. WebView isn't without problems (and also, you don't need React Native to use WebView).
The only thing that's really a pain is that react dev tools has a harder time dealing with RNW components, and debugging in general can be a bit of a pain.
Any concise/clear resource or guide you used?
Perf seems totally within reasonable bounds for a react app, no issues so far.
In terms of resources or guides, it's pretty spotty out there. The project has definitely slowed down in terms of dev and i'm not sure where things like react 18 fit into the picture across platform, but we've setup our own config that works just fine for now.
We may need to reappraise in 2-3 years if react does change architecturally too much.
It's completely painless with Expo. With the tradeoff being you are locked into the Expo compatible ecosystem. Incredible devX if you go all in on it though.
I was considering using RN for a cross platform app and for some reason got the impression (earned or not) that Expo was for beginners, and people who have "non trivial" apps will have to "eject" (as it's called in Expo) sooner or later. So I was going to avoid it.
The reason people "eject" is primarily to add 3rd party native modules for functionality not available in expokit, or to optimize build size by removing unused expokit functionality. This isnt neccessary in the vast majority of cases as you can use Expo App Services to do this (locally, or remotely if you dont have mobile sdks installed)
And you still get the other benefits of expo - e.g. "batteries included" api, OTA app updates, not having to install the mobile SDKs, etc.
whats the type of functionality not available?
You then use 3rd party modules (or build your own) to add/extend native functionality that is exposed to react native. For example, webtrc: https://github.com/react-native-webrtc/react-native-webrtc
To be precise, EAS Build does actually eject IIRC, but you never notice this during development. I haven't ejected or seen an android/ or ios/ directory in the past year of developing an Expo app, using many third party libs.
It gets harder if you want to retrofit it to an older app using older third party libraries that have no or limited support. You have to pick through everything to work out what's playing up.
Imitating native components seems both incredibly wasteful and also very fragile considering Google has an attention span comparable to a puppy.
Google what? Chrome org? Flutter org? Android org? Myriad of other orgs?
I get that it’s inconvenient/expensive for you to build three UI layers. But that’s the only way to do this well. This was true for cross-platform apps in 1989 and it remains true decades later.
Not sure how much of that is necessary. I mean, a button doesn't "look native", so what? It's a button.
Apps written to require network requests to resolve a navigation are much worse than JavaScript handling a user event.
> And say you manage to get close to emulating a native app on one platform — when the OS UI updates, you’ll be behind again.
Not really the goal. You have this backwards. Keeping up with OS churn is one of the reasons to use an abstraction like this. It doesn't break your app nearly as much. The browser is a much more stable target than native mobile APIs.
> I get that it’s inconvenient/expensive for you to build three UI layer. But that’s the only way to do this well.
Inconvenient is dramatically understating the case. 3x spend is flat out impossible for many places.
Is it? Native buttons also come with things like affordances, accessibility, recognizability.
"So what" is what lead Google to spend money on user research involving hundreds of people to figure out that text boxes looking like text boxes is good, actually.
And web views come with things like scaling, accessibility, page/document search. The recognizability and discoverability is up to the designer. Between the two, I miss browser features a lot more than native look and feel.
Then let's not forget the privacy nightmare that mobile apps have been.
I can also often fix poorly built web with some css or other hacks that I cannot do on mobile for poorly built apps. I helped a user do just that the other day, if it had been native he would not have been able to work around the design issue.
The native bias here is crazy. Most users just don't care and can't tell if they are on something that's native vs a web view. What they care about is, does this provide me value? That's real UX. Not blowing out development budgets on duplicating the same features on 3 platforms. You can spend that potential budget on refining and improving the features.
Does it matter sometimes? Yes! The are limits to what you can reasonably do in a web view. But most of the time a web view works fine.
They can. You just don't know how to listen. "It's slow to open", "it's janky", "it stutters when it scrolls", "I tap/click and nothing happens" etc.
Does this happen with native apps? You betcha. It is significantly more prevalent with web because web has never been and never will be an app platform. It's core is to display text and images, and it can barely manage that.
I've worked on many mobile products. This has been true of none of them. Please provide some evidence of otherwise?
> Does this happen with native apps? You betcha.
Something I agree with. It is the indian and not the arrow. I've seen native, multiple cross platform apps of different flavors, and web views. All of the major problems were due to institutional shortcomings. If our app is bad, it isn't a tooling problem it's because we fail to execute.
> It is significantly more prevalent with web because web has never been and never will be an app platform.
Ummm... I sell web apps. Many major vendors have products that are, at heart, web apps. Progressive web apps, web apps, electron, phone gap, Cordova, capacitor, etc. I find this observation a demonstration of your ignorance of this market.
As a user I've seen and used this crap. My understanding of the market is much better than yours, it seems, because I approach it as a user. And yeah, you definitely don't listen to the users.
I've yet to see a single [1] web app that didn't have the shortcomings I partly listed. I've seen this crap in banking apps, ride sharing apps, hotel apps, calendar apps, travel apps, ride and car sharing apps... The list is endless. Every time there's web, there's deficiencies: long loading times, bad scrolling, elements out of bounds, bad touch and tap targets, abysmal animations, layout shifts, you name it.
[1] This is a slight exaggeration. I vaguely remember a couple when I went "hmmm... it's a webview, but nicely implemented"
Declaring that you always know best. When you are asked for evidence your only cited evidence is yourself. That your personal experience is representative of the primary needs of entire markets of users. And that you know better than what transpired between myself and hundreds of users. You seem to be remarkably arrogant.
This isn't productive, I'm done.
Good day.
Software is expensive. People resent high rate subscriptions as it is. Including on here. They resent it a lot more than lack of native toolkit. Ironically, price resistance on mobile is at legendary levels.
But so many can't seem to escape the gravity pull of dev strategies that blow up budgets like multiple code bases, micro service backends, etc etc.
Very very few of my customers actually want a Ferrari with the accompanying price tag. They want stuff that is convenient and works, the car is less important than the destination I can take them to. They don't really care about the last 5% percentile UI flexibility that is a native toolkit.
From what sparse commentary I could find online, looks like this is a middle ground between web dev and native dev. It allows reusing server logic to emit html markup for mobile UI, but requires platform developers to put in the necessary native pieces piecemeal (sensible choice considering the leaky abstractions in react native).
https://play.google.com/store/apps/details?id=com.basecamp.h...
I don't know about the wrapper, but the entire app being a webview is how Peapod (grocery delivery) has been for years.
For me I use React to create User interface for all platforms then ship it as a mobile app using native webviews on Android and iOS, also I can use Electron to create a desktop version. Good thing is that these webviews offer Javascript Interfaces where you can access all native functionality you need.
With a little bit of craftiness you can make your React Code (User interface) detect whether it runs on web version, mobile version or desktop version then make it behave according to what you want.
I choose React for UI coz it's damn simple though you can use any other javascript based UI library.
BTW, I just tried this app on Android, it is broken, it is simply showing white blank screen. And on macOS, and it asks $90 a year for basic markdown features. Just no.
And then, there is this.
https://standardnotes.com/principles#negativity
https://standardnotes.com/longevity
We are complexity bigots. We don’t merely hate complexity in software—we detest it.
In the end, it seems to me like a low effort, money making enterprise with some sprinkles and wishful thinking.
The differences in text editing experiences between platforms abound. The boundaries the cursor moves to for different inputs; e.g. are spaces skipped when moving word by word; are they only skipped at the start, at the end, or does the algorithm change depending on the direction of cursor travel. How selection changes from character-based to word-based if it starts with a double-click. How the scroll position changes based on cursor movement, selection extension drag, and so on.
Do you support multiple selection of text? Windows' built-in text box does, if you hold Ctrl down, you can select multiple discontiguous text ranges and delete, cut or copy them.
Cursor navigation isn't trivial. In word-wrapped text, a single location in the text can be represented by a cursor at the start of wrapped a line or the end. Do you go with what Emacs calls goal column (i.e. when cursor passes through short lines and needs to move backwards, does it "remember" where it was when you cursor through to a long line again)? Or does it gradually work its way back to column 0. And of course for variable-width fonts, targeting needs computing in pixels, not characters.
It's extremely rare for games to include a fully featured text editing experience. In the old days, you'd consider yourself lucky to get a navigable cursor over fixed-width text. Even today, where games take text input, it's frequently a simple one-line text box with just a navigable cursor and no selection.
Games also take a big shortcut on performance: a game loop is always running, always presenting frames ideally at the refresh rate. An editor can't afford that, it consumes too much energy. So now you need to worry about dirty regions and damage control, efficiently filling in areas revealed by scrolling and edits, taking care that letters may extend beyond naive bounding boxes, whether due to ligatures, kerning, anti-aliasing, and so on.
That’s literally what Flutter is.
In our case, our users had little say in their respective organizations’ decisions to buy our product, and “good enough” was still better than what our competitors were offering anyway.
We spent a lot of time of time debugging native layer issues, and WebGL bugs that would crash the webview (vector maps using the ArcGIS JS SDK) so it’s not a magic bullet in those respects either.
There are certainly use cases for it but also many downsides, it's mainly just hard to get the UI right.
edit: would like to clarify that of course I would recommend better ways... but... clients do as clients do.
With low interest rates companies will not be able to justify paying 3x to maintain 3 different apps when they could theoretically just pay 1x for one app that works everywhere
The reality though is it doesn’t work well. The tooling, performance, debugging, library stability and observability are all substantially worse. Your team might save a ton of time spinning up a React Native app, but lose it all right back once you keep hitting gnarly Android performance issues.
In the future, once we have a proper cross platform development kit officially supported by Android and Apple, code sharing will be great. But today it doesn’t exist. And that’s why none of (the good) apps you use are written in a cross platform way.
Any examples of simple and complex apps?
Complete separate toolkit with its own patterns and semantics. I’d rather use one then learn two.
Android works fine when built from source with no Play Store at all, using F-Droid as the primary store.
I suspect that Apple/Google will never let this happen due to 30% tax they steal from devs.
If you want to deliver the best applications, there is one answer - native.
If you want to deliver the best application given a small team or other constraints like time, then you have a plethora of hybrid options at your disposal (react native, flutter, etc.)
But at the end of the day the fact remains that almost every app written in a hybrid framework, would be better, smoother, and less of a frustration at scale, than hybrid.
Resources depend on the context and business model and that might not be under the control of the developer.
Resources may also be variable over time, e.g when the funny money runs out. In the post and comments you see the anxiety about having to support diverse codebases.
Thinking longer term you also need to address how platforms and stacks and the application requirements might evolve over a few years. You dont want to compromise your future options. This is even more critical for open source projects.
Further, it is not even a binary choice as there are multiple types of "native" and "hybrid" per platform. E.g. on android you could have pure java, or some variable amount of kotlin (or even qt/c++, depending on your definition of native) and desktop is much worse.
The bottom line is that its much more of a gamble than might have been in the past.
I see this being a trend in the coming years
It's all about trade-offs; you decided to trade better performance and native look&feel for faster/easier development. Perfectly reasonable, but for others that are making different trade-offs React Native totally is the future.
I think RN is a great middle-ground where you get native looking&feeling UX, but still get to share 95%+ of the code across platforms.
As an author of a few quite large React Native apps I have to disagree. There's a few key ones and apart from that it's down to maturity. Immature developers will always reach for whatever crutch they can find first. Doesn't matter what language.
The same immaturity shows up in their attempt to recreate (a not so great) wheel with their Phonegap/Cordova clone.
I would seriously be embarrassed about an article like this if it was my business.
I understand using RN for an MVP when you have no money. But many times I feel like the issues described are organizational rather than technical.
https://learndelphi.org/kiskis-the-crazy-social-network-for-...
There are countless active platforms and other walled gardens that offer actually great tools and do just what you want them to do but the thing is, non of it is yours! You are not making something for yourself, you are working to enrich the Zuck who can turn on you at any moment, from a benevolent friend to a brain eating zombie overnight.
Take youtube, its still a great product but it's nothing like the fantastic thing it started out as. Yours may one day go from a popular channel or from quality content to being not advertiser friendly. You've invested countless hours only to be discarded with various motivations. You helped build these digital prisons, no faith can be cruel enough.
Who cares that web is slower than native. People with slow phones should buy a faster one. If they cant afford to they have no money for you either. We pretend phones are not fast enough to do anything?? They are insanely fast compared to desktops from not to long ago. The only reason they are slow is that you've piled to much crap onto them, crap that shouldn't be there.
I suggest we stop executing tasks and just pile them up, gradually execute them little bits at a time. Don't let anyone else manage this for you! Others will think their stuff takes priority over the user trying to input text. If I'm inputting text I honest to god want all other processes suspended until I'm done. Perhaps if I'm not typing for 20 seconds, gazing at the input area, perhaps you can send me a push notification. Its still heretical interference with the writing process. Apps are slow because the user just isn't important anymore.
To do a silly analogy: Some people get stuck in a monologue, say after 2 beers. Others may find themselves unable to get a word in. The problem is not that they are not talking fast enough.
> Our new mobile app still uses React Native, but is literally just 1 component: a function that renders a webview.
This is an accurate observation. I notice the same thing. It doesn't help that there are N Android versions and M iOS versions as well
I’ve never believed the hype of code once run everywhere. All solutions have drawbacks you just have to pick one.
https://ionic.io/blog/ionic-vs-react-native-performance-comp...
I recently went through the process of switching to a web stack from a native iOS stack when it came time to support Android with one of my apps (https://getradiant.app/) and my biggest concern was making it feel a near as possible to the native app it was replacing and having it perform as well as possible on older Android devices. It turned out quite well and I’ve never had a user complain about the transition.
The trick to my mind was to treat web dev like mobile dev. Focus on bundle size, load speed and fluidity within the confines of a mobile environment. Constantly compare what you’re building to a native app. Probably focus on SPA over SSR/MPAs. And remember, if you apply all of the above to much less restrictive desktop browser environment with a much higher performance ceiling, the experience is going to be pretty good.
TLDR; think small, think fast and start with the most constrained environment you’re targeting, usually mobile, usually older Android. If you understand the limitations and considerations of browser engines when taking into account the above, the rest will follow and you’re going to have a good time.
though I wouldn't describe it as abandoning RN, because I use react-native-web inside that webview.
rn-web provides certain features that are crucial for a native feel on mobile, like better coordination of touches within scrollviews.
This is one reason I created Conveyor (https://hydraulic.software/) - if you go this route without it then you'll hit the painful desktop distribution process. With Conveyor it's no harder than publishing a static webapp, and you can avoid the desktop app stores with their various rules and rakes.
The big reveal is that React Native is still their future.
TLDR: Their app continues to use React Native, but they've given up on using it to provide a native user experience, and instead just use it to access OS APIs.
Vanilla html and js?
Standard notes has no reason to exist because Apple Notes and Google Keep already fill that niche better, and they actually know how to code, contrarily to these buffons.
The thing is that its easy to get 90% there with these things. But getting that last 10% is often a huge hurdle, erasing most of the efficiency gains you just made.
Then, when a new hot framework comes along, the old hottness you bet your project on quickly becomes deprecated, and you have to rewrite your whole project under duress.
I tried the new hotness recently - Kotlin Multiplatform. Sharing code was great, debugging sort of worked but not really, and it wasn't long before I was pen pals with an overseas developer - no documentation on the bleeding edge! Ive been developing iOS for 10 years and my all-native workflow never relied on the mercy of a kind Bulgarian...
How long before people give up on that and move on to the next thing?
Hiring is really tough as well. With cross platform, at the end of the day, when you get that crazy memory issue or app crash, you need native expertise. So to be an effective cross platform engineer, you have to be an expert in iOS, Android, and whatever hot framework you bet on.
If you need to get to market very quickly and are OK with throwing it all away in a few years, cross platform is a great choice. But if you want your app to stand the test of time, the best thing you can do is to write it in the only framework which is officially supported by the platform - all native.
On desktop nobody does it any more, not even big companies. Everyone just uses Electron or something similar. It's a worse experience for the user but it's not bad enough to be a major barrier to adoption in most cases.
On mobile I guess only two platforms is not quite as bad so more people cope with it?
One thing I don't quite get is why giant companies with zillions of dollars of recurring revenue just keep using Electron (other than the obvious reason that it's there and it works already), when they could massively improve the user experience & make themselves significantly less vulnerable to competition by building native applications.
I mean, I get that making native applications is really hard, and trying to keep feature parity between version is a huge challenge (indeed, the the point of TFA). But it's obviously possible & some large organisations do it despite the difficulty (indeed, even some open source projects run by volunteers have it figured out).
I think about this every time I use Slack & feel the janky horribleness every time I click around the interface and have to deal with all the latency of waiting for it to update. I get that average users might not notice this but anyone who grew up with native applications surely can "feel" it and despair.
Couple that with the fact that web devs are much easier to recruit than devs for any native platform and it's easy to see why they don't bother with native.
The real choice is (1) be single-platform (Mac only, Windows only, etc) or (2) use a cross-platform UI with Electron being the easiest to adopt.
Beyond the regrettable (but hard to avoid) baseline memory usage, startup time, and bundle size, at the end of the day it’s just a browser. Native code might be faster than JS on benchmarks but at the level of clicking a button to perform an action, there’s no technical reason that the latency should be any different, certainly not at the level of 100s of milliseconds. It’s just slow UI code at that point. I daresay the bigger problem is the huge prevalence of slow UI code.
It reminds me of this article on why NetNewsWire (a native Mac RSS reader) is fast - turns out it takes a lot of work beyond just being native! (and a bunch of these strategies have analogs in the JS world too) https://inessential.com/2020/05/18/why_netnewswire_is_fast
Web apps get a bad rap, and justifiably so.
But the blame frequently lies with the bloated frameworks developers choose to use. Developers choose these frameworks because web development is pretty complex.
When done properly, light-weight responsive web apps can be smooth as butter and an amazing user experience.
I do think that it requires a higher degree of technical expertise and more development effort to achieve this on the web vs native, though.
In some cases, depending on the business model and audience, it's worth it.
Tack onto that experience however many NPM packages the average React app imports, maybe some hastily written synchronous calls that play fast and loose with your main thread, and it's not difficult to see why Electron and web apps in general get a bad wrap. It's not unavoidable, it's just lazy practices.
React, for instance, is famously the opposite of bloated ("it's just the V in MVC") and leaves it up to the user to shape it how they like. I think the trouble is that it's not really fast by default. You end up needing to be pretty careful to avoid excessive rendering, which in practice means thinking about referential equality a lot, and trying to make sure renders only happen when you mean them to. React can be plenty fast though, with care.
I think Svelte does a better job of being fast by default, and part of that is because it's more truly "reactive". Change a variable, and that specific part of the page is updated; if other variables depend on that one, then those parts are re-rendered too. It needs a lot less babysitting to avoid extra CPU cycles.
I've thought about this a bunch because I'm building a video editor with Svelte and Tauri. (Tauri is a Rust-based alternative to Electron that uses the system webview instead of Chromium). Of the things I'd expect to be hampered by being web-based, "video editor" is pretty high on that list! But I've yet to run into a performance problem that came down to the browser being just too slow. It has so far been something under my control, whether that's needing to optimize some canvas drawing, or finding the most efficient way to get video frames on the screen, or minimizing the messages I'm sending between Rust and the UI.
There are certainly inefficiencies that wouldn't be a problem with a native app, but it's been possible to work around them so far. And as the sole developer on the project, it's nice to be able to serve a larger market without having to keep 2 code bases in sync.
Super lightweight, blazing fast, and straightforward to develop with. Class property setters that call render() are the reactivity.
In some cases it does take more time to reason about lifecycle and rendering than the equivalent react component, though.
The promise around much of these frameworks is that any dev with web experience can handle these and become a cross-platform generalist. Faster and less expensive to find more/backfill developers and, most of the time, it won't cost anything in lost sales.
// tangential rant follows
The experience suffers but when you look at the tech landscape as a whole, there is little to no native application niche that is presenting an opportunity. Quite the other way, the prevailing trend is that everything is bring brought down to the limits of the OS's webview components. You even see this in, what used to be, pure native applications like office. One of the latest changes they're doing is replacing the room finder with one backed by a webview2 control. It sucks and is a lot less capable from the native version, but it is following the same path being charted by our industry.
Xamarin (MAUI now) is pretty decent and there are good apps out there (Bitwarden for example).
I honestly can't count the number of times I've been down this road - Alfresco, Hazelcast, Sencha Touch, a bunch of others I can't remember right now. People skills become very important.