Show HN: Appleshouter – iOS Push Notifications for PWAs and Web apps | Hacker News Reader

Show HN: Appleshouter – iOS Push Notifications for PWAs and Web apps

github.com

89 pointshauxir50 comments

This is really smart. It’s sure to be blocked by Apple at some point, but until Apple supports proper web notifications and stops fighting against web standards, workarounds like this need to exist.

If they block it then it will be one more piece of evidence in an antitrust case.

Built this to send notifications for webapps on iOS without having to wrap it in an app and go through the hassle of submitting it to the app store.

This is a great hack but is likely to get you in trouble with Apple if you make it onto their radar. Their guidelines [1] say, in section 3.2.1(iv):

> Wallet passes can be used to make or receive payments, transmit offers, or offer identification (such as movie tickets, coupons, and VIP credentials). Other uses may result in the rejection of the app and the revocation of Wallet credentials."

There's no app to be rejected since we're dealing with PWA's/webapps, but wallet credentials could certainly still be revoked.

[1]: https://developer.apple.com/app-store/review/guidelines/

I want to just appreciate the thought/hack process here. Might be legal or not. Or if we all start abusing it maybe Apple will stop. However.. for now all I got to say is thank you for this. Great one..

They'll just disable notifications for wallets passes

What stops Chrome or Firefox or Brave for iOS from providing push API?

AFAIK iOS “browsers” can inject js into pages, extending available we APIs, like e.g. web3 browsers do.

The problem is that Web Push requires active JavaScript execution to handle pushes and show the actual resulting notification (if any). (Notifications are the most common but not the only use case of web push.)

This isn't (reliably) possible using iOS APIs.

I'd like to know more about these limitations.

The iOS APIs include a JavaScript runtime engine don't they? (JavaScript Core)

Apple forbids other web engines explicitly (or only allows the WebKit respectively) in § 2.5.6 of App Store Review Guidelines: https://developer.apple.com/app-store/review/guidelines/

2.5.6 Apps that browse the web must use the appropriate WebKit framework and WebKit Javascript.

This means they cannot add a new API standard on iOS. This is why WebRTC was hamstrung until November last year.

https://bugs.webkit.org/show_bug.cgi?id=208667 https://bugs.chromium.org/p/chromium/issues/detail?id=752458

If the browser uses WKWebView or UIWebView, you're right, you can "mock" an API by injecting JS, and through tunnelling you can recreate native functionality. Not if its SFSafariViewController. As someone who has done a lot of fiddling with JS to Obj-C/Java tunnelling for iOS and Android in production, it can be prone to errors and/or get your app rejected. Browser makers probably do not see the commercial value in going down this bespoke path.

> If the browser uses WKWebView or UIWebView, you're right, you can "mock" an API by injecting JS, and through tunnelling you can recreate native functionality.

So, technically it can be done.

What's stopping them? Do you think Apple would count that sort of feature as "implementing your own web engine"?

"You might have figured out that Safari on iOS STILL has no support for the Web Push API."

The STILL there makes it sound like Apple is just slow to implement it.

They implemented it in macOS's Safari in 2013, so they are being slow to implement it on iOS.

My apologies if I'm whooshing on irony, but the clear fact is not that they are slow but rather that they have made a decision not to implement it, on every single development cycle over the last eight years.

it's not rare that vendors refuse to do things, then forced to follow standards. When they do, it'll be just like they are incredibly slow to come to a final decision.

As far as I know, Safari on macOS does not support Web Push, but rather a proprietary predecessor of it.

Oh, you're right. I thought OP was talking about the Notifications API [0], since I didn't know there were 2 different notification APIs. The Push API is still a working draft and "experimental technology", but it's implemented in all the major browsers except Safari [1].

[0] https://developer.mozilla.org/en-US/docs/Web/API/Notificatio...

[1] https://developer.mozilla.org/en-US/docs/Web/API/Push_API

This is great for personal code, but anyone who tries deploying this to a wide audience on the App Store is risking a permanent ban by Apple.

Anyone with a wide audience on the App Store already has the means of sending notifications to users via APNS…

Huh? This is for webapps / PWAs, not native iOS apps.

