Hacker News Reader

Comment by shams93 | Hacker News Reader

Given the fact that most people are already maxed out on apps on their device with just things like facebook and youtube, you're going to be hard pressed to get people to install your app just to try it out. With a progressive web app if they like your app they can add it to their device home screen without installing via the app store and without using up space on their device. Also don't need to pay Apple $100 a year but you have the same benefits as a native app. Now with wasm you can even include native performance from a progressive web app.

View on HN

We've been hearing the same pitch for literally years. Heck, I've made some of them myself: "This is it, people! Native apps have been rendered unnecessary!"

No PWA competes with a native experience. Not performance wise, not usability wise, and ultimately for the developer not even development wise. It may still make a lot of sense, and there are a lot of arguments for web apps, but the enthusiasm in this discussion seems disconnected from reality.

Indeed, right now we're seeing a big uptick in Instant Apps on Android -- go to a webpage and it actually loads a native app -- and I fully expect the same to appear on iOS.

There is a bit of app exhaustion, though I'd say it's much more significant on Android where users have been taught that it's user beware. It certainly isn't a technical limit, though.

> (paraphrasing) No PWA competes with a native experience even development wise

I'm personally too spoiled by the React debugging experience, and I'm saying this as a developer who mainly does C#. On the other hand, I know many developers who can't stand a line of JavaScript. The answer is here a huge "it depends, really".

For those who can't stand javascript, typescript was made for you

Typescript is just a huge bandage. It doesn't change that JavaScript has horrible tooling that changes every full moon. Not to mention it still keeps many of JavaScript's horrible warts.

When you can't avoid Javascript (which is extremely likely now), Typescript is a huge boon. Not everyone has the luxury of working solely on the backend.

Which "warts" does Typescript keep from Javascript?

Lack of a decent stdlib is a huge one. I would rather opt for Clojurescript or Elm.

Have you recently used Javascript? I ask because it's evolved pretty fast in the last 3 years. Even the past 2 years seem like a blur to me. Before 2015 it was unusable for me for large app development. Typescript evolves just as fast since it's a superset of javascript. 2.x was when it was usable for me. With 3.x, I have even fewer complaints. imo both are improving way faster than I can complain. That said, I still can't go back to Javascript after using Typescript. With rxjs and other popular 3rd party libs, it's hard to notice any limits. I'm not in love with Javascript, but it's just hard not to work with it since it's become the franca lingua of programming. Everyone knows it because everyone probably has to deal with it sooner or later. The ecosystem is also really strong. I have yet to had re-invent any wheels, which is something that's hard to avoid when using tech with smaller communities.

Just a few days ago actually, and probably will again later this week. It still lacks a decent stdlib.

...and for those who want even more improvement over JS than just TS, there's Dart in the Flutter world.

Why Dart instead of Typescript? How well does it integrate with npm modules? i.e. do I have to reinvent a lot of wheels compared to using Typescript?

Bigger difference than that. Flutter has you writing in high-level components that become native draw calls using Skia. There's an in-progress back-end that outputs to HTML, Canvas, and CSS paint instead of Skia. You aren't going to be using npm much at all.

https://medium.com/flutter-io/hummingbird-building-flutter-f...

If you are using Dart without flutter (eg, overReact), then you're going to use npm a bit more (though dart has better builtin libs which helps a bit on that front). There is a generator that uses typescript definition files to generate dart interopt files.

https://github.com/dart-lang/js_facade_gen

Or Scala.js. Huge stdlib (the entire jvm PLUS js) ecosystem) and no language warts.

React Native gives you the best of both

Or the worst. You still have to install an app. It isn't native. Might be some cases where it makes sense but an spa might be easier for everyone.

What is the actual problem during debugging react?

> ultimately for the developer not even development wise

Ehhh I'm not sold on that one, as someone who has done a lot of web dev and then transferred to doing some iOS and Android work. The languages you can work in (Swift, Kotlin) are fantastic, and the APIs and frameworks are great. But XCode and Android Studio are a hot mess and have been for years. Plus, compilation delays every time you want to do so much as run a test, waiting for app store approval before you can push out a bug fix....

IMO the developer story for native apps isn't that great. The web has a lot of wrinkles too, but coding with Typescript using hot-reloading and instant deployment of code to users has a lot going for it.

> No PWA competes with a native experience.

It does in one key area: it loads instantly. I know Android Instant Apps are out there too, but having to persuade your user to go to an app store and download your app before they can do anything is a huge lift. The web always, always wins on that front.

> But XCode and Android Studio are a hot mess and have been for years

I can't speak to XCode, but I agree that Android Studio is terrible. Fortunately, you don't have to use it to develop Android apps.

> But XCode and Android Studio are a hot mess and have been for years

Not sure where this is coming from but Xcode has been working pretty well for most of us.

I hear iOS devs say that, but code editing in XCode for me is very uncomfortable compared to Webstorm, Visual Studio Code or Visual Studio. There are no tabs for open files to speak of (XCode opens a new XCode for their "tabs"), the UI is very cluttered and things are quite hard to find if you don't know where they are - and it doesn't help that the UI keeps shifting around in updates, making Googling stuff harder because a lot of images of things became deprecated.

