iOS 14 for Developers: Asking for Permission

Dec 15, 2020
By: Jonathan Harrop

Privacy is Apple’s latest product, and mobile app developers have become the door greeters of the App Store. If an app makes a request to share user data, developers must use Apple’s AppTrackingTransparency framework to request permission from the user the first time this happens. No ifs, ands, or buts! We’ve heard a lot of questions from our developer partners about this framework, so we thought we’d try to clear up some misconceptions and offer some early best practices!

A Primer on AppTrackingTransparency

To put it plainly: Every developer monetizing with ads should implement AppTrackingTransparency. What does that mean? Before monetizing your users through ads, or collecting and sharing the IDFA for other purposes (especially with third parties like a Mobile Measurement Partner – MMP), apps now must ask users explicitly if they can collect and share that data.

Who Talks First? Do You Talk First?

One of the primary questions we receive is “Does Digital Turbine have text for the AppTrackingTransparency modal?” We certainly have some recommendations (more on that later, but calling the API (and therefore) surfacing the modal and the text itself is up to you, the developer.

That seems a little odd, you might say. In this case Digital Turbine is the one using that information, so we should be asking for it, right? This comes down to Apple’s perception. From Cupertino’s point of view, it’s the app developers’ responsibility to make sure the app has permission to use iOS resources or user data — for Apple, IDFA sharing is in the same bucket as Bluetooth or Microphone access. This means you only get one chance to ask if it’s okay, regardless of how many monetization or attribution SDKs you have integrated.

How do I write a Compelling Opt-In Message?

Using the purpose string (sometimes called a usage description string) in your app’s info.plist file allows you to present a short message about why your app is requesting permission. If your app already uses Bluetooth, the camera, or other OS-level resources, this should be pretty familiar.

Apple has some clear guidelines about how this message can be phrased on its developer pages but we can sum it up by simply saying: Be specific and clear. Below are some suggestions we think comply with Apple’s guidance:

  • Your data will be used to deliver relevant ads to you.
  • Your numeric device ID will be used to keep ads relevant and non-repetitive.
  • Your data allows for the optimization of the in-app ad experience for you.

Notice a theme? Facts only. Apple expressly forbids ultimatums like “This app requires your data to work,” or emotional calls to action like “This enables our developers to drink decent coffee.”

Will a hybrid approach like “Your data will be used to deliver higher quality ads, which keeps this app free” pass Apple’s check when you submit the app? We don’t know yet. No doubt more sophisticated best practices will emerge over time.

When Should I Ask?

As we mentioned above, an app only has one chance to ask users to opt-in using this framework. If a user says “no,” that’s it unless the user uninstalls and reinstalls fresh (or does so through settings, see below).

The good news is that if you’re using SKAdNetwork for your user acquisition, there’s no need to request the IDFA on the first launch. You can wait it out and follow the tried and true method of ask twice, confirm once.

We are already seeing publishers surface modals that remind the user they are using a free app that makes money from ads, and then asks them nicely to select “OK” to the app gathering data in order to provide more relevant ads, stop repetitive ads, and so on. After the user taps to progress, nothing technically happens behind the scenes – but the user is informed with more context than Apple’s modal allows.

This could happen early on in the user journey since this is just an app-level dialogue. Then, when you actually want to request an ad from any of your ad network SDKs, say before a rewarded video, the Apple dialogue appears and the user taps “OK” because they already know and understand what they’re opting in to.

Important Note: The soft and hard modals need to be presented before the app initializes any SDK that requests the IDFA, which will immediately look for the IDFA. They won’t find it at that point.

Just like with the specific messaging, we expect best practices to emerge over time as developers see what works, what doesn’t, and [more importantly] what Apple allows. We expect the 2021 developer conference circuit to be full of sessions around this topic!

Can I Incentivize Opting In? 

Apple hasn’t provided guidance for incentivized opt-ins, but we expect this will appeal to many developers. This is something we’ll be closely monitoring.

Can I Ask Again?

As mentioned above, once a user taps “Don’t Allow” on the modal, the request will always simply return zeroes for the IDFA. There’s no way presently to resurface the modal like there is for App Store reviews.

It’s possible you could show a video or loop asking a user to go to Settings > Privacy > [App Name] and toggle it back on, but that bar is relatively high for most users, and would require an extremely strong loyalty to your app and your brand. Apple hasn’t provided answers on whether you could incentivize this — “Turn on tracking for our app and receive 20 coins! It helps us keep the app free!” might work for some users, but frustrate others.

By Jonathan Harrop
Read more by this author