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 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..
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].
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.
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.
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.
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.
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.
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?
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.)
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"?
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.
53 comments
[ 3.5 ms ] story [ 99.3 ms ] threadThat means you can easily be banned for abusing their wallet apis, and they'll probably also take down your other apps on that account.
[1] https://developer.apple.com/app-store/review/guidelines/
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 STILL there makes it sound like Apple is just slow to implement it.
[0] https://developer.mozilla.org/en-US/docs/Web/API/Notificatio...
[1] https://developer.mozilla.org/en-US/docs/Web/API/Push_API
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.
Solving a minor UX concern, easily solved by defaults and settings mind you, by deleting the feature entirely is an absurd argument.
Why is it Apple users feel so strongly about what other people can run on their computers?
Atleast EU are about to punish these for anti-competetive behaviour
AFAIK iOS “browsers” can inject js into pages, extending available we APIs, like e.g. web3 browsers do.
This isn't (reliably) possible using iOS APIs.
The iOS APIs include a JavaScript runtime engine don't they? (JavaScript Core)
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.
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"?
> 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/