> but the enthusiasm in this discussion seems disconnected from reality.

This isn't the OP's point. The point is there is more friction to download new apps today so coming out with a new native experience is going to much harder to do in today's world. It doesn't mean that this is the long term strategy.

I'm speaking to this discussion, not the submitted article. Sure, start with a web app (though it really depends on the target -- if the web app yields a sub-standard interface, performance, or utility it's a dead end) with hopes of building an app when you have an established base.

However in this discussion there are a lot of people who are arguing from the perspective of a world that doesn't exist, based upon the same "this changes everything" argument we've heard every year.

> I'm speaking to this discussion, not the submitted article.

Precisely my point. That's not what the OP was saying. Per their comment: to get people to install your app just to try it out.

> based upon the same "this changes everything" argument we've heard every year.

Did we read the same comment? Where did the OP write "this changes everything"?

You're using OP to mean "the root-level HN comment" where @endorphone thought you meant TFA.

I am, but they're both making the same point, so it's kinda moot.

On the contrary.

In spite of my preference for native apps, I only got payed to deliver mobile Web and hybrid apps.

The large majority of CRUD apps don't need native features.

Also signed PWAs have access to native APIs on UWP and ChromeOS.

It is only a matter of time until the Chrome team exposes the same capability on Android.

Well, the React Native experience is very similar to React for web. So I'm not sure the developer experience is THAT far off. Also, for line of business, mostly CRUD apps a PWA is probably a better place to start. You get iOS, Android, Mac, Linux and Windows in one place with one codebase, with no install.

Frankly, I'm far less likely to install any app than I am to use a web app. In fact it pisses me off when I can't do updates from my desktop. No, it isn't a technical limit, it's more of an I don't want more crap running in the background sending notifications. I disabled both FB and Pandora notifications because they were annoying me and many users don't even know how. I'd rather not even go there to begin with.

If I use a web app that is very useful, there are times I'll see if there's a native app for mobile. If there isn't, I'm okay with that.

Right now, I'm working on an application that is web based and is for desktop use. I'm able to use react + material-ui and a few other modules and it's been going very smoothly. I can't say I've ever had a better experience with desktop app development, or mobile. ymmv.

> Indeed, right now we're seeing a big uptick in Instant Apps on Android -- go to a webpage and it actually loads a native app -- and I fully expect the same to appear on iOS.

I'd never heard of this but I can guarantee I will immediately quit and never install an app that gets forced upon me via this method. This is like the terrible "Try our app!" web popups, only 10x worse.

I realize like most people on HN I'm hardly the norm when it comes to mobile users, but UGH.

I saw it for the first time last night. I think it was Vimeo. It was actually much better than the "try our app" popup, because it was android asking if i wanted to use the instant app, and when i said no it just went away.

That's more reasonable. I wonder if these work via Firefox? Maybe that's why I've never seen them.

I normally use firefox too, maybe I accidentally opened the link in chrome last night. I don't have my phone around to test. I just remember thinking "ahh that's kind of neat" before clicking no.

As long as it remembers no locally and just lets me use the web app forever after it's a godsend.

They should't be available via Firefox, just chrome/google search

Instant apps aren't installed, per se. They don't have homescreen icons, can't send notifications, access protected data, run background services, etc. However if you have an app that has a rich interface for some need, Google slices off the pertinent parts and can serve it up transparently.

I've been hearing the constant whining about non-native apps for years. Pack in it, you've lost.

Everyone is writing Electron and PWAs at this point. Nobody wants to train C++ developers for a minor speed boost consumers don't seem to care about. They have a full build pipeline and dozens of trained webdev engineers ready to go, why invest in a whole new product?

A LOT of people have looked at the cost/benefit of electron VS something like QT. Many have decided that the performance hit isn't worth the cost of developing the C++ build pipeline and training developers on how to build QT apps:

- Spotify

- Visual Studio Code

- Atom

- Invision

- Slack

- Mattermost

- etc.

The web tooling is actually pretty nice if you stay in your lanes. CSS / HTML / Javascript can create a really nice experience if you don't do a bunch of dumb stuff and make pragmatic decisions.

Wunderlist had/has native apps for all clients. One of the main reasons people LOVED the app. It's certainly not a guarantee, but if you want that final level of polish for a consumer app, native is the way to go.

There has been a ton of whining over the years about native vs some JS framework and I'm tired of the shit too. Now I can't speak for your QT but I can for IOS. Do you know how much easier it is to learn swift + xcode vs learning html / css / js in a framework that compiles to native code? The answer is very much.

I think it depends a lot on what you mean by "compete". I'm a heavy Twitter user. I now only use its PWA on Android and it's fine. I wouldn't call it perfect, but it's certainly very usable, and I suspect most non-experts would have a hard time telling that it's not a native app.

Especially for MVPs, I think they're competitive for a wide range of uses. The UX may not be as polished, but that can be more than made up for by instant availability, instant updates, lower dev costs, and faster release cycles. The ability of a new company to learn is limited by release cycle time, and I think fast, low-cost learning is a huge advantage to startups.

>No PWA competes with a native experience. Not performance wise, not usability wise, and ultimately for the developer not even development wise.

