Jump to content
Sign in to follow this  

iOS upcoming TrackingAPI in 14.5

Recommended Posts

Hi there,


the new tracking requirements from Apple will soon be enforced into AppStore, so that apps might be rejected.

Here more guiedelines.

I would like to ask if someone already has experiences with this API, since its a little unclear what might fall under it.
Since I'm afraid that his new API contains a lot of pitfalls, like always, to see unexpected rejections, would be good to clarify as early as possible.


Its clear that, if you use any dedicated tracking system, personalized AD's, etc., that this IS tracking.

What I'm thinking of, are all the corner cases that might fall under Apples restrictions as well.


  • Sharing device location data or email lists with a data broker.
    What if device location is stored locally, and maybe sended my mail on-demand uf the user ?
    Is email a "data broker" ?
  • What kind of company constitutes a data broker?
    Data brokers are defined by law in some jurisdictions.
    In general, a data broker is a company that regularly collects and sells, licenses, or otherwise discloses to third parties the personal information of particular end-users with whom the business does not have a direct relationship.
    What is a "data broker" in practice, is this also any private service that processes data for the user only, e.g. like travel route manager, or an apps error logging service ?
    Is any service that NOT discloses any data to 3rd parties OK then ?
  • Sharing a list of emails, advertising IDs, or other IDs with a third-party advertising network that uses that information to retarget those users in other developers’ apps or to find similar users.
    What if sharing data with non-retargetting services, howto define and proof what is "retargetting" and whats not ?
  • Placing a third-party SDK in your app that combines user data from your app with user data from other developers’ apps to target advertising or measure advertising efficiency, even if you don’t use the SDK for these purposes. For example, using an analytics SDK that repurposes the data it collects from your app to enable targeted advertising in other developers’ apps.
    What if you just need a personal login on a personal service, with no advertising taking place  ? 
  • Developers are responsible for all code included in their app, including single sign-on (SSO) functionality provided by third parties. If the user will be subject to tracking as a result of SSO functionality included in your app, you must use the app tracking transparency prompt to obtain permission from that user first.
    Ok, and howto proof that an single-sign-on is used on my own server only, is a written declaration enough ?
    Are any 3rd party single-sign-in or OAuth-services still Ok, or not ? 
    Can I use my own server, to proof no tracking takes place ?
  • Can I fingerprint or use signals from the device to try to identify the device or a user?

    No. Per the Apple Developer Program License Agreement, you may not derive data from a device for the purpose of uniquely identifying it.
    Examples of user or device data include, but are not limited to: properties of a user’s web browser and its configuration, the user’s device and its configuration, the user’s location, or the user’s network connection. Apps that are found to be engaging in this practice, or that reference SDKs (including but not limited to Ad Networks, Attribution services and Analytics) that are, may be rejected from the App Store.
    Well, and what about app-generated GUUID's then, or any hash of user-provided data, like email ?
    In the meaning from above, all "generated", not "derived" data should be fine ?


I hope that already some do's and don't could be shared.



Edited by Rollo62

Share this post

Link to post
15 minutes ago, Fr0sT.Brutal said:

Only Apple has the exclusive right to track you and sell this data xD

Correct, those were the rights Moses gave them, carved in stone :classic_smile:


But whats unclear a bit is, what means "tracking" for them, and whats not.

Share this post

Link to post



My opinion on the topic stems not from the use of the APIs but rather from being a regular target, in Europe, of dodgy-behaving companies. 

To understand the problem trying to be solved here, consider this:


Oftentimes, when you visit a site in the EU, you get a popup saying "We care about your privacy!": those are indeed usually the worst offenders. 

What they will do is to comply where they must (for example offering a "Reject all" button on the screen) but you have to pay attention because if you peek into the legittimate interest you will see everything active. 

Therefore, by "saving" without looking into the legittimate interests, you will still be tracked just as before and the ads will reflect that (but with caution, because they're not stupid!). 


Yet there is more: if you then also go into the "Third Party" tab (where available) occasionally you will find some still active despite rejecting everything. 


This is the landscape Apple is unleashing the Tracking API in. This is why the descriptions are vague: because providers go out of their way to screw you over so they need wiggle room to nuke all of them from orbit.


As for the idea that Apple aims at keeping the tracking data to itself: it's possible, but I am not sure that is the real goal. I think recent scandals have shown that robust tracking is detrimental to everyone and Apple buyers are, on the whole, higher worth people who have probably expressed an appetite for tracking-less phones and apps. It's still possible that they will track you and monetize that, but I think it's not necessarily true. 

Share this post

Link to post

Thats what also Android required now, to have the "prominent disclosure" page, before touching anything.

I think thats good behaviour in general, to let the user choose whats OK for him.

Thats what I implemented now not only for Android, but also for iOS in same way.

I think its a good policy to explain and let choose before use, even if this disclosure page might distract a lot of people.


What I'm afraid of are the many unexpected side-effects of such a new API might bring, maybe unwanted crashes, exceptions or AppStore rejections.


Better to explain what I would like to do:

My apps may contact and register on my own hosted server, so that data protection is no issue, as no 3rd party is involved in the best case.

Preferably on own hosted servers, not AWS or the like, because AWS could be seen as "tracking" if you think over-sensitive.

With my hosting provider I have a data protection contract.

I do not really want to track anything at all, but the definition of "tracking" depends on the point-of-view.

Is sending data by user-confirmed EMail already "tracking" ?

Is logging by single-sign-on into a server already "tracking" ?

For the second I don't need any real privacy data from a person, but at least a unique ID, and it will be hard to secure without 2FA.

With the tracking API Apple seems to restrict to take such unique ID from the Phones itself, so I ask myself: is as self-generated GUUID or hash OK then ?

Apple provides a few examples, which of course should be restricted, but what about all those "harmless" apps, that only need to contact their servers for various, non-personal data.


Lets take for example a simple shopping list, which is hosted on a central server,  all data only for one user, anonymous user, no data processing, no data sharing, no data analysis.

Just for one user to share his own data on his several devices, is that already considered as "tracking" ?

Would be using a 3rd party OAuth-server, like Google/Facebook, already be considered as "tracking" ?

Where does it start, where does it end ?


If Apples view of "tracking" only has to do with restricting unwanted AD's, then I'm fine.

But if this is getting too strict, then it starts getting problematic.

I mean you can drill this topic always to the extreme, and I knew Apple for doing so very likely :classic_smile:



Edited by Rollo62

Share this post

Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this