>Our mobile app is just our web app
There are limitations that come with this philosophy and if the trade offs aren’t stated it usually means they’re not fully considered.
There are some UX decisions that I disagree with but I feel the underlying tech stack is solid (fast, looks good, feels native, etc)
The iOS Obsidian app doesn't feel native at all, the interface is high latency, syncing is slow and problematic, many plugins don't work, poor touch support and serious performance issues even on the new iPhone 14 Pro.
It feels like a cheap and nasty Electron / JS heavy web frame.
For sync though I can't comment as I use syncthing.
edit: Actually you're right, now that you've pointed it out I do notice slightly higher latency and animation hitches. Goes to show if you know that to look for you'll find the cracks!
I know I'm quite particular / sensitive to both interface latency and design, I'm aware I probably have higher standards than most people.
There are horrible slow or just badly built apps written with native stack as well.
Native is worthwhile for “appstore only” businesses. Mostly. For everyone else, a universal web app is the recommended path forward. Anyone who has a web app should absolutely avoid rewriting the same business logic three times over in native languages just for the appstores. It’s a nightmare to maintain and sync up three teams and codebases, not to mention also insanely expensive.
The future is pwa + webassembly + webview, and there’s no advantage of native over web whatsoever.
The future we should strive for is the best UX for the customer. That’s not achieved through a web stack.
What is it achieved through? Vendor locked, user and developer hostile native app stacks?
> The future we should strive for is the best UX for the customer.
And that’s web stack with access to system APIs.
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, they can't match native apps even remotely
Anything that locks you in is hostile to you as a consumer.
> I - as user - personally ignore anything web based, if there is a native alternative, as I prefer apps that follow the HIG and use the native toolkit of the platform.
Interface guidelines and toolkit are different matters. You can write native apps that don’t follow HIG and you can write web apps that follow it.
> No I fully disagree. A good UX is only doable, if you use native components and fully follow the HIG. I have not yet encountered a good webapp that is on par with a native app that does exactly this.
What is a good UX?
> Anything web based is good for "one code base - available - but subpar - for many platforms", while native apps are "One code base - one platform, but a great experience" (Given you follow the HIG and use native components)
If I write Apple only web that follows HIG like a bible and adheres to all standards, where does it put me?
> One extremely trivial example: I don't want to accidentally delete e.g. my files, just because some app thinks switching e.g. "Ok" and "Cancel" around is nice.
That’s platform guidelines. Nothing stops me from implementing them in web app or disregarding them in native apps.
> While yes, web apps have their uses, but they can't match good native apps even remotely.
Sure they can, and they do. You probably used them at some point but couldn’t even notice they were web.
You can't write a web app that properly follows a single OS's HIGs, much less multiple OSs'.
No you can't.
> we’re back to why vendor lock-in is bad.
Ah yes. There are some unknown theoretical HIGs that you can follow which don't exist and don't reflect the actual platforms that people, you know, actually use.
This has nothing to do with blindly parroting "vendor lock in bad". Because Apple's HIGs for a long time were light years ahead of anything else, and yes, I would expect a well-designed app to follow them on the Mac (anything from accent colors, secondary focus and humane modal dialogs to affordances, accessibility considerations etc.)
Whereas "sure you can" web implementing some bogus HIGs can't even do a modal dialog right.
Why and what you can't achieve from HIG?
> Ah yes. There are some unknown theoretical HIGs that you can follow which don't exist and don't reflect the actual platforms that people, you know, actually use.
Sorry?
> Because Apple's HIGs for a long time were light years ahead of anything else, and yes, I would expect a well-designed app to follow them on the Mac (anything from accent colors, secondary focus and humane modal dialogs to affordances, accessibility considerations etc.)
What does this have to do with native vs web argument? The topic is here what and what you can't achieve with both technologies.
> Whereas "sure you can" web implementing some bogus HIGs can't even do a modal dialog right.
???
I gave you examples, and you dismissed them because "vendor lock in is bad" and "I don't see what this has to do with native vs web".
> ???
There's no modal dialog on the web that conforms to any of the existing HIGs. And while you can implement one, the amount of effort is ridiculous. Compared to native.
And that goes for almost literally everything. For example, there's a reason 99.9999% of the thousands of dropdown re-implementations fail even the simplest of accessibility checks.
IMO it's only "developer hostile" for developers who don't want to have to learn a new OS and languages. This sounds like someone with years of Angular experience who doesn't want to learn React because it'll make all the tricks they've learned getting Angular to behave obsolete. As far as being "user hostile" I've got no idea why that's in there... unless they're just throwing things against the wall to see if they stick, and if that's their intent they picked the wrong forum to do it in.
This take is outright wrong. Non-native/webview-based apps are only a tolerable option if your goal is to maximize the number of platforms you cover with the same code base and skeleton crew dev team, at the expense of forcing users to endure subpar user experiences.
Unless you really exercise system API, I don’t want to hear about your CRUD needing native app to “provide best native experience”.
Plenty of services are simply "good enough" as a web page. I don't need a permanent icon on my phone from the local pizzeria for the once every 3 months I order for pickup. How can you make my experience better with an app? Invent different and weird new checkboxes for the order selection process, or just hope they can poll for tracking data that wouldn't exist inside a browser session?
Apps are also a terrible fragmentation for "transient" interactions where you're starting with a search or other activity, and incidentally brush across the content, rather than starting with a full "I'm going to use an app" mindset. Suddenly the UI changes and flow is broken. (see: any time you search for something and click a Reddit result)
Clubhouse (a native app) said the same thing years ago and ended up becoming irrelevant and its features were absorbed and overtaken by Discord (a React Native app) with its Stage Channels feature, all before Clubhouse could build it's Android app.
By the time Clubhouse released its Android app, their lunch was already eaten and it was too late. It turns out that, after recently looking at their latest app build they are slowly integrating React Native in their app.
This sounds like a quiet way of them admitting that they should have used React Native in the first place for both iOS and Android to release quicker had they done that as I said before. [0]
I know that other people had different experiences, and that my experience is not universal. But I am probably not alone in that experience either.
Yup. They did try to sell to Twitter [0] but that collapsed and Twitter already implemented Clubhouses features using Periscope's infrastructure which I said this before [1] the reports of their acquisition talks happened such as [0] and [2].
So due to Twitter already owning and using Periscope, the avenue for Clubhouse to sell to Twitter already made no sense.
[0] https://www.bloomberg.com/news/articles/2021-04-07/twitter-i...
[1] https://news.ycombinator.com/item?id=26273255
[2] https://screenrant.com/twitter-clubhouse-purchase-buy-talks-...
I’m not convinced their choice of technology was their downfall. On the contrary, maybe it was what allowed them to launch at the right time with the right experience and have a meteoric rise. Building it with the alternative might’ve meant obscurity from the start. Timing and luck are major influences in an app’s success.
I am not sure how the app is unusable for you. I use Standard Notes on my iPhone without any problems.
First you must imagine. Imagine that his device is not your device. Imagine that it is slower. Imagine it is slow enough to pass his threshold of unusable.
I've attributed this to the increased number of notes, but after reading the article, I'm starting to think it might be because of the programming decisions, at least partially
There is, if the only tangible alternative to building a native app is not building a mobile app at all.
Every application deals with some amount of sluggishness. Performance is not a mobile app only problem, it's not a new thing and it's not entirely clear, when it's going to be a big problem and when people will be okay with it.
With all the strides being made, the future is almost certainly not going to be 3 code bases for 90% of simple CRUD apps, because while the problem of maintaining a lot of code is not getting better for developers, the js glue layer so many people long for most certainly is, and rapidly.
So we're just throwing our hands up now and saying it's inevitable that a a notes app is just going to be slow? (In 2023!)
We are lost.
"Thou hast strayed far from the path of the Avatar. Seek now to renew a life of Virtue, lest thy soul pass finally beyond my reach!"
One would be to stop the Apple/Google hostage situation, improve pwa performance and make web apps first class citizens on Mobile (the web apis to make this happen already we exist). Another one is a better translation layer. Right now the second option seems to be winning out.
Asking devs to suck it up and continue down the triple code base insanity for mostly just reasonable feature parity is not one.
PWAs also don't solve the root problem of having to deal with different platforms. Many choose to imagine that Chrome is the only browser that matters, but that's far from true. Like native apps, PWAs are hostages to the platform they run on – browser makers.
I suppose that on mobile they also don't use web technologies
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.