How much of a usability advantage does an app for, say, IMDB offer that the regular website doesn't? Or the loyalty card apps that a lot of grocery stores and coffee shops use now?

A lot of apps on the market are functionally just wrappers put around a poorly optimized website. They'd be better off putting their efforts towards making a great experience on the mobile web instead of trend-chasing.

In the iOS environment Apple could actually help here through a simple awareness campaign. You can save website bookmarks as icons on your home screen as it is, but this functionality is little known and not easily discoverable.

Companies saddle their mobile web experience with excessive animations, gobs of dynamic elements, screen-hogging navigation bars/sharing buttons/overlays, poorly-implemented infinite scrolling, etc, etc... and then they conclude that mobile web sites are bad and native apps are good.

People have forgotten that you can build a website that isn't a user-hostile SPA train-wreck.

Amen. Twitter[1] and Starbucks[2] have both built gorgeous PWAs in the last couple of years that are perfect replacements for 98% of a native app's functionality. It can be done, people!

1. https://blog.twitter.com/engineering/en_us/topics/open-sourc...

2. https://twitter.com/davidbrunelle/status/905931990444244995

Done in-house, I'd bet, and that's another disconnect to overcome.

Outsourcing website and/or mobile dev to external company, the focus is often more going to be on whizbangflashy, vs sleek/slim/fast/simple, to justify whatever budget they're getting.

I do find that I end up using the mobile web client for twitter as often as i do the native client. It's not much in either case, but the mobile web client is generally 'good enough' such that if that's where I land, I don't feel a need to jump to the native client.

Twitter's mobile web site is the most unreliable site I encounter with any frequency. Fully 80% of the links I get to Twitter fail to load, telling me to try again, which only works when I fully refresh the page.

I don't know how it compares to their native app.

You're missing the point. A mobile app isn't for the benefit of the user, it's for the benefit of the analytics and marketing teams. They want to be able to know who's engaging with it, and spam them with notifications.

> No PWA competes with a native experience.

Sure they do. Consider Reddit's website (well, before the atrocious UX updates the past few months) vs. their mobile app. It work(s)/(ed) perfectly fine.

There's literally no reason to use their native app (well, other than their ridiculous, atrocious, never-ending prompts on their mobile website to use their native app).

Here's a tip - take any reddit URL and add '.compact' to the end. Example: https://www.reddit.com/r/all/ becomes https://www.reddit.com/r/all/.compact

This uses the original reddit mobile site. It is very fast and clean.

At least they are consistent, go to the compact site, giant banner appears:

> You've been invited to try out reddit's new mobile website! try reddit's mobile website

Luckily, it's easy to block with AdBlock Plus.

> well, other than their ridiculous, atrocious, never-ending prompts on their mobile website to use their native app

In your settings there's an option to tun this off (I agree, a truly terrible user-hostile default).

That's because Apple and Google are doing everything in their power to keep apps tied to their app stores. If they wanted to they could make progressive apps runs as smooth as native apps tomorrow by enabling better native integration, but they won't.

Google makes a ton more money off of web search than their app store and they keep releasing new features that allow you to access your devices sensors so I doubt that for google.

> No PWA competes with a native experience. Not performance wise, not usability wise, and ultimately for the developer not even development wise.

This would be correct, in theory, if companies only made apps where the extra power that the app has is necessary, and would stick to websites otherwise.

In practice, this isn't true, and anyone who has ever opened any major app store knows that many popular apps in it are, in reality, just wrappers around a webview, and the only reason why they are apps at all is because the management demanded that there is an app, like all the cool kids have these days. Most apps really would be better off as just websites precisely because they don't need anything that an app gives, but often suffer from what it takes (e.g. ad-hoc navigation versus standard browser controls).

> With a progressive web app if they like your app they can add it to their device home screen

Does anyone even know they can do that? I've never seen anyone do it "in the wild". Would love to see any stats around usage of pwa's added to home screen.

I run a PWA and can track this based on the "standalone" property. But what's more telling is customer requests. It's a confusing request that it seems like many potential customers haven't seen before. Lots of people ask me to "just put it in the app store" despite having an FAQ with instructions on how to add to the home screen. Many more say they will become customers "when you have an app"

Because of this, I'm working on making my UI more app like and using Cordova to publish it to app stores.

edit: My app is still pretty small but the percentage of logged in users who have ever loaded from the PWA is < 5%

Users always have to be educated, whether it's PWA or how to pronounce the @ symbol a mere 20 years ago.

Chrome on Android will show a banner to add it to your home screen.

True, the situation on Android is much better than iOS. Also after you do this, you get an icon in your app drawer and not just the homescreen.

iOS doesn’t have an app drawer, so I’m not quite sure where you’re going with your comparison…

Yep, sorry that was confusing. I was comparing to previous versions of Android. It's relatively new that it's added to the app drawer.

It also shows up as an app in the system menu, with natively controlled permissions, notifications, battery restrictions, etc.

I run a website where I get asked quite often to make it into a mobile app, and I reply by showing how to add it to the device's homescreen and not need an app. Never ever ever in the few dozen times I've had this conversation has anyone ever actually done it. In fact most responses to that suggestion have been overwhelmingly negative. They want an app, even though it'd just be a wrapper around the site with no added features, they want an app.

