Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Configuration: log warning if attempting to use observer mode with StoreKit 2 #3066

Merged
merged 1 commit into from
Sep 19, 2023

Conversation

NachoSoto
Copy link
Contributor

@NachoSoto NachoSoto commented Aug 23, 2023

See also RevenueCat/revenuecat-docs#299.

Since #3032 developers using observer mode need to configure the SDK with the correct StoreKit 2 setting.

@NachoSoto NachoSoto added the pr:feat A new feature label Aug 23, 2023
@NachoSoto NachoSoto requested a review from a team August 23, 2023 19:13
NachoSoto added a commit to RevenueCat/revenuecat-docs that referenced this pull request Aug 23, 2023
@codecov
Copy link

codecov bot commented Aug 23, 2023

Codecov Report

Patch coverage: 100.00% and project coverage change: -0.05% ⚠️

Comparison is base (461111b) 85.93% compared to head (5e7f906) 85.89%.
Report is 4 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #3066      +/-   ##
==========================================
- Coverage   85.93%   85.89%   -0.05%     
==========================================
  Files         233      233              
  Lines       16654    16662       +8     
==========================================
  Hits        14312    14312              
- Misses       2342     2350       +8     
Files Changed Coverage Δ
Sources/Misc/Deprecations.swift 37.85% <ø> (ø)
Sources/Purchasing/Purchases/Purchases.swift 76.75% <ø> (ø)
Sources/Logging/Strings/ConfigureStrings.swift 82.88% <100.00%> (+0.31%) ⬆️
Sources/Purchasing/Configuration.swift 82.07% <100.00%> (+1.07%) ⬆️

... and 5 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Contributor

@tonidero tonidero left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering about whether we need to undeprecate the storekit 2 setting... But I understand linking observer mode to the storeKit2 setting, so I think this is probably better

self.observerMode = observerMode
self.storeKit2Setting = .init(useStoreKit2IfAvailable: storeKit2)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering whether we really need to keep useStoreKit2IfAvailable deprecated... Considering we still need to use it here. Also, devs can potentially do .with(observerMode: false, storeKit2: true), to bypass the deprecation and achieve the same result, so it's pretty much as if it wasn't deprecated...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering whether we really need to keep useStoreKit2IfAvailable deprecated...

@aboedo and I talked about this yesterday. We think it makes sense to keep it deprecated until we finish supporting SK2 in the backend, at which point we'll at least be following Apple's guidance.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, devs can potentially do .with(observerMode: false, storeKit2: true)

Yeah maybe the method should have never been .with(observerMode: Bool) but instead .enableObserverMode().

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Feels a little odd to have to select "storekit 2 false" now, like, I'm not sure that tells you all that much about what's happening.

How about

enum StoreKitVersion {
    case StoreKit1, StoreKit2
}

