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.
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.
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..
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"?
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.)
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.
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].
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.
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?
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.
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.
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).
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.
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.