Bingo. That's exactly what end-consumers want. If you have a good enough PWA, you can wrap it in a single webview and push it to the appstore/play market. The presence is the important part, the actual implementation does not matter.

Why not just add the ability to list a PWA in the app store? At that point the installation is intentional and the overhead on Apple/Google is minimal... and Apple still gets their $99/year to allow making it easy to put your app's icon on a user's home screen.

On one hand I can see rational reasons for them not allowing it; Apple doesn't control when you push updates to your PWA, so they don't want to give their seal of approval by listing it in the app store.

But on the other hand, it's pretty depressing to give up the dream of instant app updates, by wrapping your shiny PWA in Cordova and promising to never execute external JavaScript.

I recently picked up app development and I went for React Native + Expo. I was shocked that I could push OTA updates without going through the store. Basically if my app was approved once, I can make huge sweeping fundamental changes to the app without running it past Apple again. Basically the only things you can't change are the permissions. Anything else is fair game. And with Expo it was basically trivial to get an app up and working (don't take this as biased praise in favor of RN or Expo, I still have serious dissatisfaction with both technologies, but this particular part was shockingly seamless).

So I guess moral of the story, wrap your PWA in an Expo app and update as often as you want without having to resubmit.

Oh, cool. I think I was confused about Apple's rules on this. I guess you are allowed to push minor updates to your app, as long as it's JavaScript being executed by their JavaScript engine/WebKit.

But apparently there is (or at one point was) a restriction that says you're not supposed to add new features via remote executable code pushes [0] (although I'm not sure if they'd notice).

[0] https://rollout.io/blog/updating-apps-without-app-store/

Pushing updates without going through the app store has been allowed by Apple as long as the assets being updated are not binary code; specifically CSS, HTML, and JavaScript are okay (I wonder whether WebAssembly will be considered "binary" or not... will be interesting to see). I convinced a former employer to abandon their Xamarin-built app and switch to Ionic (Cordova with nice, fancy UI additions) specifically because they could push updates to the app without going through the app store. Officially (unless things changed?) the Google Play store says this isn't allowed but there is no review process with Google Play so publishing a new app and then pushing an update for the previous version won't likely get you in trouble. If someone HAS been busted by the Google Play cops for this it would be news to me.

Ionic CEO here - have seen no issues with anyone using our deploy (web-content remote update) feature on either platform to date

Microsoft does this on UWP.

well i had a different experience. we dong have a native app, but some of our b2b customers wanted an "app" to use on mobile. The app is responsive so we show them how to add it to homescreen and that's it.

It might be business customers are more willing to jump through hoops. My website is targeted at the general public in a small midwestern town, where technology is a four letter word.

Indeed. Business customers aren't representative of the greater public because they tend to take their issues directly to IT support, they get it sorted, and don't think about it again. Your every day average user doesn't have an IT support department to which to go. They do, however, have the App Store/Play Store.

My guess is that it's rare. Hell, I didn't even know I could do it until I was developing a PWA. I've never seen a website that offers it.

It would be very nice if phones put that feature front-and-center. My guess is that they sideline it so the web can't compete with their native apps.

It really reeks of the same kind of anticompetitive behavior that got MS in trouble twenty years ago.

Apple is way worse in this regard, but Google is still incentivized to keep at least PWAs from being first class citizens on Android because they don't get their app store sales cuts or microtransaction money from them. And at least on Android you can install other browsers.

People consider the hegemony of Chrome to be the premier threat to the open web but I keep feeling iOS Safari is the real drag. Apple is so heavily incentivized to sabotage web tech that could encroach on their app store revenue.

They do it on ChromeOS though, so I guess it is politics as usual.

You can use browsers other than Safari on iOS.

All browsers on iOS are essentially wrappers for Safari. They all have to use the built-in iOS WebView; per Apple's rules you're not allowed to execute JS or anything like that on your own.

Which means no extensions for iOS Firefox nor Chrome.

I can’t install any adblockers on my iPhone, the best is Safari which has some built in anti-tracking but that’s it.

I wonder if there is anything like a PWA store?

Win10 store allows PWAs, and even automatically lists the ones it finds online (via Bing crawler).

https://developer.microsoft.com/en-us/windows/pwa

I find it all oddly ironic. Remember back in late 90s - early 00s, Microsoft was generally hostile towards open web and the (then only just appearing) web apps, because that undermined its desktop app monopoly? Here we are 20 years later, and now it's Apple and Google protecting their turf on mobile, while Microsoft is promoting PWAs to entice the mobile devs into supporting Win10.

I have a HN bookmark/icon on my home screen.

Yes. Most of my users are using the page as an app and the usage has only increased the last year's.

>if they like your app they can add it to their device home screen without installing via the app store and without using up space on their device

As far as I'm concerned, until evidence to the contrary is provided, most people either don't do this or know how.

Relying on a pinned app for smart phones is a good way to kill your startup.

>you're going to be hard pressed to get people to install your app just to try it out

In fact, the statistics prove[1] that this is false. Most app installs are to try it out, and promptly delete it. Most users will delete your app shortly after installing it.

Informed opinions are nice to share, uninformed ones not so much.

