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...
There's always been some weird edge cases, like file dialogs, but in the 90's and 00's writing cross platform desktop applications was much nicer than this mess.
For iOS and old HTML5 compatible devices you can fall back to web manifest / ApplicationCache.
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.
I didn't go over the entire list, but I was convinced the issues you faced were very much local concerns when the Flappybird clone worked fine on my iPhone 6S. As did the paper planes game (which I thought was very cute.)
>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.
And don't forget this (ill-conceived, IMO) new feature for Android, which is that you'll be able to run "instant apps" right off the web without installing them first:
> App store friction is a major obstacle. It takes about 6 clicks to install a native app
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.
>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.
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.
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.
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.
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...
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.
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 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.
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.
Not sure if you have any experience, but Cordova and Xamarin are not the same kind of thing. In Xamarin you (and I would recommend that in most cases) get to use the native APIs of your platform of choice. Aka when targetting iOS you will be using UIView and when Android View. And all methods on those objects are the same ones you would use in Swift and Objective C for iOS and in Java for Android but then under a thin wrapper of C# or F#. Cordova is very much not that. I am not sure where the confusion under devs comes from but Xamarin generally is not used to run the same GUI codebase on two platforms like one would do with Cordova.
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.
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.
I think at some point, we could feasibly reach a point in development where the website could also be the native app. In that case, the app store is essentially a self-contained browser, running the mobile site.
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.
That's an absolutely absurd notion. Ads usually direct users to a URL, and every app I've ever been a part of got almost all of its converting download traffic from the website, not from an app store search.
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.
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.
You provided a link for (2) (here's another-- http://www.theverge.com/2016/5/18/11703884/android-instant-a... ) 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.
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)...
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.
Looks nice once it loaded, but it took far longer to load than an app install would have. Why on earth would I prefer this?
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.
I should add that the demo has an unacceptable rate of frame dropping and lag, particularly for an iPad Air, by no means an old device. If a native app lagged and consumed battery like this it would be an instant uninstall. Unity apps are bad enough as it is, lagging in places no simple game ever should, and you want us to make the problem worse???
> "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...
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.
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.
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.
> 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.
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.
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?
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.
Try flipkart.com. Its done decently there. They have an icon that shows Add to home screen instructions. However, a simple api with a confirmation would have been much better.
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).
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.
"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
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.
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.
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 my experience living in Spain and Japan, depending on the app type many users will put up with only English version to try the apps out or because they are cool; they are not the majority, but many young educated users will do. Also note, Spain and Japan are infamous for low English skills.
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.
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.
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 ..
- 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...