Killing the natives apps, for good

I know it’s a bold statement but let me show you what I’m talking about, you’ll be amazed.

Developers call them Progressive Web App because:

  • Progressive: It should work for every user, regardless of browser choice (we’ll see about that). The idea should be that all browsers will catch up, eventually.
  • Responsive: Hello? 2016 is calling. Although it’s a must nowadays some customers still don’t get it.
  • Connectivity independent: Offline websites? You got it.
  • App-like: the user will have the same feeling as in a native app.
  • Safe: HTTPS only.
  • Discoverable: Search engines will know this are webapps, we’ll make sure of that by using a valid W3C manifest.
  • Push Notifications: that’s right, this is killer.
  • Installable: The user will be able to “install” this on their homescreen via a browser UI, they’ll launch it like a native app.
  • Linkable: just share the webapp URL and you’re done. No more searching inside App stores.

Don’t want to read? Watch this instead

This 30 minutes video will dive into Progressive Web Apps, check it out if you prefer to hear if from Google Developers.

First of all, Add To Home Screen

Chrome has a built-in UI for adding your webapp to the homescreen of your device (in the example below, an Android phone). It’s great because a consistent UI for this action will be more friendly to users.

More on the criteria to enable it here. (HTTPS, manifest…)



Theme Color

Very easy, great impact. Everybody (including myself for newer projects) are adding a simple meta value to change the browser color.

More information on Theme Color here.


Launch Style

Need your webapp to be fullwidth? Like a native app? No problemo amigo.

More information on Launch Style.


Splash Screen

This is actually pretty awesome. You can create a “loading” screen that will show immediately. User Experience (UX) couldn’t be more awesome, for being a website!

More information on Splash Screen.

On the example below you can see a solid background color. In fact, you can also show a centered icon and the web app name under it (set by the web app manifest file).


Push Notifications

I had some doubts myself about this. Here’s some clarifications I’ve found:

The service works even if an app or extension isn’t currently running. For example, calendar updates could be pushed to users even when their calendar app isn’t open.

From Google CloudMessaging.

Because I’m skeptical I’ve run a little test:

  • Opened in Chrome on my Android phone:
  • Accepted to receive push notifications.
  • Closed Chrome, meaning shutting down the application.
  • Running the provided command from my computer terminal to trigger the push notification.

Awesomeness happened. Chrome showed a notification to my Android, even without being open or running.

As you can imagine, we depend on the browser adaption of Service Workers. In Android, for instance, only Chrome, Firefox (44) and Opera have support.
Next time someone tells you Safari or Microsoft Edge are “modern” browsers punch them in the face.

Blame also Apple’s iOS (iPhone), at the time of this writing Chrome for iOS does not have the freedom to use Service Workers. So, it’s the phone operating system that prevents us from moving forward. No surprise there knowing how many millions of dollars Apples makes from its App Store.



At this point I hope I’ve awaken a feeling of curiosity for progressive web apps. I feel like the web is the future of mobile. Not just me but big names such as Google. Native web apps are a pain in the butt, why would you need to learn other languages and technologies to build for Android, Apple, Windows Phones…?

If you already know how to build websites, the learning curve should be way shorter than learning how to code for iOS, for instance.

Eliminating the friction between the user and the service you provide is key for better engagement. One website to rule them all, no matter in what platform or screen size your user is in. No more getting out of space in your phone due heavy apps.

The web, and the future of it, is fascinating!

Want even more?


Published by

Ricard Torres

Ricard is a Senior UI/UX Developer @ TBSCG. Based in Barcelona he also plays guitar, takes photographs and teaches Haidong Gumdo.

11 thoughts on “Killing the natives apps, for good”

  1. Ricard,

    Thank you for this summary, it was a very good read.

    A few questions and comments:
    1. Is the offline app stored in the browser’s cache or in the file system? Both aren’t that great an option.
    2. What about security? Exposing your phone’s hardware via an API to web applications sounds like asking for trouble.
    3. HTTP was designed to be stateless and hypertext was never designed to build applications. I would also question it whether a good web designer will make a good app designer and vice versa.

    It will be very interesting to see which way the market goes.

    Enjoy the sunny Barcelona!

    1. Hey there,

      1. Check out this 50min round table about Frontend Data where they explore different ways to store data (I should’ve posted this one in the article):

      Right off the bat they mention:

      File System API

      2. I’m not a Chrome Engineer but I would guess they got us covered. First by triggering native UI popups asking us to give permission to the webapp to do certain things (such as Push Notifications).
      I’m sure you can do some harm with this API’s, for instance, fill up the phone’s storage with your nasty script. However I think the more this becomes a standard more security mechanisms will be put in place.

      3. Yes, I agree. I think there’s space for both native and webapps. Probably some of which that access specific parts of the hardware.
      For the other, the vast majority we use nowadays (Facebook, Twitter, Instagram…) all those things could be webapps.

      Have you tried to use Facebook as a webapp through Chrome on Android? You can “install” in your homescreen and they’ll push you new notifications. Pretty awesome.

      3.1 Designers have to adapt too, designing for the web and native apps is different but not so much 😉

      Thank you for your input! Please bare in mind this is cutting edge API’s lot of work will be put on this things from browser vendors in the upcoming months.


      1. I don’t agree with your second point – what you propose is basically to transform browser to full blown operating system, that is already built on top of existing operating system. Marshmallow Android introduced those UI pop ups asking for permissions, iOs has that for years. There is no point to do the same with browser.

      2. Let’s agree to disagree.

        I’m with you on that it doesn’t make sense. But it also doesn’t make any sense to have to jump through all the hoops to install a shitty app.

        1) Open the store app
        2) Search for the app (oh wait, there might be 10 with the similar name. Which one is it? Think about the average user and not the smart developer who knows exactly how to identify the correct app he’s looking for)
        3) Install the app. (oh wait, I’m not on Wifi, I might wait until I get home since it will download 20Mb or more)
        4) Download the app and auto install it
        5) Open the app

        All those steps, even if you could skip one by having a direct deep link to the store are a hassle. We should be able to enjoy a service more easily, don’t you think?

      3. Yeah, I do agree with the point you are making about an easier installation. My main point is that even though most of native mobile apps could be replaced by their webapp counterparts, not every each one of them should. That what has to be understood well by app, os and browser developers.

  2. Of course that there is still space for native apps. For example you can get rid of facebook app and still enjoy the same functionalities via webapp, especially now with browser’s push notifications. On the other hand you can not expect that from Snapchat, where you need to have an access to camera and to be able to hide picture / video after given amount of time. Porting this to a webapp would cripple it way too much.

    1. hey Jan,

      I just posted the same thing in my comments moments ago about the Facebook webapp 🙂

      About the camera, you can already access the camera hardware via JavaScript 😉

  3. It’s definitely good to have more options and make app development learning curve shorter for millions of web developers out there.

    That alone makes this interesting despite my serious concerns about security.

Comments are closed.