FAQ's

Question: Why is the Acoustic Mobile App Messaging SDK for iOS so large?

Answer: When you first look at the Acoustic Mobile App Messaging SDK, it appears to be very large, especially when you consider what it does. The iOS SDK V3.7.1.2 download is in excess of 60M unzipped, and the main framework is over 30M.

The SDK is packaged for multiple architectures

Apple imposes some requirements on the SDK because it’s a third-party SDK. The SDK provides the following four architectures and bitcode:

i386 – required for emulators on older Macs
x86_64 – required for emulators on newer Macs
armv7 – required for older iOS devices
arm64 – required for newer iOS devices

Additionally, the SDK’s frameworks ship with bitcode, which is a platform-independent implementation that (in theory) allows apps to be recompiled and run on hypothetical newer devices with different architectures.

When installed on the device, the SDK is much smaller

When an app is installed on a device, only the slice of the binary that the device actually uses is included in the binary through a process called “app thinning.” The largest part, the bitcode, is never installed on the device, since we provide binary slices for all existing supported architectures.

When a universal app (an app that can run on any iOS device) is installed, the iOS V3.7.1.2 SDK adds about 2.2MB to the size of the app binary. When a device-specific build (or an app store build) is installed on a device, Apple knows the architecture and strips out even more. In these cases, the Acoustic SDK adds about 1.2MB to the app binary.

Debug builds don’t go through app thinning

If you look at the size of the sample app on the device when you debug it, you’ll see that the size is around 7M, but this size does not take app thinning into account. A universal binary that includes the sample app is about 4.2M uncompressed (2.1M compressed) while a platform-specific binary is around 2.7M uncompressed (1.5M compressed).

The sample app has a big image

The sample app includes background.jpg as part of the InApp plug-in demo. This image is 560k. If you are using in-app messages, you can substitute a smaller and less-complicated background image. If you are not using in-app messages, you can delete it.

Question: Can Apple IDFA and Google AAID be used to track users?

Answer: Acoustic has researched the Apple IDFA (ID for Advertising) and the Google AAID (Android Advertising ID) for tracking on iOS / Android. In the end, it was determined that IDFA and AAID are not suitable for Acoustic Campaign customers. Acoustic Campaign uses its own internally generated IDs (mobile user IDs and channel IDs) to track users and does not require these device-specific identifiers.

Using the IDFA / AAID has privacy implications. Many organizations prefer to avoid the issues
that surround use of these identifiers. In short, many Acoustic Campaign customers do not intend to send third-party advertisements in their app. Thus, requiring customers to accept Apple / Google terms for IDFA / AAID is overly burdensome. For this reason, the Mobile app messaging SDK is unencumbered by IDFA / AAID API calls.

You are free to use IDFA / AAID in your app. Your app must enable the permissions to turn on IDFA
/ AAID tracking, and you must accept the additional legal requirements that the platforms impose on
the use of the identifier. A recent Apple requirement asks that you confirm:

… that this app, and any third party that interfaces with this app, uses the Advertising Identifier checks and honors a user’s Limit Ad Tracking setting in iOS and, when it is enabled by a user, this app does not use Advertising Identifier, and any information obtained through the use of Advertising Identifier, in any way other than for “Limited Advertising Purposes” as defined in the iOS Developer Program License Agreement.

The Apple agreement specifies If You choose to use the Advertising API in Your Application, then you must enter into a separate written agreement with Apple and/or an Apple Subsidiary before any distribution of Your Licensed Application may take place via the App Store, VPP/B2B Program Site, or TestFlight Program (https://developer.apple.com/programs/terms/ios/standard/ios_program_standard_agreement_20140909.pdf). The Android AAID agreement is less restrictive but has similar intent in regard to user privacy (https://play.google.com/about/monetization-ads/ads/ad-id/).

Because mobile app message functionality generates and uses its own identifiers (mobile user
IDs and channel IDs), it does not depend on identifiers, such as IDFA and AAID. If you choose to use
these identifiers, your app must do the integration rather than building support into the core
SDK.

It is possible to store an IDFA / AAID identifier as a user attribute. You can query and export
user attributes in the same way you query and export any other attribute. Set the attribute after
you obtain a mobile user ID / channel ID. On iOS, make an updateUserAttributes:completion: call based on the @"MCERegisteredNotification" and @"MCERegistrationChangedNotification"
observers. On Android, make an updateUserAttributes call from MceNotifier onSdkRegistered.

Question: When I install my app on Android, I can see in the log that it runs. Why does this happen?

Answer: This is a consequence of the app having the PACKAGE_REPLACED intent. We use this to re-register in the background and restart the push service, so users don’t have to wait as long when first starting your app, and will continue to get push notifications.

Where it can introduce confusion is if you’re migrating from a non-Acoustic app to Acoustic. If the non-Acoustic app also had the PACKAGE_REPLACED intent, then you will see Acoustic attempt to register when first installed on top of the non-Acoustic app. Very old versions of the SDK didn’t handle this correctly, but all recent versions do.

Question: Due to corporate requirements, I must whitelist the FCM push servers. How should I proceed?

Answer: The Google FCM service that delivers push notifications to mobile devices uses several ports and hosts. For more detailed information, see (https://firebase.google.com/docs/cloud-messaging/concept-options#messaging-ports-and-your-firewall).