-
Notifications
You must be signed in to change notification settings - Fork 3
Update SwiftUI doc to reflect mock products for previews #276
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yesss 😍
code_blocks/📙 Platform Resources/apple-platform-resources/swiftui-app-lifecycle_1.swift
Outdated
Show resolved
Hide resolved
|
||
The Purchases SDK includes a debug overlay that allows developers to see various configuration details while running an app. You can read more about the debug overlay in our [Debugging](https://www.revenuecat.com/docs/debugging#debug-ui) guide. | ||
|
||
# SwiftUI Previews |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome 👍🏻
Previewstemp/how-grace-periods-work.md See contentsIf a customer is unable to complete their purchase due to an invalid or expired payment method, supported stores offer an optional grace period. Grace periods allow the customer to retain access to their subscription purchase for a short period of time while the store attempts to renew the subscription. This prevents disruption for paid features, and can improve the user experience for your app. Grace Periods are optional and customizable on certain platforms.
Encountering Billing IssuesAs mentioned, billing issues occur when a user is unable to complete a subscription purchase due to an invalid or expired payment method. When this occurs, RevenueCat sends a RevenueCat will only send one billing issue event -- additional payment failures won't trigger additional billing issue events, unless a renewal is successful between payment failures or the subscription ends and is restarted. SDK PromptStarting in iOS 16.4+, a system-sheet will automatically be displayed if a user encounters a billing issue, with a prompt for the customer to update their payment method. You can test this behavior by following Apple's instructions.
Entering a Grace PeriodWhen a subscription enters a grace period, RevenueCat detects the change automatically. Users will retain access to their subscriptions, but we'll immediately send events indicating the subscription has been cancelled. These subscriptions are considered cancelled because they are now past due, but will not be considered expired until the end of their grace period. During this time, a subscription may convert to paid through additional billing attempts from the store or by the customer updating their billing information. API, Events, and WebhooksTo detect grace periods in webhook events, watch for the value of To detect grace periods in the Once a user corrects their payment method, RevenueCat will send a renewal event. This will reset the DashboardCustomers who enter into a grace period will have events added to their Customer History. [block:image] Additionally, subscriptions that are currently in a grace period will still be considered "active," since the customer retains access to their entitlement throughout their grace period. Distinct customers who are currently in a grace period can be counted through Customer Lists using the "Billing Issue Trial" and "Billing Issue" statuses. See contentsRestoring purchases is a mechanism by which your user can restore their in-app purchases, reactivating any content that had previously been purchased from the same store account (Apple, Google, or Amazon). It is recommended that all apps have some way for users to trigger the Purchases.shared.restorePurchases { customerInfo, error in
//... check customerInfo to see if entitlement is now active
} [[RCPurchases sharedPurchases] restorePurchasesWithCompletion:^(RCCustomerInfo *customerInfo, NSError *error) {
//... check customerInfo to see if entitlement is now active
}]; Purchases.sharedInstance.restorePurchasesWith() { customerInfo ->
//... check customerInfo to see if entitlement is now active
} Purchases.getSharedInstance().restorePurchases(new ReceiveCustomerInfoCallback() {
@Override
public void onError(@NonNull PurchasesError error) {
}
@Override
public void onReceived(@NonNull CustomerInfo customerInfo) {
}
}); try {
CustomerInfo customerInfo = await Purchases.restorePurchases();
// ... check restored purchaserInfo to see if entitlement is now active
} on PlatformException catch (e) {
// Error restoring purchases
} try {
const restore = await Purchases.restorePurchases();
// ... check restored purchaserInfo to see if entitlement is now active
} catch (e) {
} Purchases.restorePurchases(
info => {
//... check customerInfo to see if entitlement is now active
},
error => {
// Error restoring purchases
}
); var purchases = GetComponent<Purchases>();
purchases.RestorePurchases((info, error) =>
{
//... check purchaserInfo to see if entitlement is now active
}); The
Transferring purchases seen on multiple App User IDsIf an App User ID tries to restore transactions that are already associated with a different identified App User ID in RevenueCat, you can configure how RevenueCat should respond by changing the dropdown in Project Settings > General in the dashboard: Note that the behavior set here will affect all apps under the project. Also note that Share between App User IDs (legacy) will only be available for legacy projects with this behavior already enabled, not new projects.
Transfer to new App User IDDefault ✅ The default behavior is to transfer purchases between identified App User IDs if needed. This ensures that the customer restoring gets access to any purchased content, but only one customer at a time can have access. For example, if UserA buys a subscription, then UserB logs into your app on the same device and restores transactions, UserB would now have access to the subscription and it would be revoked from UserA. If an identified App User ID restores and the owner of the receipt is anonymous, the anonymous identifiers will be merged (aliased) into the same customer profile in RevenueCat and treated as the same customer going forward. If an anonymous ID restores and the owner of the receipt is an identified App User ID, we will resort to the specified restore behavior and transfer the receipt to the anonymous user. And finally, if an anonymous ID restores and the owner of the receipt is also anonymous, the anonymous identifiers will be merged (aliased). Google Play on AndroidDue to platform limitations, purchases will be transferred as soon as you call This may cause unexpected transfers of purchases between app user IDs, especially for apps with optional logins or users with multiple devices. To prevent this behavior, you should wait to call Transfer if there are no active subscriptionsThis behavior will transfer the purchases to the new App User ID unless they contain an active subscription. This behavior is especially beneficial if you have strict business logic that associate subscriptions with a given App User ID, but you still want churned subscribers who might later return to your app with a new App User ID to start a new subscription. This is especially relevant on iOS, where a receipt contains all purchases associated with a given Apple ID, so in the case of using the behavior "Keep with original App User ID", the customer would be able to start a new subscription on the store, but they would not be able to gain access because RevenueCat would associate that new subscription with the original App User ID (since it is on the same Apple receipt). Note that the presence of one-time (non-subscription) purchases does not prevent transfers from happening. Keep with original App User IDUse with caution 🚧 Returns an error if the App User ID attempting to restore purchase or make a new purchase is different from the original App User ID that made the purchase. This requires customers to sign in with their original App User ID, and is only allowed for apps that require every customer to create an account before purchasing. Share between App User IDs (legacy)Legacy ✅ The legacy behavior is to merge (alias) any App User IDs that restore the same underlying subscription and treat them as the same subscriber moving forward. This applies to both anonymous and identified App user IDs. You can continue to use this legacy behavior as long as you'd like, but you cannot re-enable the alias behavior if you switch to Transfer Purchases or Block Restores. Example usage
Syncing purchases without user interaction
Considerations
Restoring Purchases for Consumables and Non-renewing SubscriptionsConsumables and non-renewing subscriptions can only be restored by using an acount system with custom App User IDs. This is due to these types of in-app purchases not showing up on the underlying store receipt after the transaction is finished. By logging in your users with a custom App User ID, RevenueCat can continue to provide transaction details in a user's CustomerInfo for their previous consumable and non-renewing subscription purchases. Next Steps
|
Motivation / Description
We added support for SwiftUI previews with some mock types a couple of months ago: RevenueCat/purchases-ios#2711
Changes introduced
Refactor existing SwiftUI 'app lifecycle' doc to be more generic about SwiftUI usage
Jira ticket (if any)
Additional comments