Customer.io Now Runs Two Mobile Apps in One Workspace. Merging Yours Is a Two-Release Parallel Run, Not a Setting

At 10:48 on the morning of Sunday 7 February 1904, a fire took hold in the basement of the "fire-proof" Hurst building in downtown Baltimore. It was under control by five o'clock the next afternoon. In between it levelled more than 1,500 buildings across over 140 acres. Engine companies came from Philadelphia, Washington, New York, Wilmington and Atlantic City, and most of them stood and watched. Their hose couplings would not fit Baltimore's hydrants. The Washington crews improvised adapters and got water through at badly reduced pressure.

The shortage was not equipment. By 1903 there were over 600 sizes and variations of fire hose coupling in the United States. The fix was obvious and it arrived fast: on 23 May 1905, an NFPA committee published its first report recommending a diameter and thread count for couplings and hydrants. Then came the part nobody budgets for. In August 2004, NIST published the tally—one hundred years after the Baltimore fire, 18 of the 48 most populated US cities had installed national standard fire hydrants.

The standard was right in 1905. It was still arriving in 2004.

Customer.io shipped its own 1905 report this summer. Across two release notes a month apart, one workspace can now hold more than one mobile app, and an in-app message can name the app it belongs to. That closes the last real argument for splitting workspaces by app. It does not mean you can merge yours yet, and the gap between those two sentences is where teams are about to lose a quarter.

TL;DR: Customer.io added multi-app push on 29 July 2026 and multi-app in-app messaging on 21 August 2026, so one workspace per mobile app is no longer the right architecture. Two gates stand between you and consolidation. Multi-app support is an access flag Customer.io turns on for existing accounts. App-level targeting then needs iOS 4.7.5, Android 4.20.2, React Native 6.6.3, Expo 3.7.2 or Flutter 4.3.0 at minimum. Merging is not a copy—each app build talks to exactly one workspace, so you ship a new build, run both workspaces live in parallel, and stop the old one double-sending with a cross-workspace webhook. Consolidating also moves your push metrics from one delivery per profile to one delivery per device. And the visual notification inbox serves only your default app and your website, so a second app gets no visual inbox at all.

Workspace-per-app was never a data decision

We gave this advice. So did everyone else, and it was correct: if you ran two mobile apps and one Customer.io workspace, you had no way to keep an in-app message out of the wrong app. Page rules could sometimes fake it. Mostly you split the workspaces, then paid for that split every day afterwards in duplicated automations, duplicated templates, two sets of segments and a customer who existed twice.

Notice what the split was solving. Not modelling, not privacy, not governance—targeting. It was a workaround wearing an architecture's clothes, and it survived because nothing better existed. That is now over, which means the burden of proof has flipped. Two workspaces for two apps is no longer the default you inherit; it is a choice you have to defend.

What shipped, and what each half does

Push came first. The 29 July release note is direct about the intent. You can "register each app with its own credentials, send pushes through a specific app, and create segments to group profiles by the apps they use". An app in Customer.io is a name, one or more platforms, and a push credential per platform. That means an APNs .p8 key with its Key ID, Team ID and Bundle ID, or a Firebase Cloud Messaging service-account .json. Those credentials are how Customer.io tells your apps apart.

In-app messaging followed on 21 August. Once a workspace holds more than one app, in-app messages grow a Where this message appears setting, and that is where you pick the app and the platforms. Three rules from the docs are worth reading before you plan anything:

• "Each message targets one mobile app, and one app only." Two apps means two copies of the message in your workflow.
• "New messages start with your default app selected." Every new message is a default-app message until someone changes it.
• Page rules "apply within the app and platforms you select". App choice decides which app; page rules decide which screens inside it.

The release note also carries the warning that matters. It is the only place either announcement mentions it. "If you have multiple apps that you manage across workspaces today, and you want to consolidate them to a single workspace, you need to wait until a significant number of devices have updated to the new SDK version before you consolidate workspaces."

