Integrations
Apple App Store
Apple support is planned and not implemented. What exists, what has to change, and what would have to be proven.
Not implemented. No Apple connection exists. This page records the intended design so the gap is visible rather than assumed.
What already generalizes
The pricing domain is store-agnostic. Markets, money, economic factors, strategies, dampening, bounds, confidence, and drift make no reference to Google, and would apply to Apple unchanged.
What does not
The StoreProvider contract still carries Google-only identifiers and conversion inputs. Package names, base plan ids, and purchase options are Play concepts, and the contract is shaped around them.
Making Apple possible means generalizing the contract first: provider-neutral identifiers and explicit capability discovery, so the application can ask a provider what it supports rather than assuming.
Apple-specific work
- Authentication and credential custody for App Store Connect keys.
- Mapping applications, in-app purchases, subscriptions, storefronts, and availability.
- Price points. Apple prices from a fixed tier table rather than arbitrary amounts. Rounding becomes tier matching, which is a materially different problem from Google's increment snapping.
- Price schedules, which have no Google equivalent.
- Fixtures and a shared provider contract test both stores must pass.
- Apple-specific validation, mutation, verification, partial-failure, and rollback behaviour.
What would have to be proven
A controlled exercise against a real App Store Connect test app, StoreKit Simulator checks, and a sandbox or TestFlight pass on real hardware — before Apple support is described as available anywhere.
Until then
Paywall Parity is a Google Play tool. Nothing on any screen should imply otherwise, and cross-store analysis is not something the product can do today.