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.