Add option to customize spacing applied to SwiftUI-based paywall footer

[JohnSundell]

Checklist

• [ ] If applicable, unit tests (N/A)
• [ ] If applicable, create follow-up issues for purchases-android and hybrids (N/A)

Motivation

This patch makes it possible for API users to customize the amount of spacing that's applied to a PaywallView when presented as a footer using the paywallFooter SwiftUI modifier. That API uses SwiftUI's safeAreaInset modifier internally, which by default adds a system-defined amount of spacing between the view placed within the safe area inset and the host view that the modifier is applied to. With this change, API users are now free to remove or modify that spacing, which is required for certain app designs.

Description

A new spacing parameter was added to RevenueCatUI's paywallFooter SwiftUI modifier API, which when forwarded down the call stack can be passed to the SwiftUI safeAreaInset API to enable the user to tweak the above mentioned spacing between the paywall footer and its host view.

This is a backward-compatible change, as the added spacing parameter is optional with a default value of nil, which retains the existing behavior when the new parameter isn't passed by the API user.

[joshdholtz]

@JohnSundell Hey! Long time no talk 😊 Hope all is well with you!

This change makes a lot of sense but I think we might end up moving this to a backend configuration for two reasons:

1. We would want this easily to configurable for all platforms (Apple, Android, RN, Flutter, KMP, etc). And having this being backend driven doesn't require public API changes on all of the SDKs.
2. We have a Paywalls V2 Coming Soon ™️ that will allow this type of customization that I'm really excited about 😊 And with that, we would like to not make this a public API in the SDK since it will be less effective with new paywalls 😇

So if you are cool with this, I will politely close this implementation of bottom footer spacing but we will still make this change in a backend driven approach with the same behavior 😊

[JohnSundell]

@joshdholtz Thanks for the quick feedback on this! Cool that you're working on a new backend-driven version of the paywall, as you might know, I'm a big fan of backend-driven UIs in general! 🙂

However, as far as I see it, the fix I've made here is entirely a SwiftUI-specific (and thus iOS-specific) issue, as I'm simply enabling API users (like myself) to customize (and, in my case, remove) the system default spacing that SwiftUI itself adds when the spacing parameter passed to the system safeAreaInset modifier is nil. So not sure how it would be implemented in a backend-driven manner, and if it's even worth doing that, since this is such a platform-specific issue?

Would you be more comfortable with an implementation that simply adds a Bool parameter that lets the API user remove the spacing that SwiftUI adds by default? Something like useSystemSpacing: Bool = true, which (just like the current implementation) would be 100% backward compatible and not modify any behavior unless the API user passes false.

[joshdholtz]

@JohnSundell I do know that you are a fan of backend-driven UIs 😁 Can't wait to see your thoughts on it! I'm happy to give you early beta access when its ready if you want 😉

Thoughts on my previous message

However, as far as I see it, the fix I've made here is entirely a SwiftUI-specific (and thus iOS-specific) issue

I totally agree with this and maybe I didn't explain this good enough in my first comment 😅 Our React Native, Flutter, and KMP SDKs use our iOS SDK would could experience this same kind of need. So we would like to open this to those SDKs as well.

My thought was that we could move this to a backend configuration (in our current paywall editor). So you could still get set but through a value that comes from the API (configured via the dashboard).

Thoughts on your new proposal

Would you be more comfortable with an implementation that simply adds a Bool parameter that lets the API user remove the spacing that SwiftUI adds by default? Something like useSystemSpacing: Bool = true, which (just like the current implementation) would be 100% backward compatible and not modify any behavior unless the API user passes false.

This sounds like it could fit a little bit better 🤔 It also feels like it could also interfere less with what Paywalls V2 will bring. Do you happen to have some screenshots of the before and after that shows the difference of the change you are proposing? 😇

[JohnSundell]

I totally agree with this and maybe I didn't explain this good enough in my first comment 😅 Our React Native, Flutter, and KMP SDKs use our iOS SDK would could experience this same kind of need. So we would like to open this to those SDKs as well.

Ah, now I see what you mean 👍

My thought was that we could move this to a backend configuration (in our current paywall editor). So you could still get set but through a value that comes from the API (configured via the dashboard).

Sure, that would also work, but I'm guessing that's something that would take a bit longer to implement? You don't feel like that's a bit overkill for tweaking a simple margin like this? Or would you ideally like all UI configuration to happen through the backend/dashboard?

Do you happen to have some screenshots of the before and after that shows the difference of the change you are proposing? 😇

Here are before/after screenshots of the issue I'm attempting to address. A client I'm working for wants to render a gradient right on top of the RevenueCat paywall footer, which adds a fade effect between the footer and a list of features the user will gain access to by performing the purchase. As you can see in the "Before" screenshot (which is using the current latest version of the RevenueCat SDK), there's a gap between the RevenueCat paywall footer and the gradient which the app adds (because of the SwiftUI-added spacing), and in the "After" screenshot that gap has been removed (since I'm now able to pass spacing: 0 to the new parameter that this PR adds), resulting in a smooth fade effect between the paywall footer and the list of features.

As mentioned, I'd be able to solve my particular use case with a Bool parameter instead that simply removes the SwiftUI-added spacing, if that's something you'd prefer. I just thought the spacing parameter was more suitable, given that it exactly mirrors the SwiftUI API that's called under the hood.