> Are native apps dead?
> Not yet… but they’re going to be.
This post makes very big claims based on a very basic application that doesn't seem to be much more than a few toggle buttons and a couple of animations thrown in, and some 'statistics' that don't appear to be based on any actual facts.
I work in a team developing an app that has around 5million users, and we abandoned an Ionic first version 5 years ago, after a couple of years of nightmarish development, where (after the first implementation, which went reasonably well) we spent most of our development time fixing inexplicable bugs, chasing native features, getting inconsistent UI problems, broken builds from package updates and a myriad other problems that just drained our energy and were generally dispiriting.
I personally felt the entire experience was a horrible professional dead-end. Luckily our management decided to switch to a native application, and learning Swift has been the most fulfilling part of my entire career. The application is faster, more reliable, the bugs are locatable and fixable; the entire framework feels solid and professional.
The application itself is immeasurably better now. We attracted better-qualified colleagues who have been a great learning resource. And the app itself went from an appstore rating of (iirc) around 2.8 stars to its current rating of 4.6.
We would never dream of going back to the nightmare that developing a complex and performant app with Ionic was in my experience.
Hello, author here. Congrats on having such a successful app.
Funnily enough, I actually wrote this post because if you had asked me about cross platform web apps 6 months ago I would have said the exact same thing you just said.
In 2014 I'd started an app using Ionic and actually ended up abandoning it and it killed the project. I was so frustrated. That's why I was shocked with this app (and yes it is small and pretty simple) actually worked really nicely being a react app bundled into a webview. It's crazy, I was just shocked.
Made me realize that cross platform web apps are a hell of a lot more capable today than I had thought.
And sure, maybe claiming native apps will die eventually is a pretty bold claim... But technology moves. And the direction it's going now, is in the direction of browsers becoming faster and more capable at a greater rate than user's desire for more elaborate UIs. Visual Basic and Java used to be the hottest tech you could have on your resume. Who knows what will be old fashioned and out of date in the future.
I don't normally make bold claims but I think I'll stick with this one and maybe in 5-10 years I can fish out this blog post to see if I'm right or not.
Hi - Thanks I don't consider myself responsible for the overall success of the app, it's a big company.
I know really well about how 'tech moves' as my first developer career was based on advanced and deeply immersive ActionScript3 Flash apps - and the speed that died was a genuine warning to never be complacent that I'm still fully aware of even now.
But I'm not convinced that 'web-apps' are the universal panacea you seem to think they are.
To begin with, the apparent simplicity of your app (forgive me if I'm underestimating the complexity of any features you don't mention in the article) suggests to me something that could be built using SwiftUI in a couple of days.
For side projects or simple UI applications, SwiftUI is so fast to put together that it really outstrips the setup speed of any of the web frameworks I've used in the past. Simply learning a bit of Kotlin and/or teaming-up with one other Android developer (which in itself would be a great learning opportunity) means that you could develop native apps pretty much as quickly and easily as learning and implementing an Ionic app.
You also (both here and in the article) focus on "user's desire for more elaborate UIs" - but the emphasis in most apps is not an "elaborate UI" but speed, reliability, predictability and accessibility.
In my experience, native frameworks provide a better user-experience in all these areas.
Even if you learn SwiftUI, and get a Kotlin developer for Android, you'll still need a web developer for those who just want a web app. Notion, Spotify, Hulu, etc, all have web apps. Even Gmail still has a web app, albeit an extremely poor one, which goes to show how much work multi-platform support is. The benefit of frameworks like Ionic is to support multiple platforms without having to maintain multiple codebases. So as the gap shrinks between native and web, it starts making more sense to just write a single web app
Gmail's web app is "extremely poor"? I almost never experience any issues with it, and it's quite streamlined in my experience. It's not worse than the Android app (it's actually nicer, IMO, but that's probably in large part because it's on a big screen). It could be more responsive, but that's about it.
> And sure, maybe claiming native apps will die eventually is a pretty bold claim... But technology moves
But common sense does not.
Just do not forget that you are reasoning over a "market", a supposed large number of potential users - not "a norm, some universal rule". It is very normal to want one's tools work without networking.
React Native has nothing to do with the work done by the author. He is using a browser based web view, React Native eschews the browser in favor of a JavaScript based custom native bridge. And I would agree that it's poor.
I don’t want to be wildly unkind, so I’ll keep it to this: your limited experience here is not sufficient basis to prognosticate on an entire industry.
I look for signs in posts of where the user is at and he said "I don't normally make bold claims but I think I'll stick with this one and maybe in 5-10 years I can fish out this blog post to see if I'm right or not" which is exactly the kind of thing that suggests a level of maturity (which = a willingness to be wrong and change one's mind and learn from experience) in the poster.
But saying “I don’t want to be wildly unkind” implies that there is something about the author and their claim that is deserving of meanness. I think that is an unkind thing to say.
That’s a fair point. I thought the context of “unkind” was already clear from the grandparent comment:
> This post makes very big claims based on a very basic application that doesn't seem to be much more than a few toggle buttons and a couple of animations thrown in, and some 'statistics' that don't appear to be based on any actual facts.
I have used Ionic for about 7 years now? 5 years ago it was sort of still a painful beta-like product. Not the case today. We ship and maintain 2 different apps to web, iOS, and android each, with only 3 developers. These are highly complex apps , although not games. Ionic really got great about 3 years ago.
I suspect that if you had experienced Ionic a bit later in it's cycle, you would have been happy. Hard to tell, and I do think there are genuine cases for building to specific platforms. However I think it's the exception (outside gaming), not the rule.
I can second this. My Ionic app runs incredible stable, no issues, users are happy. It is not super complex and doesn't make use of native APIs beyond in app purchases, but it isn't super trivial either.
The performance is good on modern devices to the point where you don't notice a difference.
The main downside are these things:
1. No fine-grained control over input types / the keyboard that is displayed. You basically have to use whatever Safari gives you. The options got better in recent years, but a native app has better control over the type of keyboard it shows (maybe you can achieve similar effects with a plugin).
2. The UI obviously does not respect accessibility settings. For example, if you enable the O/I markers on toggle buttons on the OS level, your app won't show them. But I think React Native wouldn't show them either, so there's that.
3. Can be a pro and a con: Your app shows the same UI for every OS version. Let's say a user is still on iOS 11 and Ionic tries to adhere to the design language of iOS 15, an app update will also affect iOS 11 users. Whereas with native apps, you can basically say "take this headline element and show it in the way the OS renders this by default". Imho, this doesn't matter for normal users that much, but if you obsess over design, it can be a downside or at least somewhat unexpected.
And you get a lot of upsides:
1. Truly one code base with close to zero custom code for each platform. Hence, a solo developer can easily develop an app for iOS, Android, and the web.
2. Assuming you use Ionic's Capacitor as a runtime environment on devices: It is basically a thin wrapper for Chrome. Since Chrome is evergreen even on older devices, I usually never run into browser issues if users are on Android 6 for example. They simply have the most recent Chrome version and your app benefits from that.
Compare this with iOS: Users with an older iOS version run an old version of Safari and hence, you need to make sure that your JS code doesn't break on older Safari versions. Although the compatibility with modern JS got a lot better since iOS 11.
3. You can easily force the same design on all platforms if you want. I wouldn't recommend it, but for some enterprise-internal tooling, it might make sense.
To sum it up, especially indie developers who want to build an app very fast and don't have a team should give Ionic a try.
This post makes very big claims based on a very basic application that doesn't seem to be much more than a few toggle buttons and a couple of animations thrown in..
That's 90% of non-game apps. Most apps could be written using web-based tech (React Native, Flutter, PWA, whatever), and because they're so simple they should be very fast and very small. Where an app that's a few toggles and animations is slow or janky it's a sign that the developer screwed up rather than a problem that would be solved by going native - the dev would screw up regardless of the tech they used.
Some apps that have extensive design or animation work benefit from being native, and there are some things that are painful to do using web tech like custom camera work or things that use the secure enclave in weird ways, but if you're not doing those things then web should be fine.
React native and flutter are very, very different from a PWA.
While a PWA is a web app, react-native renders actual native components, and flutter has its own rendering engine. I wouldn't call them "web-based" tech
They're not web-based under the hood, but the code that the developer writes to drive them is very much in the ballpark of a web developer - JS, React, TS, Webpack, etc. That's why they're classified as "web-based" or "web hybrid" rather than "native".
The fact that browser apps replaced desktop apps eventually kind of proves that the same on mobile is inevitable once computing power and efficiency is sufficient.
Unless mobile vendors put up artificial barriers on functionality of web apps (Apple).
At a certain hardware level, UX is not perceptibly different between native and Web based, yet development much easier with cross platform target
> The fact that browser apps replaced desktop apps eventually kind of proves that the same on mobile is inevitable once computing power and efficiency is sufficient.
IMHO, replacing something != proving something. We may have replaced desktop apps with browser-based apps somewhere, but that does not prove anything. I'm looking at a lot of professional software, that just won't perform as a browser app (or work at all) in the near future. And then I look at a lot of crap browser-based software (like MS Teams) that makes me wonder whether this was actually an advancement, because it absolutely does not feel like it. It's UX is just miserable and so slow.
It's proven in the sense that there is freedom to choose to write a native desktop client, and yet nobody does it anymore, regardless of how widely adopted or important their app is to the business.
It's enough proof for me, at least.
Native apps continue to exist for areas where browser APIs aren't sufficient yet, that's true. But those will get replaced once a sufficient API supports it
I partly agree, but I disagree at the point that there may be no correlation between the amount of non-native apps and the overall "happiness" of users.
Just because business see that it's cheaper does not make it the better option.
Also from a user perspective there are many benefits with a software that exists on many platforms. It's often better with a slightly less good/snappy app that runs on all platforms than a perfect app than runs only on one platform. It's a feature.
It could also be said that it's a feature that the app does not 100% follow the native UI as the experience will be the same irrespective of which OS you are on.
Is it a feature, that MS Teams (as a default setting) does not use native notifications on OS X? As a user, I have to disable two notifications now, because one does ignore the system setting. I don't know how to sell that "feature"... Imagine having many apps with each having it's own notification setting, layout and appereance.. That's hardly an improvement to the status quo.
That is only a feature for app developers and (especially) the marketing departments of companies who do so, not platform users. I use non-platform native UI as a leading indicator of contempt for users.
>It's proven in the sense that there is freedom to choose to write a native desktop client, and yet nobody does it anymore
There’s factors occluding this though I think-the JS/web stack has had millions of dollars of investment thrown at it by parties with a vested interest in seeing it succeed, so a lot of UX issues and friction points have been smoothed over as much as possible.
The wider native UI ecosystem hasn’t had the same investment, so I’m not surprised it’s superficially “easier” for devs to thrash out a UI with web tooling. Doesn’t mean the resulting application is actually any better though.
I mean, you could simply say you don't care about your users, it's not that hard.
Web apps are dreadful, regularly lock up, and are an active step back in computing. But hey, if your startup can spew out a shitty app much faster, good for you.
> And then I look at a lot of crap browser-based software (like MS Teams)
I actually prefer to run MS Teams in a browser tab instead of installing it to my computer. Same with Slack or Zoom. I'm not losing much since their core functionality relies on an internet connection. Full-blooded browsers are also more likely to stay up to date than the bundled Chromium build, and I can enjoy the peace of mind from a modern browser sandbox.
This is a classic 'My job is X, so I presume people doing Y also have the same experience"
Software developers and PM's can generally get by with a browser, but woah boy good luck getting the finance world off of desktop Excel/Bloomberg (as the most prominent example of an immovable force against browser apps).
> The fact that browser apps replaced desktop apps eventually kind of proves that the same on mobile is inevitable once computing power and efficiency is sufficient
Let me know when the power is there for the desktops. My MacBook M1 Pro chokes a lot due to running Teams, Slack, VS Code all wanting to be desktop webapps and are highly inefficient.
I have to use a proper desktop to get everything running smoothly together.
There's a reason software trends towards higher level, less performant abstractions over time. The takes about chrome being a memory hog or electron being inherently slow are very tired at this point
And garbage collected languages are slower than managed ones. Should we avoid garbage collected languages for all software then?
It's just demonstrates a very poor grasp of what actually matters in the world. And the performance gap is greatly exaggerated.
Most people would agree VS Code is very snappy, and it's written in JS and browser based. There's no inherent reason they have to be slow. And we don't double the RAM in computers every few years to leave it unused
The problem is that Electron apps are slower today than native apps were 10 years ago, despite computers getting faster and available RAM on my machine quadrupling.
I understand why developers like Electron, but like everything it's a tradeoff.
Exactly. This is a developer culture problem as much as it is a technology problem. Developers care less about runtime performance than other development factors, so they choose technologies that sacrifice runtime performance for developer speed and comfort. Is the root cause even deeper? Why are we so focused on developer productivity? Do individual developers really not care about performance, or is it that their companies are insisting that they poop out whatever crap they can in as little time as possible?
> > Electron apps are slower today than native apps were 10 years ago, despite computers getting faster and available RAM on my machine quadrupling.
Desktop software today seems to be slower than desktop software even 20 years ago, when RAM and hard disks not only had less capacity, but were also slower just as CPUs were slower. As an industry, we have sacrificed so much at the holy altar of Developer Productivity.
> it that their companies are insisting that they poop out whatever crap they can in as little time as possible?
Very much this but management are not requesting Electron. They see that JavaScript developers are cheap and plentiful, and JavaScript devs want to use JavaScript, even if it isn't a desktop language.
If you don't think having to run _an entire chromium stack_ just to display something, actively bypassing all of the OS's rendering facilities to draw some stuff on a canvas, I have a bridge to sell you.
> And garbage collected languages are slower than managed ones.
What..? Many common managed platforms are also garbage collected - .NET and Java, for example.
If I assume you misspoke with “managed” it still is untrue that garbage collection means “slower” because “slower” says nothing about whether you are measuring throughout or latency.
I only know internet commentators to talk about how VS Code is fast enough. In meat space, no one has ever said that VS Code is performant, just that it is free and X company has standardised on it.
> And we don't double the RAM in computers every few years to leave it unused
On a point of clarity.
Who is we?
I don't want my browser taking up 14gigs of my 16gigs just to watch a cat meme...thanks.
I would like my experience to be improved and elevated while using less resources. Efficiency.
> It's just demonstrates a very poor grasp of what actually matters in the world.
I find this particular statement...lacks any modicum of humility. One might say it ventures into dangerously callous.
Put simply, outside first world economies, most of humanity does not earn enough money to buy a new macbook pro/ Dell XPS every 2 years nor have access to fast internet...relying on crappy broadband instead.
Even those people deserve efficient software that does its utmost to not hog the little resources so they can get things done yes?
The biggest problem with VS Code is that it doesn't actually do anything, all functionality is performed via plugins which have dramatically different performance.
So most of the time people are not discussing the same application experience. VS Code with nothing installed isn't that bad, once you start actually using it for code then performance drops off a cliff.
> The fact that browser apps replaced desktop apps eventually kind of proves that the same on mobile is inevitable
I'm not sure whether it's that black and white. If you've worked on both platforms you know how much of a different beast mobile is, it's a lot less forgiving in a lot of aspects. The use cases and interaction model is very different.
I disagree and I think it's a common viewpoint from people who invested significant time in the apple or android ecosystem. Of course you'll be happy to have native developers helping you out in your career instead of becoming yet another web developer.
I'm not a native developer (kind of jack of all trades) but I had to do some tasks in iOS, Android, web and desktop development.
iOS and Android are incredibly overcomplicated. Web used to be fine but it's going in that direction as well thanks to Angular and React.
I wish just using Qt was a viable choice.
I used to work in a company with a very popular app (can't tell how many active users but they have 2.5M reviews right now and they're top 50 in the iOS store) and the only reason they weren't web cross-platform is that they saw an exodus of native developers once they attempted that.
They had huge parts of the application in web-views though, so we had half of the animations native and half native. They had a native canvas based editor and 3D games running in a webview (as crazy as that may sound: that's exactly the kind of thing I would have done natively - but they didn't want to implement 3D games twice for web / android and metal).
I can't really say I could tell which was which but error logging was happening in different places so you would normally find out when debugging errors or seeing the web-views in the code.
5 years ago is a lifetime in tech, the blog clearly mentions the difference. Web dev stack is a dead-end professionally? That doesn't line up with reality at all does it.
You attracted better-qualified colleagues? How so exactly? You have a smaller pool of candidates to choose from. Are you implying native developers are just smarter?
Outdated opinions, favouritism and elitism all wrapped in one.
The problem of the post is that it advocates two things at once: publish apps using Ionic, and/or just go the webapp route (like Wordle).
It's a little hard to understand, if the performance of webapps is actually indistinguishable from that of native apps, why anyone would choose the app store route. Is it for distribution purposes? Payments?
The main thing that makes a non-native app stand out today isn’t performance, it’s all the little UI inconsistencies. And not just the shapes and colors; the font sizes, the types of transitions that happen between screens, the “pressed” and “loading” states on buttons (or lack thereof), etc. The modern web gives you everything you need to do all these things, but you don’t get them for free. And many devs don’t think to implement these details, and even if they do give them attention and make the experience good, it may still be inconsistent with the host platform. That’s what’s hard.
For this app it makes total sense, because it already seems to have a pretty custom look and feel; there’s nothing that needs imitating. Many others out there are probably in a similar boat, but certainly not all of them.
Isn't that a good thing? Text should be selectable and copyable by default, since that does not induce any harm whether the user do it or not, but the reverse is not true.
The number of times a Windows UI shows me an non-copyable error code is vastly greater than the number of times I wish I cannot select any text (which is zero).
I don't know about the Windows 10/11 UWP stuff, but in any good version of Windows you can hit control+c on any standard dialog to copy the error text and the text of all buttons to your clipboard.
It's a little annoying that you can't easily make subselections in dialogs, but that's been a core Windows UI design element going back to Windows 1.0.
It's a grossly underadvertised feature of Windows and I bet the people reimplementing the Windows UI for the third time in ten years don't know about it either.
On iPhones at least with latest OS, using built in OCR is supposed to be especially easy now. Maybe that has been exaggerated now, but if it is a one step thing, that could be better than being able to copy as copying stuff sometimes includes things you don’t want and can’t exclude.
Yeah. You can prevent that too with a CSS property, but again, it’s not the default; you have to have enough time and attention to detail to go out of your way and handle it
My favorite feature in recent iOS is that you can defeat that CSS property by taking a screenshot and letting the phone OCR the image, then copy paste from the result.
Disabling copy is abused by all sorts of apps. (Yelp street addresses are a prime offender.).
I’m not convinced allowing it to be disabled is a net positive.
It’s fairly essential for things like buttons and tabs that get tapped all the time and have mostly non-content text. But it does need to be used sparingly
This used to be the norm on older versions of Mac OS, and that was good. It would help enormously when writing blog posts (e.g. copy the descriptive text somewhere rather than transcribing it) or searching the web for the content of a en error message that popped up.
Absolutely do non-tech-savvy people care about this. It’s like a film — they may not be able to explain it, but they know a good film from a bad one.
I’m the “tech guru” for many of those who know me, and I’ve seen people of all ages struggle with mobile UIs. There’s two axes with two values, making four categories that I find problems fall into:
- Simple concept + familiar UI: User is at fault (usually a misconception). I rarely see problems in this category.
- Complex concept + familiar UI: User struggles to understand what they’re trying to achieve. A little bit of extra info helps them make sense of the situation. Very easy to help the user over the phone in this situation. Often, thanks to good UI, the user figures it out themselves.
- Simple concept + strange UI: The user knows what they want to do but can’t understand what the UI is conveying, can’t find the UI controls, can’t express what they want via the UI controls, or sometimes don’t even realise something is interact-able. Even if the user understands the concept, they often struggle to succeed after stumbling their way through the app for any length of time, and need assistance. Apple iOS’s “swipe from different corners to get notifications & control panel & home & etc” and “three fingers/hold to do textual things” are good examples of this.
- Complex concept + strange UI: Situations in this category can get so difficult & time-consuming that it’s often easy to just do what the user is asking for on their behalf, or give them a step by step process they can repeat.
The things that make a UI familiar or otherwise are subtle, like what makes a film good or bad.
UI/UX designers come up with all these “clever” ways to do things, like the breadcrumbs interface on the Notion app, but many users simply don’t figure out how to use them. And they don’t think to use an element/gesture when they seek to achieve the very things which that element/gesture achieves.
I am a near-luddite on my mobile phone, but über-geek on a desktop. This weekend, I was trying to open a text file attached to a Gmail message, then search and copy some text.
Step 1: Use Gmail Android App to search my inbox for old emails with attachments with some text to me. Cool, found the email.
Step 2: Open the text file attachment. Gmail Android App does not open text files natively (weird, right?), so it defers.
I tried a few different choices. None of them allowed me to both search, then copy some text. (Note: I have a /very/ vanilla Android mobile setup.)
I spent fifteen minutes, then gave up and opened the original email on a desktop Linux web browser. I found the text, then copied, and sent back to my mobile phone by email. Then, I opened the email in Gmail app, copy/paste.
Sheesh. I thought: Am I an idiot? I felt like a struggling grandparent using a phone with the "big dialing pad" after that experience. (No offence to the big dialing pad -- always a big fan of the UX!)
Having a cross platform app (Flutter) with tens of thousands of users for a few years now I can tell you that not a single person has cared to far.
I get 20-50 mails daily through a very easy to use feedback and support function, but in none of those thousands of mails has anyone ever cared about how transitions are made or that a button doesn't look like a native iOS button.
They care about the value the app provides. About new functions or (in my case) report bad data to fix. That's why they download an app. Not because they want the button to look natural.
That's to say. I frequently get feedback about how they love the UX/UI of my app.
If there isn't a valid reason to create a native app these days I consider it a waste of time.
Can second this. Nobody ever said anything about these subtle details and I think there's a very good reason why that is:
Most native apps also have inconsistencies, lags, delays, especially if they connect to some remote web service. Heck, the iOS settings occasionally hang on my phone when I open the iCloud settings or if some Bluetooth device isn't correctly pairing or whatever.
I've seen beautiful native apps that require an internet connection all the time, because they save every little piece of data on a remote server and sometimes, the whole thing is super unresponsive.
For the muggles, this lag is a lot more noticeable than a transition or a button press that is not 100% optimal.
My Ionic app uses PouchDB and CouchDB, is offline-first/local-first and is responsive at all times, because it simply doesn't care if it is online or not. This is what users feel the most and it can feel a lot better than many internet-connected native apps.
You wrote: <<I've seen beautiful native apps that require an internet connection all the time, because they save every little piece of data on a remote server and sometimes, the whole thing is super unresponsive.>>
I have see this multiple times for enterprise software. It works when the data center is on the same continent, e,g., New York to Chicago or London to Frankfurt, or Santiago to Sao Paulo. Now add 20km+ roundtrip on fibre -- Tokyo to London. It is a horrible user experience. I have seen teams trip over that wire (pun intended) more than once in my career!
When one is drowning in a torrent of superfluous UI changes and the UX mediocrity of Windows, Android or Linux, poor software seems inevitable.
Those that do notice, likely assume that the dev can’t do better or doesn’t care.
What would you do if somebody did complain about your UI or UX, rewrite the framework’s UI controls and animations? Switch frameworks? You’d probably thank them for the feedback and say you’ll add it to your task list, where it will linger for weeks or months until it’s closed “won’t fix” because only few people asked about it.
I notice non-native apps. Even if it is very subtle: Apple has some menus around the iCloud settings interface that are actually a webview.
But what am I supposed to do, mail the dev telling them to make a native app instead? If they haven't made one, I understand that they can't afford it.
On your phone, open Settings, then tap on your name (apple id), then tap on "payment and shipping", "subscriptions", or "media and purchases" -> "view account". All of those are webviews.
If you're using that as indication for WebViews than you'll be miss-identifying a lot of native apps as well, because that's all set by the developer - both with native apps and with WebViews.
My impression is that lots of users have been so affected by frequent encounters of bad UI that they just internalized it as they're "bad at computers/technology" and become afraid of doing anything. Maybe they'll go read a book (on paper) or something.
Whatever they do, complaining about the bad UI to the people who might have done something about it isn't it.
When users raise an issue like this, I try to show empathy right away. I know they are already on edge thinking: "Am I the stupid one?" Of course, there are users with nothing but packing peanuts in their brains, but the good users with real brains... be good to them when they raise an issue!
I agree. The knee jerk reaction of many otherwise highly educated corporate users when there is a UI issue: "Oh, I must be doing something wrong." So often, something is wrong on the server that is causing horrible lag or weird errors.
It is more amazing when you meet a very resilient user (think: senior sales staff -- they'll do /anything/ for a sales commission!). They just assume this is normal operating procedure. Only when things are horrible, do they ask for help. Then, you stand behind their desk and watch in horror at all the bugs they workaround (many times per hour!) in your app, but never report... Hat tip to these amazing users!
I also always wonder this, as it constantly seems like the only people I know who care are people who have gone out of their way to study UI; everyone else seems to find bespoke UIs "fun". It certainly doesn't seem to have hurt game developers much that every game has an unrelated UI..
Also desktop cross platform native GUIs. Programmers always complain about this, but most users are on windows and for them the GUI is just going to be ugly. No user is going to care that it is native.
Yes, you nugget. That's why UX is a thing. Just because you know how to traverse your thinking patterns doesn't mean anyone else (wizzards included) can.
Surefire way to write garbage applications and APIs: don't think about the user.
I beat this mentality out of any junior that crosses my path. You're not paid to write code, you're paid to deliver a product. You studied how to write code. Massive difference
I think small bits of irregularity in a UX breed uncertainty, which breeds anxiety, probably even moreso for non-technical people who can’t quantify what they’re seeing. It may not be something conscious that they can articulate, but I’m confident that it matters.
Yes, I absolutely think they do, whether they realise it or not. Overall I believe that computers have never been harder to use and this "nobody cares" attitude is exactly why.
To use my father as an example, he sat at work with computers on his desk for 20 years, running everything from Windows 3.11 to Windows XP. He never had a problem using or understanding the computers in front of him because generally any pattern that he learned in one place would apply pretty much everywhere else on the system. Buttons had a uniform look. Radio controls worked the same way. Menus were in predictable places and had similar structures. Toolbar icons, if present, had a uniform appearance. Folders and files were presented uniformly. Tooltips appeared over many things if you hovered your mouse pointer over them. Embossing, solid, thick and dotted lines all had meaning designed to guide the user in certain directions. Disabled controls looked visibly non-interactive. Even "Open", "Print" and "Save" dialogs were globally consistent.
In that regard, older versions of Windows were beautiful in their simplicity — they were uniform and predictable. The same is true of classic Mac OS also. The reason for this is because both Microsoft and Apple spent a lot of time and energy working with real world users to figure out what made sense and what needed work. The result was that they both ended up with clear user interfaces that had learnable visual cues.
Then this aesthetic design trend started and now user interfaces have never been more unclear. Overwhelmingly UI elements are now flat or inconsistent in their appearance. It isn't clear at a glance which objects are interactive and which aren't, or what the side effects will be when you click on given thing. To make this worse, Electron happened, effectively leaving developers (who usually have completely insufficient understanding of user experience or design) to roll their own user interface toolkits and to build applications that end up looking nothing like anything else on the system. So now you don't just have to contend with the fact that the operating system controls aren't as friendly as they used to be, but now every application is out there trying to play by its own rules too, with their own designs and their own learning curves.
Now we're in a situation where very little of what you learn in one application makes sense or applies in another, which is the epitome of user hostility. I spend a lot of time trying to remotely diagnose wildly inconsistent applications over the phone and try to help him make sense of the mess that is modern day desktop computing. He rightly finds it confusing and overwhelming. Even in my own experience, modern macOS isn't much better.
At this point, Microsoft's "Official Guidelines for User Interface Developers and Designers" (2001) and Apple's "Human Interface Guidelines" (1995) should be mandatory reading for everyone who thinks they know better.
There's real psychology and methodology to building a good user experience. Every single detail matters.
This! This is my exact experience (well, with Mac:s and Amiga:s). My father introduced courses in Desktop Publishing and Digital video editing in the late eighties and into the nineties in his county school. He understood computers to such a degree that he could successfully teach others to use them.
He is older now, still fully cognizant and lucid and gladly aging has not taken its toll yet, but he has mostly given up on computers for the very reason you write about so well -- interfaces became more and more fractured.
Things are not where they ought to be, they look different across different applications on the same operating system, they behave in different manners, and all these idiosyncrasies add up quickly, so he resigned and became mostly a consumer of content rather than a user or creator of such. He still has an old PowerBook (next to his modern M1 one) with an old copy of Adobe Illustrator as a poor man's CAD to draw and print things like cable installations and load-bearing sections of walls. It saddens me because he has such a great talent.
While we came to where we are today as mostly a slow decline, I would say it was a two-punch combo that finally broke user interfaces for good: First the complete annihilation of skeuomorphism in favour of design without any cues whatsoever, it might have looked ugly and certain abstract concepts might not have mapped well to the semantics of the physical world, it still offered a clear distinction of what was "interact-able" and what was not. And second, the introduction of Electron-type applications finally ended it.
I'm not sure there is a way out of this hole, so I am mostly resigned to not complaining to developers of apps like the original author either. Because what good does it do?
And Google’s Material Design happened as well. Just a horrible pattern. “Assume all of your users are experts in the app you’re building.” I have no idea what half of Google’s icons mean.
With Apple’s Human Interface Guidelines, it’s as if they consulted with actual humans. Material Design? It’s as if they hate the humans that have to use their apps.
> “Assume all of your users are experts in the app you’re building.”
In Google's defense, I think the original rule is something along the lines of "assume all your users or experts in their field". Which is quite true, users pretty much all the time know what the outcome of what they want to do is, they are also knowledgeable in their line of work or hobby for which you are creating an app. So use their domain knowledge to help them along.
Hey, author here. Yeah you make a really good point, if I had to start an app today where the visual design was pretty close to the default iOS and Android styles that would definitely be a factor.
Funnily enough though (and this might just be my lack of skill in iOS development) I always find the UIKit components surprisingly tough to customize.
I would bet the last thing is intentional. iOS has a reasonably high level of consistency over all apps. Mostly because it’s hard to customize UI elements. And that’s what at least I like about it most
Yeah. And then there are also varying levels of in-between options: React Native lets you write and share JS code but delegates to native UI components on each separate platform, while I believe Ionic actually offers a set of UI components that are web-based, but are designed to adopt the look and feel of each platform as needed. Each of course comes with its own set of trade-offs
This was still a great case-study though! It’s good to have concrete evidence that the performance side of things isn’t an issue
Not if you're trying to make a playful app design like the author is doing. This design is halfway between a normal application and a game.
I would do silly things like clickable image views to get the style right if buttons don't provide the necessary customisability, were I in the author's position. I don't think anyone would be happy with that.
I'm all for platform consistency, which there is very little of these days, but for every API you restrict someone will find a good reason to work around it and that's where the ugly hacks come in.
Really disagree with this. Apps are rarely unique to a platform, and most users aren't on a single platform. I want Google Maps to look the same on the web regardless if I'm on macOS, Linux or Windows, and on my Android phone.
On the web that is fine. As a native app, it should fit in with the platform. On iPhone Google use the Android design language, and it produces apps which simply do not meet expectations.
Ionic co-founder and Capacitor creator here: thanks for sticking with us on the journey. The stack has actually been really successful for us. We've been able to build a significant business on top of web native apps because they work really damn well for a whole class of data-driven apps.
We've also seen a renaissance of sorts recently with this new generation of web developers realizing they can use their favorite web stack to build for mobile. A lot of them didn't "grow up" with bad phones and Cordova being the only option in town, and coming into the space with fresh eyes to see all the progress that has been made.
We are excited about seeing better UI tools and frameworks that raise the bar for mobile experiences with web tech. When we started Ionic Framework, there were few quality options. Today, there are a lot more, and we're thrilled if people want to use their favorite stack on mobile with our Capacitor project.
Author here, just wanted to say thanks for making Capacitor. It's been an absolute pleasure to use. Something about the plugin architecture just really clicked for me. I hope I wasn't too negative about Ionic at the start of the post, I get a little carried away while writing sometimes. Love your work, and thanks again. :)
> Our reaction time is ~200ms, we don’t need 100ms.
Our reaction time doesn't matter when it comes to the look and feel of an application. You can clearly feel the difference between an old DOS computer with a CRT putting characters on screen nearly instantaneously and a modern text editor having a whole UTF-8 rendering pipeline to deal with first.
We've all slowly been growing accustomed to these high latencies and the bar of acceptable performance has been lowered, but that doesn't mean such latencies don't matter.
Personally, I find browsers noticeably less responsive unless developers go out of their way to reduce latency and overhead. Leveraging things like CSS animations makes a huge difference because even on slow hardware they feel snappy, but there are many other optimisations that you need to get the job done.
That said, if the web version was already reasonably fast then I don't see a problem with porting it to mobile
If a mobile browser can operate a website with tolerable performance, then why not stuff it into a platform native webview and he done with it. You'll be fighting the terrible built-in browser engines of your user's devices (I've seen people refuse to update the Webview on Android because they don't know what it is) but your app just got a whole lot tinier and easier to update.
It would probably work the other way around just as well (Flutter to web, or maybe even Kotlin Multiplatform to web and iOS, I haven't tried the latter) if your port source is of good enough quality.
Reaction time and perception are different things not sure why author mixes them.. as a gamer having a ping of 14ms vs 90ms literally ruins competitive gaming. Pro players actually switched countries and cities to have better ping. Heck even getting a keyboard with less travel distance for each keys make a difference, just like how getting a mouse that has response rate of at least 1000hz. I have gone from typical desktop user to hardcore gaming user and each time latency improved it has helped by kd ratio directly. Even 5ms gains matter because worse case scenarios become less worse.. I notice everything above 20ms, but I used to not. One day I bought 140hz monitor it felt little better but not ground breaking I was almost disappointed. But then a week later I got to look at regular monitor, it looked like it was lagging constantly... Now I don't use my laptop because it looks so laggy now. I got used to faster frame rate.
The I notice quite few things:
- low fps animations
- delay until the keyboard popups
- no support to save the password or use e.g. an Apple account to login
- no scrollbars in the modal and the back button out of view
So in general, this would not make the cut for the native apps my employer produces. Especially the low fps is a deal breaker.
I find the claim "No one noticed" a bit hyperbolic. It's more like "and my change was easily tolerated". I certainly notice these things and I'll pay a premium for software that feels "snappy" any looks good.
Yeah, the title says "no one noticed" while the article says "my kid didn't notice" + no users complained. Which makes sense because this is an app that parents are making their kids use. The parents don't use the app and the kids have to. Who is going to complain that the interface changed?
The crash statistic may be an invalid indicator. Problems in your app will no longer manifest themselves as crashes in your native code because the only native code running is iOS's.
Hi, author here. Yeah that's a great point. With Capacitor when the browser crashes you just get this white screen and it wouldn't get picked up as an exception by iOS and reported on the App Store. I ended up having to add in custom JS crash reporting to catch browser exceptions, but I'm not 100% happy with it.
> Not brilliant, but hey, it’s a cheap Android tablet, what can you expect?
People on cheap Android tablets deserve the same experience as anyone else. You aren't rendering 3d graphics, you're displaying a few hundred characters of text.
There are hundreds of millions of users around the world with low-end Android devices. There are people in the world who are not rich white tech people living in suburbia, believe it or not.
> Are native apps dead? Not yet… but they’re going to be.
You don't have a crystal ball. What happens to all the legacy Java, Kotlin, Objective-C, and Swift code? That all just gets rewritten in JavaScript overnight? Right.
> You see as humans we’re comfortable with 60fps of animation performance. We don’t need 70fps
Bullshit. This person has never used a 144hz monitor. I'm never buying another 60hz display.
> Our reaction time is ~200ms, we don’t need 100ms
Our reaction time may be about this, but we perceive times much shorter in duration, which will matter if the tablet has a high refresh rate display like many of the iPads.
To be somewhat fair to the author, if the device's own setting app is slow and janky, you can't expect better from an application you download.
There are tablets out there, no name brands but also Lenovo branded ones, that are a complete waste of natural resources. I've had the displeasure of using a few of them in store demos and they couldn't even get video to play back at a consistent rate.
You're lucky to get an app working at all on that crapware, let alone at a smooth 60fps.
Strangely enough, I've had smoother experiences with some Chrome web apps on an old Android tablet than the native device UI is capable of providing. This thing was mid-range and outdated when I bought it years ago and it still runs Android 7 through LineageOS relatively well, but nobody is going to make that thing have a smooth experience. I'm hoping for the powervr video driver to be ported to postmarketOS so I can flash a lightweight Linux distro on there.
Sometimes, though, when the wind is just right and the stars align, Chrome is doing a smooth 60fps animation on that thing and I honestly can't figure out how they've manage to do it. It's impressive to see what modern web browsers are capable of squeezing out of slow hardware.
Total agree on all your other points. I don't think this stuff matters for this specific developer because of the nature of the application, but it's not great general advice.
> not rich white tech people living in suburbia, believe it or not.
Could really do without the racism. Tens of millions of non-white people have good phones.
It’s also a case of knowing your audience. If your app isn’t targeted towards Bangladesh, why optimize for those users? ForeFlight for example is native, iOS only. Should they release a version optimized for cheap Android devices? Of course not. People that can’t afford good hardware aren’t flying airplanes. Something like What’s App however, the audience is far more broad, so optimizing around the most users makes sense.
A non-native version of ForeFlight to me is a scary thought. Considering that it’s such a critical application being used by aviators in-flight.
GP is being a little hard on the author but high framerate applies as much to apps on mobile devices as it does an FPS game on a PC, particularly if you have touch based interaction. Even just simple scrolling will feel janky if you're only hitting 60 FPS on a high refresh rate mobile device.
Have you used an iPad with ProMotion and one without? Seriously try it, you can’t tell me that there’s no perceivable difference between the two when scrolling through something or writing with a pen.
I love to build both native and hybrid apps and while you have a pretty good write up you’ve made some pretty bold claims for a handful of app installs. I did try out your apps and to be quite honest they do feel very webby (non-native). For the use case however I suppose it works.
Have you considered going „full web“ with a PWA, foregoing a native container completely? That was my expectation when I saw the headline.
I have a couple of business apps implemented as offline-capable PWAs and the experience has been so-so. Still hoping for better browser support especially on iOS.
Customers love that they can instantly push updates and are not bound by arbitrary rules enforced by the gatekeepers (App Store, Play Store). Bit of course some crucial things are missing. App discovery through the platform app store for instance is something that just doesn’t need to be explained to users. Also the absence of push notifications hurts.
I’ve been writing cross platform apps for many years now and a huge change that I don’t think people have noticed or understand is Cordova vs Capacitor. I put up with Cordova but always felt like I was on the edge of my builds breaking. The process to create the native project in the fly was always very inconsistent in my experience. The first debugging step for a failed Cordova app build was “try it again?”, that’s a horrible way to develop/live.
Then comes along Capacitor. I assumed “Ok, it’s just the newer version of Cordova”, I couldn’t have been more wrong. Things that were a huge pain with Cordova (building the native project from scratch, any changes to the native project for things like capabilities/permissions, the version of Google apis conflicting, etc) are gone. You now commit the Xcode and Android Studio projects to your source tree. This makes builds so much easier (throw fastlane into the mix and you’ve got something really awesome) and makes writing native code super easy.
I didn’t think I’d ever want to write native code for a cross platform app but Capacitor makes it stupid-simple to drop down to native code whenever you want. No more packaging your code in a plug-in (if you don’t want to at least), just add a class with the right annotations or extending the right class and you are calling native code from JS in no time at all. Native used to be scary or hard to work with in Cordova, that’s no longer the case in Capacitor. It gives me a ton of freedom and finally makes me feel in control of my builds and my app as a whole.
If you’ve slept on Capacitor I urge you to give it a shot, it’s quite nice to work with and fixes all the major pain points I’ve had over the years with Cordova.
Eh, Ionic is good. I’ve retired native apps that I wrote, in favor of Ionic apps that someone else wrote, and felt fine about it.
But that “someone else” is a very good engineer, that did a great job.
Good software is always gonna be difficult and expensive; regardless of the tools and platforms. Good engineers are expensive, and take the time to do things right. No shortcuts. No free lunch.
We get all hung up on the tools, as if they make us good. It’s like someone with money, buying a top-of-the-line PRS guitar, and playing Smoke Over the Stairway to Freebird.
If a tool makes it easy to do something cool, and, suddenly, we can do something we couldn’t, before, that’s nice. Enjoy it while it lasts. Some kid will blow us out of the water, using the same tool, shortly.
Native will always give the best UX, if done by expert native developers, but, in many cases, this may not make financial sense.
Also, bad native developers will do bad work; even though they are using top-shelf tech (Smoke Over…).
> Guaranteed you could not tell if 10 randomly chosen apps were developed natively or cross platform.
Depends, if it's React Native it's actually getting hard to tell with all the work they've done to UI performance and animations etc. Flutter or a wrapped web site on the other hand are immediately obvious to me, in fact there's a certain flavour of Flutter jank in lists that is an obvious tell. I can also tell when an app's using SwiftUI due to the presence of a particular navigation bug so "native" toolkits don't get a pass here either.
I'm not sure it's pretentious it's just those developers are close to the topic and have opinions about it - you see it in other areas of software development too.
I'm a strong believer in web-apps-as-mobile-apps (at least for my current use case), but I'm curious what the best way to package a WebView into a mobile app is these days.
This article recommends Capacitor, but although they say "drop Capacitor into any existing web app" - they actually mean any JavaScript application. I have an Elixir app, I just want to put it in a WebView and cut iOS/Android versions. What's the best way to do this in 2022? I've stumbled upon "Jasonette", but have no idea if it's the right way to do things these days.
Does anybody have any recommendations they could share?
I think this type of decision comes down to resources available for development - if you're a one-person (or very small) team, managing one code-base and one deployment stack is way better and more reliable.
On the other hand, native app performance is second to none when done well, and if you have dedicated developers to manage a separate deployment from the web interface then you're going to have a better time going native.
There used to be this thing called AIR where you could build a game and...
oh never mind.
Turned out the big problem wasn't cross-platform compiling, it was dealing with Apple randomly telling you that your game was removed for some totally random reason and forcing you to upgrade it and submit it again every couple weeks.
Like, great, you compiled something for iOS. See how far that goes haha.
I have been in the mobile dev industry for over a decade and I can tell many have claimed that native development will eventually die. Here we are still working on native Kotlin and Swift. It all depends on the company, client and budget. So nothing will die, hybrid development won’t die and so do native.
We are doing this right now. We run iOS in an enterprise B2B setting and Apple made it shitty enough for us to look at more open paths.
Our strategy for webapp involves nearly 100% raw vanilla javascript and some very unconventional techniques. One of my team members is about to demo it to a client.
hard to estimate as most of the 1000 or so lines of swift code was there to talk to the native iOS Apple Music APIs for auth and playback - which wouldn't be a thing in Android. If anyone ever starts using this app I'll probably take a look lol
Has Flutter fixed its horrendous web application performance yet? Every time I go back and give it a shot I'm appaled at how laggy the web backend is.
The mobile backend isn't very power efficient either if I'm being honest, but at least the resulting experience is acceptable in terms of smoothness and responsiveness.
In fact, if you consider "native" to mean "using the standard platform frameworks", then the stated proposition "Are native apps dead? Not yet… but they’re going to be." will be realized by Flutter.
You could say the same when comparing native iOS apps vs web apps, and these days almost nobody cares. This jankiness will be solved --wether it is by optimizing flutter's core rendering engine or just because mobile devices will receive more powerful CPUs.
One way or another you will be able to build hugely successful multiplatform apps just using Flutter.
Doesn't Apple forbid publishing web apps on the app store? How is it then possible that something like ionic framework and react native still work? Unless they literally translate all html features to native components but I seriously doubt it.
Edit: This is a "talk to sales" framework and ionic is 50€ per month as the absolute cheapest option. This is essentially an ad then.
It wasn't only games, but having been there the cambrian explosion following the appstore's release was very much 95% games (much to Jobs' dismay).
> WebOS’s apps were as good as any other platforms apps and were PWAs unless I’m mistaken.
They were built out of "web technologies" (HTML and javascript) but they were not PWAs as they were significantly augmented with native components and concepts, none of which were part of the browser (even as proprietary extensions). That's like calling Firefox a PWA because it's built out of XML and Javascript (or was, not sure that's still the case).
iOS' first draft (pre appstore) was pretty much just web pages you pinned to your springboard (which you can still do). There were a few allowances for removing browser chrome and the like, or providing a few icons, but for the most part it was exactly what you'd run in a browser.
This post makes very big claims based on a very basic application that doesn't seem to be much more than a few toggle buttons and a couple of animations thrown in, and some 'statistics' that don't appear to be based on any actual facts.
I work in a team developing an app that has around 5million users, and we abandoned an Ionic first version 5 years ago, after a couple of years of nightmarish development, where (after the first implementation, which went reasonably well) we spent most of our development time fixing inexplicable bugs, chasing native features, getting inconsistent UI problems, broken builds from package updates and a myriad other problems that just drained our energy and were generally dispiriting.
I personally felt the entire experience was a horrible professional dead-end. Luckily our management decided to switch to a native application, and learning Swift has been the most fulfilling part of my entire career. The application is faster, more reliable, the bugs are locatable and fixable; the entire framework feels solid and professional.
The application itself is immeasurably better now. We attracted better-qualified colleagues who have been a great learning resource. And the app itself went from an appstore rating of (iirc) around 2.8 stars to its current rating of 4.6.
We would never dream of going back to the nightmare that developing a complex and performant app with Ionic was in my experience.