The two gates, not one

The announcements read as though the SDK is the only obstacle. It isn't.

Gate one is an access flag. Multi-app support is being rolled out, not switched on everywhere. The push release note says "all new accounts and accounts that have never integrated push now support multiple apps, but other existing customers need to reach out to their CSM to request access". The push setup docs give you the test: "If you can't add an app in Workspace settings > Push, you don't have multi-app support yet." One useful detail if you run several workspaces—"Multi-app support covers every workspace in your account, so we turn it on once."

Check this today. It costs one look at a settings screen and it decides whether the rest of your plan is real.

Gate two is the SDK floor. App-level targeting only works on devices running a recent enough Customer.io SDK. These are minimums; later versions are fine.

Platform	Minimum Customer.io SDK version
iOS	4.7.5
Android	4.20.2
React Native	6.6.3
Expo	3.7.2
Flutter	4.3.0

Getting your build over that floor is an afternoon for your mobile team. Getting your install base over it is not, and that is the number your plan depends on.

Who receives what while your install base is mixed

A device on an older SDK doesn't report which of your apps it belongs to, so Customer.io has to put it somewhere—and it puts it in the default app. From the docs: "Those devices receive messages that target your default app, but not messages that target any other app."

The message targets	Devices on a supported SDK	Devices on an older SDK
Your default app	Receive it if they belong to that app	Receive it
Any other app	Receive it if they belong to that app	Can't receive it
No app (built before app targeting)	Receive it	Receive it

Read the middle row twice, because it is the failure mode. Suppose you have two apps in one workspace and half your install base is behind. Messages you target at the second app reach nobody on an old build. Eligibility is resolved when the message sends, not when you build it, so the composer has nothing to tell you at the point you'd want to hear it. Meanwhile those same users keep receiving everything aimed at your default app, including messages written for a product they don't use.

Your two audiences are not equally reachable during the tail, and the only place that shows up is your delivery numbers. That asymmetry is the entire argument for waiting.

This also changes how you debug. "My in-app message isn't showing" now has an app-targeting cause sitting above every cause it used to have, so add it to the top of the five-minute decision tree before you check anything else. On a specific device, the in-app debugger is the fastest read available. Add cio_debug_session=true to the URL and the docs say you get "the SDK's current state in real time: the workspace credential it's using, the person it has identified, the route it thinks you're on, and every message that's currently active or waiting in the queue".

One piece of good news: messages you built before app targeting existed keep working. The docs say they "will continue to work after you add the new apps", going to your default app or wherever you initialised the SDK. Nothing breaks the day you add a second app. Things break the day you assume the second app is reachable.

Merging is a parallel run, not a copy

If your apps already share a workspace, everything above is all you need. If each app has its own workspace, there is a documented migration—and it is bigger than "multi-app support" implies. Customer.io has a dedicated consolidation page that neither release note links prominently. Its opening line sets the tone: "Consolidating touches your messages, your app builds, and your billing, so let us help you plan it."

The constraint that shapes the whole thing is one sentence: "Each build of your app talks to one Customer.io workspace." You cannot lift your audience across, because "if you were to copy your audience over first, any users who hadn't updated their app yet wouldn't receive messages from the new workspace". Until someone takes the new build, their device fetches in-app messages from the old workspace and their push token is registered there.

So the sequence inverts what most teams expect. You move the app first and the people follow, one update at a time. Everything we said about planning an ESP migration applies here, with one difference that makes it harder: in a normal migration you control the cutover date. Here your users do.

