- 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.
- 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...
Custom CSS could be loaded after finding out the browser. But I think it's better to go with your own unique look instead of the charmless platform style guidelines. Standardizing style is an anti-pattern IMHO.
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.
And compare that to web app - on iOS you need to tap Share button, then scroll icons to find "add to home screen", then confirm app's name on the screen. So that's 3 clicks and it's really a bad, non-discoverable UX for installing an app, try explaining this flow to the Average Joe.
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.
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.
Seemed to work just fine for Instagram -- and lots of other mobile-only or mobile-first apps.
This is not true, and a good starting point for Domain Pissing Match. It could be a good idea not to invite such "discussions" here.
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 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...
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.
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.
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.
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 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.
Do you have data for that? I've never seen anyone do that, and it hadn't even occurred to me to do it.
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.
The reality of that situation right now is not pleasant. Some apps already do this (looking at you Wells Fargo) and the experience ranges from awful to passably ok.
Ignoring all of the technical hurdles for the moment, we should also stop to consider some of the real world implications of native apps. Does my calculator really need an internet connection? Couldn't I play flappy bird while in airplane mode? Even apps which depend on an internet connection to function (like an RSS reader) can still serve some functionality out of their caches when offline. But if the app itself is delivered as a mobile web page, those features won't exist.
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?
Getting your app installed is simply a matter of not sucking and luck.
In particular, if Google were to support (1) Android apps running on Chrome for Windows and Mac; and (2) Android Instant Apps (coming soon ); then it would significantly swing the pendulum towards native apps.
Check out the ARC Welder extension (also works on Linux). It's obviously a developer tool, but showcases the technology:
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)...
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.
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/
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.
It seems to me that we keep seeing this argument over and over, but the point isn't whether a given technology makes life easier for developers, it matters whether they provide more value to the end users.
App install friction is by and large a red herring, as there is plenty of friction with the web ecosystem including user management, monétisation and the poor state of browser API support. I'll take technologies like cross-platform Xamarin anyday and provide my users with a better experience to boot.
Their are part of those single digit FPS demos I was describing.
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...
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.
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.
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.
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.
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
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.
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.
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.
In this area, I'd say that apps with little interface text/intuitive icons (such as camera-type or even chat apps) and apps for learning new languages (these users are likely to know English already) can get away with it.
I have written a couple in C++.
The guy has a trolling black belt
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.