The Salesforce Engagement SDK can coexist and work in the same app as the SDKs of other push providers. However, we recommend checking with your other SDK vendors to ensure they also support a multi-push provider implementation. Consider these factors if you implement multiple push SDKs.
Common Issues With Multiple Push Provider
Some multiple push provider (MPP) implementations can prevent the transmission of device tokens and push messages.
Without device tokens, the SDK doesn’t register the device properly. As a result, Marketing Cloud is unable to send push notifications to the device. The SDK expects you to pass push notifications to the setNotificationRequest method. Using this method makes the SDK aware of the notifications and lets it handle them accordingly.
Apple has specific delegate methods that the consuming application must implement to register with APNs and receive push notifications. Implementing multiple push providers can affect the previously mentioned functionality since other vendors can provide wrapper methods for registration and receiving the notifications. Consuming applications often listen to the wrapper methods instead of actual Apple-provided delegate methods. An example of a common issue is when registration with Apple is done for one push provider without setting the deviceToken for other push providers.
Handling MPP with the SDK
Method Swizzling is the process of changing the implementation of a selector at runtime. If Method Swizzling is enabled, other push providers automatically intercept all the application delegate methods, which differ from the normal flow in setting up the deviceToken and notification userinfo.
Method Swizzling can confuse SDK users about how and where to set the SDK’s required API methods because another provider is changing the implementation without their knowledge.
To determine if other SDK providers use Swizzling, check to see if they use these methods.
MPP implementation issues are often caused by issues related to device registration, badging, geolocation, custom payload keys, and feedback.
Registration: You must only make one call to a push SDK to register for push notifications. Otherwise, a single push notification can trigger multiple notification banners, alerts, or sounds. The SDK gives the app developer the power to register.
Notification Settings: An app can invoke requestAuthorizationWithOptions and registerForRemoteNotifications multiple times. However, only the settings from the last call are used, as each successive call overwrites the previous settings.
Badging: There’s no way to guarantee the value of a badge.
Custom Payload Keys: If your implementation must distinguish between two notification providers, use custom keys or other payload-specific data to ensure that your app calls the correct SDK handler that supports multiple notification handlers. Passing a third party’s notification to setNotificationRequest or setNotificationUserInfo is essentially a no-op call. The SDK only emits logs indicating the origin of the notification wasn’t from Engagement.
Geolocation: If you implement multiple SDKs that use location-enabled services, use only one SDK’s location enablement. Using more than one leads to unknown and unsupportable consequences. For example, the methods used by the other providers to interact with iOS CoreLocation services and enable location services are likely to affect each provider. An app can monitor a limited number of geofences at any given time. This number depends on iOS version, device type, and other considerations. With multiple implementations competing for a limited resource, the user experience can suffer. Additionally, permissions needed to use location-enabled SDKs can overlap or conflict.
Feedback: Not all providers are able to detect if a device has been unregistered. To see how notifications are handled using Firebase as a push provider, see the iOS LearningApp.
j