What App Review says about screens from a server
Apple's rules name downloaded code and hidden features, not server-drawn screens. What the text says, what to tell reviewers, and what we'd never do.
Miniwall blog
Latest
How many tests can your release train afford?
A test takes several changes, and each change waits for a release. Count how many tests your calendar allows, and which ones to move off the train.
Paywall tools compared: revenue share or flat price?
Superwall, RevenueCat, Adapty and Miniwall charge in different ways. What each model does to your bill, what each tool is for, and when not to pick ours.
Build your own remote UI platform, or use one?
What an in-house remote UI platform really includes, what you rent when you buy one, and the questions to ask either way. Written by a vendor.
How to govern remote UI changes across teams
Changes that skip the release need their own rules. Tier the changes, decide who approves each, plan the way back, and rehearse it.
The hidden cost of waiting for an app release
Waiting for a release costs more than the days on the calendar. A way to price the wait with your own numbers, and which changes are worth moving.
How to tell if remote UI is paying off
Moving screens out of the release is a bet. Four measures to check it, a way to read them honestly, and the signs that it isn't working.
Migrate one screen to server-driven UI, not your app
A low-risk way to start: move one screen that changes often, ask for it by name, and keep the old native screen as the way out.
Remote UI is untrusted input: a checklist
A screen your server describes is input your app didn't write. Seven checks for links, text, fonts, size and keys, plus questions for a security review.
Who should own remote UI: engineering, product or growth?
Owning remote UI is four decisions, not one. A way to split them between engineering, product and growth, and what goes wrong when nobody does.
Failed payments: involuntary churn and your screens
A failed payment isn't a cancellation. What a screen can do about it (one calm notice, a link to your billing page), and what it can't.
JSON, a DSL or components: describing a screen
Three ways to describe a screen from a server: plain JSON, a small language with logic, or fixed components. What each costs and when each wins.
App Store phased release: what it does and doesn't
Apple's phased release spreads an update over seven days and can be paused. It can't recall installs, cover the web, or change shipped content.
The subscription lifecycle, from trial to win-back
Eight stages from first paywall to win-back: what the user is deciding, which screen fits, which to skip, and where a small team should start.
Tracking a UI you don't ship: shown, seen, clicked
When a server draws the screen, your app can't assume what was shown. How shown, seen and clicked differ, and where events get lost.
When not to use server-driven UI (we sell it)
Five cases where server-driven UI costs more than it saves: rare changes, heavy interaction, hot paths, version-exact flows, no owner. A test for each.
A/B testing with little traffic: what you can still learn
With a few thousand visitors a month, most tests can't see small wins. How to size a test before you start, read the interval, and what to do instead.
Caching remote screens: fresh, stale or gone?
A screen you downloaded is fresh, stale but usable, or gone. How to show it fast, refresh it behind the scenes, and what to do when the network fails.
Your campaign is ready, but the release isn't
Copy, offers and banners change often, but each change rides a release train. What the wait costs, three ways to cut it, and when to leave it alone.
Cancel surveys: what to ask and what to skip
One question, a few fixed reasons, room to explain. What to ask people who cancel, what to skip, and how to avoid trapping them.
Deploy is not release: split them on purpose
Merging code and showing it to users are two decisions. How splitting them lowers risk, and what it costs in flags to clean up later.
Feature flags vs remote config vs CMS: three questions
A flag decides who sees what, remote config sets a value, a CMS holds content other people edit. How to tell them apart, and how each gets misused.
Why a paywall test can win on conversion and lose
A cheaper price can lift paywall conversion and still lose revenue. Pick one deciding metric, add guardrails, and decide how long to wait for renewals.
Three ways an A/B test lies to you, shown by simulation
We ran identical versions against each other. Looking daily gave a false winner 27% of the time. Code included, with ways to avoid it.
Server-driven UI: a field guide for app teams
A working map of server-driven UI for app teams: when to use it for a screen, a region or not at all, then how to build, secure, test and run it.
Server-driven UI: where it helps and where it hurts
Server-driven UI speeds up changes and adds a schema to maintain. Where it pays off, where it hurts, and when plain native code is the better call.
Tool pricing: per view, per user or % of revenue
Per view, per active user or a share of revenue: what each model does to your bill as you grow, with worked numbers and questions to ask any vendor.
When to show an upgrade prompt, and when to wait
Asking at sign-up is early. Look at triggers tied to a useful moment, how often to ask, and how to log shown and clicked.
Ways to change a live app without shipping a release
Staged releases, flags, remote config, OTA, server-driven UI, a CMS, WebViews and API changes: what each can change, what it can't, and how to pick.
What is server-driven UI? Three levels, and when to skip it
Server-driven UI means the backend describes a screen and the app only draws it. What it is, the three levels of it, and when to skip it.
- Send a topic
Stuck on something we haven't covered?
Tell us what you're trying to figure out and we'll write about it if it helps.
Every post links its sources and marks opinions as opinions. About this blog