There is no better way to build a mobile app than a native app. This was shown yet again when I tried Standard Notes few days ago for the nth time. It still is sluggish and slow and felt like having too many jerks and clunks. Downright unusable for a major notes app in 2022.. well 23.
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.
> There is no better way to build a mobile app than a native app.
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.
> 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.
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!"
No. We just need the sensible solutions to get better.
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 are more of a symptom than a solution. It's been decades, and we are yet to see solid, popular PWAs that offer the cost, performance, efficiency, and accessibility needed to offer transformative change.
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.
> There is no better way to build a mobile app than a native app.
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]
From the moment I heard of it, Clubhouse looked like a fad which would die as fast as it rose.
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 wonder why clubhouse didn't just sell to the highest bidder. Their product wasn't so complex and the user's weren't very locked in. It just didn't seem like a product/company that could succeed on its own.
You could say the same about loads of successful companies. Nobody really knows and hindsight is always perfectly clear what the owners should have done. People said the same about Dropbox and Google at various points and arguably if Google had executed well you’d be saying the same about Dropbox and if Yahoo! had a clue how to leverage their search dominance Google could have also looked stupid for not selling.
> I wonder why clubhouse didn't just sell to the highest bidder. Their product wasn't so complex and the user's weren't very locked in.
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.
Clubhouse was a great idea and was mostly about the celebs not the tech. But the UX was good. It was kind of like a curated citizens band. Not sure why it failed. I personally got fed up of being the “beta in the room” not allowed to speak for the
most part as the inner circles ran their rooms. Except the
room about chronic illness which was a good room.
For me it was interesting in the beginning but after a couple of weeks my Clubhouse experience was flooded by people that were on Clubhouse trying to promote themselves or their products, without providing any value in the conversations. I stopped visiting Clubhouse because of this.
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.
"Greed" is a little presumptuous, but, to answer the mechanics part of your question: Assuming their audience and valuation would continue to grow instead of falter.
Are we talking about the same Obsidian app? The knowledge base / markdown editor?
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.
Yup the markdown knowledge app hah. It could very well be the experience on iOS is worse. I'm using it on Android with the Pixel 6 and it's smooth as butter.
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!
My experience with the mobile app is also very sluggish. I think there are two reasons some people experience it differently: 1. They use high-end phones and don't notice the high CPU usage of Obsidian and 2. Their vault does contain only a few hundred files.
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.
> Native is worthwhile for “appstore only” businesses. Mostly. For everyone else, a universal web app is the recommended path forward.
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.
As someone who spends enough time on iOS, I’ll take well written web app in a browser over well written native app any time. Do you really think that your whatever thing is so important as to justify me going to an atrocious AppStore and downloading yet another >100MB app with no way to block ads or tracking?
Unless you really exercise system API, I don’t want to hear about your CRUD needing native app to “provide best native experience”.
I'd argue there are a lot of app experiences that are inherently subpar by being apps.
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)
The feature with the worst UX is the one that’s missing. There’s a trade-off between perfecting features and adding more of them. Fully native app development plants the flag on the side favoring less features with a higher polish. That is not the right choice for the user in every case, even when viewed through the lens of user experience.
> What is it achieved through? Vendor locked, user and developer hostile native app stacks?
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.
> Yes, there is Vendor-lock in, you can't deny that. I don't know what you mean with "user-hostile" and "developer hostile".
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.
Sure you can. Those are interface guidelines. When you start talking about HIG that touch upon specific native elements, 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.
> 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.
This is a fringe view, in my estimation. Websites do not follow one HIG, people are used to variance. Also, when it comes to Apple, they tend to double down on outright stupid decisions, whereas Android is just a so much of a mess that native does not really mean anything. If you want to make something cool, the basket of native widgets will not get you far either. In general, do not stray away too far from the users expectations (which may well imply not following whatever the HIG says) and they will accept you. The platonic idealists will never be happy under any circumstance, so do not optimize for them.
>Yes, there is Vendor-lock in, you can't deny that. I don't know what you mean with "user-hostile" and "developer hostile".
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.
To my knowledge it is native on both android and ios and uses qt on the desktop (which is basically native on linux), but there is also a mac-native version.
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.
It started to be very slow some time ago for me, on my Android (Xiaomi Redmi 6 Pro). I'm thinking about not continuing my subscription.
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
This sounds exactly like Notion’s mobile app tech stack roughly 4 years ago - a web app running in a React Native wrapper webview. We really struggled to get that architecture to perform well, in particular for local caching, although improved React Native bridge performance might make it more feasible these days.
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:
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.
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.
That's what puzzled me about the article. Why even have React Native in the mix if all you need is a webview and some code to hit native APIs? Is it ease of build/deployment? Developer QOL/familiarity?
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.
I don't know how big the Standard Notes team is. If your team is super small, using React Native as a glorified build system that produces a native app without needing to learn both the Android and iOS toolchains could make some sense. But given that they wrote separate iOS and Android apps before switching to React Native, I think it's more likely to be avoidance of duplicate code in some way by using React Native abstractions over native features via libraries.
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.
That's super interesting, I've read your previous comments about adopting SQLite. With WASM SQLite nearly ready and the origin privet file system API becoming available, do you expect to adopt that in the browser? And if so would you then align the mobile app closer to the web app by sharing that code?
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!).
> do you expect to adopt that [SQLite via Origin-private filesystem] in the browser? And if so would you then align the mobile app closer to the web app by sharing that code?
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.
Thanks for the detailed response. I've also seen your contributions to CRDT discussions here and it seems Notion is doing lots of super interesting things at the forefront of "local first" collaborative development. (It's a pity you only hire in the US!)
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!
> 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
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?
> 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?
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.
Cool, do you try to make it a seamless transition to native with the web views matching styles, etc.? Or do users know which sections are native versus not based on appearance or interactivity (slower)?
I occassionally use the Notion Android app - and you can feel the difference in the native interface and the webview in this case. But only due to the interactivity - appearance is similar and cohesive.
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!
Huh. At work, I did the same for a WYSIWYG editor we had to implement, but it always felt wrong for me. After looking for a native editor library I was surprised how little I could find.
I can sleep a little better knowing that even the heavy hitters resort to webview sometimes
Even the first iPhone OS used WebView for all text inputs before they implemented "native" components. Literally, every text control was a WebView. Turns out they are really great for text editing :)
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.
> 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.
This is an architecture I’ve noticed most (if not all?) large cross-platform mobile apps land on: a native core to quickly get the user to an interactive state and have smooth navigation, that then gives way to some kind of web technology for the actual feature screens.
As someone who uses this off an on amount, I was really disappointed when I opened the app to the new web app. It was slow, janky, required me authenticating multiple times (biometric then username and password). I'm now looking for alternatives because "as fast as possible" is an important feature for me. I keep the app on my android home row, not because I use it a lot, but because when I need it, I need it instantly. Massive downgrade for the user imo, this only benefits the developer.
React Native, which was meant for writing amazing native apps, is just misused as a browser web-view thing. I am an expert in this field. Just never use React native to open single WebView. Never try to turn your website into mobile app like this. If it's a website, it's a website. If you need app make app. React, Electron and React Native enables you to make apps using Javascript, which is same as your website, it means you can have the same business logic between web and native app, same language it all written in, team talking on the same language, only the rendering logic will be different, which is huge saves. But it's not Flutter. It was not meant just to present webviews with your webpage. There is a Browser for that. Finally there is a PWA for just exactly that.
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)
It may be ”single language”… until you have to dive into the insides of a React Native library at which point you also have to know at least Java AND Objective-C. Add to that Windows-specific language(s) if your library will want to support Windows.
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.
I would say... In a smart company, you would enjoy learning some* ObjC and Java while working on a React Native app. It can be tough, but at the end of the day, we nerd hackers know Python and C and Java and bits of C# and objC. If you have to dive into Native internals, it can be a really fun journey if your boss tells you to explore and research it carefully, but it can be really confusing if you on a tight deadline.
> 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
Most importantly platforms like RN substantially lower the barrier to entry for making mobile apps, and cross platform ones at that. Whenever you lower the barrier to entry to something you inevitably attract low quality, low effort content that can obviously damage the perception of the broader platform. Setting that aside however, the development agility that RN provides I think is priceless. Most apps don’t need maximum performance, or the usage of niche platform specific APIs and so the time you’d spend working with two standalone codebases can be reinvested in your actual product and not mental overhead.
> 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?
Because two things, UI is different between platforms, to make a quality native-feeling app, you will have to use the design guidelines and native elements of every platform. What you can share is the business logic, abstract ui logic, but not the views themselves. You absolutely don't need to merge codebases in order to share something between them, you just need to have it portable. Having one mega-app seems more of a complication to me.
> you will have to use the design guidelines and native elements of every platform
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.
I think we're battling on the same side, I was generally speaking about subject of the OP post, where people make one web mega-app for all platforms with the same views, achieving this kind of single-codebase ;)
Think people are talking about different things. When I think about sharing the same code base I think about a single repo with lerna packages, where a lot of the common code is in packages, and each platform's native app is also its own package with its own build toolchain, that pulls in the shared code packages.
You're proposing a perfectly fine setup, what people are trying to do is just a single web app for every platform, they achieve this by releasing their own web browser app which opens just their page
I run a fairly popular mobile web app and the most common request is for me to release it as a native app. I try to tell them that the app would just be a web wrapper and that they wouldn't get any different experience than from running it in the browser, but it doesn't matter. Even after showing them that they can install the PWA they just say "I'll come back when you release it as an app".
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.
I would say it's a big misconception, when users want native app they don't want webview, native apps on each platform have a certain look and feel, as well as baseline performance, which they are used to. WebView will never be able to provide these key things, and it is prominently noticeable to most they are using one or another. So don't try to fool your users, then they want native they want native, and React Native is a perfect thing to build it using same technology as the Web, just with these crucial Native elements.
No, that's not correct at all. They want my web app as an app in the App Store/Google Play, even if it's just a WebView wrapper. I don't want to dox myself but it's more of a game than a regular application and all elements are custom graphics so there wouldn't be any native elements regardless.
Your case might be outstanding, surely there will be a situation where this is perfectly applicable, say you need such an app where utility prevails over the design, or maybe your html5 game works perfectly in the web view. For sure, you can take one of the custom browser solutions, and release a new browser just for your page, but it is not RN use-case, just use Flutter in this case
I do agree that native apps are better (mobile dev since 2009) but there are definitely ways to make your web app feel better and less sluggish if you care enough. Most shops don’t.
I think this is the key reason why going hybrid native with a lightweight WebView was needed at Notion. If there was a ProseMirror-like standard library for rich text editor available for crossplatform, with:
- 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.
Agreed. I would even call such initiative premature optimization, with unknown gain compared to just optimize the WebView component in the native shell if that's ever needed. More so for any new startup trying to enter the KMS space in general.
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.
Just like any other app. In React Native, there is a TextInput component which is fully under control, from caret position to nesting typography rules. You can build up all logic you need for text editing based on it.
TextInput does not appear to be rich text, I don’t see a way to represent bold text in the docs, much less complex rendering like @mentions tokens, images, or tables. Unfortunately when I Google “rich text input React native”, all the libraries I found use a Webview internally.
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.
I personally implemented web-compatible rich text using TextInput and I will share some of my knowledge here which hopefully fills the gaps for you.
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
In fact, never otherwise is mentioned, so generally you should feel free to experiment nesting everything inside anything unless otherwise mentioned explicitly. Of course you will discover that TextInput is only rendering Text elements this way, surely it's not documented well enough, although you should 100% of the time understand it's not the web and, with many many familiarities, things still work different here
One codebase sounds great but I always feel devs try to ignore that there just are significant differences between platforms that you must address if you want a well integrated app. Writing separate codebases in native iOS, Android, and web has a huge amount of waste but you can achieve higher quality and os integration, writing react native and react on web means you get just 2 codebases and higher dev productivity but at the cost of pain in libraries which typically also means less native integration, the solution proposed here means 1 codebase and even less native integration. If it is right for you great but like everything it is tradeoffs, pick your poison.
Agreed. Although the economic reality is that it’s borderline impossible for a company to develop a cross-platform native product unless they have significant amounts of money. Cross-platform is a terrible necessity to that end.
Eh. Not sure I agree, unless you mean taking a non-native already made react bit and try to turn it into RN.. that is far harder and does require lots of money.
too many people don't realize just how non-portable react code can be.
No I mean building a product that works on web, android, and iOS, and has a native experience on all platforms. It’s hard enough to find a good web dev, but it’s far harder to find good iOS and Android devs. It’s a very large and expensive endeavor.
As somebody who did it several times in multiple companies, it's not as hard as it looks. Usually you don't want to replicate your complete frontend experience, only the user facing part (and admin panel/etc can be a lot of product). Also things like notifications, emails, etc are all usually dispatched from your backend.
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.
It is definitely a challenge, but as prev EM / hiring manager of many iOS / Android devs it certainly isn't impossible. Not sure about large and expensive. Surprisingly most of my best devs were all inbound, not via recruiters. Felt recruiters usually wasted our time and small teams of native devs can get a lot more done than web teams (at least so it seems based on my subjective exp).
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.
Besides companies, there are also solo web developers working on cross-platform apps. It opens up mobile/desktop app development to them. Learning new languages and platforms to create native apps might simply not be an option. And users benefit from more apps on the app store, more options for them.
On the other hand, I have used some web apps that, when I "Install as an app" on Android, work pretty well.
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.
The thing is that most paying customers are most often on iOS, so target that experience while using react native and you will get some Android users for free. Android users are less likely to pay anyway.
Tried it out on Android and it feels janky. It just feels like a web app and it's not working well. To just give one example, if I click on the header of a note, a menu with "options" shows up. But Android also selects the text in the header and pops up a menu with "Cut, Copy, Paste, etc." which is exactly on top of that menu I was actually trying to get to...
Eh, these are easy fixes. We're making progress daily on making it feel more "native" (i.e recently added present/dismiss animations). Try the demo[0] in your mobile browser, should feel pretty smooth. We've tested extensively on a whole range on devices and performance wasn't an issue. It's really the animations (or lack thereof) that make or break perception of "jankiness." What we have now is our first solid functionality-oriented release; next releases focus on tidying up the edges.
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.
>The only way to build a decent mobile UX is by making an actual native app.
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.
This is not accurate. There’s a JS bridge to a lot of non native elements. You can get acceptable performance out of RN if you know what you’re doing but it will never match true native code.
> It is entirely compiled down to native code for your respective platform
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.
> 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.
Sorry... what? The more I read this, the more asinine it sounds.
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.
That's an interesting take that I don't agree with.
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?
> Calling something that a person *says or writes* "asinine" is inflammatory
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.
I’m sorry what?? Native code gives you access to libdispatch and concurrency. RN is single threaded. There are a myriad of processes, shared memory, optimizations, and daemons that run on your phone that coordinate better with native binaries.
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
I don’t think many people left those days TBH. I personally saw how 2 large RN efforts have been rolled back to native at a big tech company. I don’t know whether RN is gaining traction or is stagnating - would love to see some stats.
You mean Facebook sized large? Not every company has the resources to hire a full on Android and iOS team. So they write React Native instead, which is good enough for most.
Objective-C actually gets compiled down to machine code at compilation down. When you download an app from the app store, there is no more Objective-C.
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.
You do realize that RN runs on single thread right? Have you tried implementing background processes in RN? I suggest you try also implementing push notification in RN.
> 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.
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.
Web is a 2nd class citizen because it’s designed for documents, not for interactive applications. All the application bits are afterthoughts and bolted on and it shows.
By the time mobile was established as a platform, the web is known to be an application delivery platform.
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.
Apple actually wanted to have only web apps on iOS initially. They only published the iOS SDK after the outcry of developers, because web apps sucked so much.
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.
PS: As Steve Jobs was good friends with Larry Ellison, I can imagine he truly believed web apps would be sufficient (as Ellison was a long time proponent of them already).
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
Google was and still is the canonical Web Company. Android went with Java and custom APIs over the web stack. More than a decade later and this hasn't changed. The new Android UI layer is Jetpack Compose - again, not the web.
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.
Depends on the user’s expectations, I guess. The demo you linked does not feel close to native yet. Lots of reflows, small shifts, inconsistent rough animation… even for a web app it’s not smooth enough (iOS Safari)
You guys are technically correct, but also dead wrong with your outlook
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
I am not trying to nitpick - just giving my honest feedback. This submission is not for a technological breakthrough that I would admire from a theoretical perspective.
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.
UX is a real thing. Any user that feel your app is crappy, slow, inconsistent, ugly, breaking OS paradigms, janky. Will just dump it, and just get another one (there are plenty) Users are the real judges giving you the Award of Excellence, any minute they keep using your app
I don't lose a tab among hundreds others if I need to reference something. It has all the necessary navigation on-screen (language switch, search inline, table of contents)
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.
Hmm, I was really intrigued by this post and am thinking about digging into capacitor a bit. It does seem to me, however, that there are often subtle ways in which the fact that an app isn't native bleeds through. For example, trying the demo you linked to: if I click on one of the notes in the list and then swipe right from the edge of the screen in order to go back (gesture navigation), I expected it to behave the same way the arrow in the top left would, but it doesn't and I found myself back on some other website. Maybe it doesn't work like this if I actually download the app on Android?
One more thing to tidy up: your full screen hamburger menu in notes on android chrome/Firefox can't be dismissed with a back button press. Instead that closes the entire app, because apparently you're also missing a navigation stack?
Sorry but it is janky asf... and if it's easy to fix why deploy without said fix. Uninstalled. Unsubscribed. Alone for the condescending tone of this comment. At least the export is easy. sic.
We went forward with this exact solution years ago at a company I worked for. In our case our mobile usage was actually really low compared to web. It just didn’t make sense to invest in native development. So we found React Native with web views to work pretty well. We also tried React Native Web, it was a lot newer and kind of an experiment back then. It was cool that we could get it to work but the web results were a little crazy when you care about semantic markup and SEO. It might have changed a lot since then.
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.
This is an important technical discussion, one that the community needs to keep having to reduce unnecessary work and get more cross-platform support. There is a lot to be learned from (and reused) from history.
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.
What are your users saying? Especially mobile users. Are they expecting a native experience? Engineering decisions that sacrifice user experience usually don’t have a happy ending. As a native iOS developer the best feedback I can get is when somebody tells me that my app looks like it was developed by Apple. I like using vanilla controls as much as possible. But as previously mentioned its all about tradeoffs.
I don't have personal experience with this, but React Native Web claims to solve this issue: https://necolas.github.io/react-native-web/, not sure if anyone has had experience with this. Of course, you will have issues with dependency hell/package maintenance.
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).
I would prefer imitated components any day compared to dealing with the actual SDK native components. Especially when there is "one code" that compiles into corresponding these components on different platforms. These things always change with each SDK version on each platform, and there needs to be a lot of messy hand-stitching in the library (React Native) to keep things working as expected.
Imitating native components is actually the only realistic approach. Those components are guaranteed to work on newer OS versions, they work on any platform and they give you easy access to the low level guts.
>combining RN and RNW is a pain in practice. It can be done, but not easily.
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.
not so. you can build complex apps with the expo libs.
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.
This is (effectively) false. You don't need to eject to use third party modules (including, but not limited to, react-native-webrtc). You can use expo-dev-client to build your own "Expo Go"-esque development app, and EAS Build provides a fully transparent build environment.
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.
I agree with Expo being pretty painless. Anytime people are really set on using RN I tell them, just use Expo. Now a day, you can integrate external libs and such quite easy.
I've done it. Once you're setup, it really does work quite out of the box. What you do have to be mindful of is clear separation of concerns when designing platform specific components - you have to think in terms of Button.native.ts and Button.web.ts when you're doing things like haptic feedback or animations.
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.
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 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.
Yeah seriously. Just a worse version of the bridge. IMO the cart is leading the horse on this one. Might be more convenient for their dev team to just have a web codebase (though I’d argue if they took the time to transition their web codebase to react native web they’d see the same benefit), but it will definitely hurt UX.
There's no reason it has to hurt UX in theory. The difficulty is just in spending a lot of extra time perfecting the animations and interactions, which is 100% doable. We just released navigation present and dismiss animations a few weeks ago, which feel pretty great imo. They're non-interactive, and again, this will take a lot of extra work you get for free with native, but the tradeoff is worth it for us, and again, amenable.
You seem to be in very heavy denial. This will never be as nice to use as a native app, because you cannot replicate all of the small details of how native UI works on each platform. 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.
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.
> This will never be as nice to use as a native app, because you cannot replicate all of the small details of how native UI works on each platform.
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.
> Not sure how much of that is necessary. I mean, a button doesn't "look native", so what? It's a button.
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.
> Is it? Native buttons also come with things like affordances, accessibility, recognizability.
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.
> 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.
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.
> 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"
> 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.
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.
3x spend may well be impossible for some places—but maybe that means great UI is impossible for them, too. The fact that I can’t afford a Ferrari does not magically make “the best car I can afford” be as good as a Ferrari.
If my customers don't really need a Ferrari, then making them pay for one is expensive. Most cars work just fine for most people.
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.
Really do check out Turbo Native from the Basecamp team. They’ve taken this hybrid web approach a step further with a bridge and native navigation. It is quite difficult actually to distinguish between their apps and real native UI, the library is astonishingly good.
Interesting tech. Looks like it's developed by hey.com, and their email app on Google Play store is only 9MB, which is impressive.
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).
> Quite simple really: a bridge between web-land and mobile native-land. Our new mobile app still uses React Native, but is literally just 1 component: a function that renders a webview.
I don't know about the wrapper, but the entire app being a webview is how Peapod (grocery delivery) has been for years.
I've also been wondering why people still use ReactNative despite the availability of much simpler stacks.
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.
The only way to survive with a single code base is to go the way of gamedev, to own the substrate you are running on completely. From rendering of fonts to user input. This, of course, depends on the complexity of software. App in this blog post is not really that hard compared to the effort any game would need to go to render on screen. C'mon, it is just a text editor, there is not much of anything there really. All this just shows the state of modern development of too many abstractions for really nothing in exchange except a slow, overengineered fashion hype train. Surprised, there is no mention of WebAssembly in there. (edit typos)
I assume you're sarcastic, because creating a good native editing experience from the ground up is not trivial, when you try to make context menus look native, have native editing keyboard shortcuts, integrate with system IMEs and accessibility for screen readers, etc.
No. There are absolutely no problems with providing accidental native context menu elements or integration with menubar, etc.
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.
How many times have you tried this? Text editors are not easy to write. There's a wonderfully fractal level of detail.
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.
> The only way to survive with a single code base is to go the way of gamedev, to own substrate you are running on completely. From rendering of fonts to user input.
It is not, you do not own Flutter in a way that if in 5 or 10 years it stopped being maintained and broken on current platforms, or not available for a new platform you want to port to, you are screwed.
“And then we wanted to write a widget or use the dynamic island and we realized we can’t, so we just delivered a subpar experience, but hey - who cares about user UX when our dev UX is so great”
I think the point is that they write their UI once. There will always be platform specific parts, but those are a lot smaller if your UI is shared between platforms.
I spent the last 6 years building an Ionic app for “enterprise”. The still-not-native UX is the main reason why it’s not more popular, in my opinion.
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.
I reckon there is space for a drop in replacement ui for Angular and Ionic that respects screen real estate and users ability to interep a more dense set of information. Less padding etc. I'd pay for it. Or there could just be a few small modifications to make what is there more workable.
It fell out of favour for one of the same reasons the author cites - that third party dependencies were a dumpster fire. I would say that as frustrating as this can be with React Native, Cordova was substantially worse.
With the right libraries and clean code, going native for iOS/Android is usually the solution. Building UI/networking/etc quickly in Swift/Kotlin just isn't an issue anymore. RN/Flutter won't be used in 5 years.
Strongly disagree. Both frameworks save on dev time to a very significant degree. I actually foresee better cross platform solutions being introduced in 5 years
I don't agree, and I have worked with this significantly as a consultant and core contributor to react-native. What typically happens is people convince themselves what you are saying is true then there ends up being huge delays to spin up all the infra app side... THEN eventually, they kinda are okay. until the next react-native release.
edit: would like to clarify that of course I would recommend better ways... but... clients do as clients do.
You are looking at this with hindsight bias and are assuming that for some reason the future will remain the same as the past. There are no fundamental reasons why ios and android development occur with two different ui frameworks in two different languages.
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 key word here is “theoretically”. These cross platform solutions are great in theory - who wouldn’t want to share code across all platforms? It’s a great sell, especially to the folks holding the purse.
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.
Good metrics for proposal to VCs .. to steel the cake from native platform overlord. Lets eat the apple and google cake to boost our return margins. Bam! VCs alliance for new scene graph renderer for the web on any device.
I don't think that works as a metaphor. IE got MS in trouble because it was so embedded into the OS that it was literally required, and MS did everything they could to force users to use it.
Android works fine when built from source with no Play Store at all, using F-Droid as the primary store.
Apparently Jetpack Compose for iOS has zero accessibility support so far, if the Droidcon NYC app is a representative sample. I'm sure that will come; just don't use it yet for anything more important than the iOS version of an Android conference app.
With tons of effort put on browsers to adhere to web standards and seamlessly interface with different kinds of hardware and platforms, the nasty hard work has already been done. How many times will the wheel be reinvented? It is consumers who should openly demand for web applications and resist efforts pushing for app alternative. This will help the consumers hide their backs and developers save their backs.
Apple google don't “steal” from devs. Devs are a business and if they are worth their salt they account for business expenses in their pricing. If anything Google and apple “steal” from their OS customers. This is the same as saying government steal from corporations, while technically true they in reality steal from citizens as businesses account for their government expenses in their pricing.
I have read the post and 60 comments but the "future" is as clouded as ever. I wonder if there was ever a period where developers had such difficulty identifying how to best deliver applications.
There is no difficultly in identifying how to best deliver applications. The issue is entirely resources.
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.
Identifying a key variable (resources) helps but doesnt really solve the optimisation problem.
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.
People don't speak about other approaches. For example my team adopted the BFF (Backend for frontend) pattern. Android and iOS Developers work together on a shared BFF and encapsulate there as business logic as possible. Also we define OpenAPI specs on the BFF to generate data models and API code for the clients. It works pretty good for us.
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.
I was waiting for "progressive web app" (PWA). Safari is lagging behind in stuff like native file system access. But for most apps a PWA would most likely do the job.
Apple's monopoly via an app store and its market share is the only reason why PWAs aren't already ubiquitous. It makes no sense why I can't download a web app to my phone directly from any browser other than "well, that would cut into our monetization through IAPs and the app store." Genuinely, fuck Apple for holding the web back.
fanbois have entered the reply 3 2 1: no no no it's evil google's agenda that will invade your privacy and security on your devices .. a lot of excuse.
> There is also no practical way to build on React Native without using a metric ton of third party libraries
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.
User experience. It seems like it’s rarely mentioned in discussions like this. The sad truth is it’s usually sacrificed. This approach, as well as RN, will never give you the experience you get from native app. That applies to Standard Notes app too - it’s not great, not terrible.
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.
We did Fotolog.com using mobile and it gave us several problems. Webviews aren't good at all. We tried Flutter, and we also had complete troubles, but not related to the technology but finding people who were able to do it. The answer was react-native with a good balance of performance, pool of people who knew how to work on it.
Okay, let me be that guy... I was that guy telling people no no don't send your customers to Facebook, Noooo twitter is not the superior RSS replacement. Live journal is the wrong choice, your Myspace efforts are not history in the making and your Geocities was historically just as much a waste of time. Flickr is not the place for your family album and neither is Picassa.
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.
Is the actual view rendering done in webviews? I've struggled with that because the compatibility between different Android webviews can be very janky, and lead to some really obscure bugs, plus on many phones it just feels "off".
> Packages for React Native are their own special breed of monstrosity because the package author would be the one writing code twice: once for iOS and once for Android (and of course the JavaScript wrapper). The result is a drastic increase in library abandonment and stability issues. In addition, keeping your packages in sync with the latest version of React Native (which is notoriously difficult to keep up to date) was a nightmare of its own.
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 look forward to the blog post in 2 years where Standard Notes realizes that reinventing Cordova was not in fact the right solution to building a high quality, cross platform app!
We do cross functional mob programming at my company with native iOS and Android apps. Works like a charm with a small team and I don’t think a react native app would offer any advantage. Instead we try to build the best app for each platform as one team.
I’ve never believed the hype of code once run everywhere. All solutions have drawbacks you just have to pick one.
Having read through the comments and tried standard notes I can see why users might have been disappointed going from native to this web implementation.
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.
I'd say it's the inherent foolishness of spending time and $$$ trying to get your web UI into the uncanny valley of looking "as close as possible to the native UI" instead of spending that time and $$$ actually using the native UI and components, but that's just me.
I don't - but check out WKWebViewController ... and its WKScriptMessageHandler delegate, which lets you receive messages from javascript embedded in the currently viewed page.
If an app is available in native and PWA/webapp versions, I always install the PWA/webapp version. It's usually lighter, is better w.r.t. privacy, will need fewer permissions, and might allow copying text.
Interesting, no mention of Flutter here. I found the dev experience as well as customer experience far better than web apps on web and mobile as they mention here.
Flutter and Kotlin Multiplatform have the potential to be sleeper hits here. Kotlin in particular is interesting because it lets you go in at several points on the spectrum - you can share just logic code between platforms and use Apple UI on iOS / HTML for a web version, or you can use Jetpack Compose and use the same UI toolkit on each platform. You can also create desktop apps this way and that opens up the possibility of just skipping the web version entirely: use Kotlin and Jetpack Compose for Android, iOS and Desktop. This is nice because it means you can do things like consistently use multithreading throughout, share libraries, use GraalVM native image to optimize startup time and memory usage on desktop, have low latency UI everywhere, work offline, use files, integrate with the host OS and so on.
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.
What they decided to do is really quite strange. Something like Capacitor makes much more sense but they said they wanted access to React Native libraries... I hope https://github.com/OpenNative/open-native can address their requirements in the future. It's goal is to make things like React Native native modules work across frameworks (e.g., react native libraries working in capacitor and native script)
Cordova would be a lot more performant for their setup. Right now, they spin up a JS VM, parse and evaluate ~800kb JS, then call out to native to add a web view. It’s a lot to do - and only really worth it if you’re using the rest of RN
These note apps created by tiny companies are useless and trying to reinvent the wheel.
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.
I wish, but I don't think it'll be the case as long as Apple and Google control the mobile platform. The problem was always economical, and not technological. The tides of regulation seem to be changing, and we might get key rulings on their stranglehold on the app stores in the coming years, but it's very hard to conceive how the regulator could compel them to open their systems, and for example implement certain PWA APIs.
Ive been an iOS dev for 10 years now and every few years a new cross platform framework comes along. They all suck. Either the development experience is awful, or the user experience is awful. Actually, it's usually both.
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.
... which means you have to write the application at least twice for mobile and at least three times for desktop.
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?
> It's a worse experience for the user but it's not bad enough to be a major barrier to adoption in most cases.
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.
They do it because coding a large UI project is brutally hard and money doesn't help that much. Building a new UI team is hard, hiring is hard, managing is hard, designing is hard, it's all brutal. Now do that 2-3X in parallel and manage that efficiently and ship new features on time.
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.
I think a big part of what people perceive as being Electron’s fault actually comes down to how the app code is written.
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
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.
Just the other day I did an experiment while writing a new Electron app. I created a Hello World -- once using React, and another with just static HTML & Vanilla JS. The React version, literally just the default Hello World page, was already noticeably slower and jankier at startup than the static HTML version.
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.
Yeah, and honestly I don't think it's even down to the framework all the time either, but some frameworks make it easier than others.
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.
Slack used to feel better than it does now, and from my outside perspective it feels like most of the slowness that's started to happen comes down to lazier caching and slower back-end requests (loading conversations, etc)
From my experience the reason why these kinds of platforms get used as much as they do is that it follows the concept of the fungible developer. It is painful and expensive to find an iOS/Android/Win32 developer because the pool of skilled developers limited.
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.
> 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...
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.
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.