Being able to use the 'app' offline is a pretty important feature tho. I almost always have web access, but most apps also almost never need it (for me to do what I want to do).

This really depends on what the app is. A few of my friends use apps to look up when the next bus is coming. I use the official website. There's zero need for their apps to be available offline, they only thing they're for is looking up the next bus, which requires an internet connection. The app in this case gives absolutely no advantage to the website. I find that's the case for a lot of phone apps

I feel like such an app could download the bus schedule and do this all offline (and let the user know it is simply an estimate)

In fact, I really wish Google Maps did this, but I guess the damage of getting it wrong once is far greater than getting it right 100 times.

Phones are pretty powerful with huge storage. If you can compute directions offline, why not buses? Saving a map or route is tiny compared to the 64, 128, or 256 GB storage on most people's devices, surely bus schedules can't be that big.

I think you may misunderstand. The bus company provides live information. This is not a schedule, so cannot be downloaded ahead of time.

Many public transit agencies provide both static and real-time data.

- static data often is sharing using the "GTFS" specification, which includes stop locations, route geometries, scheduled trips, etc. See http://gtfs.org/

- real-time data is shared using a variety of specifications, and typically includes vehicle locations, service alerts, and other notifications from the agency

The static kind of data can certainly be cached for local use. Try browsing and downloading some from the Transitland open transit data platform and its API: https://transit.land

What if I just want the schedule though? It's not unusual that I'm underground (perhaps getting off a subway train) and don't have connection.

The online search takes into account all short term schedule modifications. Considering how many such changes occur on almost daily basis, you would be quickly complaining about data usage from all those schedule updates. Or you would frequently get wrong route.

Either way, a lot of complexity / resources spent on something trivially solved by the original solution (webpage).

Some buses don't have schedules, just an estimated frequency. Or some have schedules but don't stick to them with any reliability.

Not providing schedules because some buses don't have them seems like throwing the baby out with the bathwater.

The bus schedule is available on the bus company website. The only thing that app gives over that is what the schedule is now.

You clearly haven't ridden the buses in Boston.

There should be paper schedules available in the station.

Then download the schedule from the web site?

So... like a PWA?

the app is in leveraging the rider's actual experience ... each time the rider rides the bus, she records the time of arrival - eg takes a photo of the bus - and builds a record of actual arrival times. the app makes predictions about when the bus will come.

Even for this use case, an app (including offline-enabled PWA) should load faster than an online-only website if they're designed properly, because the app UI is pre-cached and it's just making a small JSON web request for the next bus.

> look up when the next bus is coming

That's ridiculous argument against offline use - bus schedules are small enough data that we print them out and carry them in our pockets.

Sure, if the bus company socks, it might be nice to know about changes due to roadwork, real-time updates (ie look up the next bus via it's gps location and speed) - but doing off-line route planning would be a great feature...

It sounds like you're not a daily bus rider. The printed bus schedules are useless due to delays. I take transit into work everyday and you need to know when the next bus is coming or you risk waiting at a station for twenty minutes.

Yeah, they're majorly helpful for transit commuters - you can avoid extended wait times, know when you can take a walk to the convenience store or even know when there's another or a bigger bus coming so you can decide whether it's worth getting on the packed bus or waiting for the next one. It really does change the transit game a lot.

In Missoula, Montana, where I live, the Mountain Line app shows you where every individual bus on a given route is, and computes ETA to a selected bus stop.

I'm pretty sure that's common functionality.

(To be honest, the Mountain Line is very punctual, so I could likely do just fine with just a printed schedule.)

Where I currently live, the bus app does the same, but the difference between scheduled time at each individual stop is typically 1-3 minutes. So it's not like off-line functionality would be useless, even if on-line can add value. But it obviously only adds value when you're on-line - and if off-line the app doesn't work at all...

Displaying the live AVL data for all Missoula busses is not too bad. In Seattle where I currently live, not so much. Thus, most of our apps here tend to give arrival times of busses with nearby stops.

Fun aside: my dad drove for the Mountain Line many years ago. I rescued one of his 1970s yellow shirts with the embroidered logo patch a while back.

You must not live in a city with over 100 bus schedules.. in my city, the offline app which uses your location data to tell you what bus stops are nearby and what the arrival times of each bus are, is immensely helpful.

Can you elaborate why offline use is something that matters for bus schedules?

I mean, I get the usefulness of wilderness-related apps (e.g. ocean fishing) or various things that could be useful in an emergency like the aftermath of a hurricane, and for these offline functionality matters, but for buses, if you're within a few miles of a bus stop and the buses are running at all, then you're guaranteed to have high-speed cellular internet access and offline features don't matter.

I can imagine being in the middle of some national park where the closest bus is unimaginably far away but I still have mobile internet access, but I really can't imagine a situation where I'd care about buses but don't have internet. Or are USA data plans so small that it's worth thinking about the data usage (as opposed to just latency) of downloading a webpage with timetables?

> If you're within a few miles of a bus stop and the buses are running at all, then you're guaranteed to have high-speed cellular internet access

This just isn't the case in the United States. There are large swaths of the country that straight up don't have high speed internet in any form.

But those large swaths apparently have a bustling public transit system? Sorry, rural America lacks both decent cell service AND decent busses.

Certainly, our rural public transit is a catastrophe in it's own right. That still supports the argument that there is a very real use case for offline bus schedule lookup.

edit: /apps/lookup

Offline time tables are more than zero useful!

This is a complaint of their example rather than the concept, though.

Nah, you're wrong! [You're not totally wrong, tho you wrote in really broad absolutes.] Even your example would be a much better app with offline support. The app shouldn't stop working just because of a hiccup in the user's internet connectivity.