.with(observerMode: Bool, storeKitVersion: StoreKitVersion) -> Builder {

(well, with changes for objc compatibility for the enum and stuff)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't that the same for usesStoreKit2IfAvailable? We made that a Bool too.
While we're at it, we could add an overload of that one to use this new enum. What do you think?

Copy link
Member

@aboedo aboedo Aug 24, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wouldn't add a new API that's already deprecated when we add it.
I was only suggesting that

.with(observerMode: false, storeKitVersion: storeKit1)

might be slightly more expressive than

.with(observerMode: false, storeKit2: false)

But I don't feel strongly about it

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That way the docstring can read something like

* Set `observerMode` with a corresponding `StoreKit` implementation
* - Parameter storeKitVersion: Set this to the StoreKit implementation 
* your app uses for purchases. 
* I.e.: if your app uses StoreKit 1, set it to `.storeKit1`, 
* and if your app uses StoreKit 2, set it to `.storeKit2`. 
* Apps using StoreKit 1 use `SKPaymentQueue` for transactions, 
* whereas StoreKit 2 uses `StoreKit.Product.Purchase`. 

Added some more text in case folks don't know which is which. Apple removed many of the SK1 docs, so I think it's likely that folks will start getting confused about this over time as SK1 slowly fades away

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd avoid adding a new enum + docs + Obj-C equivalent etc just for one API.
But I do think it makes sense to change the deprecated method (which arguably won't be once we fully support SK2) to use it as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@aboedo changed!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd avoid adding a new enum + docs + Obj-C equivalent etc just for one API.
But I do think it makes sense to change the deprecated method (which arguably won't be once we fully support SK2) to use it as well.

I missed this comment but that makes a lot of sense

@@ -129,9 +129,23 @@ import Foundation
* Set `observerMode`.
* - Parameter observerMode: Set this to `true` if you have your own IAP implementation and want to use only
* RevenueCat's backend. Default is `false`.
*
* - Note: This assumes your IAP implementation uses StoreKit 1.
* If you use StoreKit 2, use ``with(observerMode:storeKit2:)`` instead.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we should deprecate this method and ask people to use the other one to make it more explicit...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that would be a good way to notify developers that are currently using this function

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I'll do that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

Copy link
Member

@aboedo aboedo Aug 30, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If a developer is currently using this function, it's almost certain that they're using SK1, though, right? Like, it seems fairly unlikely that you:

  • have an existing SK1 implementation that you don't want to touch, but you want RC, so you add observer mode
  • decide that you do want to move into SK2, but still want to keep RC in observer mode

Right?

So I'd vote to just keep it without deprecation

@@ -129,9 +129,23 @@ import Foundation
* Set `observerMode`.
* - Parameter observerMode: Set this to `true` if you have your own IAP implementation and want to use only
* RevenueCat's backend. Default is `false`.
*
* - Note: This assumes your IAP implementation uses StoreKit 1.
* If you use StoreKit 2, use ``with(observerMode:storeKit2:)`` instead.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that would be a good way to notify developers that are currently using this function

@NachoSoto NachoSoto changed the title Configuration: added observerMode overload that allows configuring SK2 setting Configuration: changed observerMode method to select SK2 setting Aug 24, 2023
@available(*, deprecated)
func checkDeprecatedConfiguration(_ builder: Configuration.Builder) {
_ = builder
.with(usesStoreKit2IfAvailable: false)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was missing from the API tester.

@NachoSoto NachoSoto requested a review from aboedo August 24, 2023 18:59
Sources/Misc/Deprecations.swift Outdated Show resolved Hide resolved
self.observerMode = observerMode
self.storeKit2Setting = .init(useStoreKit2IfAvailable: storeKit2)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That way the docstring can read something like

* Set `observerMode` with a corresponding `StoreKit` implementation
* - Parameter storeKitVersion: Set this to the StoreKit implementation 
* your app uses for purchases. 
* I.e.: if your app uses StoreKit 1, set it to `.storeKit1`, 
* and if your app uses StoreKit 2, set it to `.storeKit2`. 
* Apps using StoreKit 1 use `SKPaymentQueue` for transactions, 
* whereas StoreKit 2 uses `StoreKit.Product.Purchase`. 

Added some more text in case folks don't know which is which. Apple removed many of the SK1 docs, so I think it's likely that folks will start getting confused about this over time as SK1 slowly fades away

@NachoSoto NachoSoto force-pushed the observer-mode-parameter branch 2 times, most recently from 2b43259 to af0ea6c Compare August 29, 2023 20:10
@NachoSoto NachoSoto requested a review from aboedo August 29, 2023 20:11
@NachoSoto
Copy link
Contributor Author

Planning to ship this with the paywalls release since they both require a minor.

@NachoSoto
Copy link
Contributor Author

Updated this per our conversation:

  • Not deprecated .with(observerMode:)
  • Not deprecated .with(observerMode:usesStoreKit2:)
  • Deprecated .with(usesStoreKit2IfAvailable:)

@NachoSoto NachoSoto changed the title Configuration: changed observerMode method to select SK2 setting Configuration: new .with(observerMode:storeKitVersion:) Aug 31, 2023
@@ -400,7 +400,7 @@ extension CustomerInfo {

public extension Configuration.Builder {

/// Set `usesStoreKit2IfAvailable`. If `true`, the SDK will use StoreKit 2 APIs internally. If disabled, it will use StoreKit 1 APIs instead.
/// Set `storeKit2Setting`. If `true`, the SDK will use StoreKit 2 APIs internally. If disabled, it will use StoreKit 1 APIs instead.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the name of the property in Configuration.Builder.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we use double backticks to create a code reference then, so mismatches get caught at the docs generation step?

@NachoSoto NachoSoto added the HOLD label Aug 31, 2023
@NachoSoto
Copy link
Contributor Author

Changing this since we can't support observer mode + SK2.

@NachoSoto NachoSoto changed the title Configuration: new .with(observerMode:storeKitVersion:) Configuration: log warning if attempting to use observer mode with StoreKit 2 Sep 14, 2023
@NachoSoto NachoSoto assigned NachoSoto and unassigned NachoSoto Sep 14, 2023
@NachoSoto NachoSoto added refactor and removed HOLD pr:feat A new feature labels Sep 14, 2023
@NachoSoto NachoSoto force-pushed the observer-mode-parameter branch 2 times, most recently from 4fd073c to 17fce11 Compare September 14, 2023 19:20
…StoreKit 2

See also RevenueCat/revenuecat-docs#299.

Since #3032 developers using observer mode need to configure the SDK with the correct StoreKit 2 setting.
This new API makes that explicit, while leaving `with(usesStoreKit2IfAvailable:)` still deprecated.
@slavasemeniuk
Copy link

slavasemeniuk commented Sep 18, 2023

Changing this since we can't support observer mode + SK2.

Hey, is there any insights on availability of SK 2 support for the observer mode?

Also is there any way to just manually call something like ‘trackPurchase(transaction)’?

Thanks

@NachoSoto
Copy link
Contributor Author

Also is there any way to just manually call something like ‘trackPurchase(transaction)’?

@slavasemeniuk
We are indeed looking into adding that exact API in our continuous effort to better support StoreKit 2 :)

Copy link
Member

@aboedo aboedo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we plan on doing the syncObserverModePurchase thing? Is this an intermediate step?

@@ -400,7 +400,7 @@ extension CustomerInfo {

public extension Configuration.Builder {

/// Set `usesStoreKit2IfAvailable`. If `true`, the SDK will use StoreKit 2 APIs internally. If disabled, it will use StoreKit 1 APIs instead.
/// Set `storeKit2Setting`. If `true`, the SDK will use StoreKit 2 APIs internally. If disabled, it will use StoreKit 1 APIs instead.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we use double backticks to create a code reference then, so mismatches get caught at the docs generation step?

@NachoSoto
Copy link
Contributor Author

do we plan on doing the syncObserverModePurchase thing? Is this an intermediate step?

Yup that's the plan (@MarkVillacampa do you think you can take on that? I think you're pretty familiar with the setup now, and I'm happy to support you in the process :))

This is an intermediate step. Once the API is available we can remove the warning and update the documentation

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants