Paid access

One supports two paid-access policies. App account is the default: active One entitlement grants unlock access for the customer. App Store is optional for iOS apps: verified Apple purchases on the installation determine access. An email login can identify one customer across devices without transferring paid access between different Apple purchasers. Supported Family Sharing still requires Apple evidence.

Enable and integrate

1. In Configure → Auth → Paid access, select your Test app and choose App Store.
2. Initialize the current iOS SDK with OneSDKConfig(apiKey: publicKey, paidAccessPolicy: .appStore).
3. Download the app configuration and add one-paid-access.json to the app target’s resources. It must match the app bundle, One App and environment. Export again when the catalog or historical paid-download rules change.
4. Use customerInfo.entitlements, one.entitlements, isEntitled, and preparePurchaseAccess for feature checks. accountEntitlements is billing information and cannot grant installation access in this mode.
5. Invalidate old account-derived extension caches. Mirror only effective SDK entitlements and their verification/expiry deadlines. Opening an extension before the updated main app runs must not reuse an old account-only grant.

The configuration file contains product mappings, not purchase proof. Without a valid bundled or cached configuration, the first launch requires connectivity. StoreKit and bounded SDK caches handle verified offline access. Only an explicit Restore action invokes App Store synchronization; apps must not add retry loops. Historical paid-download access requires explicit rules against signed original purchase evidence. Imported account grants or restored app flags are not evidence.

Older iOS versions and historical purchases

App Store access supports iOS 15+. iOS 15 verifies Apple’s app receipt and current StoreKit purchases; iOS 16+ uses AppTransaction. Purchaser-specific manual support grants require iOS 16+, because app receipts do not expose the same purchaser ID. Receipt access never falls back to an email account’s grants.

Historical rules can specify originalAppVersionFormat: "integer" or "dotted" with a matching originalAppVersionBefore cutoff. These fields are part of the initial version-1 format and require the compatible SDK/API. Use separate rules when an app historically used both build numbers and dotted versions. Sandbox receipts contain synthetic original purchase values; verify real historical eligibility with production evidence.

Accounts and deletion

Authentication, customer/device records, and purchase ownership are separate. The same authenticated app identity can resolve to one customer with multiple devices. Deleting credentials follows the app’s configured deletion policy. It does not cancel an Apple purchase or erase app-owned files. Full customer deletion and credential-only deletion are different operations; review that policy separately.

Live activation

Validate purchases, restore, Family Sharing, account changes, offline launch, expiry/revocation, historical purchases, and extensions in Test first. Enabling Live changes protected server decisions immediately. Older app builds cannot supply the new purchase context and continue their old local access behavior. A server switch alone cannot upgrade those binaries. Keep Live unchanged until the adopting build and rollout have been accepted. Export the Live app configuration for that build.

One Agent

one_get_paid_access_settings reads the policy and configuration with apps:read. one_plan_update_paid_access_settings previews a change for an exact App/environment with apps:write. Apply the saved plan only after approval using one_apply_action_plan. The server rejects stale settings/catalog previews. Check that the deployed API and installed plugin advertise these tools before use.

Manual support access and unavailable Apple verification

For App Store apps, a manual grant follows one verified Apple account across its devices. Sharing the app’s email login does not share the grant. Signing out of that app login does not cancel the grant. Family members have separate Apple identities, so a support grant is not automatically shared with the family.

In the customer’s Grant entitlement dialog, choose the verified Apple account. If none is listed, ask the customer to open the updated app and verify their App Store account first. Apple does not supply its account email here; Admin identifies the verified account by its observed device and verification time.

Existing customer-level grants are retained in history but do not unlock App Store access. Create a new grant for the intended verified Apple account; One never reassigns an old grant by guessing from an email. App account apps keep their existing customer-level manual grants.

Expiry and revocation remain independent of purchases. A new device needs Apple verification and a One connection to receive its grant; previously verified access can use the bounded offline cache. A simulator with no Apple proof can still show plans and bundled paywalls, but cannot receive an Apple account’s support access.

Use the updated local SDK with the matching API and database migration. The API returns manualEntitlements only through verified Apple access. It does not turn manual support into an App Store purchase or subscription.