
Why Native Apps Really Are Doomed: Native Apps Are Doomed Pt 2 - xZhan3
https://medium.com/javascript-scene/why-native-apps-really-are-doomed-native-apps-are-doomed-pt-2-e035b43170e9#.whqlr4tvj
======
grk
Previous discussion:
[https://news.ycombinator.com/item?id=13002598](https://news.ycombinator.com/item?id=13002598)

------
jakub_g
I've been the hybrid/web guy for a long time, but recently I realized native
apps are not going anywhere. (I'm stil in the "I don't need your app" camp,
but it doesn't change this realization).

The issue is, most of the "apps" do not need to be apps, they can well be web
pages. Everyone thinks they need "an app" because it's hot this year. But for
apps that make more sense being an app, native is much better solution.

For example, for apps that need to store data and work reliably offline, I'd
much more trust a native app than any PWA despite of all the services workers
and other stuff that it implements.

(Side rant: I hate governments spending public money on apps for two selected,
closed ecosystems, instead of producing a good interoperable webapp).

From purely technical point of view, in my experience (writing Cordova app,
and reading about NativeScript and other technologies) is that all of the
"write once, use on 10 platforms" frameworks are typically more polished for
iOS than for Android, or vice versa.

We've built two Cordova apps in the last time, one with Ionic, one earlier
with proprietary framework. While they work okayish on Android, the UX on iOS
is rather horrible due to a number of smallish issues that when added up, sum
to a big difference.

Next, with Cordova et al. you can do easy things easily, but hard things are
hard or impossible; you are always behind the native platform capabilities
(which change very often and fast), which give a lot more power.

Edit: The point of cost of getting users into a native app is fair, I very
very rarely download new apps. This only gets harder as app stores get
bombarded with thousands of apps each week. But it doesn't mean native apps
should be totally abandoned. They have their place in the ecosystem.

~~~
yoodenvranx
> The issue is, most of the "apps" do not need to be apps, they can well be
> web pages. Everyone thinks they need "an app" because it's hot this year.

Why is "being a webpage" suddenly the default state of an application?

I'd rather turn this around and say:

"The issue is, most of the webpages do not need to be webpages, they can well
be native apps. Everyone thinks they need 'a webpage' because it's hot this
year."

------
frogfuzion
Javascript Developer: SPA/PWAs are better!

Swift Developer: Native apps are better!

Reality: both will be around for a long time and both have their appropriate
use cases. At some point they may converge but we are far from it.

Also, creating any app (web or native) and hoping to achieve widespread
success is a gamble.

------
Hydraulix989
Recording audio on mobile browsers in a cross-platform way still isn't solved
yet (it's been years):

[https://www.quora.com/How-do-I-record-audio-using-the-
iPhone...](https://www.quora.com/How-do-I-record-audio-using-the-
iPhone-6-running-on-iOS-8-1-3-microphone-on-the-Chrome-or-Safari-
browser/answer/Charles-Moyes?srid=3o7l)

Remember, due to Apple regulations, any browser on iOS (including the Chrome
app) is actually just a thin shell around Safari. It HAS to be Safari, no
custom browsers allowed.

This really stifles progress when it comes to the many "bleeding edge" web
technologies that are required for web apps to truly replace native apps.

Unfortunately, browsers are still far behind in general.

------
spiralpolitik
The straw man proposed in the "Why Native Apps are a Gamble" section equally
applies to Web Apps. The 80% number for example probably isn't going to change
just by making your App a WebApp.

Development is expensive whichever way you want to slice it. Write Once, Run
Everywhere is equally expensive because you have to test everywhere as well so
the economics aren't as straightforward as the article suggests. If it was
Java would have won years ago.

A counter argument could also be made that a well curated ecosystem of 16% is
cheaper to developer for than an ecosystem of 84% made up of a whole mix of
different supported levels.

------
niftich
I don't see how this conversation is really about apps vs. websites.

It's really about content and value -- and in a way, discoverability and
marketing. Like the article says, most apps are never downloaded. It stands to
reason that websites are nearly never visited. Those that are, are found
through search results, advertisements, or out-of-band knowledge (e.g. friend
recommendation)

Even the examples are not helpful: Alibaba is a market leader. Weather.com is
a market leader. I've never heard of Housing.com, but they have one of the
best, most valuable, most-obvious domain names in the world. Perhaps they
increased conversations and reduced user friction, but these platforms could
have only _lost_ business to those of their competitors who clear the bar of
'discovered', 'advertised', and get those user conversions in turn. Quoting
their smaller competitors would be far more impactful of the article's point.

The fact is, the app boom is clearly over, top apps dominate user traffic, and
it's even harder to become a breakout hit than it was in the past. But native
apps still have their uses: seamless homescreen presence, sophisticated
layouts (drinking game: drink every time someone brings up flexbox as a
counterpoint), offline operation (using mature tech, not serviceworkers),
integration into iOS preferences, integration into Android intents, OS-native
permission control, etc. These advantages are not negligible over browser-
based solutions.

------
htormey
I don't think PWAs are quite ready on iOS yet.

"You may be thinking that PWAs are a non-starter until iOS starts to support
the manifest standard and service workers, but I have news for you:

You can achieve PWA-like behavior with Apple’s proprietary meta tags.

There is a service worker polyfill for Cordova that will allow you to build a
hybrid app for iOS, so you can get the PWA benefits without sacrificing an app
presence on iOS."

Cordova is a JavaScript/HTML based app framework:

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

So using Cordova means you have to submit an app and hence is not pwa right?

Can non native web apps on mobile get access to push notifications, the camera
(low level like snap chat), the photo library, audio recording or touch the
address book? As of today I don't think you can do these things without an app
on iOS.

If you look at the top paid/free apps on iOS most of them are either
multimedia heavy (Instagram, snapchat, Pinterest, etc) or games. Neither of
these types of apps would work well with the current state of PWA.

That being said having a separate android/iOS team and shipping apps to two
app stores is expensive and a total pain. I think that some major changes in
the way apps get developed are on the horizon.

I think by looking at react/react native you can see where things are going.
I.e business logic and API layer shared cross platform, cross functional teams
that can work on 60-70% of your products surface with domain experts dealing
with platform specific issues. That plus the ability to push over the air
updates is going to change things quite a bit.

I feel this approach is valid even for large parts of nultidmedia heavy apps
(sign up flows, pop up dialogs, etc) and could even be used in a hybrid
approach with a pwa style App.

------
Ghostium
While Elliott writes a lot of good posts, in my eyes his blog posts are a bit
too much biased.

------
martinald
While I totally agree way too many apps are just webpages, the problem is that
a bunch can't be easily be webpages, even with all the HTML niceness.

The flaw in this argument I think is that does the author think you can build
a great PWA for less than $100k either?

In my experience of doing heavy duty mobile web, it is horrendous to polish to
a high standard. It was actually more expensive than doing native apps (before
even Xamarin/RN) if there was any tricky parts in it.

------
CyberDildonics
I'm surprised this ends up being as controversial as it is. Either the
capabilities of web technologies that are here or coming (webasm) what can be
done with a web page is increasing. How many native apps are even compiled
natively? Webasm actually has the potential to be faster than many native apps
at the same time.

~~~
lj3
> Webasm actually has the potential to be faster than many native apps at the
> same time.

How do you figure?

~~~
candiodari
This is the constant claim from the web community. You can easily find
references that there is no reason javascript has to be slower than compiled
code from long ago. They all boil down to the sufficiently smart compiler
argument.

Of course that became well known to be ridiculous.

But rhino would change that. asm.js would change that ! V8 will change that !
Native client will change it ! P-nacl will change it !

Of course, for all of these you can find some skewed edge case where someone
was able to make a benchmark say the javascript/web version was faster. . It
never was faster in practice for any of these. Browsers, after 22 years of
optimizations are still far slower than even pretty bad native apps ... And
let's just not mention games (not to worry the latest javascript 3d
abstraction will change that. Of course)

And now webasm will change it - I guess. Well, no, truth be told, I guess not
!

~~~
lj3
As far as I can tell, pnacl came pretty darn close. It executes LLVM bitcode
and supports hardware features like SIMD and threads. For some reason I'm not
aware of[0], they made pnacl dependent on the pepper plugin api, which only
chrome uses. That pretty much killed it dead on arrival. None of the other
browser manufacturers were interested in implementing chrome's pepper api so
they can run chrome plugins, especailly since the pepper api isn't open and
isn't documented anywhere.

[0]: I'm sure there's a good reason for this decision, I just don't know what
it is.

~~~
candiodari
I would agree. PNacl is one of those technologies that failed because it died,
not because it was bad. People felt it needed to be killed and it was killed,
or abandoned.

There is criticism, such as that it only solved one part of the puzzle of
getting real apps running on the web browser, but it's not like anything else
came closer.

