For answers to the following frequently asked questions, click on the links.

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

Answer: When you first look at the IBM 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 IBM 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: I tried to set an attribute but it didn’t show up. Why’s that?

Answer: Both the SDK and the server cache updates to attributes. When you set attributes, only the attributes for defined columns get updated. If you want to set an attribute for a column before the column exists, IBM recommends that you set invalidateExistingUser=true to ensure your testing is in sync with your client devices. For information about invalidateExistingUser, see Assign new MUIDs to devices when reinstalling apps.

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

Answer: IBM 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-WCA app to WCA. If the non-WCA app also had the PACKAGE_REPLACED intent, then you will see WCA attempt to register when first installed on top of the non-WCA app. Very old versions of the SDK didn’t handle this correctly, but all recent versions do.

Question: Due to corporate requirements, I have to whitelist the GCM push servers. Which IP addresses should I use?

Answer: NOTE: We recommend that you not set up any whitelisting for your FCM or GCM push servers. That will ensure your app will continue to work regardless of what changes occur with IBM’s infrastructure.

We understand, though, that sometimes corporate requirements are such that whitelisting is required. IBM’s push servers are on static IPs owned by SoftLayer. If you need to whitelist IP addresses for push servers, use the following IP addresses:

169.55.63.14
169.55.63.26
169.55.63.32
169.55.63.33
169.55.63.87
169.55.63.89
169.55.63.90
169.55.63.91

Go Back to Mobile App Messaging home page.

Join The Discussion

Your email address will not be published. Required fields are marked *