If I, the user, switch from the when-is-the-next-bus-coming app to another app and then switch back (within, say, a few minutes), it'd be really great if the app could default to showing me info based on the data it just downloaded instead of automatically resetting the UI and waiting to update it until it downloads the data again.

Correct me if I'm wrong, but PWA's support 'offline mode'. React's official tool, `create-react-app` comes with this boilerplate enabled by default.

PWAs can do offline.

I've always naively assumed that apps were given preference because they are better at gathering info about the user (can get location more easily for instance, can phone home whenever...) and better at displaying ads (no Adblock there), and therefore I'm surprised nobody evokes this. Don't you think it's at least partly true?

Surprised I didn't find this comment up higher. This is my first thought every time. Good observation!

> > You don't have to create a native app because PWAs now offer all the functionality of a native app.

I didn't think you could do arbitrary network or disk I/O. The sandbox is really, really nice for many applications, but PWAs aren't suitable for all native applications.

My thoughts exactly, wondering why so many here are saying they are equivalent? PWA disk usage has tiny limits.

For the curious: https://developers.google.com/web/fundamentals/instant-and-o...

> I think it's going to be an uphill battle just to convince them that in many cases, you don't even need an app. You just need a mobile website.

but, isn't it a lot less expensive to build and maintain a mobile website than to build apps for both iOS and android? wouldn't that win the argument in a lot of cases?

Isn't the reason for stuff like NativeScript and React-Native that stuff like PWAs and PhoneGap weren't good enough?

Can someone with experience answer this please?

I give you a hint: Yes

Are PWAs and phone gap good enough now?

What about sensors/stuff on the hardware that the browser may not be able to access?

Edit: I have seen some browser demos that could show your phone's orientation. In the past the camera trigger was not reliable that was in 2013-2014 if I recall dang time flies.

The author also points out (correctly) that web apps are smaller than their equivalent native app. That's nice, but I'm not terribly constrained as far as storage goes on my phone. I am constrained by battery life and data consumption.

> The author also points out (correctly) that web apps are smaller than their equivalent native app.

Well, the author straw-mans that web apps are smaller. Yes, web apps are lighter than equivalent native apps. But not to anywhere near the degree described in the article.

There's no legitimate reason for the Starbucks app to be 100MB. None. A native Android app equivalent to the PWA in the article would come in at about about 2MB, for instance.

Starbucks app is huge because they stuffed it with something (same for Twitter, Facebook, etc). Starbucks new PWA is clean and light because it hasn't (yet) been stuffed with the equivalent junk. It's not a technology difference, it's a political/corporate one.

Google will punish badly made web apps though, whereas the same apparently doesn't apply to native apps.

Even worse every time you go to Starbucks.com you might re-download all of the junk. If you use it multiple times a day, that's a lot of wasted bandwidth compared to a slim (unusual in these days) native app.

The value of PWAs with service worker support is that redownloads don't happen. That's also how they can have offline support (on Android at least, safari currently has a lest robust caching story)