1. Pick the workspace to consolidate around—the docs say choose the one "with the most engaged audience"—and add your other apps to it with their push credentials.
2. Copy your messages in. Whole workflows and one-time sends copy between workspaces. Automations don't, so create the automation in the new workspace, set its trigger, then paste the workflow in. (Automations are what Customer.io renamed campaigns to in July.)
3. Release app builds pointing at the consolidated workspace, on an SDK that supports app-level targeting, and have the build send an attribute in its identify call—the docs suggest consolidated: true.
4. Flag arrivals back in the old workspace. An automation triggered by that attribute fires a webhook at the old workspace's Track API, setting the same attribute on the matching profile there. Use "_update": true in the body so you never create a profile that didn't exist. EU workspaces post to track-eu.customer.io.
5. Mute the old workspace for flagged people. Add the attribute to every automation's exit conditions, so anyone flagged mid-flow leaves. Add it to the trigger conditions too, so nobody flagged enters again, and to the audience conditions on your one-time sends.
6. Cut over when arrivals level off, then retire profiles or the whole workspace.

Step five is the one that bites. The docs say why. "It's important that as each profile arrives in the new workspace, you stop the old workspace from sending to them, so you don't send them duplicate messages over channels that aren't unique to a workspace—SMS, email, etc." Push and in-app sort themselves out, because a device can only be registered in one place. Email and SMS don't care which workspace they came from. Miss a one-time send's audience condition and someone gets your September promotion twice, from two workspaces, with two unsubscribe links.

And plan the rebuild, because the copy is partial. This is the list to hand your team before anyone starts:

Comes across	You rebuild by hand
Whole workflows, copied between workspaces	Segments
One-time sends and broadcasts	Email layouts
Messages built before app targeting (they keep working)	Sender addresses
	Action conditions that reference a segment
	Automations themselves (trigger set in the new workspace, workflow pasted in)

Two more traps on the way out. Don't promote a newly added app to default. "The default app receives every message that doesn't name an app", worked out at send time. Make the new app default and all of that traffic moves off the app that was already there, silently. And you can't delete an app while messages still target it; the count Customer.io shows you "includes drafts and messages in stopped automations, not just the ones actively sending".

Retirement needs the same patience. If you delete profiles from the old workspace while integrations still point at it, you can "inadvertently re-identify people in the old workspace after you delete them—which can affect billing".

What consolidating changes that neither release note leads with

Your push numbers move. With multi-app enabled, "your metrics reflect one delivery per device, no longer one delivery per customer profile". The note spells out the consequence: "a push to a profile with two devices counts two Sent, where it previously counted one". Nothing about your sending changed. Your denominators did. Anyone comparing this month's push delivery rate against last quarter's needs to know the day the counting method changed, or you will spend a Monday explaining a cliff that isn't there.

Frequency caps don't span workspaces. Message limits are created "in your workspace settings", which means neither workspace can see what the other sent. During a parallel run your cap is per workspace, not per person, and the person on your list twice can absorb twice the limit. If you have gone to the trouble of setting channel-by-channel limits, that is exactly the protection the parallel run suspends. Both are reasons to keep the parallel run short rather than thorough. And limits never covered in-app or inbox messages anyway.

We got the inbox wrong in June, and the new limit is worse than the old one. Our post on the no-code notification inbox told you the visual inbox was web-only, and that mobile meant building your own. The docs now say it "renders on the web and in native mobile apps", so that limit is gone—good news, and our post is behind. The limit that replaced it matters more here: "the visual notification inbox only serves your workspace's default app and your website." A workspace still gets one inbox, so consolidating two apps into one workspace means your non-default app has no visual inbox at all. Send a push-to-inbox copy from a message targeting a non-default app and "we won't send the notification inbox copy". Build your own inbox and you can target different apps—which puts you back where our June costing started.

Two smaller ones while you have the list open. Design Studio "doesn't have a concept of app-specific default styles", so the docs recommend prefixing global styles per app—app1-h1, app2-h1. And websites are still one bucket: the Web checkbox covers every site you run, and "you must set mutually exclusive page rules to show messages on the correct site".

The sequence we'd run

Not this quarter. Here is the order, and roughly what each step waits on.

