merge commit

Author: titerman

src/components/reusable/sharingaccesslevel.md

@@ -4,48 +4,54 @@ no_index: true
 
 <!--- sharingaccesslevel.md --->
 
-**Enabled (default)**
-
-Identified users (those with a [Customer User ID](identifying-users#setting-customer-user-id-on-configuration)) can share the same [access level](https://adapty.io/docs/access-level) provided by Adapty if their device is signed in to the same Apple/Google ID. This is useful when a user reinstalls the app and logs in with a different email — they’ll still have access to their previous purchase. With this option, multiple identified users can share the same access level.
+> Main article: [Sharing paid access between user accounts](sharing-paid-access-between-user-accounts)
 
-Even though the access level is shared, all past and future transactions are logged as events in the original Customer User ID to maintain consistent analytics and keep a complete transaction history — including trial periods, subscription purchases, renewals, and more, linked to the same profile.
+When a user makes a purchase, Adapty assigns a new [access level](access-level) to the active [customer profile](identifying-users).
 
-**Transfer access to new user**
+But the user's customer profile may change — if they reinstall the application, log into a new account, or purchase a new device. How does Adapty ensure that the buyer doesn't lose access to paid content? The **Sharing paid access between user accounts** setting determines Adapty's behavior.
 
-Identified users can keep accessing the [access level](access-level) provided by Adapty, even if they log in with a different [Customer User ID](identifying-users#setting-customer-user-id-on-configuration) or reinstall the app, as long as the device is signed in to the same Apple/Google ID.
+:::important
+If you need to test purchases on a sandbox account, change the setting for [sandbox accounts only](sharing-paid-access-between-user-accounts#sharing-paid-access-on-sandbox).
+:::
 
-Unlike the previous option, Adapty transfers the purchase between identified users. This ensures that the purchased content is available, but only one user can have access at a time. For example, if UserA buys a subscription and UserB logs in on the same device and restores transactions, UserB will gain access to the subscription, and it will be revoked from UserA.
+:::note
+Anonymous user profiles associated with the same store account *always* share their access level, regardless of this setting.
+:::
 
-If one of the users (either the new or the old one) is not identified, the access level will still be shared between those profiles in Adapty.
+**Enabled (default)**
 
-Although the access level is transferred, all past and future transactions are logged as events in the original Customer User ID to maintain consistent analytics and keep a complete transaction history — including trial periods, subscription purchases, renewals, and more, linked to the same profile.
+If the **Sharing paid access between user accounts** setting is on, new customer profiles associated with the same store account will *inherit* the access level of the original. This is the default behavior for Adapty apps.
 
-After switching to **Transfer access to new user**, access levels won’t be transferred between profiles immediately. The transfer process for each specific access level is triggered only when Adapty receives an event from the store, such as subscription renewal, restore, or when validating a transaction.
+* If a user logs into your app with a new set of credentials, they retain access to paid content.
+* If a user reinstalls your application after a factory reset, they retain access to paid content.
+* If a user installs the application on other devices with the same store account, the purchase is made available on all devices. Even if each instance of the application has its own customer profile.
 
-**Disabled**
+This behavior is best for common use cases and store compliance. Do not change it if your app does not have authentication capabilities, and only uses Adapty’s anonymous profiles.
 
-The first identified user profile to get an access level will retain it forever. This is the best option if your business logic requires that purchases be tied to a single Customer User ID.
+**Transfer access to new user**
 
-Note that access levels are still shared between anonymous users.
+If you select this setting, Adapty limits purchase access to 1 customer ID at a time. The device owner can reinstall the app, log in and out, but cannot access the same product from more than one customer ID simultaneously.
 
-You can "untie" a purchase by [deleting the owner’s user profile](ss-delete-profile). After deletion, the access level becomes available to the first user profile that claims it, whether anonymous or identified.
+For example, if a customer downloads your application on a second device, Adapty will transfer paid access privileges to the customer ID associated with the new device. The original device will lose access.
 
-Disabling sharing only affects new users. Subscriptions already shared between users will continue to be shared even after this option is disabled.
+If one of the customer profiles is *anonymous* (not associated with a specific customer ID), the two will continue to share the access level. This is necessary to prevent access loss in applications without mandatory authentication.
 
 :::warning
+When you disable from the default setting, Adapty does not immediately update the access levels of existing customer profiles.
 
-Apple and Google require in-app purchases to be shared or transferred between users because they rely on the Apple/Google ID to associate the purchase with. Without sharing, restoring purchases might not work upon subsequent reinstalls.
+The switch occurs when a user triggers a new store event: for example, renews the subscription, or restores their purchases.
+:::
+
+**Disabled**
 
-Disabling sharing may prevent users from regaining access after logging in.
+If you disable paid access sharing, Adapty ties the product to the active [customer ID](identifying-users#setting-customer-user-id-on-configuration) at the time of the purchase, and does not share these privileges with any other customer profiles. This policy allows for stict 1-to-1 product distribution, but demands mandatory in-app authenticaion.
 
-We recommend disabling sharing only if your users **are required to log in** before they make a purchase. Otherwise, an identified user could buy a subscription, log into another account, and lose access permanently.
-:::
+You need to implement your own authentication logic to make sure that users retain access to their purchases. Select this setting if your app requires customers to create an account before completing a transaction, with strict rules that tie purchases to a single user entity.
 
-### Which setting should I choose?
+:::warning
+If you disable paid access sharing, some users may not be able to restore their purchases.
+
+If your application does not guarantee that the user retains access to their purchases, it may fail the mandatory store review.
+:::
 
-| My app...                                                    | Option to choose                                             |
-| ------------------------------------------------------------ | ------------------------------------------------------------ |
-| Does not have a login system and only uses Adapty’s anonymous profile IDs. | Use the default option, as access levels are always shared between anonymous profile IDs for all three options. |
-| Has an optional login system and allows customers to make purchases before creating an account. | Choose **Transfer access to new user** to ensure that customers who purchase without an account can still restore their transactions later. |
-| Requires customers to create an account before purchasing but allows purchases to be linked to multiple Customer User IDs. | Choose **Transfer access to new user** to ensure that only one Customer User ID has access at a time, while still allowing users to log in with a different Customer User ID without losing their paid access. |
-| Requires customers to create an account before purchasing, with strict rules that tie purchases to a single Customer User ID. | Choose **Disabled** to ensure that transactions are never transferred between accounts. |
+You can transfer the product from one profile to another without sharing paid access. When you [delete a user profile](https://adapty.io/docs/api-adapty#/operations/deleteProfile), Adapty transfers access to the next available profile, whether anonymous or identified.

versioned_docs/version-3.0/general.md

@@ -96,9 +96,7 @@ It is important to consider that the selected option not only affects analytics
 
 Please ensure that you select the designated option that aligns with your desired approach to handling subscription prices for existing subscribers. This will help maintain accurate data and synchronization between Adapty analytics and the results obtained from the App Store Connect.
 
-## 6. Sharing purchases between user accounts
-
-When a <InlineTooltip tooltip="Customer User ID">[iOS](identifying-users#setting-customer-user-id-on-configuration), [Android](android-identifying-users#setting-customer-user-id-on-configuration), [React Native](react-native-identifying-users#setting-customer-user-id-on-configuration), [Flutter](flutter-identifying-users#setting-customer-user-id-on-configuration), and [Unity](unity-identifying-users#setting-customer-user-id-on-configuration)</InlineTooltip> tries to restore transactions or extend a subscription that is already associated with a different identified <InlineTooltip tooltip="Customer User ID">[iOS](identifying-users#setting-customer-user-id-on-configuration), [Android](android-identifying-users#setting-customer-user-id-on-configuration),[React Native](react-native-identifying-users#setting-customer-user-id-on-configuration), [Flutter](flutter-identifying-users#setting-customer-user-id-on-configuration), and [Unity](unity-identifying-users#setting-customer-user-id-on-configuration)</InlineTooltip>, you can control how Adapty responds by adjusting the **Sharing paid access between user accounts** dropdown:
+## 6. Sharing paid access between user accounts
 
 <Sharingaccesslevel />
 

versioned_docs/version-3.0/img/sharing-paid-access.webp

@@ -164,9 +164,7 @@ Why do events show future timestamps in profiles and integrations? Event timesta
 - **Impact on Analytics and Event Feed**: These events will only appear in **Analytics** and the **Event Feed** once their timestamps have passed. Events with future timestamps are not shown in either section.
 - **Impact on Integrations**: Adapty sends events to integrations as soon as they are received. If an event has a future timestamp, it will be shared with your integration exactly as received.
 
-## Sharing access levels between profiles
-
-When a [Customer User ID](identifying-users#setting-customer-user-id-on-configuration) tries to restore transactions or extend a subscription that is already associated with a different identified [Customer User ID](identifying-users#setting-customer-user-id-on-configuration), you can control how Adapty responds by adjusting the **Sharing paid access between user accounts** dropdown in the [Adapty Dashboard -> **App settings** -> **General** tab](https://app.adapty.io/settings/general):
+## Sharing paid access between user accounts
 
 <Sharingaccesslevel />
 

versioned_docs/version-3.0/profiles-crm.md

@@ -355,6 +355,7 @@ See more details on how to finish transactions in the [guide](ios-transaction-ma
 
 ### Clear data on backup restore
 
+<<<<<<< HEAD
 When a user restores their app from an iOS backup, the Adapty SDK can detect this and automatically clear its cached data to start fresh. This prevents potential issues with duplicate profiles and ensures clean analytics data.
 
 Enable this if you want to ensure a fresh SDK state after backup restoration. Keep it disabled (default) if you want to preserve SDK data when users restore from backups.
@@ -363,6 +364,12 @@ To enable automatic data clearing on backup restore, set `clearDataOnBackup` to
 
 :::note
 This only clears the SDK's local cache. The user's actual purchases and subscriptions remain safe and are stored with Apple and in Adapty's servers.
+=======
+When `clearDataOnBackup` is set to `true`, the SDK detects when the app is restored from an iCloud backup and deletes all locally stored SDK data, including cached profile information, product details, and paywalls. The SDK then initializes with a clean state. Default value is `false`.
+
+:::note
+Only local SDK cache is deleted. Transaction history with Apple and user data on Adapty servers remain unchanged.
+>>>>>>> ADP-5209
 :::
 
 ```swift showLineNumbers

versioned_docs/version-3.0/sdk-installation-ios.md

@@ -0,0 +1,83 @@
+---
+title: "Sharing paid access between user accounts"
+description: "Sharing paid access between different user accounts to accomodate users with multiple devices or multiple app profiles"
+metadataTitle: "Sharing paid access between different user accounts to make sure the user doesn't lose access to purchases | Adapty Docs"
+---
+
+import Zoom from 'react-medium-image-zoom';
+import 'react-medium-image-zoom/dist/styles.css';
+
+When a user makes a purchase, Adapty assigns a new [access level](access-level) to the active [customer profile](identifying-users).
+
+But the user's customer profile may change — if they reinstall the application, log into a new account, or purchase a new device. How does Adapty ensure that the buyer doesn't lose access to paid content?
+
+If the **Sharing paid access between user accounts** setting is on, new customer profiles associated with the same store account will *inherit* the access level of the original. This is the default behavior for Adapty apps.
+
+* If a user logs into your app with a new set of credentials, they retain access to paid content.
+* If a user reinstalls your application after a factory reset, they retain access to paid content.
+* If a user installs the application on other devices with the same store account, the purchase is made available on all devices. Even if each instance of the application has its own customer profile.
+
+This behavior is best for common use cases and store compliance. Do not change it if your app does not have authentication capabilities, and only uses Adapty’s anonymous profiles.
+
+:::important
+If you need to test purchases on a sandbox account, change the setting for [sandbox accounts only](#sharing-paid-access-on-sandbox).
+:::
+
+If your business model demands a different policy, open the [App Settings](https://app.adapty.io/settings/general) page, and navigate to the **Sharing paid access between users** section. You can select an independent paid access sharing policy for the production environment and for your [sandbox accounts](#sharing-paid-access-on-sandbox).
+
+<Zoom>
+  <img src={require('./img/sharing-paid-access.webp').default}
+  style={{
+    border: '1px solid #727272', /* border width and color */
+    width: '700px', /* image width */
+    display: 'block', /* for alignment */
+    margin: '0 auto' /* center alignment */
+  }}
+/>
+</Zoom>
+
+:::note
+Anonymous user profiles associated with the same store account *always* share their access level, regardless of this setting.
+:::
+
+We recommend **the Enabled (default) setting** for most applications. There are two other options to choose from:
+
+## Transfer access to new user
+
+If you select this setting, Adapty limits purchase access to 1 customer ID at a time. The device owner can reinstall the app, log in and out, but cannot access the same product from more than one customer ID simultaneously.
+
+For example, if a customer downloads your application on a second device, Adapty will transfer paid access privileges to the customer ID associated with the new device. The original device will lose access.
+
+If one of the customer profiles is *anonymous* (not associated with a specific customer ID), the two will continue to share the access level. This is necessary to prevent access loss in applications without mandatory authentication.
+
+:::warning
+When you disable from the default setting, and enable **Transfer access to new user**, Adapty does not immediately update the access levels of existing customer profiles.
+
+The switch occurs when a user triggers a new store event: for example, renews the subscription, or restores their purchases.
+:::
+
+## Disable paid access sharing
+
+If you disable paid access sharing, Adapty ties the product to the active [customer ID](identifying-users#setting-customer-user-id-on-configuration) at the time of the purchase, and does not share these privileges with any other customer profiles. This policy allows for stict 1-to-1 product distribution, but demands mandatory in-app authenticaion.
+
+You need to implement your own authentication logic to make sure that users retain access to their purchases. Select this setting if your app requires customers to create an account before completing a transaction, with strict rules that tie purchases to a single user entity.
+
+:::warning
+If you disable paid access sharing, some users may not be able to restore their purchases.
+
+If your application does not guarantee that the user retains access to their purchases, it may fail the mandatory store review.
+:::
+
+You can transfer the product from one profile to another without sharing paid access. When you [delete a user profile](https://adapty.io/docs/api-adapty#/operations/deleteProfile), Adapty transfers access to the next available profile, whether anonymous or identified.
+
+## Sharing paid access on sandbox
+
+Paid access sharing allows users to access their purchases even if the original transaction originated from a different customer ID. When you're using a sandbox account, this benefit can become a limitation.
+
+As you test your paywalls with a sandbox account, you may need to purchase the same product more than once. This is impossible to achieve if Adapty detects that the account has already made the purchase.
+
+Adapty allows you to change the sharing paid access setting for *sandbox accounts only*. To purchase the same product more than once, disable paid access sharing, and change the customer ID. Adapty will not be able to restore the earlier purchases with the new customer ID.
+
+## Paid access sharing in analytics
+
+Paid access sharing does not impact revenue metrics. Adapty logs transactions as they occur. The credit for the transactions depends on [which install definition](general#4-installs-definition-for-analytics) you use.

versioned_docs/version-3.0/sharing-paid-access-between-user-accounts.md

@@ -696,10 +696,22 @@
             "collapsed": false,
             "items": [
                 {
-                    "type": "doc",
-                    "id": "profiles-crm",
-                    "label": "Profiles/CRM"
-                },
+                            "type": "category",
+                            "label": "Profiles / CRM",
+                            "link": {
+                                "type": "doc",
+                                "id": "profiles-crm"
+                            },
+                            "collapsible": true,
+                            "collapsed": true,
+                            "items": [
+                                {
+                                    "type": "doc",
+                                    "id": "sharing-paid-access-between-user-accounts",
+                                    "label": "Sharing paid access between user accounts"
+                                }
+                            ]
+                        },
                 {
                     "type": "doc",
                     "id": "segments",