Running seasonal campaigns without an app rebuild

Retail runs on a calendar. App stores run on a queue. The whole problem with seasonal campaigns in a mobile app is that those two things do not negotiate: if your Black Friday banner requires a new build, your sale date is set by a reviewer you have never met.

The way out is knowing exactly which changes need a build and which do not, then designing your campaigns entirely out of the second category.

The two categories

Over-the-air (no build, no review). In StoreToNative this is configuration your app fetches: themes and colors, typography, the home-screen layout and which blocks appear, banners, intro slides, feature toggles, and merchandising collections. You publish from the console and no store is involved.

Native shell (new build, new review). Three things, specifically: the app name under the home-screen icon, the launcher icon itself, and the bundle identifier. These are baked into the binary because the operating system reads them, not your app.

That split is the entire planning constraint. Everything a campaign normally needs is in the first category. Everything in the second category is a rebranding, not a campaign.

How the delivery actually behaves

Be precise about this, because “instant” is the wrong word and planning around the wrong word is how a launch lands late.

A fresh install picks up the current configuration straight away — someone installing on Friday morning sees Friday’s design.

An app already on someone’s phone fetches the change in the background and shows it on the next open after that. So allow a launch or two rather than expecting a change mid-session.

The practical rule: publish campaign configuration the day before it starts. Then every customer who opens the app on the campaign’s first day sees it. Over-the-air updates, explained has the full mechanics.

A campaign built entirely from OTA changes

Take Black Friday. Here is the whole thing, with nothing that touches a store review:

Two weeks out

• Build the collection in WooCommerce (the products, the sale prices). This is normal store work and syncs to the app automatically.
• Design the banner in the console, switched off or scheduled with a Show from / Until window. Every console change goes live as soon as it is saved — there is no separate publish step — so leave anything early switched off. Theme colours can’t be scheduled; change them on the day.

Three days out

• Push campaign #1: a teaser to your app audience. “Our sale opens Friday. App first.”
• Add an intro slide for new installs explaining the sale — new installs during a promotion are your best-converting cohort.

One day out

• Switch the campaign on: hero banner, the sale collection promoted to the top of the home screen, and a countdown block if you use one — or let their Show from time do it. Change the theme colour now if you are changing it.
• Verify on a real device by opening the app twice.

Launch day

• Push campaign #2 in the morning for most of your customers, deep-linked to the sale collection — not to the home screen.
• Watch push opens and app revenue on the Analytics page during the day.

Mid-campaign

• Rotate the banner to a second product group. Another over-the-air change, no review.
• Push campaign #3 only if you have something new to say. Restocks count; “don’t miss out” does not.

End

• Switch the sale sections off (or let their Until time do it) and put the normal theme back. Do this before the prices revert, so nobody taps a sale banner into full-price products.

Zero builds. Zero reviews. The only calendar you obeyed was your own.

The mistakes that force a rebuild anyway

• Putting the campaign in the app’s name. “BrandName — Black Friday” is a new build, a new review, and a name you have to change back.
• A holiday launcher icon. Charming, and it is a native change with a review attached. If you want it, plan it three weeks out, not three days.
• Discovering mid-campaign that a feature is off. Feature toggles are OTA, so this is recoverable — but check them during planning rather than at 9 a.m. on launch day.

The verification that prevents a bad Friday

Ten minutes, the day before:

1. Open the app on a real device twice, confirming the new design appears on the second open.
2. Tap the banner and confirm it lands on the sale collection, not the home screen.
3. Confirm the sale prices are correct in the app, not just in wp-admin — a variable product with per-variation sale prices is the classic miss.
4. Check the collection on a small, old phone. Campaign banners are where layouts break.
5. Send one push to yourself and tap it.

Two seasons, one calendar note

If your customers shop across different retail calendars — Black Friday and Ramadan, say — the OTA model matters more, not less, because you are running more campaigns per year and each one would otherwise be a review cycle. Themes, banners and collections all being configuration means a second calendar costs you design time and nothing else. Layout direction is part of the storefront rather than a campaign asset; Arabic-first commerce covers that side.

The one-line rule

Design every campaign out of colors, banners, layout and collections — and never out of the app’s name or icon. Then publish the day before, and your retail calendar stops asking anyone’s permission.

Related reading

• OTA, explained: redesign your app without shipping an update
• Designing an app home screen that actually sells
• Push notifications for a WooCommerce store, end to end
• Arabic-first commerce

The OTA layer is on every plan — see what ships over the air.