1. This week. Open Workspace settings > Push in each workspace. Can you add an app? If not, email your CSM, or [email protected], and get the flag turned on across the account.
2. This month. Get the SDK floor into your mobile backlog for the next scheduled release. Don't cut a release for it; ride one you were shipping anyway. Mobile engineering time is the scarcest thing in this plan, which is also why we argued that live notifications don't belong on that backlog. An SDK bump that clears the path to a workspace merge does.
3. Pick your threshold before you have the data. Decide the share of active devices on the new SDK at which you will consolidate, and write it down now, while nobody is impatient. We would not start a merge under 80% of active devices, and we would want to know what the remaining fraction is worth before touching the other 20%.
4. Watch adoption, not the calendar. Devices arrive on the new build in a long tail. Your threshold is a measurement, not a date.
5. Consolidate. Then run the parallel-run steps above, in that order, with step five in place before step three ships.
6. Rebuild targeting last. Segments and layouts have to be recreated anyway. That is the moment to consolidate the two sets of near-duplicate segments into one set that reasons about both apps, rather than porting your old split into a workspace that no longer needs it.

That last step is the prize, and it is worth naming, because it is easy to finish a migration and forget to collect it. We consolidated two Customer.io workspaces into one for Kip, Australia's pet boarding and daycare network, with more than 200,000 profiles and 80+ live campaigns merged with zero disruption. The merge itself was the boring half. The value showed up afterwards, in standardised event naming and segments that could finally see a customer's whole relationship at once—one win-back campaign went out to 1,465 people, 43.1% opened it and 7.2% converted. None of that was available while the same customers sat in two workspaces with two names for the same event.

When not to consolidate

Four cases where two workspaces still earn their keep.

Your audiences don't overlap. The docs' own premise is that you might want multiple apps in one workspace "if your apps can share audience members". If your fitness app and your accounting app have no customers in common, you get the migration cost and almost none of the payoff.

Your workspaces are in different regions. The consolidation docs treat the EU region as a different Track API hostname, which is the small end of the problem. Merging an EU workspace into a US one moves personal data between regions. That is a conversation with whoever owns your data protection position, and it happens before anyone opens a settings screen.

Separate legal entities or separate billing. If two apps belong to two companies, or two clients, the workspace boundary is doing real work—access, invoices, audit. Multi-app support doesn't change that.

One app's install base updates slowly. Enterprise-managed devices, kiosk hardware, an audience on old Android builds. If your threshold is months away for one app, consolidate the apps that are ready and leave that one where it is.

The architecture is right; your install base isn't there yet

The 1905 committee got the standard right and it still took a century to reach the hydrants. Customer.io has done the same thing in miniature. The architecture is correct as of 21 August 2026. The version running on your customers' phones will lag by however long they take to press update.

That gap is manageable. It is not skippable, and the failure mode is quiet—a second app's messages going nowhere while its users keep getting the default app's. Check the flag this week, get the SDK into your next release, set your threshold before you're impatient, and treat the merge as the two-release parallel run the docs describe.

If you'd rather have someone who has run this migration hold the plan, that's what we do—tell us what your workspaces look like and we'll tell you honestly whether it's a this-quarter job.

Frequently asked questions

Can one Customer.io workspace serve two mobile apps?

Yes, since 21 August 2026 for in-app messages and 29 July 2026 for push. A workspace can hold multiple apps, each registered with its own push credentials, and each in-app message picks one app through the Where this message appears setting. Existing accounts that already use push may need Customer.io to turn multi-app support on first.

What SDK version supports multiple apps in Customer.io?

App-level targeting needs iOS 4.7.5, Android 4.20.2, React Native 6.6.3, Expo 3.7.2 or Flutter 4.3.0, or later in each case. Those are the minimums published on Customer.io's multiple-apps docs page. Devices on anything older can't be targeted by app.

What happens to users on an old SDK version?

Their device doesn't report which of your apps it belongs to, so Customer.io routes it through your default app. Per the docs, those devices "receive messages that target your default app, but not messages that target any other app". They fail silently, because eligibility is resolved at send time rather than while you're building the message.

