So the fine seems to be for treating 3rd parties differently from their own stuff.
They could make their own popups require double confirmation instead...
So the fine seems to be for treating 3rd parties differently from their own stuff.
They could make their own popups require double confirmation instead...
If Apple doesn't feel like they need additional consent and/or doesn't use ATT-blocked systems then they don't need that.
This is stupid.
I'm not sure this is fixable?
Or maybe there is widespread misunderstanding of the requirements in this scenario? But I also thought the rule was tough enough to require verifying that extra consent? Maybe it's not?
Truly confused here.
Not from Apple's end.
Apple mandates that all requests for permissions go through a single, OS-provided dialog. If a user accepts, the permission is granted; if the user rejects, the permission is not granted, and the app can't ask again. Simple enough.
App developers try to maximize their chances of getting that permission granted by adding another warm-up dialog before actually doing the official permissions request. Since those other dialogs aren't part of Apple's permissions request chain, they can be rejected by the user without consequence, and the app can present them as often as it wants.
There is nothing which requires third-party developers to use these additional dialogs. It's a design pattern (and an annoying one at that) which many developers have gravitated towards. Not all developers use it; in particular, Apple doesn't use it for their first-party apps. And apparently FCA is faulting Apple for not following that pattern themselves.
[1] https://developer.apple.com/design/human-interface-guideline...