AI paywall experiments: check what your iOS app actually serves

Two drafts. Still the same screen.

Imagine an iPhone journaling app with two polished paywall drafts. The team starts a headline experiment, but onboarding always selects an offering named premium_default. Both test accounts keep seeing the old screen. This is a hypothetical integration mistake, not a reported RevenueCat incident.

RevenueCat’s AI Toolkit update, published on 16 October 2026, describes generating unpublished paywall drafts using app-code context. It also flags a gap: the experiment skill does not automatically inspect whether the app displays the offering returned for that customer. The team needs to request that check explicitly.

The announcement builds on an existing toolkit; it does not mean every capability launched today. Our practical takeaway is narrower than “let AI optimize subscriptions”: give the agent a task that ends with the intended offer appearing in the actual iOS app.

Follow the offering into the app.

For a standard offering experiment, RevenueCat’s implementation requirements say the app must dynamically display the customer’s current offering. An offering groups the packages available to purchase; it is more than the artwork around a button. If your integration uses placements for different paywall locations, inspect the selection path for the relevant placement too.

Our suggested audit starts where onboarding opens the paywall. Follow the request for offerings, the selection, the screen presentation and the package passed into the purchase call. A screenshot can establish that the headline changed. It cannot establish that the correct package was purchased or the paid feature unlocked.

In a test environment, capture the expected variant, returned offering identifier, displayed offering identifier and purchased package identifier together. Keep these diagnostic records separate from production analytics and avoid recording journal contents. A mismatch is an implementation issue to resolve before interpreting conversion.

Give the agent a small, inspectable job.

For the hypothetical journaling app, suppose searchable archives are already a paid feature. Keep the current paywall as control. In a copied treatment, change only its headline from a generic premium message to “Find the entry you need.” Leave prices, trials, packages and the rest of the layout unchanged. This is a proposed test, not a proven improvement.

Here is an original task brief you could adapt for your coding agent:

Trace the SwiftUI onboarding paywall from entry point to offering selection, presentation and purchase. Identify hardcoded offering choices and report the relevant files and lines. Prepare a draft headline variant for our existing searchable-archive feature. Do not publish it, change store products or enroll customers. Return the exact proposed changes and a plan to verify both variants in our test app.

If your app draws its own paywall, editing a remote Paywalls draft will not change that custom screen. RevenueCat’s update distinguishes this case: the variation must be implemented in app code, potentially using offering metadata. Establish which system owns the screen before asking for a redesign.

Open an older supported build too.

The embedded SDK matters alongside the iOS version. RevenueCat’s fallback documentation warns that unsupported paywall components can produce a default paywall or an empty component; an unsupported Custom component does not render. It describes serving a simpler fallback through SDK-version targeting, with rule order affecting which offering is selected.

Our acceptance check: open both variants on the current build and an older build you still support. Confirm the intended text, packages and purchase controls appear. Exercise sandbox purchase, cancellation and restore, then verify entitlement-based access. If the older build needs a simpler screen, record that as a deliberate variant of the experience rather than silently treating all exposures as identical.

Then decide whether to enroll anyone.

Keep a record of the original configuration, reviewed changes, affected app builds and how to recover if the wrong screen appears. Preview approval and starting customer enrollment should be separate decisions.

Before the experiment begins, define the eligible iOS audience, exposure event, payment outcome and observation window. Allow time for the existing trial to finish. Follow cancellations, refunds and net proceeds as well as initial purchases; use our paywall measurement guide for the denominator and event guide for instrumentation.

This note reviews documentation, not a hands-on SDK test or a measured conversion result. AI can shorten draft preparation. Whether the change reaches the right customer and improves the business remains something your team has to verify.