
Why Native Apps Really Are Doomed, Part 2 - ericelliott
https://medium.com/javascript-scene/why-native-apps-really-are-doomed-native-apps-are-doomed-pt-2-e035b43170e9
======
comex
I went to pwa.rocks on my iPhone and briefly tried out some of the apps, and
almost every single one was obviously broken in some way. In no particular
order, some of the issues:

\- No or broken animation.

\- Wrong dimensions for screen.

\- Dropping frames (for the Flappy Bird clone - an extremely simple game).

\- When viewed in-browser, swiping left to right to initiate a 'back' action
causes flicker or a double animation, or is broken (doesn't go back to the
right thing).

\- Taps on the bottom navigation get messed up, showing/hiding Safari UI (this
is unavoidable to some extent but there are workarounds).

\- Clicking the hamburger button is so laggy on one of the apps it's probably
making a network request.

After "installing":

\- Doesn't work properly in a chromeless environment (e.g. the Google I/O app
has a login screen that you can't cancel once you click it).

\- Apple web app metadata missing or broken.

\- Pressing any button takes you out of the app and into the same site in
Safari.

\- Icons that look bad when cropped to the iOS rounded rect.

Oh, and some of them didn't work because of missing Safari features, but that
at least isn't their fault.

Even those that worked didn't look native; some of them looked like Android
apps, which is nice if you're on Android. None of the ones I tried installing
supported the swipe-back gesture in chromeless mode, which works in
essentially every app on iOS not made by Google. (Presumably because the page
would have to do it manually, as opposed to in-browser when it gets mapped to
the browser back action, see above.)

Overall, maybe the browser primitives are there, but libraries for proper app-
like UI are clearly not. I'll stick with my native apps for now, thanks...

~~~
benguild
Cross-platform development has always been a bit "function over form"

~~~
ssalazar
It sounds like in some cases its not succeeding at either.

------
coldtea
> _App store friction is a major obstacle. It takes about 6 clicks to install
> a native app_

If I'm at the app's entry in the Store (similar to the navigation I need to do
to first visit a web app), I can install an iOS app in 1 click of the
Get/Purchase button (plus the thumb touching for authorizing the sale). I'm
pretty sure it's the same in Android.

Even better, with the native app I don't have to create an account, re-enter
my details and suffer all the BS that I have with web based commercial
services. Plus, Apple/Google already have my credit card details.

I also don't have to suffer a lowest common denominator platform, or wait for
the the web standards AND the vendor to have new native feature access finally
trickle to the phone's JS engine.

> _Deciding to install an app is a lot harder than deciding to use a web app._

Committing to a web app (for a user), and monetizing it (for the software
author), is much harder -- especially on mobile.

~~~
itsbits
>Committing to a web app (for a user), and monetizing it (for the software
author), is much harder -- especially on mobile.

Partially agree. Monetizing it is surely a big concern. But creating a web app
is far easier than native. Big concern for me is the updates in OS which
forces us doing changes and unnecessary wastage of time. Docs are also not
proper. But unless you use frameworks like angular, web hardly needs those
changes. Now a days I am able to do proper native kind of animations with help
of CSS3.

~~~
dagw
_creating a web app is far easier than native._

Getting started with a web app is easier than native. Delivering something
non-trivial that scales, run smoothly, works on all browsers, is secure and is
easy to use is as hard as anything else in app development.

~~~
candiodari
That may be your bias. I know a lot of software engineers saying the exact
opposite.

~~~
ericelliott
Unless you decide not to build a web app at all (and miss out on your single
best source of traffic to the app, and the lowest-friction way for users to
try the app before downloading), it's not a bias, it's a fact. Opting into
native means opting into more work, or opting out of supporting other
platforms.

