Closed remarcus closed 7 months ago
Hi @remarcus,
Thanks for reporting this issue. Just to make sure I got everything right:
.reenqueue
+ .reenqueue
)
BrazeInAppMessageUI.stack.count == 1
BrazeInAppMessageUI.stack.count > 1
.reenqueue
+ .discard
)
BrazeInAppMessageUI.stack.count == 0
BrazeInAppMessageUI.stack.count == 1
In both cases, on step 4.
we are calling BrazeInAppMessageUI.present(message:)
passing BrazeInAppMessageUI.stack.last
as argument?
If this is accurate, we are already working on a fix that should be part of the next release.
Hey @lowip,
Thank you for correcting the 2nd example, otherwise it's correct.
And yes, we're using the BrazeInAppMessageUI.stack.last
as an argument.
Thank you for a quick response.
Hi @remarcus,
We've released a fix for this as part of version 8.3.0 of the Swift SDK. I am going to close out this thread, but please let us know if you have any other questions or issues.
Thanks!
Platform
iOS
Platform Version
17.3.1
Braze SDK Version
8.2.1
Xcode Version
15.1
Computer Processor
Apple (M1)
Repro Rate
100%
Steps To Reproduce
Example 1:
.later
/.reenqueue
BrazeInAppMessageUI.present(message:)
invoked.later
/.reenqueue
returnedExample 2:
.later
/.reenqueue
BrazeInAppMessageUI.present(message:)
invoked.discard
returnedExpected Behavior
BrazeInAppMessageUI.stack.count
is equal to1
Actual Incorrect Behavior
BrazeInAppMessageUI.stack.count
is greater than1
Verbose Logs
No response
Additional Information
Original issue I raised for how to handle InApp postponing and comment suggested that
present
will remove InApp form stack. As I see from the code it sure does remove the message if.now
is the decision returned and can verify that from testing, still the mentioned behaviours seem to build on top of the stack. https://github.com/braze-inc/braze-swift-sdk/issues/71#issuecomment-1643987534