React-native-firebase: [SOLVED we think] AdMob support for iOS 14 AppTrackingTransparency

[khoabuidev]

Hi, Today I received this message on google Admob "Prepare your apps for iOS 14 Apple announced the new AppTrackingTransparency framework, which requires changes to your iOS apps. Implement the GMA SDK 7.64.0 (or later) and set up consent messaging to help prevent a significant loss in ad revenue." so what can I do now for it? many thanks!

Issue

Describe your issue here

---

Project Files

Javascript

Click To Expand

#### `package.json`:

# N/A

#### `firebase.json` for react-native-firebase v6:

# N/A

### iOS

Click To Expand

#### `ios/Podfile`: - [ ] I'm not using Pods - [x] I'm using Pods and my Podfile looks like:

# N/A

#### `AppDelegate.m`:

// N/A

---

Android

Click To Expand

#### Have you converted to AndroidX? - [ ] my application is an AndroidX application? - [ ] I am using `android/gradle.settings` `jetifier=true` for Android compatibility? - [ ] I am using the NPM package `jetifier` for react-native compatibility? #### `android/build.gradle`:

// N/A

#### `android/app/build.gradle`:

// N/A

#### `android/settings.gradle`:

// N/A

#### `MainApplication.java`:

// N/A

#### `AndroidManifest.xml`:

<!-- N/A -->

---

Environment

Click To Expand

**`react-native info` output:**

 OUTPUT GOES HERE

- **Platform that you're experiencing the issue on**: - [ ] iOS - [ ] Android - [ ] **iOS** but have not tested behavior on Android - [ ] **Android** but have not tested behavior on iOS - [ ] Both - **`react-native-firebase` version you're using that has this issue:** - `e.g. 5.4.3` - **`Firebase` module(s) you're using that has the issue:** - `e.g. Instance ID` - **Are you using `TypeScript`?** - `Y/N` & `VERSION`

---

• 👉 Check out React Native Firebase and Invertase on Twitter for updates on the library.

[andersonaddo]

Hmmmm
so I had a look at this:
https://developers.google.com/admob/ios/ios14

Looks like there are two options: Stick with IDFA (which Apple is trying to effectively kill), or move on to SKAdNetwork.
And it seems that most of the work will still be developer side work for either option you choose - you just have to add some things to your info.plist.
Some native code checks are recommended but not needed. But I suppose patch-package can help with that.

I wonder if we should think about integrating this: https://developers.google.com/admob/ump/ios/quick-start

[khoabuidev]

Hmmmm
so I had a look at this:
https://developers.google.com/admob/ios/ios14

Looks like there are two options: Stick with IDFA (which Apple is trying to effectively kill), or move on to SKAdNetwork.
And it seems that most of the work will still be developer side work for either option you choose - you just have to add some things to your info.plist.
Some native code checks are recommended but not needed. But I suppose patch-package can help with that.

I wonder if we should think about integrating this: https://developers.google.com/admob/ump/ios/quick-start

Thank @andersonaddo very much, I will try to apply this.

[andersonaddo]

Just to note:
The docs note that Google Mobile Ads v7.64.0 will be needed, but I think we use a lower version. I'm not sure.
Having a look at our tests files (which contains a compiled app):

https://github.com/invertase/react-native-firebase/blob/fcf24478f9c889021afc4426a7016cfd3fd5d6cc/tests/ios/Podfile.lock#L14

https://github.com/invertase/react-native-firebase/blob/fcf24478f9c889021afc4426a7016cfd3fd5d6cc/tests/ios/Podfile.lock#L219

[mikehardy]

Good spot @andersonaddo

They specify '~> 7.50' https://github.com/CocoaPods/Specs/blob/b513b219e9a15e2ab11b7ed93e69e0c7336a176a/Specs/0/3/5/Firebase/6.30.0/Firebase.podspec.json#L93

