Why Native Apps Really Are Doomed: Native Apps Are Doomed Pt 2
medium.comPrevious discussion: https://news.ycombinator.com/item?id=13002598
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.
> 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."
Your webpage app will be unavailable if I am offline
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.
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...
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.
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.
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.
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:
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.
While Elliott writes a lot of good posts, in my eyes his blog posts are a bit too much biased.
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.
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.
> Webasm actually has the potential to be faster than many native apps at the same time.
How do you figure?
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 !
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.
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.
> And now webasm will change it - I guess. Well, no, truth be told, I guess not !
You didn't give anything to back up your claim except for 'nope, nuh uh'. V8 did speed up the state of the art in javascript and asm.js went further than that, but both of those are tangential.
Webasm is made for statically typed programs with explicit memory allocation. Combine that with the fact that most apps are not compiled natively and those that are still don't have explicit memory allocation unless made with swift for IOS. What is the limitation other than you not understanding webasm and not wanting to believe it could be JITed efficiently.
> How many native apps are even compiled natively? Webasm actually has the potential to be faster than many native apps at the same time.
If non-compiled native apps end up slower than web pages, they'll start using webasm as well.
Yea, Java/C# with AOT can be faster than C. Only under some circumstances, on some hardware, if VM supports it.
Java and C# both use garbage collection and typical Java and C# make heavy use of pointers, indirection and many tiny heap allocations.