Show HN: Appleshouter – iOS Push Notifications for PWAs and Web apps(github.com)
github.com
Show HN: Appleshouter – iOS Push Notifications for PWAs and Web apps
https://github.com/kosmigramma/appleshouter
53 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/
> 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/
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.
AFAIK iOS “browsers” can inject js into pages, extending available we APIs, like e.g. web3 browsers do.
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.
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"?
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"?
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.
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)
The iOS APIs include a JavaScript runtime engine don't they? (JavaScript Core)
"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.
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
[0] https://developer.mozilla.org/en-US/docs/Web/API/Notificatio...
[1] https://developer.mozilla.org/en-US/docs/Web/API/Push_API
[deleted]
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.
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/
[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.
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".
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.
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.
Ah, of course. Thanks for clarifying.
Thanks, this puts it better.
My thoughts exactly. Here’s hoping their anti-PWA stance might soften with increased antitrust scrutiny.
Anyone with a wide audience on the App Store already has the means of sending notifications to users via APNS…
[deleted]
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?
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.
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.
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.
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).
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!
I can think of numerous websites i'd like notifications on. HN comment replies, for example. But let's keep limiting peoples choices
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?
Why is it Apple users feel so strongly about what other people can run on their computers?
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.
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.
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.
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/