Hacker News new | past | comments | ask | show | jobs | submit login
The End Is Near for Mobile Apps? (medium.com)
144 points by miguelrochefort 4 months ago | hide | past | web | favorite | 180 comments

This is written by someone who lives in the "web eats everything" bubble. It also neglects the apple store.

The fact is, webapps are suboptimal, and unless something drastically changes, will remain so. Unless you have decent caching, they are slow, difficult to use, and generally annoying.

Why? firstly HTML/JS is a very slow presentation layer compared to native, which means less battery. You still can't multithread, so any heavy lifting is serverside, which means latency in anything other then decent bandwidth areas (so no travelling for you....)

Secondly, and possibly most importantly, the GUI language of the native OS doesn't exist, which means everyone re-designs every thing, making things much much harder for end users, old people and hard of sight.

Consolidation has a point, but I suspect its the OS that will provide these apps/function.

The data I have seen from the old company was this: people who installed our news reader app were 4-8 times more engaged than the people who used our uber mobile friendly and fast news site. Apps can be faster, handle offline/near offline far better.

Apps are here to stay, until mobile web changes from a inefficient presentation layer to something more like a windowing toolkit.

Sorry to say but from my perspective you seem to live in a bubble as well, to use your words.

What apps do is add eas of install (app store), and usability (cache, use device sensors, do some offline tasks)

For a webapp the installation is "Add to homescreen" on a webpage. It then behaves like a native app, no address bar. Usability is tackled by modern browsers that allow webapps started like this to: - cache the entire webapp, and some/all data it requests. - run webworkers in background, (get push notifications, etc) - provide sensor access via APIs, (camera, etc) And to conclude, todays webapps respond FAST. They do everything the same way a native app does.

Ofcourse if your webapp does video transcoding or uses some specific OS feature it might profit from being native. But even then, its unbelievable easy to wrap your webapp in a shell that adds these functionality.

How do you think FB and other popular content consuming apps work nowadays? You are basically looking at webapps rendered in a shell that provides the few APIs a browser doesnt yet have, like share button and contact/calendar integration, to get/set data specific to/on your device.

Almost nothing you said here is true. Add to homescreen is a horrid broken mess on iOS, caching is broken/bugging as hell on chrome and safari, webworkers are really horrid battery drains and again don’t work on iOS. Wrapping a native HTML5 mixed with native code results in a buggy, spaghetti code mess of an app.

Also literally NONE of the biggest most popular apps are HTML5/native. FB, Twitter, Uber, etc... are all native apps.

Yes, Apple is good at keeping their web stack good enough for "regular" web browsing but not feature full enough to compete with their native toolkits. And of course, doesn't allow alternative implementations of the web stack on their platform...

That will be irrelevant in 7 years (time horizon in the article) since Apples's device share will continue to dwindle relative to Android. It will be the same as the historical OSX/Windows ratio. They already signaled that by focusing on pushing up the price per phone versus the number of phones as their stock price driver.

Arguing “market share” as a headcount instead of, say, disposable income share or % of mobile spend, is like arguing the 1% is irrelevant because they’re only 1 in 100.

Isn’t there a security argument for limiting native APIs to apps from the App Store?

True but for web apps you use the same way to give permissions to use your device sensors you would use for a native app. The only difference is that it doesn't pass through the app store review process and apple gets no cut for it.

> for web apps you use the same way to give permissions to use your device sensors you would use for a native app

Which would mean any malicious site a user got tricked into visiting can access the native API. (Downloading an app is more deliberate than visiting a site and instinctively clicking to make the pop-up go away.)

All I'm saying is there are non-financial reasons why an OS designer might sandbox websites from the native API.

So the problem appears to be ios in this case. I personally have 3 web apps on my android phones home screen and they offer a decent experience same as a native app. They are not processor or graphics intensive apps but the same applies for a lot of store apps

OTOH, on my Android devices I find "add to homescreen" web apps to feel janky and non-native.

I like React Native and apps written in it are just fine by me but the browser and the web doesn't compare in L&F or responsiveness. Maybe someday down the line, but not now.

This could also mean that Android native apps are just worse than iOS native apps.

if you put it like this then it could mean a lot of things.

I agree with GP's reasons, but not the conclusion. Native apps are going away, which is a shame, because web apps are bad.

> For a webapp the installation is "Add to homescreen" on a webpage. It then behaves like a native app, no address bar.

