The line is getting fuzzier. But, mostly when an app has specific native capabilities. If all your app is, is a link to the site, then that’s a link, not an app.
I don’t really do a lot of mobile specific stuff, but I know there are APIs where you can do can interact with a lot of native features from the web.
ie: Battery API, which has been around for a while.
I feel like lots of places are moving away from this. I’ve never been a fan of Apps, except for my most used sites. If I’m just clicking your site to read something, I don’t want you to ask me to download your App. I’m much more likely to click back than to click yes.
This is an interesting talk.
Basically, you can use some new techniques that further blur the line between app and web app.
From the 2015 Velocity Conference in New York: Websites are optimized for ease of use, discoverability, and sharing – you’re one URL away with no upfront installs. However, these same sites are now also capable of earning new capabilities: offline, background tasks, notifications, storage, homescreen integration, and more. In effect, they progressively earn “app capabilities” as, and when, needed; they are progressive web apps.
True, it is a blurry line, but I like the idea of an app being able to do more with easier user interaction required.
And I like the “works offline” capability where an app will work off a cache and only “phone home” when it needs to and can.
I really need to revisit service workers. I can see that like HTML5 and CSS3 a lot oof progress has been made since I first heard of them