Paywalls manually handle purchases, finishTransactions/ObserverMode -> PurchasesAreCompletedBy #3917

joshdholtz · 2024-05-24T17:13:22Z

Motivation

Allow developers who have their own purchase logic with StoreKit to use our paywalls.
Adds a new API purchasesAreCompletedBy: PurchasesAreCompletedBy to Purchases, which replaces finishTransactions, and observerMode which have been marked as deprecated (public APIs only).
Internal references to finishTransactions and observerMode will be done as a separate PR.

Todo

Update any doc on new method to make sure its SUPER CLEAR on what its doing and that it will only work if finishTransactions (trying to not call it observer mode) is disabled
Maybe add some debug logs so developer knows which path paywalls purchase buttons are taking if finish transaction is disabled
Fix broken unit/integration tests
Add new tests
Add new API tests
Also add a similar method for handleRestore()

Description

Adds new . handlePurchaseAndRestore modifier that can be used to complete purchases initiated via a paywall:

.handlePurchaseAndRestore(
    performPurchase: { storeProduct, purchaseResultReporter in
        // make purchase for `storeProduct`
        
        // report result to RevenueCat
        purchaseResultReporter.reportResult(userCancelled: false, error: nil)
    }, performRestore: { restoreResultReporter in
        // restore purchases

        // report result to RevenueCat
        restoreResultReporter.reportResult(success: true, error: nil)
    })

RevenueCat-Danger-Bot · 2024-05-24T17:13:50Z

	1 Message
📖	Size increase: 22.06 KB

Generated by 🚫 Danger

…to paywalls-manually-handle-purchases

To enable useful code completion.

…ndler`

RevenueCatUI/Purchasing/PaywallPurchasesType.swift

jamesrb1 · 2024-05-31T23:04:59Z

RevenueCatUI/View+PurchaseRestoreCompleted.swift

+        content
+            .onPreferenceChange(HandleRestorePreferenceKey.self) { restoreResultReporter in
+                if let restoreResultReporter {
+                    self.handler(restoreResultReporter)


The restore method, which is called here, does not provide any information, just a callback which the user can report if it succeeded or not, plus an error. An implementation looks like this:

}, performRestore: { restoreResultReporter in // restore purchases // report result to RevenueCat restoreResultReporter.reportResult(success: true, error: nil) })

I'm unsure if this is correct, and if we are able to or need to create a correct "CustomerInfo" object after this?

I think this is fine! But @aboedo would know for sure 😊

I'm a bit lost on the context, but ideally restore gives you the latest customer info when it's done

Here it's the app developer performing the restore operation (because purchasesAreCompletedBy == .myApp), but all they give us back is if the restore succeeded or not (and any associated error). Is that sufficient?

It's the code block in my first comment that is the focus here (but this doesn't appear in the PR because that code would be customer code, so I commented on the code that triggers it instead, which is probably confusing!).

ohh I see, now I understand the initial question, then. Yes, we'd be able to create a CustomerInfo - assuming the SDK is configured (which I'm guessing it is, otherwise it would crash 😅). We would have to internally call syncPurchases however if we want CustomerInfo to reflect stuff that the user might have done

Ah OK then I will need to add that! And we should do the same after a purchase then too?

It should be only for restores - a purchase should still trigger activity in the SK1 queue, which we'll observe, and in SK2 we check purchases after the app comes back into foreground, which should also work.

restores are a bit of a special case because nothing actually happens in the queue - when you restore using RC, we just fetch the receipt and send it to the backend

Perfect, thank you!! 🙏

joshdholtz

This looks sooooooo good! Just a few nits and then this will be shipshape 🚢

RevenueCatUI/Data/Strings.swift

RevenueCatUI/Purchasing/PurchaseHandler.swift

RevenueCatUI/View+PurchaseRestoreCompleted.swift

Co-authored-by: Josh Holtz <[email protected]>

to catch new cases

…CompletedBy`.

joshdholtz

Looking real good! A few really small nits but this is look ship shape 💪 🚢

RevenueCatUI/Purchasing/PurchaseHandler.swift

RevenueCatUI/View+PurchaseRestoreCompleted.swift

joshdholtz · 2024-06-07T01:42:26Z

RevenueCatUI/View+PurchaseRestoreCompleted.swift