Only as long as you have an open Internet connection. Maybe a properly made web app will cache itself somehow, but that process is relatively obscure and (from the user's POV) pretty unreliable. Whereas a native app is an executable on the phone, it will run whether or not you're on a network.

> They do everything the same way a native app does.

Only slower and worse. Between basic UI functions being (poorly) reimplemented one abstraction layer and extra VM level higher, and random 404 screens because oops, you briefly lost connectivity, it takes lots of extra work to get a web app to native level of quality - at which point one might want to consider why they didn't write it native in the first place?

> How do you think FB and other popular content consuming apps work nowadays? You are basically looking at webapps rendered in a shell that provides the few APIs a browser doesnt yet have, like share button and contact/calendar integration, to get/set data specific to/on your device.

Yes, I can tell, by the frequency with which it breaks in unexpected ways, and shows its internals - by e.g. giving you a web error page instead of the app-specific one, or just giving you a blank screen.

Webapps are just "worse is better" in action. Gross.

FB was at one time a web app, today it is a monstrous objective-c nightmare (someone a couple year ago measured 18,000 classes in the codebase). They never could get the web app to work. Building iOS apps is what I do for a living, its really not that hard.

That app, or rather its descendent, still works, and is arguably preferable for privacy and battery.

Of course they would, in fact they already do, it's the Facebook website itself.

Is there a _convenient_ way to bill the user for microtransactions and subsriptions, after you have added the page to the home screen?

As far as I know, the web alternatives are miles behind the convenience of ”click the side button twice to confirm this payment” that an app provides.

On iOS devices that support Apple Pay, yes, this is available to the browser for transactions. Not sure what mechanism exactly, I’m just an end user using Apple Pay to pay on websites in Safari on my iPhone without any issues.

>How do you think FB and other popular content consuming apps work nowadays?

Majority of the content on these apps is native and not html/js. They have a small amount of content on the settings screens in html/js but all of the main view code is native. For an app with complex layouts and content like facebook, html/js scroll performance would be far too slow. You can easily verify this by running the application with UIAutomator turned on which will show you the widgets being used on screen.

Native is faster because it's not layout and control agnostic. So you get controls like recyclerview which recycle view elements while scrolling large lists to keep animations smoooth. Sure, you can implement that in javascript too, but the javascript can't beat a native c++ implementation which is also GPU accelerated. This is also the reason why frameworks like React Native and Flutter were born. They use javascript/dart but render all UI content natively which allows them to maintain smooth 60fps animations.

To be honest, I wouldn't like mobile going the html/js way at all. Html/js has moved to desktop with electron and the results aren't that great. They take up huge amounts of memory ( gmail web on chrome takes up 500mb of ram on my machine, also slack is a noteworthy mention). Native desktop apps take up a fraction of that memory. For the sake of accessibility we have significantly sacrificed performance. I can't wait for webassembly to be widely adopted so that the browser can move away from html/js. Google has a nifty tool called ArcWelder which allows android apps to run in chrome. Apple has already announced support for running iOS apps on Mac. Would people really want to use html/js apps if they have native and more performant apps available on their platform?

> For a webapp the installation is "Add to homescreen" on a webpage. It then behaves like a native app, no address bar. Usability is tackled by modern browsers that allow webapps started like this to ...

Does this finally work? I remember first reading about this many years ago. I tried to make a simplest-possible webpage that I could "add to homescreen" and have it work like a native app. Unfortunately, there were too many critical features that were missing, broken, or unreliable.

Every couple years I've tried again, and every time I've failed. Does it finally work? Is there any example of a webpage which can successfully pretend it's a phone app?

> For a webapp the installation is "Add to homescreen" on a webpage. It then behaves like a native app

No, it doesn't, I'm sorry. It's often a far cry from how a native app would be behave, both in terms of usability and performance.

90% of apps just deliver information and work just fine (or better) on the web, at least for me. Nobody needs a reddit app or a Medium app, even though those companies try to convince you otherwise.

Yeah, I'll download an app for Uber or Southwest airlines or Airbnb because their two-way information requirements work better as apps. But I won't clutter up my phone with things that work just fine in a browser, which is most of what I need. I don't play games, so maybe I'm not most people.

If only the web made it easier to completely revamp someone else's pages... Reddit is a great example - on mobile, I still use the "reddit is fun" application, which is a solid piece of work. It's lighter than the old Reddit, not to mention the shitshow the new Reddit is. It has much better UX than the webpage. I'd use it on my PC if I could. All this is possible, because right now, APIs change slower than webpages, so if a service is publishing a functional enough API, there is a way to fix problems with the official interface.

Good point. I miss Twitter's API.

>Nobody needs a reddit app

Here it's true if you talk about official app, which you seem to be doing, but there's a couple of other options - apps made by community, which can be way better than official anything. I guess that Reddit doesn't want to fall behind and that's it.

Relay is awesome on android. Way better than the official.

Nobody needs an app for anything, but the Reddit app is far superior for me vs. their mobile experience. So much so that I refuse to install it because it makes Reddit far more addictive. Same for Facebook. A huge percentage of their usage is the mobile app vs. mobile web. Like Reddit, part of that is due to them making the mobile web experience crappier to drive app adoption, but that's not the only thing going on. The web just for UX in many ways, and will never beat a well-built app for anything other than ease of initial installation.

Good point. Another reason not to do business with a company is if they remove information from their mobile website that's available on their app. Looking at you here, Yelp.

> But I won't clutter up my phone with things that work just fine in a browser

That's the window for apps to compete. If "just fine" works for you, cool, but it's possible for apps to make the experience better in meaningful ways. A web page can't notify of you a new message, but an app can, for example. Look at all the Twitter apps that came up, and they've had to start to systematically kill over time because the experiences are _so much_ better than Twitter in the app. "Just fine" doesn't push us forward.

> it's possible for apps to make the experience better in meaningful ways.

Now if we could just get app designers to realize that!

IME, apps are usually just poor front-ends for the website, where companies think it's OK to shove stupid things like unblockable ads, notifications, data-harvesting, etc.

I see notifications as a downside as a user, not an upside.

Well I'm not going to tell you that the way you use a mobile device is wrong, but it is not the way I use my devices. I guess we'll have to see which one of us most people agree with. If people stop downloading apps, we'll stop seeing companies put effort in to them.

I don't give a rat's ass what makes the most money. You're shitty app needs to earn my attention, rather than annoy me into giving it attention.

Yet another problem with apps. Every time I download a new one I start getting pointless notifications and I have to go to the Apps Manager (which on Android is O[n] slow) to turn them off.

> Nobody needs a reddit app

Oh, reddit on mobile without an app is a displeasing experience. The official app though, isn't much better.

It’s only a displeasing experience because Reddit is doing everything they can to make the mobile web experience miserable so you use their app.

Yeah, same for me. The only apps I have are the ones where the web experience is either non existent (Camscanner) or extremely sub par (Spotify/Google Music)

I do have apps for all the shoppibg platforms I use, even though the performance isn't substantially better

Pretty much.

Like you said, it's slow, drains battery and add a barrier to customer conversion.

But also:

Web apps don't have a direct access to the file system. Forget about filming or recording voice and saving that for anything serious.

They can't respond to intents, making them completly isolated from the rest of the OS.

They can't use the share function so your data is hard to extract, move around or ... well, share.

They don't have access to the cryptographic facilities, or the authentification ones (e.g: no finger print unlock). They can't be directly filled in by other apps like lastpass. You can't even chose between security and convenience.

The amount of data they can store is very limited, hard to manipulate, and the API changes from one browser to the other. Unless you have a bit of texte, though luck.

Basically, anything that is not a simple CRUD service is useless offline, and slower online than the app version.

Plus, how many people know that they can "add this app" to the home menu ?

Not to say you should not offer a web version of your app. But it's an ersatz.

I have an eerie feeling of déjà vu, namely that "This is the year of Web Apps!" appears to be the new "This is the Year of the Linux Desktop!" in many ways.

You're thinking of this too much in terms of technology. Even when what you say is true, it's rather irrelevant for most apps.

> The data I have seen from the old company was this: people who installed our news reader app were 4-8 times more engaged than the people who used our uber mobile friendly and fast news site. Apps can be faster, handle offline/near offline far better.

I think you're mixing up causalities here. Those users that are already more engaged are the ones that can even be bothered to install your news reader app. How many users is that though? Do they make up for the ones that don't install the app? You're probably going to need both anyway, you're paying for both, you better make sure the native app is worth it. For a lot of business, it isn't worth it.

The core issue is that people aren't willing to install any more apps. Case in point, the very article wants me to install the "Medium" app. I'm not going to do that, because it's pointless. Medium works just fine as a website and that's true for most other apps you use merely on occasion. Could it be more responsive, use less battery, if it was native? Of course. I don't care.

Medium is an absurd example because medium pages are the kind of content that the web was originally designed for so it’s unsurprising that an app is unnecessary.

> The core issue is that people aren't willing to install any more apps.

Is there any source for this? Are app installations declining?

Anecdotally, plenty of my friends have 16gb phones still, and often are deleting and reinstalling apps like instagram/snapchat/anything you can dispense for a few days to free up storage to actually use the device. Want to record a 2 minute video? Better delete an app or else recording will abruptly cease. While I still had a 16gb phone, it got to the point where I wasn't reliably getting emails pushed to the device because it was always full, yet I had only a small handful of apps.

This isn't 2010 where everyone wants the top 25 apps, and could actually install them since they weren't hitting 100mb each. Inflation of app sizes and continued premiums on useful storage amounts from Apple has been forcing people to cut the fat and keep only the most essential apps installed. Even if you had a large iCloud account for your photos or texts to reside off your device, you still need local storage for apps.

This is very common around anyone who is a heavy phone user for photos or as their main digital device.

Thanks. I wouldn't characterize this as "users aren't willing to install any more apps" though; that's quite the leap from the conclusion of the report.

To be clear, I didn't mean it in the sense of "there is a global trend towards less app installations", but rather "I already have 100 apps on this phone, I'm not installing this one too". I think that's anecdotally true for most people who have had a smartphone for a while.

Of course strictly speaking I will install more apps in the future, but the chance that it's going to be the kind of App that I could just use as a website is practically zero.

Agreed - for the quality experience there's really no substitute. Maybe the author thinks that this will change (technologically speaking) in the next 7 years, but I doubt it. Things will definitely improve, but there'll still be reasons to code native apps. Desktop still has tons of native apps - it's not all running in browsers. We're in 2018, and your web browser is leaking memory and performance is sub-optimal (try scrolling through a large number of threads on Reddit and observe your CPU usage).

>Why? firstly HTML/JS is a very slow presentation layer compared to native, which means less battery. You still can't multithread, so any heavy lifting is serverside, which means latency in anything other then decent bandwidth areas (so no travelling for you....)

This was the case a decade ago, but not anymore. I have been writing medium complex web apps using Angular/React, Web-workers and RxJS which runs on mobile (Android 4.4+ and iOS 9+) from last 4 years with no extra battery draining side effects and native (like) look and feel. You just need to choose write framework and responsive design UI guidelines. Today most frameworks provides it out of the box. JS, DOM and CSS engines in mainstream browsers are getting more and more performant.

> browsers are getting more and more performant.

Moore's law is getting us out of a hole. The processing power, and performance per watt on mobile has increase exponentially. Those people who who are stuck on three year contracts feel the pain of this idea. Yes, JS engines are getting faster, but they are being asked to do more and more stuff.

React native is a marvel of engineering, where the bridge intercepts UI calls and diverts them to native. But thats not a webapp, that re-invented version of QT, Wx, tk or whatever java uses.

My point is this: a native app on a underclocked pi zero, can animate UI items at 60FPS. Via a browser, no where near. HTML is many things, but efficient is not one of them. HTML/CSS/JS is a marvel of engineering to get it anwhere near as fast as it is, but its comes from a very slow base.

Performance is a detail which is often lost from the mobile/web discussion. Yes there are many reasons for good web-apps to exist, and they can often deliver a very good experience on modern hardware. But conceptually, the idea that all software should run on top of a compatibility layer, with many restrictions and performance considerations compared to running directly on the OS is a strange one.

It’s an ecological concern as well: how many gigawatts of electricity a day is spent fetching react.js?

> It’s an ecological concern as well: how many gigawatts of electricity a day is spent fetching react.js?

I've been asking questions like this for years now, mostly as rhetorical devices, but I swear one day I'll try to get data and compose a chart of "how much your bloated product is contributing to climate change".

I have to think that bitcoin etc are far worse offenders.

And it seems that server usage consumes around 1% of the USA energy budget. Heating, industry and transportation are most of that list. Not sure apps are going to show up.

Yeah, ceilings should be easy to establish. The max possible cost of bloat on mobile is (number of mobile users * average phone battery) / average charges per day. The max possible waste on backend will be roughly constrained by the energy use of data centres, and that value is available.

I don't expect the answer to come out very high, relative to other things. But it would be good to see an absolute value, if only to drive home the point that everything your software externalizes to your users has costs multiplied by the number of those users.

Facebook iOS app was 400 MB last time I checked. And it also wants to get updates.

How much electricity is used to power casual games on mobile phones? People should stop playing games, they are contributing to climate change.

How much electricity is spent by developers using Electron based apps like VS Code and Slack and npm packages during their work hours? We should all develop in terminals, with no GUIs and no GPU usage. Only in non-bloated languages like C and ASM. Anything else is crime against the climate.

All sites should also be text only (like the motherfucking website), no images, especially hero ones.

I think nobody reasonable would argue that you should stop all use of energy, period. The question always is, what does the energy use buy you? Does it buy you food? Safety? Entertainment? Or is it just pure waste created by a combination of greed, laziness and bad engineering?

people who installed our news reader app were 4-8 times more engaged

Of course they were more engaged, they're the tiny minority that cared enough to find and download your app.

You have't adressed the most important point in the article - people simply don't want hundreds of apps on their phone.

> people who installed our news reader

But how many people installed your reader? I think it's easy to explain why they engage more with your site in your app: they have nowhere else to go, and the website icon is there, on the screen. This doesnt scale

A significant number of the subscribers. There were at the time something like 800k of them.

Its important to say that it was a choice, there was no full page banner or bouncer that forced people to install the webapp, it was entirely optional.

If, however you are saying that people only click on it because there is an icon on their phone, then you are making possibly the biggest argument for keeping apps (although its perfectly possible to have webapps on the homescreen with icons)

Did your old company adjust for selection bias?

It seems to me the category of people who have gone to the length to install an app is perhaps going to spend more time with the content compared to the full set of people interacting with the content.


Engagement is measured across the entire subscriber cohort. consumer "councils" are made up of a selection of subscribers, so we can adequately get data from all sections.

We had a webapp, the users were very engaged. We replaced the webapp with a native app, we got way more people who very engaged, we also got loads more people who were mildly engaged. The overall effect was more engagement from a wider base of subscribers.

Lowering the bar to entry, proper offline caching of content, faster loading, just a better more seamless experience.

In what way does it need to scale?

in every way. imagine having to switch between apps to read every article in HN

That would be okay if there were a Hacker News app that could display all the stories.

I mean, I agree with you that simple web pages are best for simple news and articles. But I don’t think you can immediately generalize that to “apps don’t scale”.

There is a HN app that displays all the stories (safari popup for links)

an app for every website would not scale icon-wise. and it would destroy the hypertext

Your points are all valid, but they were also all valid in 1998 when people told me that desktop apps weren’t going to be replaced by web apps.

And they haven’t, so that argument seems to have held up pretty well.

I can’t tell if you’re being facetious. Of course desktop apps haven’t disappear entirely, and they won’t anytime soon. But entire classes of apps have largely disappeared, especially internal corporate apps.

Any ‘entire classes’ other than the corporate apps?

> This is written by someone who lives in the "web eats everything" bubble.

Most mobile developers have no idea how web-centric non-mobile devs are. I've recently started working in a web-centric company, and am the only mobile dev. It's mind boggling, freaking unbelievable how less open minded web developers really are. I had no idea.

I don't know what is the cause of this, but this article is pretty common to the crowd who were trying to convince everyone that Phonegap was a viable solution 5 years ago. All I know is that the web community need to get this kind of hyperbole under control because they're losing credibility.

I've almost reached the point where I don't take anything they say seriously anymore, especially when it comes to platforms that they've never spent a single project developing on.

The FastMail mobile app is an example of an "hybrid" app working correctly: it's a native app wrapping the web app using a WebView. The native part takes care of things like notifications. The web part part takes care of the rest and is shared by all platforms. Anyone here using it?

I use it, and it works fine when I have good connectivity. But I'd really prefer something that was better. Things like tapping a notification about new mail and having to wait to load it are amazingly frustrating (maybe I should turn off notifications). It also only works with good connectivity, I wish there was an option to download message bodies (but not attachments) automatically when available.

Basecamp's mobile app is also a good example of this. Native navigation and notifications but web based content.

I think people actually prefer using decent mobile web apps over native apps and app vendors are actually actively fighting it by putting annoying 'get the app' link overlaying content on mobile web. they are trying to push people as much as as they can to force them to download the damn native app. you don't see any app publisher putting a link to mobile web app over the content inside the native app prompting people to use mobile web app over native app. For most of the content websites I use I don't feel the need for the app (twitter, reddit, LinkedIn, etc.) but they are making the mobile web experience horrible by putting that content overlaying link on every damn page.

The end user really doesn't care, they care about the following things:

o can I find what I want o can I find it easily o can I find it fast o can I view what I've found properly o nothing gets in the way of getting what they want.

slow load time, dodgy networking, waiting for app to load from notification, losing your place, inconsistent or foreign UI, all make the user scream in annoyance.

"TRY OUR APP" fits stops you from viewing what you want.

Linked in on mobile is shite, you have to use the app. The emails don't redirect to the app, which is fucking stupid

Twitter's desktop site is rubbish, the mobile version is slighty less annoying, you have to use the app.

Facebook's webapp is really slow.

> I think people actually prefer using decent mobile web apps over native apps ...

agree. right or wrong, as an android user, i feel less vulnerable, less bloated, less violated, using a web app than i do installing a native app.

Or, the mobile app experience is better, and the overlay link is a convenience, rather than “actively fighting”.

> Or, the mobile app experience is better, and the overlay link is a convenience

For whom is it better? Me, the customer, or you, the vendor? I buy furniture from Wayfair's website, and browse on the site quite often. On the mobile site, I'm able to view products, add/remove them from a wishlist, and make a purchase. All from a browser with ad and tracking blockers enabled.

Wayfair still puts a "Download the app!" popup on the site, even though it can see from my repeated visits and purchases that I primarily use the mobile site. I imagine it's because on an app, notifications are opt-out and tracking is continuous.

For me the customer. The sites I use most often have better apps than websites.

As for your imagination about tracking, it’s both false and paranoid. Mobile notifications are opt-in, and tracking is limited to behavior within the app, unlike the web where you are tracked across sites wherever you go.

The overlay link for reddit takes up 1/3 the screen, and the link to hide it is in 9pt font at the edge while clicking anywhere else opens the App store.

its definitely the opposite of convenience. if i need the app i know where to find it. its especially annoying when the link keeps reappearing after i dismissed it once already.

Not all apps need many resources. The beauty of Web apps is simplification and delivering crucial functionality. Limitations and focus are good things.

> The fact is, webapps are suboptimal, and unless something drastically changes, will remain so.

I agree it’s still suboptimal for now, incremental improvements are making it less so year over year. More parts of native apps are also getting written with web technologies. Eventually, maybe, most of the app icons in our phones might just be a shortcut to some website

That might happen, but I wonder if the distinction will then still have any relevance.

If you continue the current trends, this process could involve making WebAssembly more powerful, making CSS and Web Components into an actual widget framework and adding more capabilities to service workers to enable OS hooks, background activities and offline use.

However, all of those changes will push web apps into the direction of becoming more "app-like", not more "web-like".

So after the improvements are done, I think we might end up with just another framework for building apps, not having moved away from apps. (With the one downside that HTML will still have to drag around reams of cruft to maintain backwards compatibility which other app framework could easily do away with)

Yes, I think you’re totally right. We’ll end up writing clientside code for phones, tablets, and desktops. A lot of the code can be shared if you use good engineering practices, but if you use good design practices, each UI will be different so there will need to be some custom code for each. It doesn’t really matter whether this code is Swift, Java, JS, “native”, “web” or whatever.

I’d add that that’s the good scenario. The bad scenario is that everything goes the way of desktop apps, where everything just becomes a lowest-common-denominator web page with crappy UI design that doesn’t really use the platform effectively, just because it’s cheaper that way and cheap always wins.

> might just be a shortcut to some website

For the longest time it was. Because $newsCompany was subscription it had to leave the apple store, or give apple ~25% cut. To get round this we had a fully offline HTML5 webapp.

it was very good, but despite mega optimisations, it was slower than native, and had limited storage.

Users were constantly asking for a native app, In every customer council/survey. Bear in mind that these people were not techhead, they were babyboomers who struggled with tech, they knew enough however, to know that native apps were faster. (for example the times, grauniad and telegraph. )

> people who installed our news reader app were 4-8 times more engaged

That's maybe because people that are engaged with something could be more willing to install the app. Also once the app is installed there is an icon on your phone constantly reminding you to use it.

1. Not all apps need multi-thread capability, and handle offline scenarios, like pay utility bills, book tickets, order food etc 2. GUI is most easy part for web app to mock. WeChat mini-program has its own UI controls

> Not all apps need multi-thread[ing]

you are correct, not all apps need multi-threading, but it sure is useful. Especially if you don't like callbacks. Blocking the UI to do a HTTP call with no network isn't not a good move.

> GUI is most easy part for web app to mock.

Yes, but thats not my original point. Mocking a UI in a webapp easy to do, but very hard to do fast, smooth, offline capable, with all the features you want, and cross platform.

Also, have you considered that consuming content on mobile is a completely different experience than consuming content on the web?

Most comparisons I've seen talked about here on HN, seem to think these two are equivalent. They're not.

Basically every flashlight app on Google Play contains adware or malware and wants non-negotiable (thanks, Google) access to my contact list and files and network. Same with many task managers and qr code scanners and other random little apps and utilities.

Fuck that. I'll install Uber and an IM client or two, but that's it. No more "that looks like it might be cool" apps for me. I've said this before - the app ecosystem on Android is like software on Windows circa 2000.

I don't know what the story is in Apple-land, but Google did this to themselves, and they deserve the oncoming fallout. Google Play has been a neglected disaster for years.

After I discovered F-Droid [1], I've found myself installing practically nothing from the Play Store, especially such neat little utility tools. F-Droid has a lot of half-done or unpolished stuff, but it also has tons of simple, elegant tools that do their job, as well as minor works of passion that have their own niche. I use the main repo, the Guardian one and one from IzzyOnDroid [2].

[1] https://f-droid.org/ [2] https://android.izzysoft.de/repo

"the app ecosystem on Android is like software on Windows circa 2000" amen. Maybe even worse, as it's harder to get people to pay for mobile apps than line of business / productivity software.

> I don't know what the story is in Apple-land

The walled garden is great and protects my privacy.

Please mark sarcasm at least with a ";)" otherwise many people might think you mean what you say becaise they don't know that it's a ridiculous idea that a big corp will come and protect each users privacy.

Google's business model, in broad strokes, is selling user data to advertisers.

Apple's business model, in broad strokes, is charging consumers premium prices for hardware.

As long as Apple thinks the market values user privacy, they are economically incentivized to provide privacy- and security-focused software features that get people to buy their hardware over Android equivalents.

Is that an irontight guarantee? Of course not. Is it a (current) alignment of incentives that means Apple is categorically more likely to protect privacy than e.g. Google? Absolutely. That's also played out so far in practice, between things like app security sandboxing and Apple's historical unwillingness to help law enforcement decrypt encrypted backups — see e.g. the San Bernardino shooter case.

More accurate description, with fewer words:

Google's business model, in broad strokes, is selling advertisement space.

Apple's business model, in broad strokes, is selling hardware.

I actually pay more for an iPhone to be in their walled garden (with all the restrictions therein) for the better security and privacy. I consider my smartphone to be an appliance and am ok to trade-off uber-customization-capabilities for better than Android level of security. I also carry an Android phablet for on-the-go mobile hacking/coding/exploring shenanigans, but don't keep any data on it for obvious reasons

It's funny you mention Uber. Both Uber AND Lyft have Webapps, and they work very well.



Apple-Land is fine, because it didn't adopt the broken security model of Android. That has nothing to do with "walled garden" (disallowing third-party applications). Google could've put the same limitations on Apps. In fact, they've slowly adopted the "Always Ask" permission model of iOS, but it still isn't fine-grained enough, especially when it comes to the file system.

Having said that, a "file system" for iOS that Apps could share with each other is something that just didn't exist for the longest time. Sending files from App to App has always been weird.

Yep it adopted Symbian 3.0's security model as base, which many think it was introduced by Apple.

As a mobile dev, I of course jumped into the article, expecting some kind of insight that I had overlooked. Well, there was none. Those arguments have been around for some time and have not proven compelling.

Points 1 & 2 were invariants from the start. On the contrary, excellent and fast on device search has enabled me to keep hundreds of apps, as long as I remember their names or keywords. I have always argued that pure information is better served as a single page website, and I have always told my clients so.

Point 3 is interesting, but at some point the OS vendors will take steps against that to maintain control. I also cannot see how shipping an app in WeChat is fundamentally different from shipping it on the App Store, bare technical details like programming language.

Point 4 is the one-sided observation of the centralize-decentralize circle that is happening in all ecosystems. Once FAANG have purchased all the startups and apps, people will crave for new ones. Governments will even incentivize that.

I think the only thing that can kill on-device apps in the next years is PWAs with WASM and friends (IF a central market place for PWAs develops). But Apple and Google will have it let that actively happen; and development paradigms might not even change that much, with Swift/Kotlin to WASM compilers in the works.

I have two points on this.

1. The end has been here for some of us. But only for the apps the author is talking about. And these apps are the whitelabeled generic restaurant menu apps. If an "app" like that is not useful, who cares about it. If I need to order from that restaurant, why not just use the ordering app that includes that restaurant?

2. He talks about apps in general and how we have 100 installed but use max 30, so the rest 70 are useless, so apps are dying. I don't agree. We might have 100 and use 30. But I bet I have and use a different 100 and 30 than you, and you from the person next to you. That doesn't mean the apps are dying. That means there is diversity and choice. To me that's a plus for the platform. Of course we can get to extremes, but I don't think apps are on the way out.

In conclusion, I felt the post was "controversial" just for the sake of it.

Yes. And in particular:

> He talks about apps in general and how we have 100 installed but use max 30, so the rest 70 are useless, so apps are dying.

Mobile app usage is (likely) Pareto-distributed which makes it... just as alive as every other such phenomenon.

Yes, but these metrics web is dead already. I mean there are billions of the websites and I only have five in my favorites.

The apps are dying and the year of the Linux desktop is just around the corner. (I wonder what's the ration of Linux desktops in use vs. Android phones in use, which are running Linux after all).

I always find ironically that these type of articles mention how hard apps are to find and monetize and we should all go Web, as if the Web was wasn't that in an even bigger scale.

Even PWAs and WebAssembly adoption means that the Web stack is getting more app-like and less hypertext documents.

Poor Lance Ng. He has an article with a lot of attention, but it’s this silly piece.

BTW, no one needs to read the article, but if you’re here I guess it’s probably too late.

He’s actually arguing with his six-years-in-the-past self, who thought people wanted lots and lots of pointless shovelware apps. He’s now realized this isn’t the case, but has swung too far the other way and now sees no reason for apps. I think most people realized all along apps weren’t good for everything. That doesn’t mean they aren’t great for some things.

My favorite part is where one of his reasons the end is near is that people only have 100 or so apps on their phone and only use ~30 regularly. Right. Nobody goes there anymore, it’s too crowded.

You know what rocks, and which doesn't get nearly as much attention these days, vis a vis mobile app development?

Using a single game engine for real business apps, and then shipping those apps on every platform the game engine supports.

Sure, you maybe have to do a bit more work to get a data entry field up on the screen - but you only have to do it once and you've got the same, consistent, agreeable (assuming you design it right) interface across all supported platforms.

This isn't the same as using browser-based frameworks to accomplish the same thing. What I mean is, a game engine that provides equal access to the rendering and input event pipeline across the board.

Its the native-framework dance that is killing mobile apps. The time spent grok'ing one Android SDK release, only to have to do it all over again just to keep your app current and constant on the platform. To a lesser degree its the same with iOS.

But, if you take sufficient responsibility for the engine such that you're really targeting GLES and an event queue, you can produce amazing apps that run everywhere.

This is the promise that needs to be fulfilled going forward. We don't need more apps that just look the same, yet take up infinite resources and attention just to stay in place. With a game-engine approach, app developers can actually differentiate themselves again - and the good ones, the really good ones, produce really good apps.

Think about this some time: the most-shipped, most-used apps on any of the mobile platforms are those that, pretty much, eschew tight integration with the vendor-provided frameworks and instead bring their own to the party. This will get traction as more and more devs start to understand just how far you can take your modern engine these days .. and those engines are becoming their own OS in their own right, anyway ...

You've just described Flutter, it's basically a video game engine for apps.

Precisely. After nearly a decade of list-detail view apps doing REST API calls, and the most widely used apps having their own unique branding that's the same across both platforms, you might as well distill those common features into a Unity for mobile apps.

And Qt, Xamarin, ....

And we're back to flash.

Just learn the damn platform you're deveoping for.

What you're describing sounds an awful lot like Flutter's architecture to me, which ships the rendering engine + code as native ARM code to any supported OS. Currently it targets Android, iOS & Fuchsia, but support for Windows and MacOS is in the works; the only requirement for the OS is that it supports OpenGL.

Unity is a very good tool for this.

How much of unity’s runtime is optional? Bundling an entire game engine in every app install sounds heavy

Well, you can just use Unity's 2d engine if you want to make a flat application.

There are business, non-game apps that use Unity?

A friend of mine recently built one for training people to dig up roads without hitting electricity supplies.

Flutter is a better tool for this.

I haven't used it, so can't say either way. Am having a look at it now and it looks pretty nice though.

For years I haven't installed any apps but the absolute minimum. I don't have an app for news, Facebook, Amazon, airlines, this, that, because of all the reasons mentioned in the article. I read news on the mobile optimised websites, I retrieve my flight ticket as a PDF in my inbox, I never like to shop from my phone anyway (best done on a desktop when having a mental break at work) and don't think Facebook offers anything that requires my attention more than maybe once a couple weeks.

Completely agree. I do the same thing and even uninstall or deactivate unecessary apps installed by default. As a result I have less app than my phone can display on a single page of the app drawer even with good sized icons, which is actually very convenient.

So the author proposes that most apps will be consolidated onto platforms such as wechat, messenger or aliexpress. With each new app, comes new requirements of the platform to produce better and more functional API's for the sub-apps.

Eventually these platforms will bloat and bloat until they basically become their own operating system.... then tada we're back at the beginning...

> So the author proposes that most apps will be consolidated onto platforms such as wechat, messenger or aliexpress. With each new app, comes new requirements of the platform to produce better and more functional API's for the sub-apps.

This is actually happening in China to some extent.

I'm blown away that Apple and Google actually approves apps that run a mini-OS inside them like WeChat/Alipay. I initially thought they would have rules to kick these apps off their store. These mega-apps are able to run mini-apps that effectively bypass any control from Apple/Google, the loss of control on their end is maddening.

Google and Apple have no control over whether WeChat mini-apps respect their respective App Store rules and guidelines for example. Also, WeChat got so big that I wonder if they would even ban it from the app store if transgressions are found. WeChat literally took control away from them.

Example : people install WeChat, from there install mini-apps that aren't controlled by Google/Apple, and even can pay though third party apps : Google/Apple don't get a piece of the cake like they would if you used their IAP system.

It is amazing how they are allowed to run these apps through the Play Store. I remember a few years ago Google removed thousands of alternative "app store" apps for the Play Store... Not sure how these are different...

At least for android, I'm pretty sure google doesn't control the app store(s) in China. It seems there are many app stores which explains why.

    Tencent MyApp (15.12%)
    360 Mobile Assistant (10.60%)
    Oppo Software Store (9.24%)
    Baidu Mobile Assistant (8.55%)
    Huawei App Market (8.28%)
    MIUI App Store (6.28%)
    Vivo App Store (4.81%)
    PP Assistant (1.98%)
    HiMarket (0.72%)
    Anzhi Market (0.50%)

It really made sense for the Chinese companies to go this route since they didn't own the mobile OS. They effectively become an OS like you say.

These platforms own the food delivery and ride hailing platform too so it is much more difficult to compete as users have much fewer incentives to switch.

Isn't the web such a platform in itself?

> Too many apps slow down your phone. They take up memory space, run background processes, and constantly check for push notifications even when not in use.

This is provably false on iOS, yeah? iOS's backgrounding model means apps that aren't actively doing work don't "take up memory space". Apps that you never open are quickly throttled from all forms of background processing on a pretty aggressive timescale (I know this firsthand, it's been a major pain for one or two specific apps I've worked on). Push notifications are, as the name implies, a push service rather than a pull/polling service.

Unused apps do take up storage space, but iOS 11 and newer automatically silently delete apps you don't use, keeping the user's data and the app icon around for when you open it again. In the settings UI where you can disable it, this is explicitly framed as only saving you storage space, rather than having performance benefits.

Most users aren't on iOS, but even the ones that are probably have the perception that apps do stuff in the background that drains battery.

I've seen probably most of my iOS friends open the app switcher and kill every single app after they're done showing me something. It's not worth it to try to explain it to anyone because it's such an ingrained muscle memory now.

My coworker, who is an iOS Developer, does this fully understanding it's counterproductive. He just doesn't want to see any apps in the app switcher.

> The idea was to make it easy for individuals and small businesses to create their own personal apps for social or marketing purposes.

> The vision was that, one day, every legal entity (human beings and companies) would have its own mobile app. These apps would be dotted all over the internet, like physical properties on a map. Unfortunately, it didn’t happen.

Er, thank $deity that didn't happen. This is a vision that exemplifies the sales-level delusions I've seen some times, of the "we'll sell lots of useless shit and make boatloads of money" kind. It doesn't stop to consider that apps need to provide value to the users, and the technology context of a smartphone puts constraints on what form that value can take. Gross. I'm happy I've never heard of this vision in the past, as I wouldn't be nice to the people preaching it.

To be honest, I wouldn't like mobile going the html/js way at all. Html/js has moved to desktop with electron and the results aren't that great. They take up huge amounts of memory ( gmail web on chrome takes up 500mb of ram on my machine, also slack is a noteworthy mention). Native desktop apps take up a fraction of that memory. For the sake of accessibility we have significantly sacrificed performance. I can't wait for webassembly to be widely adopted so that the browser can move away from html/js. Google has a nifty tool called ArcWelder which allows android apps to run in chrome. Apple has already announced support for running iOS apps on Mac. I actually believe that the reverse will happen and for more popular apps like fb, gmail etc people will move back to using native , less memory hogging applications once they are out.

Never mind Electron. Soon it will become normal to install web apps on desktop, directly from the browser—it will be basically a website rendered in a separate window without any browser UI. That system will not have Electron’s memory problems.

Memory problems aren't inherent to electron, they are inherent to html/js apps and you can also see that in chrome by opening up your task manager. Even small websites with minimal content end up taking 100+mb in memory. It has always been possible to install web apps from browser, chrome has supported it since a number of years but they haven't caught on as much.

Whats the issue with using 500mb memory? I have 8gb on a 5 year old computer.

That's also multiplied by the number of tabs that you have open. A medium tab is right now taking up 200mb and so is Amazon. I have over 3 browser windows open with many tabs and need to use extensions to auto kills tabs so that the OS doesn't end up into swap space territory. I also run Android Studio and an emulator on the side which compete for memory.

I do similar where I have 60 tabs and 5 windows open, a few servers, text editors, etc...

But I can always close tabs.

You need to close tabs, but when was the last time you had to close apps on mobile for performance reasons? Even though mobile devices have significantly lesser specifications.

"The vision was that, one day, every legal entity would have its own mobile app."

Yes, that was a classic bad idea. There were magazine apps which simply contained JPEG files of all the pages. In both orientations, even. That was both unnecessary [1] and annoying [2].

The successful apps are now all from the big players. We're past the "anyone can sell an app" era.

[1] https://xkcd.com/1367/ [2] https://xkcd.com/1174/

> We're past the "anyone can sell an app" era.

I think you've summarized the heart of the article here and I totally agree with you.

When OP says "the end is near" I think we can interpret it to mean that it's the end of the big growth era, the end of the era where that technology and demand for expertise in that technology dominates other technologies, the end of the era where new companies and their technologists are wise to invest their time in apps and learning apps.

The vast majority of apps (esp. android) make too little money to justify the expense required to create and maintain. They're not profit centers. They're loss centers.

I only agree with the third point the author makes

> Smaller apps will become part of social media and mobile wallet ecosystems.

I find actually unbelievable that Apple and Google didn't crack down on it yet as it takes considerable control away from them. Through iOS's WeChat for example, I can install and run mini-apps that effectively bypass any control or review scrutinity away from Apple. Not to mention about how all payements are processed thru these mega-apps, fully bypassing the in-app purchase system.

Could Apple even ban some of these big offending Mega-Apps like WeChat at this point? Probably not, as that would cripple their marketshare in China. So meanwhile they effectively host a third party app store competitor... in their app store.

WeChat in China is more important than Facebook is in the US. That's why they get away with it.

The question isn't solely about tech, but how the mobile OS' wrap and deliver the experience. Even with attempts like progressible web apps, we still have the same approach and behavior to navigate on our mobile home, a central place to launch a specific problem-solver. I don't think that we are going to change this, but develop the pattern above this concept. That is what we already see with the evolution of iOS on iPad or Chrome OS. Apple and Google respectively could be inspired by different analogies, but instead, they are doubling down on the new conceived standard brought the mobile phone.

This was obvious 10 years ago, so why have mobile apps been successful? What has changed?


This article is shortsighted to me. Is it the end of mobile apps? No of course not, webapps are gaining features of native apps and will run more like a native app. The real difference will be the app delivery method. Is it the web or an App Store. An App is an App, if it’s written in Dart, Js, Swift, and C++ it doesn’t matter it’s still an app experience. That experience is fundamentally better than the web page and still has all the downsides of an app also. How we deliver the app experience may change but I don’t think it will. Is there are difference for th emend user if they have 100+ shortcuts vs 100+ apps from the App Store? What we are seeing is a competive market where you have to offer real value to attract users. No much different than the current indie game market. It’s completely overwhelmed with numbers of options and users are sticking with the top level of apps/games. Maybe the delivery of apps changes but honestly I doubt that as discovery is much better in the App Store.

> Chances are, if you take away the manufacturer’s pre-installed apps that you can’t delete, you have, at most, 100 apps.

I don't see how this can be the first point in arguing that the end of mobile apps is near. Imagine saying, "The end of desktop apps are near, people will only put up with 100 third-party apps on their computers these days!"

I'm convinced that mobile devices are useless for anything but the most trivial usages. Just last night I sat and watched my mother-in-law flail for the better part of two hours trying to look up and then purchase some replacement filters for her vacuum cleaner. What should have been relatively simple on a real computer was torturous on a smartphone. Between the tiny display, awful on-screen keyboard that is flaky and obscures most of what you are looking at, clunky apps and busted mobile websites, it's just a rage-inducing disaster.

Not to mention that if you are not on absolutely perfect WiFi, everything is so slow and janky to load. It's just not acceptable that the bar is so low for usability; I'm convinced that we've gone backwards to a significant degree, and I'd much rather go back to the web that we had in 2008 than the one we have in 2018.

These kinds of apps is exactly what the linked article is arguing against. However, if a mobile app has worse usability than desktop then the company failed to redesign their product experience for mobile. That or, their product is simply not meant to be used on small screens at all.

What the author doesn't mention is that apps have become increasingly easier to write as time has gone on. Not only do we have better native languages that you can write apps with (Swift and Kotlin) but we have incredible cross-platform tools as well in the forms of Xamarin and React-Native.

I've personally been working with React-Native over the past year and it's just as easy as writing React code for the web (if you're using expo), once people understand this it'll only be a matter of time before web-dev teams adopt it. Historically the problems with app development is that it was a lot harder than web development and often required you to learn a new language and framework in order to get anything functional, this is no longer the case.

I'd actually argue that there will be more apps going into the future as the technology needed to build them simplifies.

They're easier to write now, but still not easy enough: the vast majority of apps earn too little revenue to justify their dev cost.

Author seems to have missed a big reason for why apps will continue to persist: they obscure data access permissions far better than browsers do. If you install FB messenger, Instagram, LinkedIn or whatever, you will be asked one time which permissions (location, microphone, contacts) you want to grant it, and most people won't even review the list before hitting Install.

On the web, the browser dialog will ask you each time the app wants to access any of these things, whereas on the app, it'll quietly continue the use the permissions you granted it, and eventually you'll forget you signed off on them in the first place.

Not to mention some particularly shameless actors will gimp their mobile web functionality to ensure you use their app at all times (FB, Airbnb, others).

One thing this article gets right is that it is just going to be harder to persuade users to download an App that only brings in marginal/augmented functionality. I have about 1.5 screens of Apps installed, probably somewhere near 30-50 apps in total, and use barely 10 of them fairly frequently as far as I can recall.

Maybe it won't be too surprising that Google/Apple will announce something similar to Wechat's mini-program, a lightweight application distribution system that doesn't require a browser, nor installation to work. In fact, Google's Instant App aren't that far from the above description, it is just a matter of marketing effort to push it closer to users.

I don't agree with the overall premise that native apps will disappear. I agree that certain apps, such as the static content Wix example, don't need to exist.

I found the article unconvincing. The core argument is that native apps will consolidate into larger social media apps as part of an in-app app? That may be the case for China, but not the US. Even if that did happen in the US, that means you are still building mobile apps (with another abstraction layer).

As long as native apps provide a better UI (as expected of native apps) & continue to have access to OS APIs that the mobile browser does not, native apps will continue succeed by providing a better experience.

So it would be like myspace but a mobile app?

Here’s the thing: a webpage will never be able to do a number of privileged operations, for a very simple reason - visiting an arbitrary web page is not controlled by a user, as any webpage can cause an automatic navigation to another.

Installing an app acts as a user intent driven security boundary. Dialogs coming up on random webpages is a buck-passing technique, as users cannot discern a “safe” request from an unsafe one. This applies to technical users as well - dialog fatigue, incorrect script inclusion, ads, etc. eventually you can end up accidentally saying yes to the wrong dialogue and a random website gets to download your contact list, etc.

The end? No.

But PWA websites will most likely kill many native apps. I use the Twitter PWA and it works perfectly fine on Android.

Working with IoT (i.e. Beacon technology) HTML5 and even React Native, nothing beats native code responsiveness. The need for "White label" apps may start going away, but emerging technologies that rely on efficiency and speed should be utilizing mobile app native environment.

I remember when people were saying that the end is near for web apps since mobile apps are going to eat everything. No one knows what will happen in the next three to seven years. Best we can do is observe the market every year and adjust course as necessary.

There are domains of problems that can be solved with the WeChat model. Money, shopping, paying utilities, ordering food, etc, make sense to have in one app. I don't know if I'd want my task planner or email/cal app in there.

Congrats, you have then moved into a walled garden inside another walled garden.

For Mini program in WeChat, they are independent with iOS or Android. So it just inside one broader walled garden

Functionally yes, most apps could be mobile websites except for one thing: Mobile users don’t use bookmarks. Mobile users use icons on the home screen. It is easier for users to add an app to their home screen than a website.

But you can add a website to your home screen too, and it will act like app.

Blizzard would like a word....

TLDR: Betteridge's law applies.

Fact is mobile apps will remain useful for as long as mobile devices occupy the same space they do now. Maybe you don't have more than 100 apps installed, but that does not equate to all apps being deemed useless. Different people find different apps useful enough to install and continue using. I don't ever see myself using a web-app alternative over my security camera app, or my email app, and so on.

Fact is, native apps have their uses, but not all native apps are useful to all people.

"Betteridge's law" comes to mind when reading this.

We have some in-house apps, and it comes in handy to have control over the device you are using and developing for.

In general though, I do think apps (from the app stores) are not installed as much anymore as they once were. Anecdata, but I hardly install anything anymore on my phone.

App ecosystems help perpetuate oligopolies.

How can I read that article? Even web link gives me the paywall.

It opened on the medium app on iOS for me, and I could read it.

Do you realize how ironic that is considering the title of article...

I do. I just haven't taken the time to delete this app from my phone, as one of the 70 I don't use.

Just open it in a private window.

This is a very Western centric point of view. Even if most of the RN like apps become "good enough" there will be a market for those apps that want to differentiate with the sluggish good enough apps.

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact