Hacker News Reader

Comment by sjroot | Hacker News Reader

The real answer to this question? (Surprise!) It depends.

I have worked on a side project for the last year or so that will have a website and a mobile application. It has social elements, so ultimately I decided to prioritize the mobile application, because that is where users have access to their contacts, and do most of their communication with their friends and family. There are, of course, other business ideas that would be better suited to a website (or electron app?): work-related tools, dashboards, etc.

A lot of people on here are talking about PWAs which are amazing, but iOS Safari is missing the Web Push API. Unfortunately, that makes the effort nearly futile because you have to build a separate mobile app anyway.

If you are an Apple engineer and can help get that shipped, I will buy you a nice dinner. If you're an Apple recruiter, hire me so I can help ship it! :)

View on HN

> If you are an Apple engineer and can help get that shipped, I will buy you a nice dinner. If you're an Apple recruiter, hire me so I can help ship it! :)

Not that I know anything not known publicly but I suspect the reason Apple iOS Safari does not have Web Push API is not because they lack developer resources to write the code to get it done. Apple is under tremendous pressure to increase revenue from its "services" right now so it seems a bad time to strengthen PWAs.

I don't think that's really true, because Apple has strengthened PWAs in a lot of ways in recent iOS releases.

I personally suspect it has a lot to do with waking up a service worker outside of the browser lifecycle - given how aggressively iOS monitors apps no longer running in foreground I can imagine that being quite a hurdle to overcome (without compromising the reason for doing it in the first place).

> I personally suspect it has a lot to do with waking up a service worker outside of the browser lifecycle - given how aggressively iOS monitors apps no longer running in foreground I can imagine that being quite a hurdle to overcome (without compromising the reason for doing it in the first place).

I don't think this is true. Please correct me if I am wrong but there are ways to handle the scenario. Apple could create nsfirebase (basically an Apple version of Firebase for lack of a better name) and require all websites to talk to nsfirebase and the iOS device only needs to reach out to that particular end point on nsfirebase which minimizes battery loss. In addition, it could say something like your worker can only run in the background if a user has been to your site in the last n hours (where n is something Apple can monitor and update with any iOS release).

> In addition, it could say something like your worker can only run in the background if a user has been to your site in the last n hours

But iOS apps can't do that. The only way they can guarantee background execution is if they are playing audio, or say they're a VOIP app. Of course, Apple could change those rules for Safari, but what I'm saying is that I don't think it's as simple as just flipping a switch - it'll need OS level changes, which will slow things down a lot compared to stuff like offline caching, which the Safari team can implement themselves.

There's also a fundamental difference between iOS notifications and Web Push ones - the notification is already created in the iOS payload. So it doesn't need to wake the app up at all, it just shows the notification. That's not possible with Web Push, so it's a change compared to how iOS handles every other notification.

Getting background location updates will also let your app stay unsuspended. You better have a good reason for getting them, though, or your app won't make it into the store. (Ditto for VoIP or audio apps; the app store reviewers are wise to tricks for mimicking services in a non-service architecture.)

This is interesting:

> the app store reviewers are wise to tricks for mimicking services

Has that been written up anywhere? I'd really like to know more about the reasons behind this arms race.

Wouldn't you say though if that push notifications were allowed PWAs would cannibalize the revenue of the ios app store? It doesn't seem like apple would have much incentive to do this as PWAs would eventually compete with their own platform.

Apple makes most of its app revenue from in app purchases and most of that is for consumables for games.

The types of apps that could be a PWA wouldnt make Apple any money.

You can integrate Apple Pay pretty seamlessly into a PWA. It actually adds a lot in the way of feeling like a real native app.

>It depends.

Sadly I think to often people are to focused on "apps" fail to make that consideration. Businesses seems focus on getting their little icon on the home screen of people phone, to keep them coming back to their service. News sites are especially to blame here.

There are also some app that completely fail to recognise that there are people who need the service an app provides, but doesn't have a smartphone. For instance the only way I can buy a bus ticket with my debit card is to use an app on my phone, but what if I didn't have a smartphone?

Quite frankly not having a smart phone in 2019 is becoming not having a computer in 2000.

Yes you can live just fine without it but you're the exception not the rule.

Reply on news.ycombinator.com