Created PaywallExtensions: StoreView and SubscriptionStoreView overloads for Offering

[NachoSoto]

Description

This adds overloads, but there's still a few things pending for the SDK to fully support these:

• Set presentedOfferingIdentifier when displaying StoreKit2 paywalls: SDK-3176
• Fix preventPurchasePopupCallFromTriggeringCacheRefresh: SDK-3172
• Always initialize StoreKit2TransactionListener even on SK1 mode: SDK-3170

Example:

struct App: View {

    var offering: Offering

    var body: some View {
        Content()
            .sheet(isPresented: self.$showingSubscriptionSheet) {
                SubscriptionStoreView(offering: self.offering)
            }
    }

}

[codecov]

Codecov Report

Merging #2593 (5ba1822) into main (9494f2e) will decrease coverage by 0.05%.
The diff coverage is n/a.

❗ Current head 5ba1822 differs from pull request most recent head d747701. Consider uploading reports for the commit d747701 to get more accurate results

@@            Coverage Diff             @@
##             main    #2593      +/-   ##
==========================================
- Coverage   86.29%   86.24%   -0.05%     
==========================================
  Files         205      205              
  Lines       14334    14334              
==========================================
- Hits        12369    12362       -7     
- Misses       1965     1972       +7     

see 4 files with indirect coverage changes

[tonidero]

2 questions:

• Will the ProgressView use the full available space? Or more importantly, will the transition between this and the SubscriptionStoreView once it's loaded look good?
• Did you/should we get a design review on this?

[NachoSoto]

Yeah this is very WIP.
I'm going to extract CurrentOfferingSubscriptionStoreView into a separate PR so we can merge the rest, and handle this and the offering failure separately.

[tonidero]

So if getting offerings fail, we just keep the loading state? I think we should show some error UI. Thoughts?

[tonidero]

A couple more questions about these views:

• When purchasing through this view, does it automatically finish the transaction? Or does the developer still have to do it?
• If the user purchases an offering through this view, we won't be getting the presentedOfferingIdentifier setup in the SDK... We need to figure out a way to set that.

[tonidero]

Will add to this, that anything we do in the purchasePackage/Product methods won't happen when they use this view. We should check if there are any other unintended side effects of this. Another one I see is that we would not be calling preventPurchasePopupCallFromTriggeringCacheRefresh so we would never set the offerings cache as stale I think.

[NachoSoto]

When purchasing through this view, does it automatically finish the transaction? Or does the developer still have to do it?

Our SDK handles that :) (though we do need SDK-3170)

If the user purchases an offering through this view, we won't be getting the presentedOfferingIdentifier setup in the SDK... We need to figure out a way to set that.

Oh great call. Just filed SDK-3176 for that.

[NachoSoto]

Will add to this, that anything we do in the purchasePackage/Product methods won't happen when they use this view. We should check if there are any other unintended side effects of this.

I think that's fine. This is basically like our SDK acting in observer mode for a purchase being done from outside.

Another one I see is that we would not be calling preventPurchasePopupCallFromTriggeringCacheRefresh so we would never set the offerings cache as stale I think.

Another reason to do SDK-3172 and get rid of that method.

[NachoSoto]

@tonidero updated this to leave just the overloads, and listed the 3 tasks that need to be done (working on those today)
This is just overloads for SwiftUI so they don't have to wait for those fixes.

[tonidero]

Looks great! As you said we can work on future improvements in other PRs