Naive approach to handle the onPurchaseCompleted event for an offer code

[JZDesign]

Checklist

• If applicable, unit tests
• If applicable, create follow-up issues for purchases-android and hybrids

Motivation

We have 2 issues with how the purchase handler callbacks work that can be used in swiftUI or ReactNative.

1. The offer code flow is executed outside of the bounds of our paywall, and therefore the purchase handler does not directly handle the transaction and no event is fired back through our callbacks
2. If state mis-management causes SwiftUI to re-render the views, a disconnection can occur and the PurchaseHandler that is processing a transaction may not be the same instance that would trigger the callback through the view hierarchy.

If either of those things are true, applications that are depending on the information that comes through our onPurchaseCompleted callback get let down and they miss the event entirely.

Description

Using a naive approach (the broadcast receiver pattern via the NotificationCenter), we enforce that all instances of the purchase handler will get all purchase events. They will be de-duplicated to ensure that we do not invoke the callback twice.

[emerge-tools]

📸 Snapshot Test

78 modified, 797 unchanged

Name	Added	Removed	Modified	Renamed	Unchanged	Errored	Approval
RevenueCat com.revenuecat.PaywallsTester.mac-catalyst-optimized-for-mac	0	0	1	0	235	0	✅ Approved
RevenueCat com.revenuecat.PaywallsTester.mac-native	0	0	9	0	158	0	✅ Approved
RevenueCat com.revenuecat.PaywallsTester.mac-catalyst-scaled-to-match-ipad	0	0	68	0	168	0	✅ Approved
RevenueCat com.revenuecat.PaywallsTester	0	0	0	0	236	0	N/A

---

🛸 Powered by Emerge Tools

[JZDesign]

Perhaps this is something that Tuist will help with, but I copied a file and pasted it so I could get these tests to run

[rickvdl]

💪