Apple is continuously replying this to my app
The app appears to manipulate users into enabling tracking across different apps and websites. Specifically:
The app requires users to enable tracking in order to access the app's content and functionality.
Users should have control over how their personal information is used and should not be forced or manipulated into enabling tracking.
Next Steps
Take the following step(s) to resolve this issue:
Revise the app so that users are not required to enable tracking in order to access the app's content and functionality.
Resources
Learn more about these requirements in guideline 5.1.2.
iOS App 1.0App Version
Rejection Reasons:
5.1.2 Legal: Privacy - Data Use and Sharing
My login function is dependent on advertising id and advertising id can be achieved through tracking, what to do for my case? We aren’t taking advertising id for ads purpose or unlawful acts. Advertising id is solely taken to get us know that user is using same older device he used for last successful login.
We need two unique identifier:
keychain uuid used
advertising id
how to get this thing approved from Apple? I tried to reply the message and requested phone call but no response.
App Tracking Transparency
RSS for tagRequest user permission to access user data for tracking a user or device.
Posts under App Tracking Transparency tag
43 Posts
Sort by:
Post
Replies
Boosts
Views
Activity
In order to have ads on Meta that link to the App Store directly (instead of to a website) Meta requires that I install the FB SDK.
Now: Apple requires an ATT permission popup if a user is being tracked.
I've installed the SDK but turned all tracking off by default (so it behaves as though the user said "no" to the ATT popup) and it's still not passing review. Any ideas as to what I could try next?
We develop an SDK that requires sharing a device-specific identifier with our web API, in order to guarantee that certain artifacts are only used on the correct device. For the device-specific identifier, we use UIDevice.currentDevice.identifierForVendor which should not be restricted under ATT.
In production, many developers are getting back to us with complaints of web requests being blocked:
nw_endpoint_handler_path_change [C1 [our url]:443 waiting parent-flow (satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi)] blocked tracker
Connection 1: received failure notification
Connection 1: failed to connect 1:50, reason -1
Connection 1: encountered error(1:50)
Task <FA03088C-DDFC-437E-A06F-E05CC930E3E0>.<1> HTTP load failed, 0/0 bytes (error code: -1009 [1:50])
Task <FA03088C-DDFC-437E-A06F-E05CC930E3E0>.<1> finished with error [-1009] Error Domain=NSURLErrorDomain Code=-1009 "The Internet connection appears to be offline." UserInfo={_kCFStreamErrorCodeKey=50, NSUnderlyingError=0x3031118f0 {Error Domain=kCFErrorDomainCFNetwork Code=-1009 "(null)" UserInfo={_NSURLErrorBlockedTrackerFailureKey=true, _kCFStreamErrorDomainKey=1, _kCFStreamErrorCodeKey=50, _NSURLErrorNWPathKey=satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi}}, _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <FA03088C-DDFC-437E-A06F-E05CC930E3E0>.<1>, _NSURLErrorRelatedURLSessionTaskErrorKey=(
"LocalDataTask <FA03088C-DDFC-437E-A06F-E05CC930E3E0>.<1>"
), NSLocalizedDescription=The Internet connection appears to be offline., NSErrorFailingURLStringKey=..., NSErrorFailingURLKey=..., _kCFStreamErrorDomainKey=1}
Interestingly, I've made a few observations:
The blacklist seems to be persistent, across devices.
The blacklist stays in place regardless of whether we send no identifiable data in the web request (in fact, an empty ping request to our URL still gets blocked)
The only way to get past the block is to use ATT, and request from the user that we track them across websites. This is false, because we don't track any user data whatsoever; and iOS disables ATT by default (in the settings app, users have to opt-in).
Our iOS SDK already has an xcprivacy manifest mentioning the fact that we use a device-specific identifier, and that we send it to our web API URL. Still, we get blocked.
How can we fix this? We can standup a proxy URL but I'd imagine it's only a matter of time before that also gets blocked. Apple has not provided any guidance on the specifics of how domains get blocked, and how they can be unblocked.