If you’re a developer trying to optimize your app’s revenue, A/B testing and remote configuration aren’t just nice-to-haves – they’re how you find your edge. You need to test paywalls, tweak onboarding flows, and roll out features gradually to see what actually moves the needle

But there’s a lingering fear: If I change my app remotely without going through App Review, will Apple ban my account?

Short answer: No, as long as you understand the rules of the game

Apple isn’t against A/B testing. In fact, they offer their own Product Page Optimization tools for testing App Store assets. The key to testing safely inside your app comes down to understanding the difference between changing data and changing code – and respecting the spirit of the review process

Let’s break down what you can (and should) be testing remotely, how to do it safely, and where the hard lines are drawn

The green light: what you should be testing

The golden rule for remote testing is Guideline 2.5.2. It states that apps “may not download, install, or execute code which introduces or changes features or functionality of the app”

Notice the word code

If you are using remote config (like Firebase or RevenueCat Offerings) to change data – JSON payloads that tell your existing, pre-compiled code how to behave – you are generally in the clear. Here are the high-impact areas you should absolutely be testing:

  • Paywall UI and copy: changing the background color of your paywall, swapping out the hero image, or testing “Start Free Trial” versus “Subscribe Now” is perfectly fine. The code to render a button is already in the app; you’re just telling it what text to display. This is the lowest-hanging fruit for conversion optimization
  • Pricing and packaging: swapping which StoreKit products are shown on your paywall (e.g., testing an annual vs. monthly default, or introducing a new tier) is standard practice. As long as the products themselves are approved in App Store Connect, dynamically choosing which ones to display is safe and encouraged
  • Feature flags for gradual rollouts: if you’ve built a new feature, included the code in the binary you submitted to Apple (and made sure the reviewer could actually access it), and just want to turn it on for 10% of your users to monitor crash rates or engagement, you’re safe. The feature was there during review, even if it was dormant
  • Onboarding flows: re-ordering the screens in your onboarding flow or changing the text on those screens to better explain your value proposition is a great use of remote config. You’re optimizing the user journey using existing components

The nuance: it’s about the spirit of the review

Where developers get into trouble isn’t usually the mechanism of remote config, but what they are configuring. The most common trap is bypassing the spirit of the App Review process

Let’s look at a classic example: testing a hard paywall versus a soft paywall

A soft paywall allows users to dismiss it and use some limited version of the app. A hard paywall blocks all access until the user subscribes. Developers often want to A/B test these two approaches to see which yields higher LTV

The problem? A hard paywall fundamentally changes the nature of the app. If your App Store metadata and screenshots show a free app with optional premium features, but a remote config flag suddenly locks 50% of your users out of the app entirely, you’ve created a discrepancy

Apple reviewed and approved a freemium app. You are now delivering a paid-upfront experience. This violates Guideline 2.3.1 (Accurate Metadata) because customers don’t know what they’re getting when they download the app

It’s not the remote config that gets you rejected here; it’s the bait-and-switch. If you want to test a hard paywall, the safest approach is to submit the app with the hard paywall active for review, ensuring your App Store presence accurately reflects that experience

The red light: what will actually get you banned

While Apple is generally fine with data-driven A/B testing, there are a few lines you absolutely cannot cross. Apple’s Introduction to the guidelines is very clear: “If you attempt to cheat the system (for example, by trying to trick the review process… your apps will be removed from the store and you will be expelled from the Apple Developer Program”. Here’s what to watch out for.

The ‘Review Detection’ pattern

This is the most common fatal mistake. Developers use remote config to detect when their app is being reviewed by Apple (often by checking IP addresses or looking for specific test accounts) and show a clean, compliant version of the app. Once approved, they flip a switch and turn on aggressive monetization tactics. Apple actively looks for this, and if they catch you, your account is gone

The web checkout swap

Following the Epic v. Apple ruling, developers in the US can now link to external web checkouts. But many developers misinterpret this ruling and use remote config to swap their IAP paywall for a web checkout after review. This is a fast track to rejection for several reasons:

  1. The ruling requires most apps to still offer IAP alongside the external link. You can’t just replace it entirely
  2. The ruling only applies to the US storefront. If your remote config enables web checkout globally, you’re violating guidelines in every other country
  3. Changing the fundamental payment mechanism post-review is seen as hiding functionality

The native Stripe SDK trap

Another common misunderstanding of the Epic ruling is thinking you can now use Stripe’s native mobile SDK (like Payment Sheet) to process digital subscriptions inside your app. You can’t. Apple allows a link that opens the default browser (not a WebView) to an external checkout page. If you use remote config to turn on a native Stripe checkout for digital goods, you will be rejected. If you turn it on after passing review with an app that didn’t show this checkout, you risk an account ban

Downloading executable code

You cannot download new JavaScript or native code that adds entirely new screens or functionality that wasn’t in the reviewed binary. You can change the data that populates a screen, but you can’t download the screen itself

The yellow light: navigating the grey area

Even when you’re playing by the rules, you might stumble into Guideline 5.6: Developer Code of Conduct. This guideline states that apps should not engage in “manipulative practices” to trick users into making unwanted purchases

Because “manipulative” is subjective, this creates a grey area for certain types of tests:

  • Exit offers: when a user tries to close your paywall, you pop up a secondary offer with a discount. Is this a smart e-commerce win-back strategy, or is it manipulative? We’ve seen apps get rejected for this under Guideline 5.6, yet many top-grossing apps do it every day
  • Aggressive back-to-back paywalls: showing a paywall during onboarding, and then immediately showing another one if the user declines, often triggers a 5.6 rejection

If you’re going to experiment in these grey areas, transparency is your best friend. Never try to hide your experiments from App Review. If you’re testing an exit offer, make sure it’s active in the build you submit. Use your App Review notes to explain your A/B testing setup: “We are currently running an A/B test on our paywall flow. The reviewer may see either Variant A or Variant B”

Remote testing is a powerful tool for growth. As long as you’re using it to optimize the user experience and find the right pricing – rather than trying to sneak unapproved features past Apple – you can test with confidence.

A loving note from our editor: you may have noticed this blog post is missing periods at the end of many paragraphs. Please don’t be thrown off or think we haven’t spotted this; it is simply the signature trademark of Rik Haandrikman, VP of Marketing at RevenueCat. For more of his antics, follow Rik on X (you’ll know you’ve found the right account when you stop seeing periods).