[1]https://www.emarketer.com/content/most-apps-get-deleted-with...

> Most users will delete your app shortly after installing it.

Which is why it is so crucial to focus on the core utility of the app. If the app is fun to use, great. But the apps that stick around provide services that are essential to the user.

> >you're going to be hard pressed to get people to install your app just to try it out

> In fact, the statistics prove[1] that this is false. Most app installs are to try it out, and promptly delete it. Most users will delete your app shortly after installing it.

I'm really not following how this disproves what was being said. They were saying it's difficult to get people to even install for a test run, and you're saying most installs are test runs. There's nothing mutually exclusive about those two statements.

> Informed opinions are nice to share, uninformed ones not so much.

What a pompous response to make when you're not actually falsifying anything in their post.

>They were saying it's difficult to get people to even install for a test run

How is it difficult to get someone to install something for a test run when like 90% of app installs are test runs? So you're saying it's difficult to get someone to install your app at all, and that has nothing to do with your product or your marketing, but it has something to do with the technology?

And the PWA experience of pinning things to your home screen, which we have absolutely no reason to believe is widely done, is a better option?

There are 200 billion some odd app installs per year (primarily for test runs), there are ??? mobile PWA app home screen pins per year.

I'd like to see you try and support OPs claim rather than argue about my comment.

> How is it difficult to get someone to install something for a test run when like 90% of app installs are test runs?

The link you shared does not provide any statistics about the amount of installs relative to didn't-installs. It only deals with the set of people who have already installed, which says nothing to prove or disprove the point in contention (that increasing the set of people who have installed at all is difficult).

> So you're saying it's difficult to get someone to install your app at all

Yes [they are].

> and that has nothing to do with your product or your marketing, but it has something to do with the technology?

Based only on what they wrote, not necessarily. They only seem to be saying that the statistics you provided do not support your conclusion:

>> you're going to be hard pressed to get people to install your app just to try it out

> In fact, the statistics prove[1] that this is false. Most app installs are to try it out, and promptly delete it. Most users will delete your app shortly after installing it.

Ah, if I had seen you post this before I did, I wouldn't have bothered to post my own. Thank you for summing it up so succinctly and respectfully.

To recap. The claim is that PWAs are preferable to apps because "people don't test drive apps."

In fact, people test drive apps as a rule, and none of them install PWAs. I have shown a 2 second googled piece of evidence showing the degree to which people test drive apps. No evidence to support the ease of use or frequency of PWA homescreen pins exists/has been provided.

I'm going to stop responding to this thread unless your comment contains a substantive argument supporting OP.

> To recap. The claim is that PWAs are preferable to apps because "people don't test drive apps."

Ah. Now I see where the confusion lies. I don't think that's what the OP was saying.

> Given the fact that most people are already maxed out on apps on their device with just things like facebook and youtube, you're going to be hard pressed to get people to install your app just to try it out.

No one in this thread is claiming that people who install apps don't test drive them. Your evidence proves that they do, and no one has challenged or disagreed with that evidence.

The claim is not related to how often people who download an app test it out and delete it soon after. You're focused on the wrong detail. The claim is that they aren't even downloading apps to test them in the first place.

> I'm going to stop responding to this thread unless your comment contains a substantive argument supporting OP.

The OP is the only one arguing OP's perspective right now. Everyone else is just trying to get you to understand what the OP is actually saying rather than what you claim they're saying.

Let's try an analogy:

> Millennials are increasingly choosing not to eat at casual dining chains such as Applebees.

Responding to that by saying that Applebees is the most popular casual dining chain by a given metric does not disprove this claim. Whether people choose Applebees more often than Chilis has nothing to do with the fact that they're both losing millennial customers.

>They're saying it's difficult to get people to install an app even to test drive them, and saying it's easier to get them to visit your webpage.

But getting people to visit your website being easy does not mean that is where you should host your app. I don't believe people are going to say "Wow this website was useful, let me pin it to my screen." I believe that is a niche thing that nerds do, and has awful results for the rest.

>The claim is that they aren't even downloading apps to test them in the first place.

But there is nothing here to show that a PWA is the solution to get someone to download the app! The assertion is that the download is the issue, which there isn't any evidence for. If downloading apps was such a problem, why would people constantly be test driving apps? They may uninstall because of space or tracking concerns, or maybe it's a cleanliness thing, but I am refuting the base claim that "space on your phone" being a deterrent means that PWA is a solution.

Get the download through marketing, hold the download through value.

>Everyone else is just trying to get you to understand what the OP is actually saying

I think I understand what OP is saying just fine.

> How is it difficult to get someone to install something for a test run when like 90% of app installs are test runs?

As I said in my previous post I'm clearly missing something here. Why are those mutually exclusive at all?

You're saying that most installations are test runs. That implies people are leery about leaving an app they don't want installed. Why does that mean that it's somehow easy to get users to install in the first place? It sounds like they don't want a bunch of apps installed.

> So you're saying it's difficult to get someone to install your app at all, and that has nothing to do with your product or your marketing, but it has something to do with the technology?

No? When did I say your product or marketing were unrelated to install rate?

> And the PWA experience of pinning things to your home screen, which we have absolutely no reason to believe is widely done, is a better option?

