
The web apps that will eat mobile - ausjke
https://kruschecompany.com/blog/post/the-web-apps-that-will-eat-mobile
======
judah
PWAs indeed have a bright future.

Apple's iOS Safari remains terribly lagging behind in PWA support. Even the
latest iOS 12 beta support for PWAs is utterly broken[0], including full
reloads on suspend/resume, local storage gets blown away on reload, no icon,
incomplete support for web manifest, and much more[1].

A charitable interpretation of this would be, Apple hasn't felt the need to
keep its PWA support up to par with the other browsers due to the success of
its App Store. A cynical interpretation is that Apple is deliberately dragging
their feet because PWAs undermine their $99/year + 30% app price + 30% in-app
purchases business.

[0]:
[https://twitter.com/firt/status/1003761267155394561](https://twitter.com/firt/status/1003761267155394561)

[1]:
[https://twitter.com/tomayac/status/1003910651151085568](https://twitter.com/tomayac/status/1003910651151085568)

~~~
jmull
"A cynical interpretation is that Apple is deliberately dragging their feet
because PWAs undermine their $99/year + 30% app price + 30% in-app purchases
business."

That interpretation doesn't make sense. The $99/year/active developer is a
nominal amount -- sofa change to Apple -- that couldn't sanely affect the
Safari development roadmap. The 30% is a much a larger amount (though still
small to Apple's scale), but PWAs don't compete for that money; a PWA
developer looking to monetize their app doesn't have an alternative
monetization platform/store with anything like the reach into the iOS device
market. Put another way: a PWA developer looking to monetize their app is
surely going to release it through the Apple app store anyway.

~~~
Fuddh
I agree that the $99/year/developer isn’t that much for Apple. The 30% of all
sales is probably significant though - the App Store has a lot of users.

I don’t necessarily agree that PWA developers have no way of monetising their
apps though - if I’m not mistaken they could use ads and subscriptions for
their services. These would normally grant a cut to Apple if they were done
through the App Store, hence the incentive for apple to delay the
implementation of PWAs.

~~~
judah
$99/year isn't small. There are 2m apps in the iOS App Store today. Each app
must pay $99/year. That's __$198m /year __as a passive income stream for
Apple.

Factor in 30% of app purchase price, plus 30% of in-app purchases, and you
have a significant revenue stream.

~~~
nodamage
This assumes (incorrectly) that every app is released by a different developer
with their own account. In reality many of those 2M apps are basically
shovelware - with developers releasing dozens if not hundreds of different
apps under the same account.

------
bsbechtel
Unpopular opinion here, but I just don't see PWAs living up to the hype. Yes,
there are lots of technical advantages, they're catching up to native apps in
capabilities, and there is reduced friction by bypassing app stores. However,
the ingrained user behavior of downloading apps from the app store, trust of
knowing what you're downloading by doing so (yes, even on Android), and
browsability on mobile falling behind searching the app store from a ux
standpoint make me think there are still some big barriers to PWAs taking the
mobile world by storm. Yes, they'll have their place, but I don't see them
living up to the hype often promised by their evangelists.

~~~
zwieback
Depends on the user, I might be an outlier but my "ingrained behavior" is to
not download an app unless I absolutely have to.

~~~
tjoff
So the solution is to automatically download and execute anything and
everything?

The 90s called and want ActiveX back.

~~~
jasonkostempski
As long as I can use a browser with uBlock Origin and API access (location,
file system, camera, etc.) remains sane, I would very much prefer a web app. I
don't want to: waste time installing; use up limited storage space; allow who
knows what kind of access to other stuff on my device (e.g. LinkedIn and
Facebook style abuse of native APIs); and have no way to combat ads.
Especially for something I'm going to use maybe just once a month or less.

~~~
zwieback
Add "10 apps need your approval to update" to the list

------
mikece
Progressive Web Apps have the potential to be massively disruptive to apps as
we know them now... and that's _before_ the near-native speeds that WASM will
bring are factored into the equation. After making the mistake of going all-in
on Xamarin in 2014 I realized, much to my chagrin, that the future of mobile
is HTML, CSS, and JavaScript. Sure, there are cases where certain features
require vendor-native apps for now, for example if you want to register a
service that runs in the background without the app being launched. Currently
that's not possible with mobile web or hybrid but there's no reason the mobile
OS cannot look for and hook JavaScript -- or WASM -- code and run it as part
of a background service. Could be as simple as specifying in the app manifest
one or more code files which contain logic for background processes along with
instructions like "run this only when the app is active, run it all the time,
or run it on this cron schedule."

A completely different question is whether vendors like Apple will refuse to
support something like this because it circumvents the need to deliver via the
app store (and the $$$ they collect through the Apple Developer Program) but
there's no reason background services and processes can't be implemented in
JavaScript.

~~~
vbezhenar
I have the same thoughts. Phones were too slow few years ago, web standards
were not mature, so well written native apps were in obvious advantage. Now
phones have proper CPUs, lots of RAM, so web apps for many tasks won't be
distinguishable from native apps. Web standards are good too.

May be Apple will curate list of blessed websites and allow them to launch
background services, using icloud payments, etc. This way they'll continue to
have their cut and their control.

~~~
fauigerzigerk
5G could help close the gap as well.

------
oneshot908
How many years have we been hearing this tale? And yet almost every major web
site continues to bend over backwards to persuade us to install their battery-
killing surveillance system oops I mean mobile app.

So the solution now is even more battery-killing HTML + Javascript + Secret
Sauce? Hell no...

PS Just say no to push like the Hulk says no to Banner.

All IMO of course but these days, I use my phone for Yelp, Google Maps,
weather, GMail, stock prices, and little more. The improvement in battery life
from 6-8 hours to 2+ days has been astounding and what it's drove me to the
viewpoint I just espoused. Am I missing something here?

~~~
blub
We've been hearing this tale for more than a decade and native apps are still
better at pretty much everything. :)

Web devs are a very optimistic bunch.

~~~
vbezhenar
They are not better at a single and simple thing: cost of development for
multiple platforms. And it means everything, unless you're swimming in money.

------
htormey
“According to Google’s data, for native apps 80% of time is spent in each
users’ top 3 apps. Just 3 apps!“

I also probably spend a large percentage of my time online on a handful of
websites. That doesn’t mean the other 20% of my time isn’t incredibly valuable
and not worth building an app/website for.

As an advertising company Google have plenty of incentives to push PWAs.
Apple, who own the minority hardware platform with the most affluent users, do
not. So long as this is the case their will be a strong monetary incentive to
build Apps as the PWA experience will always feel a little off.

A non technical point glossed over by this article is the discoverability app
stores afford the end user. I see this in person all the time: I tell someone
about a new service or online store and the first thing they do is search the
App Store for an app not the web.

In summary I think companies will build PWAs as either a complement to an
existing mobile app or as a first product when they don’t have the budget to
build an app.

~~~
mromanuk
I was looking for this comment. I concur, is in Google interest to push PWA.

------
djanogo
There are two ways to write mobile app...

1\. Write native app's for both the platforms, pay once and cry once. 2\.
Write web mobile apps, realize how sub par the experience is, rewrite in
native. Pay twice, loose competitive advantage, and cry twice.

This is what, 3rd or 4th iteration of web app's are going to take over mobile
cycle?. My first instinct about any blog that promotes this turd is, either
their business depends on selling this solution or the person is huge web guy
and never really worked on complex native apps.

~~~
chii
> realize how sub par the [mobile web app] experience is

why is this a given?

~~~
pjmlp
A proven experience since Symbian introduced the Web Runtime in 2011, with a
few dead OSes pushing for a Web only experience?

~~~
oblio
There is such a thing as "good enough". The cheap plastic solution tends to
win when that happens. We weren't there in 2011, maybe we're not there in
2018, but the writing's on the wall.

~~~
pjmlp
When that happens, the browser would have turned into a general purpose VM
running apps via WebAssembly with WebGL/WebGPU for rendering, thus becoming
native as well.

The writing is on the wall with the ongoing efforts on .NET, Java, Go, Unity,
Unreal and who knows, someone might even port Flash to it.

~~~
oblio
I don't consider an universal bytecode as native.

~~~
pjmlp
So according to you IBM and Unisys mainframes, the Xerox PARC computers,
watchOS apps don't run native code.

~~~
oblio
Do the CPUs of their respective systems directly understand the instructions?
In my opinion, if they don't, that's not native code. Of course, for strategic
reasons such as portability the manufacturer might not provide any kind of
access. At which point that's the closest to "native" you're going to get...

~~~
pjmlp
Depends, on the mainframes and watchOS, bytecode (or bitcode) is used as
portable binary format and JIT compiled at installation time into native code.

On Xerox PARC systems, the CPUs were micro-coded.

------
jeffbax
I'm down for enhancing what sites I only go to on occasion can do for me as a
user, but that PWAs will replace Native is IMO not desirable (particularly
every website asking me to allow notifications these days -- turn that right
off immediately)

A PWA will never be nicer than Tweetbot, but if it means I no longer get
harassed to install an app for EVERYTHING it will have a place alongside
native

~~~
Brakenshire
At least we do have a solid cross-browser implementation of Service Workers,
that will allow a lot of quiet optimization in the background to make websites
feel a lot snappier.

------
millstone
These apps seem to solve a developers’ problem, not a users’ problem.

~~~
jbergens
As long as people wants new apps quickly (now) and cheaply (free) the
developers problems are _very_ important. Making those problems smaller or
disappear makes it quicker and/or cheaper to develop apps and the companies
paying for the apps will like that.

------
berns
> Dramatically, a huge change has happened again thanks to a move from Apple.
> This time with Safari.

A few paragraphs later:

> -There’s still no Web Push or Background Sync on iOS (and it will take
> time).

And here is a response from Apple[0]:

> As we indicated we were doing last year, we’ve implemented the core
> ServiceWorker spec -
> [https://w3c.github.io/ServiceWorker/](https://w3c.github.io/ServiceWorker/)
> \- in trunk WebKit. Web Push is a different spec that we’ve made no comment
> on one way or another.

[0]:
[https://bugs.webkit.org/show_bug.cgi?id=182566](https://bugs.webkit.org/show_bug.cgi?id=182566)

------
mromanuk
Doubt it. Just look at recent history (2011), back then the hype was
"HTML5"[0].

[0]: [https://www.allbusiness.com/web-apps-vs-mobile-apps-which-
is...](https://www.allbusiness.com/web-apps-vs-mobile-apps-which-is-the-
future-16672651-1.html)

------
archagon
All that text and not a word about monetization!

I realize that selling binaries directly or via IAP isn't all that lucrative
these days, but plenty of developers still make a living doing it. How,
exactly, are you supposed to sell a PWA? I assume they're meant to be a value-
add for the main product, which is probably SAAS/subscription/ad-based, but I
think a world without a good way to sell software directly—a world exclusively
centered around services, not software—would be a sad one indeed.

EDIT: I just remembered that, I guess, Android lets you sell PWAs directly
through the Play Store. But if you're not installing them from the web, then
what's the point?

------
shapiro92
the problem noone mentions with PWAs is that simple users do not know what
A2HS means. They dont know what a PWA is so in the end we are talking about a
web page that is mobile friendly.

~~~
Cthulhu_
With a popup asking to be added to the home screen. A lot of mobile websites I
visit (usually if my HN reader app can't parse the content) either have one of
those, or have it hidden somewhere in the other popups - sign up for our
newsletter, agree to our cookies, fixed headers, etc.

------
dfansteel
I’ve read this exact same article every year for ten years and in that time
the web has become increasingly slower and more personally invasive while apps
have become more capable and faster.

Pardon me if I take this all with a grain of salt.

------
mkirklions
No mention of writing apps in React Native?

~~~
bigato
it's out of fashion already :-p

~~~
jbergens
According to this article, yes, it is. On the other hand it is a really,
really easy to convert a react native app to a web app with react so it might
have been a very good choice of technology anyway.

~~~
mkirklions
Basically my thought when I chose RN.

Although, after building my backend with php + frameworks, I already have a
web app.

Im just hoping I wont need to update an IOS app every time apple breaks it.
Also, I'm looking to avoid buying an apple computer and doing the compiling
only 1 time. I hope...

------
EGreg
Web apps have a bright future, with only Safari lagging behind. (Did you know
Steve Jobs originally envisioned AL mobile apps to be web based?)

I have emailed Jonathan Davis (web-evangelist@appl..) from Safari several
times over the last few years asking when Push Notifications will finally be
supported. Without this, websites need to rely on email as a retention
mechanism.

But here’s the thing with all this. It’s a lot to build and support all these
operating systems, where things constantly change. Even more to have an
integrated unified solution.

Take for instance onboarding. New people click an invite link and go to your
site. First you want an instant social experience. That’s easy enough: just
have each invite have a unique link confirming that phone number or email, and
when they arrive show them all the friends who uploaded hashes from their
Contact list where they are found. And show all the content they have already
engaged with. But wait, phone numbers only have 10^7 possibilities roughly, so
that’s a trivially reversible space. SO now go read about the state of the art
from Signal and others and figure out your own more secure solution.

And after this you want the user to download the native app so you can send
notifications to them, they can upload their Contact list and find their
friends, invite people easily etc. Seems easy: just redirect them to the
store.

But wait. You want attribution for campaigns, and you want to resume sessions.
How to do it? Well you could use SFSafariViewController to get the web cookies
but that’s been deprecated in iOS so now you need to to use
SFAuthenticationSession.

Wouldn’t it be nice if there was a project that would take care of all this
shifting stuff for you so you can focus on building the core of your app?

Well that’s why I started Qbix initially. We keep adding free open source
plugins to solve these individual problems:

[https://github.com/Qbix?tab=repositories](https://github.com/Qbix?tab=repositories)

Go ahead and grab them, we plan to maintain them as the OSes change since we
use them in our ow apps.

But this is literally the tip of the iceberg. Most of the questions have to do
with social and communty features like roles, permissions, realtime sync,
offline notifications, user authentication across apps, payments, and so on.

If you want something that will let you develop new web based apps at record
speed or support turning existing websites/apps into social apps with accounts
(think turning git into github) without reinventing the wheel you are welcome
to the code

[https://github.com/Qbix/Platform](https://github.com/Qbix/Platform)

It is licensed under AGPL so if you want to keep your code private and not
open source it to your website visitors then you’d have to contact us for a
license, which at this point is probably like $100 a year regardless of users.
But for FOSS projects and weekend stuff it’s totally free, to promote the
improvements of the ecosystem.

Here is the vision long term:
[https://www.youtube.com/watch?v=pZ1O_gmPneI](https://www.youtube.com/watch?v=pZ1O_gmPneI)

Oh also we aren’t happy with the state of mobile browsers when it comes to
supporting content addressable routing, verification of resources, encrypted
web push notifications secure access to contacts by websites, and so on. So we
are building the Qbix Social Browser:

[https://projects.invisionapp.com/m/share/TKHYMVSJNW2](https://projects.invisionapp.com/m/share/TKHYMVSJNW2)

------
tvorog
Web app can be easily blocked by government. Look at telegram in Russia.
Native app still useful without vpn.

~~~
xamarinthrw
This doesn't even make sense. Blocking is blocking of network connection.
Native apps still need that to talk back home

~~~
evgen
Native apps can be a bootstrap shim for a more distributed back-end. PWAs are
not going to be loading off onion nodes or ephemeral distributed networks any
time soon. Native apps, especially those that can side-load or update without
the app stores, will always be more resistant to these sorts of attacks.

------
thinkingemote
PWAs feel to me as if they are a way for websites to get around adblocking or
any kind of extra browser extension. They are the equivalent as a website
wrapper webview as a native app. I equate a PWA similar to an Electron-based
stand alone web app (e.g. like Discord).

Am I incorrect in my assumptions about PWAs? I know you can run them in
browsers, but the intended use is to launch them in their own browser window
as a separate process, right?

