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
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.