[v5 migration guide] simplified observer mode configuration calls #3855
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…n of StoreKit to use (#3487) This PR introduces a new configuration option to select the StoreKit version to use. It supersedes the deprecated `.with(usesStoreKit2IfAvailable: true)` and the internal `usesStoreKit2JWS` configuration options. Uses JWS tokens instead of SK1 receipts when in StoreKit 2 mode where applicable. Example usage: ```swift Purchases.configure( with: .builder(withAPIKey: apiKey) .with(storeKitVersion: .storeKit2) .build() ```
We already set this for SK1 purchases: https://github.com/RevenueCat/purchases-ios/blob/daa0e1f3d0b8eaf653d81ef99396caa2a5e95506/Sources/Purchasing/Purchases/PurchasesOrchestrator.swift#L385 However, as explained in the documentation, if this value is not a UUID, it basically gets ignored: https://developer.apple.com/documentation/storekit/skmutablepayment/1506088-applicationusername This PR makes sure we do the equivalent in SK2 purchases.
Default to StoreKit 1 when enabling observer mode.
[`Carthage` cannot build fat `.framework`s on Apple Silicon](https://github.com/Carthage/Carthage?tab=readme-ov-file#migrating-a-project-from-framework-bundles-to-xcframeworks): > require `XCFrameworks` when building on an Apple Silicon Mac It fails with this error: > RevenueCat have the same architectures (arm64) and can't be in the same fat output file To address that, we're planning to remove these on the next major release. Instead, `.xcframework`s, SPM, or CocoaPods should be used.
Fixes #3031. Depends on #3582. See also bielikb/fastlane-plugin-create_xcframework#21
See https://github.com/RevenueCat/purchases-ios/blob/1fd2736217c94ec025f5e44724f978505f4a84c0/Contributing/UpdatingRequirements.md ### After this PR: - #3616 - Update deployment target on PHC and hybrids - Update https://github.com/RevenueCat/revenuecat-docs/blob/main/docs_source/Getting%20Started/installation/ios.md - Update https://github.com/RevenueCat/revenuecat-docs/blob/main/docs_source/Getting%20Started/installation/macos.md
Follow up to #3615. 
The word `StoreKit` was unnecessarily duplicated.
…ting` (#3663) This will be used for multi-tier paywalls.
This will allow the implementation of _color overrides_ by tier for the upcoming multi-tier paywall.
This is a breaking change required to support multi-tier paywalls. Instead of failing to decode `PaywallData`, this is now validated when processing the data before displaying the paywall.
This will be used for multi-tier paywalls.
This adds `TemplatePackageSetting.multiTier` and `TemplateViewConfiguration.PackageConfiguration.multiTier`.
This is useful for implementing custom paywalls using `.footerPaywall` and responding to the tier selected in a paywall. 
`PurchasesOrchestratorTests.swift` was getting too big and hard to understand. I've made a first pass at splitting the tests in three files: `PurchasesOrchestratorSK1Tests.swift`: Tests related to StoreKit 1 `PurchasesOrchestratorSK2Tests.swift`: Tests related to StoreKit 2 `PurchasesOrchestratorCommonTests.swift`: Tests related to both versions of StoreKit My plan is to further clean and organize the tests but I wanted to first split them as they are, without changing any test.
Coming from #3695 where we first split `PurchasesOrchestratorTests.swift` into multiple files: `PurchasesOrchestratorSK1Tests.swift`: Tests related to StoreKit 1 `PurchasesOrchestratorSK2Tests.swift`: Tests related to StoreKit 2 `PurchasesOrchestratorCommonTests.swift`: Tests related to both versions of StoreKit To further organize and improve PurchasesOrchestrator Tests, now that we have gotten rid of the old SK2 flag/implementation that mixed some of SK1 and SK2, we need to define a clear list of tests and have separate implementations for SK1 and SK2. For that, I have defined the `PurchasesOrchestratorTests` protocol which includes a list of tests both `PurchasesOrchestratorSK2Tests` and `PurchasesOrchestratorSK1Tests` must implement. Furthermore, tests specific to one version of StoreKit can be implemented in its corresponding file without adding a method to the protocol. Will be leaving inline comments as self-review and to add further context to the changes.
We can use any transaction token available, not only auto-renewable ones
…ase (#3711) <!-- Thank you for contributing to Purchases! Before pressing the "Create Pull Request" button, please provide the following: --> ### Checklist - [ ] If applicable, unit tests - [ ] If applicable, create follow-up issues for `purchases-android` and hybrids ### Motivation <!-- Why is this change required? What problem does it solve? --> <!-- Please link to issues following this format: Resolves #999999 --> ### Description <!-- Describe your changes in detail --> <!-- Please describe in detail how you tested your changes -->
### Motivation `onChangeOf` was accidentally made public in #3517 ### Description - Change scope of `onChangeOf` from `public` to `internal` - Added breaking change in v5 migration doc
…-main-5.0-dev-2024-04-18
Merge `main` -> `5.0-dev` 2024-04-18
simplified a couple of calls to configuration methods in the migration guide
Generated by 🚫 Danger |
fire-at-will
requested changes
Apr 29, 2024
There was a problem hiding this comment.
I made a small change, but otherwise looks good to me!
We should consider adding a configure function with the signature Purchases.configure(withAPIKey:observerMode:storeKitVersion:) - it makes a lot of sense to use observer mode with anonymous users and it'd be nice to do that without using the builder configure function.
| Purchases.configure(with: .builder(withAPIKey: apiKey) | ||
| .with(observerMode: true, storeKitVersion: .storeKit2) | ||
| .build() | ||
| Purchases.configure(withAPIKey: apiKey, observerMode: true, storeKitVersion: .storeKit2) |
There was a problem hiding this comment.
We don't currently have a configure function with this signature - currently if you want to use observerMode with this type of configure function you need to provide an appUserID. Perhaps we should add a configure function with this signature in the future, but for now this won't build.
FWIW, you can configure observer mode without an appUserID, but you need to use the builder pattern:
Purchases.configure(with: .builder(withAPIKey: apiKey)
.with(observerMode: true, storeKitVersion: .storeKit2)
.build()
)
Suggested change
| Purchases.configure(withAPIKey: apiKey, observerMode: true, storeKitVersion: .storeKit2) | |
| Purchases.configure(withAPIKey: apiKey, appUserID: appUserID, observerMode: true, storeKitVersion: .storeKit2) |
| Purchases.configure(with: .builder(withAPIKey: apiKey) | ||
| .with(observerMode: true, storeKitVersion: .storeKit1) | ||
| .build() | ||
| Purchases.configure(withAPIKey: apiKey, observerMode: true, storeKitVersion: .storeKit1) |
There was a problem hiding this comment.
Suggested change
| Purchases.configure(withAPIKey: apiKey, observerMode: true, storeKitVersion: .storeKit1) | |
| Purchases.configure(withAPIKey: apiKey, appUserID: appUserID, observerMode: true, storeKitVersion: .storeKit1) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
simplified a couple of calls to configure the SDK in the migration guide