[Feature]: Ability to Blacklist Classes for Automatic Session Handling and In-App Messaging Registration in Swift SDK

[initishbhatt]

What problem are you facing?

the in app messages interfere with certain screens where we do not expect them to be shown.

Workarounds

delays are the only workaround i can see as of now.

Ideal Solution

In the Braze Android SDK, there's a feature that allows developers to configure a blacklist of Activity classes to disable automatic session handling and in-app message registration. This is achieved through methods like AppboyLifecycleCallbackListener.setActivityClassInAppMessagingRegistrationBlacklist(), AppboyLifecycleCallbackListener.setActivityClassSessionHandlingBlacklist(), and a specific constructor in AppboyLifecycleCallbackListener. However, this capability seems to be missing in the Braze Swift SDK.

Introduce similar functionality in the Braze Swift SDK that allows developers to specify classes that should be excluded from automatic session handling and in-app message registration. This feature would be particularly useful for apps that have certain views where session tracking or in-app messaging is not desired.

Other Information

No response

[jacksonemiller]

Hi @initishbhatt, thanks for the post. This is something we'll look into supporting on iOS. Our current thinking, however, is that it'd be difficult to exactly duplicate the Android feature on iOS due to differences in each platform's OS and UI APIs/frameworks. We're going to start by looking into other potential ways of giving developers more control over BrazeInAppMessageUI and will let you know about a potential fix.

Thank you again for this. (And also nice profile picture!)

[jacksonemiller]

Hi again @initishbhatt,

After looking into this further, we think the best approach would be to use the BrazeInAppMessageUIDelegate functions to achieve the behavior you are looking for. I think the differences between the Apple and Android dev platforms (primarily iOS lacking a direct parallel to Android's activities) make it difficult to really create a non-hacky solution that'd bring direct parity between the platforms.

The delegate I've linked to would allow you to discard or delay IAMs based upon whatever sort of criteria or logic you want and should be able to garner the desired behavior.

I am going to close this ticket for now, but please let us know if you have any other questions. Thank you.

[initishbhatt]

Hi @jacksonemiller thanks for the update, we will try out this solution

[simonmitchell]

Hi @jacksonemiller if I delay a message by returning .reenqueue from my implementation of the UI delegate, but then want to show them when a certain piece of UI is shown, how can I trigger BrazeUI to loop through the stack of in app messages again and send them in order?

It looks like I could call presentNext() but that won't initiate the recursive behaviour? And also potentially doesn't re-check the delegate for display choice (although that's obviously not a problem in my case).

[jacksonemiller]

Hi @simonmitchell, for your use case, you should be able to do something like the following:

if let oldestMessage = inAppMessageUI.stack.first {
  braze.inAppMessagePresenter?.present(message: oldestMessage)
}

The stack has a public getter, and we append to the higher-indexed end when placing things on the stack, so first should give you the oldest message on the stack. Keep in mind that calling present(message:) will trigger the delegate method again.

If you have any other questions or follow up about this, please let us know. But, we'd ask that you open a separate GitHub issue for our own organization and so that other devs with the same problem can find it in the future.

Thank you!

[simonmitchell]

Brill, thanks for the speedy reply @jacksonemiller, appreciate it! And that looks like it may well cover us 😄

Absolutely, apologies will open a separate issue in future, apologies and thanks again!