~~~
coldtea
> _Unless you decide not to build a web app at all (and miss out on your
> single best source of traffic to the app_

Seemed to work just fine for Instagram -- and lots of other mobile-only or
mobile-first apps.

------
sgt
I still thinking developing the first app on iOS makes sense. If the app works
out (i.e. people start using it), then I'll consider building an Android
version. What I've observed is that if the iOS app is not going to work out
(because iOS users tend to buy more apps), then it probably won't work out on
Android either.

~~~
nudpiedo
I cannot upvote you enough: some business common sense in a world of
softwarefilia...

------
brilliantcode
wow, I can't believe some of the attitude here in the comments. PWA is not an
all fit solution. It's still in the early stages but it's pretty good at
taking advantage of your browser. It covers a high enough minimum of
capabilities that's enough to replicate an app like experience. The big pluses
are the add to home feature as well Service Workers that lets you run your
code after the browser is closed (this part freaks me out and saw something
here about sw botnet lol) and SPA pretty much replicates UI of any native app.

Think of the chrome browser on Android as another app you are constantly going
to compete with in which it's capability is getting more and more absurd until
it inevitably covers almost all native capability. It's only a matter of time
and seeing how quickly Chrome moves, I'm not surprised.

I think this is fucking great. I was going to learn Xamarin but now I won't
have to. That's fucking huge. I've been putting off mobile dev for a while
because I found working with Java and Swift clunky. So I waited and
waited....and now my dream is coming true. It's pretty amazing that it's
Javascript that unites them all. But ES6 is a serious contender...especially
that ... operator that expands the JSON objects, it makes working with REST
API which almost always involves JSON, it's a heaven to work with. Hell, I
shunned ES5 and was actually learning clojure and maybe using Clojurescript
with Om, but even though I really love clojure es6 seems like the much perkier
option.

I wonder if there's any nice frameworks that can generate some scaffolding and
UI kit and stuff for PWA. I'm learning React & Redux but I personally think
Vue.js will outpace it...

~~~
debaserab2
But your dream isn't really here. There's a ton of bugs with this experience.
It's just not on par with it's native counterpart.

Yes, you, as a developer, can enjoy some major shortcuts in your development
workflow to get an app like experience in people's hands - that does not,
however, make it a better user experience.

Until the user experience has parity with native apps, I don't see it filling
anything other than the niche that the Xamarin/Cordava's of the world already
fulfill.

~~~
brilliantcode
I know it's not perfect but it's good enough for most cases. It no longer
makes sense to completely discount PWA when native apps have long suffered
from app install friction. It's never going to beat typing a domain name vs
going to play store, searching for app, clicking install, asks for
overreaching permissions (why the fuck does a QR reader need access to my
contact list), and after all your visitors drop off, the final nail is the
loathed uninstall.

[http://pwa.rocks](http://pwa.rocks) have some pretty nice looking examples,
and to most users, they wouldn't have a clue if it was native or not if they
didn't see the Chrome Browser. But the add to home screen is the true killer
app feature here, now your native apps are competing with Chrome Browser apps
which is good enough for most use cases.

~~~
debaserab2
It's good enough when you can't afford to build native or your intended
audience/product isn't primarily mobile, sure.

Just clicking through the samples at pwa.rocks - a good portion of these are
demos/prototypes. Some are just well designed responsive websites that aren't
much else than a brochure/ecommerce sites. Sure, it's not hard to format
content for mobile and make it look nice. There's a couple of good ones on
this list, but for the most part I wouldn't put this list against a list of
top ten well designed native apps. They're just not comparable.

That said, I'm not arguing against building out nice mobile responsive sites
(and this is something that I think gets forgotten way too much with "rich
interface" single-page app designs that are all the craze on desktop). I'm a
strong believer that _every_ site should be written with mobile in mind first
unless there are strong use cases to argue against it. Don't ever force your
users to install an app to consume your product unless the product itself is
the app.

------
klaustopher
From some technical perspective, the author might be right ... But what he is
totally missing is the user side.

When seeing an ad for a service on TV (which is where most of users are coming
from if you are talking B2C businesses) or anywhere else, every user goes to
the app store and enters the name of the service there. I have seen quite a
few businesses try the "mobile website only approach" and as soon as they
started real world ads (read: not online), they very quickly realized they
needed to be on the app stores. Cordova[1] might be a solution for that
problem but then you would have to write a Cordova app and not _just_ a mobile
web site ...

So, completely disregarding the user story, the author might be right. But
when your app is trying to reach end users, there's absolutely no way around
the App Stores in the foreseeable future.

[1] [https://cordova.apache.org/](https://cordova.apache.org/)

~~~
euyyn
> every user goes to the app store and enters the name of the service there.

Do you have data for that? I've never seen anyone do that, and it hadn't even
occurred to me to do it.

~~~
klaustopher
I'll see if I can find some research later that supports this.

But at the last places I used to work for that did B2C with apps, I know that
during the times we ran TV or newspaper ads, the app installs increased
exponentially while Google and Bing searches stayed almost the same.

------
flukus
> The average user downloads less than 3 apps per month. Half of US smartphone
> users download zero apps per month.

Why is this at all surprising? It's not very often I have more needs in my
life that an app can helps solve.

>60% of apps in the Google Play app store have never been downloaded.

Again not surprising. How many of these apps are crappy wrappers for a website
anyway?

~~~
zamalek
I'm sure that there are many users who download a handful of apps once per
phone lifecycle. The app honeymoon period is over. PWA or Native, your app
needs to earn its place on the launcher. People are going to answer "no" to
the PWA prompt just as frequently as they ignore the app banner.

Getting your app installed is simply a matter of not sucking and luck.

------
MarkMc
The author seems to focused on the improvements to web apps, but ignoring
potential improvements to native apps.

In particular, if Google were to support (1) Android apps running on Chrome
for Windows and Mac; and (2) Android Instant Apps (coming soon [1]); then it
would significantly swing the pendulum towards native apps.

[1] [https://developer.android.com/topic/instant-
apps/index.html](https://developer.android.com/topic/instant-apps/index.html)

~~~
fattire
You provided a link for (2) (here's another--
[http://www.theverge.com/2016/5/18/11703884/android-
instant-a...](http://www.theverge.com/2016/5/18/11703884/android-instant-apps-
no-download) ) and regarding (1), Android apps are coming to Chromebooks-- I
can't imagine Chrome is too far off, though supporting the Android framework
would make Chrome pretty big... would probably need to do it via some kind of
extension I guess.

~~~
flukus
This will work just as well as the average windows store app, poorly.

------
Hydraulix989
My app needed to be able to do 3D rendering of 200k polygon scenes at real-
time framerates on circa-2013 devices with Adreno 320-spec GPUs.

Needless to say, a custom C++ engine was the only thing that could cut it
(shared code base with native activity/NDK on Android and Objective-C "glue"
using C wrapper functions on iOS).

Even Unity was only hitting 8 FPS on Adreno 320 (with mobile shaders and
everything I could think of doing to try to coerce their black box into doing
what I wanted it to do)...

~~~
pjmlp
My devices are all ES 2.0, ES 3.x and DX mobile capable.

Native apps don't have any issue taking advantage of those GPUs.

WebGL demos usually posted here or on Reddit tend to be single digit FPS, if
they run at all.

~~~
ericelliott
It's true that WebGL lags native capabilities significantly, but that's a good
thing in terms of the number of users who will be able to enjoy your app.

For a mobile WebGL-native experience, check out PlayCanvas, which offers a
Unity/Unreal Engine style game production environment on the web platform, and
targets mobile browsers by default.

Check out Swooop on PlayCanvas for example:
[https://playcanv.as/p/JtL2iqIH/](https://playcanv.as/p/JtL2iqIH/)

Can you do more with native? No question. Will you reach the same number of
potential users? Certainly not.

Will your users appreciate the native difference? Maybe.

~~~
pjmlp
I am well aware of those examples.

Their are part of those single digit FPS demos I was describing.

~~~
Hydraulix989
> "Will you reach the same number of potential users? Certainly not."

What's your reasoning here? From a bird's eye point of view, this statement is
completely factually incorrect.

When it comes to reaching users, being able to run the game at a playable
framerate is very important. WebGL is unplayable on 2013 devices. Period.
You're not reaching these users with WebGL, but you are with native C++.

To reiterate, I'm using a shared code base. I can type ONE command and build
for either iOS, Android (x86 and ARM), desktop Linux, desktop Mac, or desktop
Windows with the same code -- no extra work. This is possible with C++, given
that it is a cross-platform language. Hell, even my toaster can run OpenGL.

So regardless, I can reach almost the same number of users using C++ though --
without relying on a walled garden. Emscripten is a thing, too, if I really
want it to run in a browser.

> "Will your users appreciate the native difference?"

Definitely! Our point is that the difference in performance is staggering.
Single-digit framerates feel like a slideshow. 30 FPS with native is smooth as
butter.

My app's primary market is China. You see a lot of under-specced Huawei and
Xiaomi phones there -- A LOT. The difference with C++ is them actually being
able to run and enjoy my app.

Rest assured, I'm not masochistic -- I don't enjoy prolonging the prototyping
process in this world of iterative development and quick and dirty MVPs, and
for a startup that was at the time months away from completely running out of
cash, it was still completely justified for me to invest six months of time
building a C++ code base from the ground up to actually reach my user base.

Believe me, I tried my damndest to avoid the C++ gauntlet. Unity and WebGL
developers are much easier to find and to hire. When the benchmarking data
came in, it just wasn't possible to do anything otherwise.

You're trying to argue against using C++ in one of the few niche areas (real-
time interactive computer graphics) that it is ACTUALLY the right tool for the
job.

And don't even get me started on the sad state of cross platform in-browser
audio recording on mobile...

~~~
pjmlp
You should have commented to ericelliott's post, not me, right?

------
jevinskie
It will be interesting to see how Android "Instant Apps" end up working.
Looking at AOSP, bits of "ephemeral-app" support code has been tricking in for
(probably) Android O release but I haven't been able to find a complete
example. Has anyone else had better luck? I never received a reply from Google
about an invitation to the Instant App beta.

I'm mostly interested in if the ephemeral apps can use native code. From what
I've seen so far in platform/system/sepolicy, it looks like native shared
libraries _will_ be allowed but I'd be very happy to hear any more information
that others have uncovered.

------
TeeWEE
Native apps are always here. Your browser is a native app. Your dailer is a
native app. Your homescreen is a native app... There will always be native
apps. And on top of that higher level languages might work. But its not that
progressive web apps will replace native apps. Maybe for some apps. But the
current tech stack for web apps will never beat the performance of native
apps. Their architecture is build for very fast loading, and best graphics
performance. Web still has some way togo, and is inherently bound to http
request based app loading. Which will always be slower than loading native
code into memory.

------
partiallypro
I think native apps are doomed for most smaller companies where the cost just
doesn't make sense, but there will always be a place for native apps for
popular services that need OS level permissions. I do wonder how many native
apps for smaller companies that end up costing more money than they are worth,
but I'm sure at this point some companies are invoking the sunk cost fallacy
instead of creating a proper web app that would save them money in the long
run. Or the "we have to have this because our competitor has this," even if
their competitor is experiencing the same problem. It will be interesting to
see how long it takes for that to shake out.

On a whole it's not doomed, but it's a bit silly to have 2-3 dev teams that
have to keep platform parity in native apps instead of just having one app
that has the same experience across all platforms. Even solutions like Xamarin
haven't really removed this rigidity with continual delivery and feature
parity.

~~~
candiodari
> On a whole it's not doomed, but it's a bit silly to have 2-3 dev teams that
> have to keep platform parity in native apps instead of just having one app
> that has the same experience across all platforms. Even solutions like
> Xamarin haven't really removed this rigidity with continual delivery and
> feature parity.

That's only true if you want to support the platform idiosyncracies in the
app. Certainly not needed for a game or a line of business app, where one team
can perfectly suffice.

In a webapp, however, you can't do this. Not with 30 dev teams.

------
blntechie
I use HTML apps in place of native apps as much as possible and this is B.S.
We have been hearing about web apps replacing native apps in mobile since the
original iPhone came out without a native SDK. I understand JS and browser are
catching up but they are not close to replacing the native apps anytime soon.

------
KaoruAoiShiho
Am I missing something? According to the linked alibaba case study there
should be a add to homescreen prompt on it. However, I go to alibaba.com, I
get a link to google play or to download an apk, no add to homescreen prompt.
Did the experiment fail and alibaba revert to native?

~~~
tuxracer
There's no proper API to ask to prompt to homescreen. The only thing you can
do (android chrome only) is enable the prompt to be shown at some point in the
future. Google takes over from there and decides when and if users will be
prompted, and the exact UI and copy of that prompt.

For sites that have enabled this, you'll be prompted once you visit a site a
number of times over a short enough period of time.

This is a staggering limitation unique to PWAs. Any Product Manager I've ever
worked with wants to experiment with different copy, UI, timing, etc... So the
PWA add to homescreen prompt limitations makes it a complete non-starter.

In lieu of a proper API for PWA add to homescreen I'm then asked to put up
prompts that send users to native app stores.

------
SCdF
I think the lack of friction is a real and present benefit. And the benefits
of native development (eg interaction outside of the browser sandbox, high
performance) are not required for a lot of apps. _And_ , it would hopefully
kill off all of the pointless individual news sites app that exist for no
reason.

If Google and Apple coherently get behind the concept, it could be a big deal.

There is a lot you'd need to do right: making sure things like notifications
and storage are managed clearly; allowing users to "uninstall" / wipe apps
that have gotten too large; something to combat and manage the slow sludge
that will accumulate with endless "driveby" app installs (imagine if every
news website was a PWA with offline content, you go for one article and oh
look now you have all of their CSS and JS with offline support stored on your
device, and maybe random data [say, how far you scrolled in the article + the
article contents for offline support] stored in leveldb, with no way for the
browser to know if automatically clearing it will break things for the user);
etc.

The problem is that Apple have shown no interest in doing this.

And I cannot see Google internally organising themselves well enough to be
coherent about this either (c.f. the messaging / hangouts / allo / duo
disaster).

Which would be a real shame.

~~~
pjmlp
The dismiss of ChromeOS on the latest tablet, the introduction of streaming
apps in Android N, the introduction of PlayStore on ChromeOS, introduction of
Fuchsia with Dart for native apps, shows which side is currently winning at
the Chocolate factory.

------
franciscop
"iOS has 45% of the US smartphone market, and iOS users spend $1.08 per user
per app per user vs $.43 on Android, so obviously, write an iOS app and you’ll
come out ahead, right?"

Let me guess those prices ($1.08 and $.43) are for the US. Which is probably
the country where people actually pay for most stuff, I'm pretty sure Android
users monetary reward differ from the US than from other countries

------
ivan_gammel
I don't think it's correct to blame the technology choice on the failure of
some apps, as the author does, talking about percentage of revenues and user
retention. Every technology has it's own pros and cons and with adequate
investment in R&D can be applied to achieve very good UX. More likely, the
success rate has business reasons, not technology ones - how the development
was organized, what was the business model, how much time did the team spend
on UX design etc.

That said, what are the real benefits of PWAs, which by design are not fully
compliant with platform best practices? That's the question that I'd like to
get an answer to, including the comparison of installation success rates, not
just exposure of user failures to install native app.

I myself have chosen Ionic/Cordova as reasonable trade-off between the speed
of cross-platform development and quality, but eventually I'd like to convert
my app to the native to get the best UX on each platform.

------
enos_feedler
The issue with app store friction is obviously going to disappear. This was in
the cards ever since Apple decided to do runtime permission model vs. install
time. If there is one thing iOS innovates on is reducing friction (identity,
payments, etc). The app store is clear friction. In the next couple of years
you will be brought into a native app experience simply by tapping a link.

Why isn't it here yet? Some infrastructure and technology is needed under the
hood. Distributing resource dependencies (code, data, assets, etc) under the
hood so tapping a link is a smooth experience is not easy. We will get there
though.

Google has announced similar technology with Instant Apps. I think with both
sides its going to take time for developers to really understand the paradigm
and build apps in a performant way for link-driven experiences.

------
z1mm32m4n
> Android has 86% global market share.

I hear it frequently mentioned that Android has larger market share globally,
and as such is a better target than just looking at iOS market share in the
US.

Is this a fair statistic? Let's say you're just writing on the first version
of your app. That is, it doesn't have the full i18n and l10n treatment yet.
How do things compare if we still set our sights globally, but we only look at
the English-speaking population?

My hypothesis is that it might be worthwhile at least when starting out to
target iOS just because it has a larger market share in the population that
you're likely to hit first. Ideally later when your app has proven itself,
you'd expand to different regions, different platforms, etc., but I've only
ever seen one side of this statistic.

~~~
mercer
Then there's app downloads per platform. I can't look for official statistics
at the moment, but anecdotally the people I know who use iOS install more apps
and games than those who use Android. And I do remember seeing statistics that
iOS users are more likely to pay for apps in general.

~~~
ericelliott
This is accounted for in the original article.

------
relics443
I feel like I've heard this before...

------
fit2rule
There are other ways to write cross-platform apps that don't require one sell
ones soul to the web demon - for example, using a VM of ones own choosing, one
can build a host engine on each platform, and then use the same common
framework for app development ..

~~~
ericelliott
You sound like you have a lot of free time...

~~~
fit2rule
Certainly it takes less time to do cross platform development properly than
improperly..

------
baybal2
>Eric Eelliot

The guy has a trolling black belt

------
onebot
Nonsense from a "Javascript" developer.

~~~
dwaltrip
This type of comment devalues the HN experience and I wish people would think
twice before posting something like it.

You didn't address a single word of the article, and you attack a large
segment of developers while failing to provide any reasoning or explanation.

Put in other words, your comment is inflammatory and provides essentially no
new information to other HN readers.

~~~
flukus
The article title is inflammatory click bait.

------
_RPM
Use the Fast Mail mobile app for a week, then tell me this again.