When did I make that claim?

> I'd like to see you try and support OPs claim rather than argue about my comment.

Why does disagreeing with you mean I support the OP? Whether or not I support PWAs, native applications, both, neither, or even "native" wrappers around a PWA is irrelevant.

My stance is that your statistics don't disprove the claim made, and to then claim that the OP is arguing from a point of ignorance is not okay.

>As I said in my previous post I'm clearly missing something here. Why are those mutually exclusive at all?

If it was hard to get people to test drive your app, then 90% of app installs would not be test runs. They would be one time permanent installs.

>It sounds like they don't want a bunch of apps installed.

It also sounds like people are constantly trying new apps, no? Precisely what OP said people do not like to do.

>No? When did I say your product or marketing were unrelated to install rate?

Again, OPs claim was that somehow PWAs would be a preferable medium to app installs. This implies that the medium is the problem, which I am saying is not the case. "The reason people aren't downloading my app is because it's in the app store instead of being a PWA" is essentially the claim.

>Whether or not I support PWAs...is irrelevant. My stance is that your statistics don't disprove the claim made, and to then claim that the OP is arguing from a point of ignorance is not okay.

I think we both know that I could scour the internet and find 1,000 articles filled with statistics showing that people are constantly installing and uninstalling apps, and I would find almost none showing PWAs being successful in a business case. I'm not going to apologize for being incredulous about unsubstantiated conjecture that I have only ever seen proof of the opposite for.

>If it was hard to get people to test drive your app, then 90% of app installs would not be test runs. They would be one time permanent installs.

That doesn't logically follow.

Consider the possibility: Only 1 in 1000 of people who learn about your app is persuaded to install it. And then, of the small number who install it, 90% of those uninstall after 10 minutes.

I've exaggerated the numbers to make the point.

The point is it can be hard to get people to test drive your app and also have most installs be test runs.

They are not mutually exclusive.

> If it was hard to get people to test drive your app, then 90% of app installs would not be test runs. They would be one time permanent installs.

I think you and I have opposite understandings of the same data. You're looking at a high abandon rate after installation and claiming that it represents an increase in customers going out to find apps.

I don't think there's any substantive evidence of this. You have evidence showing that customers have a strict filter on what they keep on their phones. Why does a tightening of one stage of the pipeline have anything to do with a loosening at a previous stage?

There aren't a fixed number of installations that stick, uninstalling an application does not mean the customer will go right back out and install something else.

> I think we both know that I could scour the internet and find 1,000 articles filled with statistics showing that people are constantly installing and uninstalling apps

That people uninstall most apps they eventually do install does not imply a regular stream of new installations.

I wonder what would happen if you provided instructions for pinning a web app on popular platforms. Would users ignore this new information?

Many websites in the past have provided instructions for bookmarking.

On iOS you won’t get notifications or be able to run anything in the background.

But if you are trying to start a business and the $100 a year you would have to pay to distribute your app will make or break you, you have bigger issues.

Too many applications abuse notifications and background processing anyway. If you need those features, you have to convince of far more value before I'll install a thing.

If you want an iOS app not to “abuse” background processing, there is a setting that will disable the ability on an app by app basis. Of course you have granular control over notifications and how they are presented on a per app basis.

I'd wager you are not a great representation of the market that 99% of apps serve. Apps abuse those features because it works well for their business.

>Apps abuse those features because it works well for their business.

In the short-run anyway...

This is true.

I allow certain apps to use notifications because there are things that I want to be notified about. My card balance from the Starbucks app, or breaking news from the New York Times app.

Both of those companies started abusing notifications. Their apps are no longer on my phones.

> I'd wager you are not a great representation of the market that 99% of apps serve

I'd wager no one is. Snapchat has 200 million users. There's some 4 billion people on the internet. Niches are niches, and no one serves everyone.

I wish "no one" was my customer then I could get a $40B IPO serving everyone :)

I think the point stands, and the article explicitely says "start with". Apps can come later in lots of cases. A personal example - I was hired to build the MVP Android app for a new greeting card company. 1 year later: It's been done for 6 months, no one's using it, no one wants to use it, everyone's using the web app.

On iOS you won’t get notifications or be able to run anything in the background.

Ok, but what are the downsides?

As a user notifications are a problem, but as an app developer they absolutely work to drive engagement, which is why so many apps use them. So if you’re trying to run a business that’s a pretty important thing.

> As a user notifications are a problem, but as an app developer...

So do you develop apps but not use them? I can't think of a way the hypocrisy isn't shocking here. "Do unto others" and all that.

I’ve developed software all of my career that I personally have no use for.

I develop software to pay my bills. We are talking about notifications, not killing puppies.

We're not talking about whether or not you are killing puppies -- I don't think you're a sadist. Just "make stuff you would want to use." Or "do unto others as you would have them do unto you." Or, if you prefer, "act only according to that maxim whereby you can, at the same time, will that it should become a universal law."

> Just "make stuff you would want to use."

So I should quit my job developing enterprise software because I don't personally have a use for enterprise software?

You think notifications are universally "a problem"? I find many notifications to be quite useful. Appointment reminders are VERY important to me and not at all a problem.

