Add custom PurchaseLogic support to PaywallView component

[rickvdl]

Summary

• Adds support for passing custom purchaseLogic (performPurchase / performRestore) to the Paywall and PaywallFooterView components on iOS
• When purchaseLogic is provided, the paywall delegates purchase and restore operations to the app via an async bridge (HybridPurchaseLogicBridge) instead of using RevenueCat's default implementation
• Used when purchasesAreCompletedBy is set to MY_APP

Dependencies

• Depends on purchases-hybrid-common PR: Implemented support for passing custom PurchaseLogic to PaywallView from hybrids purchases-hybrid-common#1494

To Do

• iOS
• Android

[tonidero]

Haven't reviewed this yet, but just a note that I don't think we should release this API with only iOS support. Ideally we can release it for both simultaneously 🙏

[rickvdl]

Haven't reviewed this yet, but just a note that I don't think we should release this API with only iOS support. Ideally we can release it for both simultaneously 🙏

Sorry should have made that more clear, but that's the plan indeed. Working on Android support at the moment :) Will change it to a draft to make it more explicit.

[tonidero]

Looking great! I think that it would be great to try to use the same API we did for Capacitor here though, so it's easier to share between the SDKs later if possible. Nothing blocking other than that 🙏

[tonidero]

We should test this thoroughly by showing and hiding the paywall view, both without paywall dismissal (like the developer hiding it on their own), and with paywall asking to dismiss, whether with a successful purchase or a close event. In all of these scenarios, we should make sure this instance is cleared and can be shown again later.

Just want to make sure since not fully familiar if onDropViewInstance will be called always. Hopefully it does 🙏

[rickvdl]

Tested onDropViewInstance cleanup on Android with debug logging across these scenarios:

Test	Scenario	Result
1	Normal dismiss (close button)	Bridge created + cleaned up via cancelPending()
2	Re-mount (navigate back, open again)	New bridge with new view ID, no stale state
3	Purchase cancel + dismiss	Cleaned up properly
4	Auto-success (immediate resolve)	Cleaned up after completion
5	Dismiss during in-flight purchase (5s delayed resolve)	cancelPending() called before timer fires, no crash
6	Programmatic dismiss (unmount via state)	Cleaned up properly

[tonidero]

I think this makes sense! Only thing is whether we might want to remove it from the Footer support, since I think it's not needed there... Not sure if it might overcomplicate things though, in which case, we could keep it.

[tonidero]

Amazing job! 🚢