From the Github: "What you will need: An Apple Developer Program account".

That means you can easily be banned for abusing their wallet apis, and they'll probably also take down your other apps on that account.

Thanks, this puts it better.

Ah, of course. Thanks for clarifying.

My thoughts exactly. Here’s hoping their anti-PWA stance might soften with increased antitrust scrutiny.

App Store Guidelines [1] wouldn't apply here since this is for web apps opened in Safari. If anything, it'd be language in the Developer License Agreement that might cover this.

[1] https://developer.apple.com/app-store/review/guidelines/

Web apps opened in Safari.

So if I build a web app on my own dime, on my own hosting resources, signing no developer agreements with Apple whatsoever...

... there's not a remote chance that I'm subject to any of Apple's whims, and there's very little they can do about it.

Add my site to a Safari exclusions list? That will and should go down like a flaming mess.

The first requirement is: An Apple Developer Program account. Presumably for creating the "passes".

I don't suppose there's such a thing as an open push notification service that could work on iOS, Android, and security-focused mobile OSes such as GrapheneOS, is there? Lacking such an ability are websockets or polling the only options for push-like notifications on an OS like Graphene?

This is fantastic, thank you! I was thinking about pirating OSx to do this.

What does the flow to add a notification-supporting Wallet pass look like for the end user?

They have to add a pass to their Wallet with the confirmation screen, which may be a bit confusing ("I'm not buying anything!"). But that's the only step.

So the user hasn’t actually opted-in/allowed notifications?

Whoa, this is super clever! Thanks for sharing!

Anyone got a demo up to see this in action?

nice

Apple has no incentive to make PWA or web apps work natively since they don't get their 30% cut on that.

Steve jobs made it abundantly clear when he blocked Flash on iOS citing battery and security reasons and every developer including myself hailed it as the best thing that could to the internet then; never figuring out the insidiousness of such changes and how it was a priority for Apple to cripple the web browser and keep it crippled to make their App store flourish and get more % cut on apps. They have made billions of dollars doing that and Steve jobs was truly a visionary in this regard.

As someone who was glad that Flash was never supported in the first place I'm twice as glad mobile web notifications aren't supported!

You're always asked if you want to enable notifications.

Exactly, it would be super annoying for every mobile site I visit to prompt me for notification permissions.

surely that could be solved by a single switch in the settings that disables all web notifications? I believe most desktop browsers have that already.

I would be happy with a compromise where a single switch in the settings enables notifications for people who want them.

So you propose solving that annoyance by disabling the tech entirely? Maybe we should disable the browser entirely, so now you don't have annoying sites to worry about at all!

Solving a minor UX concern, easily solved by defaults and settings mind you, by deleting the feature entirely is an absurd argument.

Desktop Chrome has this feature. If it annoys you, you simply turn off the entire feature altogether. Problem solved.

The solution to this is to only allow it if the user "installed" the PWA by adding it to their home screen. Same with the other complex api's like bluetooth etc.

If only your posts weren't supported by hackernews.

Why is it Apple users feel so strongly about what other people can run on their computers?

I can think of numerous websites i'd like notifications on. HN comment replies, for example. But let's keep limiting peoples choices

There was a recent reveal in court documents where Apple tried together with Adobe to make it work but Adobe couldn't pull it off. Now, I think the point about Apple not being interested in PWAs still stands but I think this kind of thinking is rather new at Apple and ever increasing since Tim Cook took over (Other, better examples of this line of thinking are imo, the omission of critical accessories, the ridiculous upselling in all product families and the increasing intrusion of Apple ads in the OS).

I saw the Flash thing for what it was. And all their privacy features are not about being pro-consumer as much as they're about trying to choke off Google's revenue. I can't believe how many developers and other tech-savvy people seem willing to let Apple get away with their blatantly anti-competitive behavior. If you own an iOS device, you're not able to put code you wrote onto that device without both an Apple computer and and Apple developer account. And you probably need Apple's programming language and editor. And none of their devices are expandable or repairable despite charging a premium.

FYI, Steve Jobs originally wanted everything on the iPhone to be web apps. He changed course a little later.

Also see Pushover https://pushover.net/

Reply on news.ycombinator.com