They probably mean generally a problem. Things like reminders seems like a good use case, but with all the apps trying to increase engagement, it seems necessary to mute notifications to an app right after downloading it.

You don’t need to “mute” them, just don’t approve the notifications permission request. Out of the 100+ apps I have installed, I have zero that annoy me with notifications.

Notification management is the problem. Not notifications themselves.

One part is on the system to provide the right management tools, the other is on the user to tell the system what notifications are important.

> Notification management is the problem. Not notifications themselves.

Notification abuse is the problem. Notifications have been so heavily abused by apps (and increasingly now by websites themselves) that makes the notification system itself look terrible.

Users don’t care about “driving engagement”. If your product’s user experience is important, or if is made with any empathy at all for the user, it won’t be spamming him with notifications purely to juice a startup vanity metric.

Unless I absolutely have to have the app (work or something), I avoid it. Webpage any day. It wont bug me in the middle of the night.

  3AM. Sleeping
  Phone: BING!!!
  Me: *groggy* shit, hope everything is ok...
  Me: *picks up phone*
  Phone: Rayman Adventures has updated!
  Me: *uninstalls Rayman Adventures, angrily goes back to sleep*

That’s an easy one - set Do Not Disturb to start at 10:00 and end at 7AM. It will still allow messages through for contacts that you specify.

In iOS 12, you can turn off notifications directly from the Notification Center for an app that bugs you.

Not to sound condescending but why would you have your notifications on at night? 10pm-7:30am do not disturb has been a godsend.

Work. Slack, texts, calls (could be anyone in my department whose number I don't know), PagerDuty, the random number PagerDuty call from. More of a pain to whitelist than to just avoid random apps with notification.

You have to specifically allow notifications after you install and launch the app. Just say “no” when it asks you for permission to send you push notifications.

Good luck, it sounds like a nightmare to be on call all the time.

One week out of five (rotation). Our software has to work (and work well) 24/7/365.

Service workers allow for push notifications and other background tasks.

iOS doesn’t support push notifications for web pages.

Are Safari push notifications desktop only?

https://developer.apple.com/notifications/safari-push-notifi...

Yep, desktop only

https://www.izooto.com/blog/ios-push-notifications-safari

And this might be why....

Web Push Notifications have clearly made difference in every marketing campaign it gets involved in.

Using email as a notification service works in this case. The user probably gets a notification for new emails.. at least if they do they chose to. :)

Email delivery has its own set of problems - mostly spam filters.

Even when the email does reach the end user, most people get so many emails it’s easy to get lost in the noise.

Using notifications to bypass spam filters speaks to the quality of the notifications you're sending.

If your e-mail is important, people will find it.

If your e-mail gets lost in the noise, then notification is probably not essential.

Getting caught in spam filters has little to do with whether the email is legitimate - just whether it is seen as a bulk email.

It does have issues when it comes to getting users to do something they don't want to do, but it is more than good enough to communicate with users about something they actively want to do.

I have no interest in the former.

With cordova you can create a thin wrapper that can add those features you need, starting with a PWA and extending.

Can you provide data to substantiate your claims? I'd truly like to know if this is true, because my intuition and experience tell me the opposite. People like downloading and trying out new apps. I also disagree with the premise of this post. Many people exclusively use their phones and would never utilize a web version of an app.

I think it depends... it's probably bias to more technical users vs moms, dads and kids generally. I know I'm far less inclined to use a native app for something new. I also hate when I can't do updates from my desktop. I use linux, windows and mac regularly.

Of course via cordova, it's easy enough to create a thin wrapper and add a few bits for notifications and better capture integration (if you need photos/video, etc). Since I'm mostly doing react these days, I'd consider react-native a natural next step.

PWAs are becoming reasonable for mobile devices and could really help with some apps for initial distribution and usage.

I might implement the first version of mobile reading within Polar (https://getpolarized.io/) by using a PWA.

The general idea is to have both a PWA and a native app.

The PWA gets the users addicted and then you can have an 'install app' button within the PWA.

If your app is insanely complicated it's possible to have your app as just a PWA on steroids (though not always straight forward).

We're using Firebase (just wrote up a post about it here):

https://getpolarized.io/2019/01/03/building-cloud-sync-on-go...

... and the cool thing about Firebase is that there are SDKs for basically all platforms with really solid mobile support.

> Given the fact that most people are already maxed out on apps on their device

This argument has been given a few times here. But I question whether web applications are a solution. Aren't these just more applications that people are overwhelmed with but harder to find and use?

If you've got a brilliant new app (web or mobile) I'm still fatigued either way. The mental effort is the same. Saying the mobile apps are "maxed out" seems to me to apply to web apps in just the same way.

I think they were referring to RAM or storage space rather than human fatigue or mental effort, although I'm not a native English speaker so I may be misinterpreting.

Indeed, there are many low-end smartphones that run out of storage space after one or two years even without installing anything, just with the automatic updates of the preinstalled apps (Facebook is a major offender here, why does their app grow more and more?). Being forced to install an app to use a service when you are in this situation is highly frustrating.

What year are we in? I've got a $200 phone with 128gb storage and 4gb ram. It will be a long time before I can max this out if at all.

Not everyone buys a new phone frequently, and not everyone can or will spend $200 on a smartphone without a second thought, especially at the global scale.

Smartphones are getting better and hopefully this problem will be irrelevant in a few years, but I still know plenty of people for whom it's still very real at the moment.

Sure, I was part of a startup designing apps for emerging markets and I understand the restrictions but I think these restrictions changed somewhat for phones bought from 2018 on. I just returned from 2 weeks in India and it was common to see people in the streets with ~$200 phones

Sub $100 phones rule the streets here in Nigeria. In those cases storage is very precious and limited.

The flip side is that people who can only afford sub $100 phones are not as valuable targets to develop apps for.

To add a progressive web app to the home screen on iOS, doesn't the user have to use the share menu (and even then, it's buried a bit -- the user has to page the share options at least once to find it)? There's no way to display a prompt to add it, like with Chrome/Firefox on Android?