Do existing in-app messages break when I add a second app?

No. Messages created before app-based targeting "will continue to work after you add the new apps", and they go to your default app or wherever you initialised the SDK. When you edit one, you can set Where this message appears to point it at a specific app and platforms.

How do I change my default app, and should I?

You change it in Workspace settings > Push: click the app, then Set as default. During a consolidation, don't. The default app receives every message that doesn't name an app, resolved at send time, so promoting a newly added app moves all of that traffic off the app that was already there.

Can I segment by which app someone uses?

Yes. The 29 July release note says you can "create segments to group profiles by the apps they use". That is also how you'd size your SDK adoption tail before deciding whether to consolidate.

How do I merge two Customer.io workspaces?

Customer.io documents a six-step parallel run. Add your apps to the workspace you're keeping, copy your messages in, and release app builds pointing at that workspace with a flag attribute in the identify call. Then use a webhook to mark arrivals in the old workspace, add that attribute to the old workspace's exit conditions, trigger conditions and one-time-send audiences, and cut over when arrivals level off. Customer.io asks you to contact your CSM, or [email protected], before you start.

Can I just copy my profiles into the new workspace?

No, and the reason is structural. "Each build of your app talks to one Customer.io workspace", so a user who hasn't taken the new build still fetches in-app messages from the old workspace and has their push token registered there. Copy the audience first and those people sit in a workspace that can't reach them.

Does multi-app support work for the notification inbox?

Only for your default app. The docs say "the visual notification inbox only serves your workspace's default app and your website", and a workspace can have one inbox. A push-to-inbox copy is dropped when the push targets a non-default app. If you build your own inbox with the SDK's inbox() method, you can target different apps in the same workspace.

Does consolidating change my push metrics?

Yes, and it's a reporting break worth announcing internally. With multi-app enabled, "your metrics reflect one delivery per device, no longer one delivery per customer profile"—so "a push to a profile with two devices counts two Sent, where it previously counted one". Your sending hasn't changed; your denominators have.

Should I still use separate workspaces for separate brands?

Sometimes. Separate workspaces still earn their place in four cases. Audiences that genuinely don't overlap, workspaces in different data regions, two apps belonging to different legal entities or billing arrangements, and an install base that updates too slowly to clear the SDK floor. Outside those cases, the targeting reason for splitting has gone.

Is multi-app support available on all plans?

The 21 August in-app release note is tagged Builder, Essentials, Premium and Enterprise, and the multiple-apps, consolidation and push setup docs carry the same four plan tags. Treat that as the published availability and confirm in your own workspace settings, since existing push accounts may still be waiting on the rollout.

Sources

• Support in-app messages for multiple mobile apps in the same workspace. Customer.io Release Notes, 21 August 2026.
• Send push notifications to multiple mobile apps in one workspace. Customer.io Release Notes, 29 July 2026.
• Support in-app messages across multiple apps. Customer.io Docs, retrieved 1 September 2026.
• Consolidate push and in-app messaging workspaces. Customer.io Docs, retrieved 1 September 2026.
• Push notifications: getting started. Customer.io Docs, retrieved 1 September 2026.
• Set up your notification inbox. Customer.io Docs, retrieved 1 September 2026.
• Message frequency limits. Customer.io Docs, retrieved 1 September 2026.
• Test and debug in-app messages. Customer.io Docs, retrieved 1 September 2026.
• Major U.S. Cities Using National Standard Fire Hydrants, One Century After the Great Baltimore Fire. Momar D. Seck and David D. Evans, NISTIR 7158, National Institute of Standards and Technology, August 2004.
• Conflagration in Baltimore. Federal Reserve Bank of Richmond, Econ Focus, 2015 Q4.
• Great Baltimore Fire and North American fire hose coupler incompatibilities. Wikipedia, retrieved 1 September 2026.