https://guides.cocoapods.org/using/the-podfile.html#specifying-pod-versions
`~> Major.Minor' (but not patch!) means that pod update should be allowed to bring in the 7.64 Google-Mobile-Ads-SDK

That's why the test Podfile.lock has 7.62 (must have been current the last time the lock file was updated) vs 7.50 which is specified

So it's achievable to test using current dependencies I think

[andersonaddo]

Great.
@khoabuidev please keep us updated about this. If it works, it might be worth mentioning it in our docs.

[khoabuidev]

I have updated all dependencies in my project, remove Podfile.lock and Pods folder and run "pod install" . I see that it installing Google-Mobile-Ads-SDK (7.64.0), detail as below:

1. npm i -g npm-check-updates
2. npx npm-check-updates -u
3. rm -r node_modules
4. yarn install
5. cd ios
6. pod install
   And there is the result
   

FYI: @andersonaddo

[mikehardy]

Of interest, react-native-permissions has a pull request that should work now, but it requires Xcode 12beta toolchain to compile https://github.com/react-native-community/react-native-permissions/pull/501

And adding the right stuff to your plist

<key>NSUserTrackingUsageDescription</key>
<string>This identifier will be used to deliver personalized ads to you.</string>

[mikehardy]

With the addition of that PR to react-native-permissions to handle the user consent, and the ability (proven) to use the latest version of the AdMobs SDK, I don't think there is anything more to do here. I'm going to close this but if I am wrong obviously we can reopen and discuss - not closing because it's not important just that I think it's resolved :-). Cheers

[khoabuidev]

Of interest, react-native-permissions has a pull request that should work now, but it requires Xcode 12beta toolchain to compile react-native-community/react-native-permissions#501

And adding the right stuff to your plist

<key>NSUserTrackingUsageDescription</key>
<string>This identifier will be used to deliver personalized ads to you.</string>

Thanks so much @mikehardy mikehardy

[mikehardy]

The related react-native-permissions PR has been merged, if you get [email protected] (or greater) and have Xcode12 + ios14 + pod update (to get the new Mobile-Ads-SDK) you should be set.

Any reports of success or failure are welcome, this is the leading edge of development now but will affect lots of users so the reports will be useful to your fellow developers!

[manuhook]

Do you think there's any chance react-native-firebase will support the User Messaging Platform (UMP) SDK (https://developers.google.com/admob/ump/ios/quick-start) which replaces the previous open source Consent SDK currently integrated to rn-firebase ?
It will be a great help to manage automatically both RGPD or CCPA consent and iOS 14 AppTrackingTransparency. Thanks !

[mikehardy]

@manuhook that does look like a nice way forward. We'd gladly take a PR to migrate to it

[rochapablo]

Besides adding

<key>NSUserTrackingUsageDescription</key>
<string>This identifier will be used to deliver personalized ads to you.</string>

To get the alert request, should I do something else?

I'm not getting errors but neither getting that alert request permission.

Xcode 12.0 beta 6
iOS 14.0 (simulator)

"react": "16.13.1",
"react-native": "^0.63.2",

"@react-native-firebase/admob": "^7.6.2",
"@react-native-firebase/app": "^8.4.1",

"react-native-permissions": "^2.2.0",

https://github.com/react-native-community/react-native-permissions/issues/500#issuecomment-689452140

[rochapablo]

I thought that the request for permission was already implemented, but it isn't. Is that right? I'm, asking just to be sure. I did and now the alert it's working.

import { request, PERMISSIONS } from 'react-native-permissions';
request(PERMISSIONS.IOS.APP_TRACKING_TRANSPARENCY)

[mikehardy]

@rochapablo wrong repository - that's a react-native-permissions question, this library does nothing to check or request the permission

[AlekseyKutsko]

Hi there!
Should I call consent form(AdsConsent.showForm) on ios if I'll add AppTrackingTransparency?

[emilioheinz]

Is there any roadmap to automatically request this permissions when using something that requires the APP_TRACKING_TRANSPARENCY (Something like React Native Camera that automatically requests the permission of camera access)? Or the final approach is requesting this permission with React Native Permissions?

Thank you.

[mikehardy]

I am not interested in merging functionality here that handles permissions. react-native-permissions exists for this very purpose, it should be used

[emilioheinz]

Yes I totally Agree!

[brianGammon]

Hi all, question on this topic... if I do have the latest Google-Mobile-Ads-SDK (7.67 as of now), but I do not implement the request for permission using something like react-native-permissions, what happens? Will adMob work, but default to non-personalized ads and no tracking?

[emilioheinz]

@brianGammon I think after January 2021 , or as apple says early next year, it will stop working.

“On iOS 14, iPadOS 14, and tvOS 14, apps will be required to receive user permission to track users across apps or websites owned by other companies, or to access the device’s advertising identifier,” Apple posted today in a developer update. “We are committed to ensuring users can choose whether or not they allow an app to track them. To give developers time to make necessary changes, apps will be required to obtain permission to track users starting early next year. More information, including an update to the App Store Review Guidelines, will follow this fall.”

font: https://www.forbes.com/sites/johnkoetsier/2020/09/03/idfa-stay-of-execution-apple-delays-new-ios-14-privacy-measures-until-2021/#162e185d569f
font: https://developer.apple.com/news/?id=hx9s63c5

[bd-arc]

It looks like there hasn't been any feedback from the trenches on the AdMob/ATT issue yet, so allow me to share some.

We've been trying to push one of our apps' update for weeks now. We had been using AdMob for months, and have recently implemented the ATT — kudos to everyone in this thread, your conversations have been really helpful for that 👍

Since we're based in Europe, we also need to deal with a few GDPR specifics. For example, Apple asked us to present the ATT prompt before the one that AdMob requires in the EEA.

But, so far, each attempt to publish the app (5 and counting) has been met with the following answer:

We're looking forward to completing the review of your app, but we need more information to continue. Specifically, we noticed that your app uses the AppTrackingTransparency framework, but we haven't been able to locate the relevant AppTrackingTransparency permission requests.

While it is not required to implement AppTrackingTransparency at this time, we check to make sure the implementation is compliant with our guidelines when we detect the framework in an app.

And now for the crazy part: no device running the latest iOS version (14.2 at the time of this writing) seems to trigger the ATT prompt whereas every single XCode 12 simulator running exact the same version does!

So it looks like developers are stuck in a loophole:

• we're required to implement the ATT
• apps are rejected because ATT is implemented but the prompt is not triggered on actual devices (yet?).

Fortunately, Apple is there for us: "More information will follow this fall."

Did any of you experience the same madness?

---

If you're interested, know that I've filled a bug report on react-native-permission's repo.

I doubt this is related to the plugin itself. But if it is, at least we'll know.

[mikehardy]

@bd-arc - thanks so much for the real experience! This is helpful to me at least, and likely others.
I follow the react-native-permissions repo as well (though I don't often make PRs there) and I saw that issue. Combining the two, I think that issue - when resolved - will be the root cause and hopefully you can proceed.

[bd-arc]

@mikehardy Happy to help!

I'll share here what we've discovered in the bug report I had opened. Hopefully it will save other people a lot of headaches!

1. ⚠️ There's a system setting that, if disabled, will prevent the ATT prompt to ever appear.
   
   
   
   • See this SO answer for more info.
   
   
   • I personally wasn't aware of this setting's existence, both as a developer and as a user.
   
   
2. If "disabled" is the default value of this setting, you can kiss tracking goodbye — at least if you rely on the IDFA.
   
   
   
   • The odds of having someone a) finding this setting, b) voluntarily enabling it, c) allowing the tracking in your app is probably less than being hit by a meteorite.
   
   
3. Now for the funny part: most Apple testers apparently have the system setting disabled on their own phones. It seems crazy since they're supposed to double-check everything related to ATT, but that's the way it is.
   
   
   
   • We'll add some review notes to let them know that they must enable this setting before checking our app for the 6th time. I'll keep you posted on whether that worked or not.