That's how it was the last time I checked, and it was enough for my employer to say no.

Yes. There is no way to prompt the user and, to make it worse, it can only be done from Safari. If the user is using a browser from the app store (like Chrome) it can't be done at all.

Yeah it is massively worse user experience than installing an app from the app store. I feel like anyone suggesting it is better has an agenda of some sort. It's objectively worse in every way for the user. Suggesting the $100 is a barrier to entry is absolutely laughable. If you are going to talk about money talk about the 30% cut they take. That's really the only reasonable argument in favor of them.

https://www.apple.com/newsroom/2019/01/app-store-caps-record...

The list of top grossing apps paints a rather different and rather unflattering picture of the app store economy.

https://www.apple.com/itunes/charts/top-grossing-apps/

I agree completely. What’s surprising is that Spotify is still a top grossing app even though they haven’t allowed new in app subscriptions for a year or two.

I guess those are legacy subscriptions.

But on the other hand, that also goes against the narrative that PWA’s will replace native apps anytime soon. Most of the apps on the list:

1. Require some type of DRM (streaming media)

2. Take advantage of in app consumables like games where the immediacy of being able to capture the whales through in app purchases make sense.

3. Need the performance of native apps.

> Given the fact that most people are already maxed out on apps on their device with just things like facebook and youtube.

I don't even have those apps. If I did, my battery would be dead in a couple of hours. If I need to use those platforms, I do it through a web browser and usually I use a different browser (e.g. duckduckgo) isolated from my other browsing habits.

duckduckgo has a browser now?

Pick your poison: https://play.google.com/store/apps/details?id=com.duckduckgo...

https://itunes.apple.com/us/app/duckduckgo-privacy-browser/i...

I did not know they made one. Thanks!

Does Duckduckgo makes a browser now? Or do you mean that like most of non geeky folks you access websites not by typing an url in the address bar of a browser but instead by going through a search engine (in this instance Duckduckgo)?

That's only the case for useless apps. Try creating a useful one. For example, here's my old hobby project, now open source, that got more than 100k installs with zero marketing: https://github.com/Const-me/SkyFM

I think PWAs are still considered more of a novelty.

If they really ever catch on, I could see where apple might require you to start hosting some kind of cross-signed cert or something that you can only get from Apple to install/use them.

> If they really ever catch on, I could see where apple might require you to start hosting some kind of cross-signed cert or something that you can only get from Apple to install/use them.

And you would find this acceptable? I would find this appalling. Apple can charge for the App Store because over the overhead. It hosts the servers that have to transfer the apps. It runs an App Store to help with discoverability. It also maintains the API developers use.

In the case of PWAs, none of these are true. There is no overhead for running an App Store for Apple. I could see there being a fee to be in the App Store. That should be up to the developer though. If you are doing the work of getting people to install the app yourself, you owe them nothing.

In Apple's defense, they do have to do the work of building in PWA support to iOS/Safari. But if you are paying over $1,000 for a device you better damn well be able to install a PWA.

Microsoft does it, if the PWAs are signed, they get full access to UWP APIs, just like any other native app.

I've never added a PWA to my device. How do you find them? I suppose they don't get added to the store so no way to search for them there. Do they show some popup when you visit their site?

Is there some directory of PWAs?

What does "maxed out on apps on their device" mean?

After years of experience:

0) Native means you get notifications: APNS, GCM.

1) If you don't go native, you go SEO. SEO is hard.

Web has had notifications for years too.

Not on iOS. https://caniuse.com/#feat=notifications

I have never clicked yes to allow web notifications in my life. I have only once added a site as an icon on my mobile. The whole premise of this article is false. The real answer to whether to start with a site or an app is it depends. At Bibimapp we have an app [0] requiring sign up etc (launching beta next week) and a related site which is free to browse which provides value but approaching the problem space from a different angle. The site is essentially the top of the funnel.

[0] https://bibimapp.com/

"Web has had notifications for years too."

Yeah. But people don't use desktops anymore.

So what are all those laptops on every coffee shop I go to?

Native means you also get background processing and access to things like geolocation and camera feed w/o needing a plugin.

> With a progressive web app if they like your app they can add it to their device home screen without installing via the app store and without using up space on their device.

Just no. As near as I can tell, PWAs are worse than apps from a security point of view. The odds approach zero that I'd ever dare to use one.

Reply on news.ycombinator.com