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

[WIP] Multi-tier Paywall #3887

Draft
wants to merge 49 commits into
base: 5.0-dev
Choose a base branch
from
Draft

[WIP] Multi-tier Paywall #3887

wants to merge 49 commits into from

Conversation

joshdholtz
Copy link
Contributor

@joshdholtz joshdholtz commented May 13, 2024

⚠️ WIP ⚠️

Motivation

Coming soon

Description

  • Changed colorOverridesByTier to colorsByTier
    • No overriding behavior anymore
  • Changed imageOverridesByTier to imagesByTier
    • No overriding behavior anymore

MarkVillacampa and others added 30 commits April 15, 2024 15:46
…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()
```
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.
The word `StoreKit` was unnecessarily duplicated.
…ting` (#3663)

This will be used for multi-tier paywalls.
`PaywallData.packages` won't be used by multi-tier paywalls, so we need
to allow that.
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.

![simulator_screenshot_E024C30D-F7D3-4022-9FB3-5C4860DCB3ED](https://github.com/RevenueCat/purchases-ios/assets/685609/e167d524-fb08-4790-a15a-1cc4327eaacd)
`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
MarkVillacampa and others added 17 commits April 15, 2024 16:03
…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
Co-authored-by: James Borthwick <109382862+jamesrb1@users.noreply.github.com>
@RevenueCat-Danger-Bot
Copy link

RevenueCat-Danger-Bot commented May 13, 2024

1 Error
🚫 This PR increases the size of the repo by more than 250.00 KB (increased by 308.96 KB).
1 Message
📖 You can bypass the size check failure by adding the label "danger-bypass-size-limit". Please exercise caution.

Generated by 🚫 Danger

@joshdholtz joshdholtz added the feat A new feature label May 13, 2024
@@ -24,11 +24,9 @@ struct UpsellView: View {
requiredEntitlementIdentifier: Configuration.entitlement,
purchaseStarted: { _ in
print("Purchase started")
},
purchaseCompleted: { _ in
}, purchaseCompleted: { customerInfo in
Copy link
Member

Choose a reason for hiding this comment

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

customerInfo can still be ignored here?

Suggested change
}, purchaseCompleted: { customerInfo in
}, purchaseCompleted: { _ in

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

Successfully merging this pull request may close these issues.

None yet

7 participants