FAQs About Specific iOS and Android Releases

This document describes notable changes associated with specific iOS and Android releases, and how they impact Iterable's customers (if at all).

# In this article

# iOS

The following sections describe information related to specific iOS releases.

# iOS 14.5 (App Tracking Transparency, IDFA)

Apple's iOS 14.5 includes various new features and enhancements that make the iOS experience better for end users. It also includes some changes that mobile marketers should be aware of.

In particular, iOS 14.5 includes an update to App Tracking Transparency. This update requires apps to request user permission before tracking them or linking their data with data collected from other companies' apps and websites.

Previously, apps could perform this sort of tracking without user consent, but no longer. Because of this change, The Identifier for Advertisers (IDFA)—which is used to track users across sites and apps—may no longer get much usage, since users likely won't opt in.

Below, find answers to common questions you may have about whether or not this impacts your mobile messaging with Iterable.

# Will Iterable change its mobile offering because of this update to App Tracking Transparency?

No. Iterable's mobile offering does not need to change because of this iOS update. Iterable’s mobile SDKs do not request or store IDFA, or share data across apps or websites. As such, they will not be impacted by the App Tracking Transparency updates in iOS 14.5. Iterable only allows its customers to track their own data.

# As an Iterable customer, do we need to do anything in light of these new updates?

No. iOS 14.5 and the new IDFA standards do not change the way you can use Iterable to engage with your mobile customers.

# What should we be aware of when considering the broader impact these changes may have to our current mobile strategies?

Though these changes in iOS 14.5 do not affect Iterable, many companies that use Iterable also leverage other paid marketing tools that may use IDFA for cross-site and cross-app tracking. These tools may be impacted by low end-user opt-in to IDFA tracking.

# As an Iterable customer, will these updates affect our ability to send push notifications?

No. These updates will not impact your ability to send push notifications with Iterable.

# Will Iterable, or Iterable’s mobile SDKs, cause the iOS IDFA prompt to appear?

No. The changes to IDFA permissions in iOS 14.5 do not affect Iterable, and our SDK does not capture nor use IDFA.

# On Feb 10, 2021, Apple sent the following notice to iOS developers. Does this affect our usage of Iterable?

On March 29, 2021, token and certificate-based HTTP/2 connections to the Apple Push Notification service must incorporate the new root certificate (AAACertificateServices 5/12/2020) which replaces the old GeoTrust Global CA root certificate. To ensure a seamless transition and to avoid push notification delivery failures, verify that both the old and new root certificates for the HTTP/2 interface are included in the Trust Store of each of your notification servers before March 29.

Note that Apple Push Notification service SSL provider certificates issued to you by Apple do not need to be updated at this time.

(Announcement link)

There are various ways to connect to Apple's Push Notification Service (APNs) to send push notifications. One way is to make a direct connection, as discussed in this notice. Since Iterable uses Amazon SNS—and not a direct connection—to communicate with APNs and Firebase Cloud Messaging (FCM), this notice isn't relevant. Push notifications will continue to work as-is.

# Android

As specific Android releases bring up questions relevant to Iterable customers,
we'll add information in this section.

# Android 13

Android 13 introduces a new permission POST_NOTIFICATIONS, which allows users to decide at runtime whether or not your app should be allowed to display push notifications. When your app requests this permission, Android will display a dialog similar to this:

With this permission, Android users can more easily opt in and out of push notifications for particular apps without having to manually update the Android Settings app.

As described in our blog post about this feature, this new permission will impact different users in different ways, depending on the device and your app's configuration:

• If your app does not yet target Android 13, and a user installs it fresh on an Android 13 device, Android will prompt the user for permission to display push notifications. This usually happens at app startup, which isn't a best practice (users are more likely to consent to push notifications if your app first explains why they're needed). Because of this, consider upgrading your app to target Android 13 as soon as possible.

• Android 12 users who install your app and then upgrade to Android 13 won't see a change in behavior. If they never explicitly disabled push notifications on Android 12, they'll still receive push notifications from your app in Android 13.
  This also applies to users who install your app on Android 13 through a backup and restore from Android 12.

• If your app targets Android 13, and a user installs it fresh on an Android 12 device, Android will default push notifications to an enabled state. The app will not prompt the user for permission.

• If your app targets Android 13, and a user installs it fresh on an Android 13 device, your app can request permission to display push notification whenever it makes most sense. This way, before it asks for permission, it can provide context as to why that permission is necessary and how it will be used.

When you're upgrading your app to target Android 13, declare this permission in your app's manifest:

<uses-permission android:name="android.permission.POST_NOTIFICATIONS"/>

Then, after you've explained to a user why they should allow your app to display push notifications, you can tell Android to prompt the user. For example:

Kotlin

// Check to see whether POST_NOTIFICATIONS has been granted
fun checkNotificationSettings() = ActivityCompat.checkSelfPermission(this,
   Manifest.permission.POST_NOTIFICATIONS) == PackageManager.PERMISSION_GRANTED

// Prompt the user for permission to display push notificationslack
fun requestPermission() {
    var permissionsToRequest = mutableListOf<String>()
    if(!checkNotificationSettings()) {
        permissionsToRequest.add(Manifest.permission.POST_NOTIFICATIONS)
    }
    if(permissionsToRequest.isNotEmpty()){
        // Ask the user for permission
        ActivityCompat.requestPermissions(this, permissionsToRequest.toTypedArray(), 0)
    }
}

// Handle the user's response to the permission request
override fun onRequestPermissionsResult(
        requestCode: Int,
        permissions: Array<out String>,
        grantResults: IntArray
    ) {
    super.onRequestPermissionsResult(requestCode, permissions, grantResults)
    if(requestCode == 0 && grantResults.isNotEmpty()) {
        for(i in grantResults.indices) {
            if(grantResults[i] == PackageManager.PERMISSION_GRANTED) {
                Log.d("MainActivity", "${permissions[i]} granted")
            }
        }
    }
}