+        content
+            .onPreferenceChange(HandleRestorePreferenceKey.self) { restoreResultReporter in
+                if let restoreResultReporter {
+                    self.handler(restoreResultReporter)


I think this is fine! But @aboedo would know for sure 😊

joshdholtz · 2024-06-07T01:43:35Z

Sources/Purchasing/Configuration.swift

@@ -143,12 +151,26 @@ import Foundation
         * RevenueCat's backend. Default is `false`.
         *
         * - Warning: This assumes your IAP implementation uses StoreKit 1.
-         * Observer mode is not compatible with StoreKit 2.
+         * `.myApp` is not compatible with StoreKit 2.


I think this will end up changing when this gets rebased by 5.0-dev branch, right? 🤔 cc: @fire-at-will @MarkVillacampa

Yep we'll change this when it gets rebased.

You can keep it, that way we'll surely notice when we get a conflict 😄

Co-authored-by: Josh Holtz <[email protected]>

…om/RevenueCat/purchases-ios into paywalls-manually-handle-purchases

aboedo · 2024-06-07T17:31:56Z

RevenueCatUI/Data/Strings.swift

+
+        case .executing_external_purchase_logic:
+            return "Will execute custom StoreKit purchase logic provided by your app. " +
+            "No StoreKit purchasing logic will be performed by RevenueCat. " +


This seems a bit misleading to me - a lot of StoreKit purchasing logic will be performed by RevenueCat regardless. We still fetch products, post receipts, etc, right?
The only real change is that we won't finish transactions. I realize that that might not be a concept that a user grasps all that well, but then again, we're assuming that this developer has a full StoreKit implementation of their own, so it feels reasonable that they could figure out what finishing transactions is?

How about something like

Initiating a purchase for product <product_id>. Note that the StoreKit purchasing logic will be provided by your app and not RevenueCat, since the SDK was configured to blah blah blah.

I think my confusion here is regarding exactly what StoreKit logic is outsourced to our customer's app.

This:

Will execute custom StoreKit purchase logic provided by your app. No StoreKit purchasing logic will be performed by RevenueCat.

sounds the same to me as:

the StoreKit purchasing logic will be provided by your app and not RevenueCat

The only real change is that we won't finish transactions, but when purchasesAreCompletedBy is .myApp, we don't call into PurchasesOrchestrator.purchase(product:package:completion:) - is this part of finishing transactions?

I think what matters most is that someone who has written or is going to write their own StoreKit interfacing code understands exactly what they are now responsible for. Should we list the StoreKit API calls we no longer call? I'm a bit concerned that unless we're crystal clear, there may be confusion on the customer's side too.

Yeah, that was my specific concern as well - we need to make it clear that you need to finish transactions.
That's really the only important part.

Finishing transactions happens specifically when we detect a purchase, then post it to the backend, and receive a response from the backend.

So even if you don't go through the purchase method, we can still detect the purchase, and that's when we finish transactions (unless this mode is enabled).

It'd be finishTransaction in SK1, transaction.finish() in SK2

aboedo · 2024-06-07T17:35:50Z

RevenueCatUI/Data/Strings.swift

+        case .executing_external_restore_logic:
+            return "Will execute custom StoreKit restore purchases logic provided by your app. " +
+            "No StoreKit restore purchases logic will be performed by RevenueCat. " +


Will execute custom StoreKit restore purchases logic provided by your app. No StoreKit restore purchases logic will be performed by RevenueCat.

Doesn't quite roll off the tongue, right? It took me a couple of reads to understand this. Maybe we can simplify it a bit?

how about something like:

Suggested change

case .executing_external_restore_logic:

return "Will execute custom StoreKit restore purchases logic provided by your app. " +

"No StoreKit restore purchases logic will be performed by RevenueCat. " +

case .executing_external_restore_logic:

return "Initiating a restore. Note that the restore logic will be provided by your app and not RevenueCat, since the SDK was configured to blah blah blah...

I feel the word "Initiating" could mean that it is doing actual restore work. What do you think of "Requesting"?

But even "Requesting" - requesting to whom? It needs to be clear it's of the app (not StoreKit). 🤔

"The user has requested a restore. Note that the restore logic will be provided by your app and not RevenueCat, since the SDK was configured to blah blah blah..." ?

ohh I like that

aboedo · 2024-06-07T17:40:07Z

RevenueCatUI/Purchasing/PurchaseHandler.swift

+    func restorePurchases() async throws -> (info: CustomerInfo, success: Bool) {
+        switch self.purchases.purchasesAreCompletedBy {
+        case .revenueCat:
+            return try await performRestorePurchases()
+        case .myApp:
+            return try await performExternalRestoreLogic()
+        }


curious about how this works - is the SDK still getting configured in this scenario, and observing queue / delegates?

When purchasesAreCompletedBy equals .revenueCat, there is no change in behavior. When purchasesAreCompletedBy equals .myApp, all behavior is as it was when observerMode was set to true (so I assume this means the answer to your questions about configuration/queues/delegates is "yes"). The change here, which is an addition, is that when someone taps restore on one of our paywalls, the app developer will get a callback via a view modifier that allows them to know this happened and execute their own restore code.

Does that answer everything?

makes sense. What happens if I set it up as "purchases completed by my app" but I don't set up the view modifiers?

You'll see a log message in the console that an external purchase/restore has started (we are discussing the exact wording needed in this PR), but if you haven't set up the view modifiers, there will be no error. I tried to think of a good way of detecting this but couldn't, short of setting up a hacky singleton. Discussed somewhere briefly with Josh, did not come to any solution for this. I'll look at this again, it would be a lot better if it actually could identify the bad state....

honestly it feels like the way that this is usually solved is that instead of "purchases completed by my app", you provide a delegate.
If delegate exists, we call it. If not, we use our own logic. That way you can't possibly set it up wrong, right?

Had a huddle about this with Andy, we are considering moving from view modifiers to a new initializer, to be continued next week. I'm going to separate out the API change so that these discussions don't hold up other projects.

That makes sense to me! 💪

aboedo · 2024-06-07T17:45:21Z

RevenueCatUI/View+PurchaseRestoreCompleted.swift

+        content
+            .onPreferenceChange(HandleRestorePreferenceKey.self) { restoreResultReporter in
+                if let restoreResultReporter {
+                    self.handler(restoreResultReporter)


ohh I see, now I understand the initial question, then. Yes, we'd be able to create a CustomerInfo - assuming the SDK is configured (which I'm guessing it is, otherwise it would crash 😅). We would have to internally call syncPurchases however if we want CustomerInfo to reflect stuff that the user might have done

joshdholtz · 2024-07-18T14:37:20Z

Closing since implement since #3973

joshdholtz added 2 commits May 24, 2024 16:07

Initial commit

2538c2a

Paywalls - Allow developers to handle purchase logic

4b3d0e7

joshdholtz added the pr:feat A new feature label May 24, 2024

jamesrb1 added 24 commits May 27, 2024 13:46

Merge branch 'main' of https://github.com/RevenueCat/purchases-ios in…

d914925

…to paywalls-manually-handle-purchases

Use HandlePurchaseComplete directly

1e3b3f8

To enable useful code completion.

Rename callback; Better documentation

472a177

Debug log

fb29c58

Fix tests; make finishTransactions configurable in mock `PurchaseHa…

6a383dc

…ndler`

Remove foundation import

839d83a

Test PaywallView().handlePurchase { … }

1ee8110

WIP handle external restore logic

18a6db3

Missing from last commit

a5214c8

Only call restore once!

f642ffa

No need to be optional

95cafb7

No need for explicit initializer

52faa87

Ability to pass restore result back

3a282e8

Better error handling

e5e0e07

Naming

2244b8e

correct label

094722c

Test restore

1b8390a

Documentation

3cdc95f

More logging

8532e33

Linting

b7adeb0

Code organization

9d7099e

Tweaks

c205d5f

Lint

45b4425

Update test method name

534cc83

jamesrb1 reviewed May 30, 2024

View reviewed changes

RevenueCatUI/Purchasing/PaywallPurchasesType.swift Outdated Show resolved Hide resolved

Change name from finishTransactions to purchasesAreCompletedBy

122d2c2

jamesrb1 added 2 commits May 31, 2024 15:41

Documentation

be0b23b

More documentation

0bfa9db

jamesrb1 reviewed May 31, 2024

View reviewed changes

joshdholtz commented Jun 5, 2024

View reviewed changes

jamesrb1 and others added 7 commits June 6, 2024 14:41

Code review doc fixes

b43f77e

Co-authored-by: Josh Holtz <[email protected]>

if -> switch

7da678d

to catch new cases

Move defer

5aa3730

Remove public access modifier

604ea4f

Add error logging if callback is nil

ce8b8e0

Deprecate observerMode from public APIs, replace with `purchasesAre…

40c0685

…CompletedBy`.

Return pre-processor marker

bd7bbf3

jamesrb1 marked this pull request as ready for review June 7, 2024 00:33

jamesrb1 requested review from a team June 7, 2024 00:35

jamesrb1 changed the title ~~[WIP] Paywalls manually handle purchases~~ Paywalls manually handle purchases, finishTransactions/ObserverMode -> PurchasesAreCompletedBy Jun 7, 2024

jamesrb1 added 2 commits June 6, 2024 17:52

fix preprocessor

f30bd1f

Add API tests

ef9526f

joshdholtz commented Jun 7, 2024

View reviewed changes

jamesrb1 and others added 8 commits June 6, 2024 20:12

Documentation wording

1df2679

Co-authored-by: Josh Holtz <[email protected]>

Obj-C API Tests

256a450

Merge branch 'paywalls-manually-handle-purchases' of https://github.c…

37b3cb9

…om/RevenueCat/purchases-ios into paywalls-manually-handle-purchases

Lint

f12f20e

Fix unit tests

6911c38

Fix build (I guess our build machines use old versions of Swift?)

faf226b

More old swift compatibility

07ef349

CustomEntitlementComputation API Tester update

b2fc2e2

aboedo reviewed Jun 7, 2024

View reviewed changes

jamesrb1 mentioned this pull request Jun 12, 2024

[WIP] Paywalls manually handle purchases init based #3954

Closed

joshdholtz closed this Jul 18, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Paywalls manually handle purchases, finishTransactions/ObserverMode -> PurchasesAreCompletedBy #3917

Paywalls manually handle purchases, finishTransactions/ObserverMode -> PurchasesAreCompletedBy #3917

joshdholtz commented May 24, 2024 •

edited by jamesrb1

Loading

RevenueCat-Danger-Bot commented May 24, 2024 •

edited

Loading

jamesrb1 May 31, 2024

joshdholtz Jun 7, 2024

aboedo Jun 7, 2024

jamesrb1 Jun 7, 2024

jamesrb1 Jun 7, 2024 •

edited

Loading

aboedo Jun 7, 2024

jamesrb1 Jun 7, 2024

aboedo Jun 7, 2024

aboedo Jun 7, 2024

jamesrb1 Jun 7, 2024

joshdholtz left a comment

joshdholtz left a comment

joshdholtz Jun 7, 2024

joshdholtz Jun 7, 2024

MarkVillacampa Jun 7, 2024

aboedo Jun 7, 2024

aboedo Jun 7, 2024

jamesrb1 Jun 7, 2024

aboedo Jun 7, 2024

aboedo Jun 7, 2024

jamesrb1 Jun 7, 2024

jamesrb1 Jun 7, 2024

jamesrb1 Jun 7, 2024

aboedo Jun 7, 2024

aboedo Jun 7, 2024

jamesrb1 Jun 7, 2024

aboedo Jun 7, 2024

jamesrb1 Jun 7, 2024

aboedo Jun 7, 2024

jamesrb1 Jun 7, 2024

joshdholtz Jun 7, 2024

aboedo Jun 7, 2024

joshdholtz commented Jul 18, 2024 •

edited

Loading

Paywalls manually handle purchases, finishTransactions/ObserverMode -> PurchasesAreCompletedBy #3917

Paywalls manually handle purchases, finishTransactions/ObserverMode -> PurchasesAreCompletedBy #3917

Conversation

joshdholtz commented May 24, 2024 • edited by jamesrb1 Loading

Motivation

Todo

Description

RevenueCat-Danger-Bot commented May 24, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jamesrb1 Jun 7, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

joshdholtz left a comment

Choose a reason for hiding this comment

joshdholtz left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

joshdholtz commented Jul 18, 2024 • edited Loading

joshdholtz commented May 24, 2024 •

edited by jamesrb1

Loading

RevenueCat-Danger-Bot commented May 24, 2024 •

edited

Loading

jamesrb1 Jun 7, 2024 •

edited

Loading

joshdholtz commented Jul 18, 2024 •

edited

Loading