One codebase for multiple cruise brands: a 2026 architecture guide
TL;DR
One codebase for multiple cruise brands means every brand app ships from one trunk, and the differences live in build variants, design tokens, feature flags and backend adapters instead of long-lived branches. In 2026 the systems under the apps are already merging, so the apps should follow.
- On October 22, 2026, Cruise Industry News reported that Norwegian Cruise Line, Oceania Cruises and Regent Seven Seas are moving to one Versonix Seaware platform.
- A brand branch makes you merge every fix once per brand. A brand variant gets the fix in the next build.
- Apple rejects template apps not submitted by the content owner, so each brand app ships from the brand's own account.
- Mercury Development's onboard spa platform for OneSpaWorld runs on over 160 ships operated by multiple cruise lines and reaches each line's API through middleware.
Why cruise groups end up with one app per brand
The big cruise groups run several brands each. Norwegian Cruise Line Holdings has three: Norwegian Cruise Line, Oceania Cruises and Regent Seven Seas Cruises. Royal Caribbean Group has three wholly owned brands: Royal Caribbean International, Celebrity Cruises and Silversea. Since sailings departing June 5, 2024, a member with status in one of those loyalty programs automatically attains the equivalent tier on the other two.
That one detail is the architecture problem. A guest with status on Celebrity expects the Silversea app to know it. If the brand apps were forked years ago, that status logic now lives in three places with three owners. Cruise teams put it from the other side: one app version for every line, with no separate version to support per line.
Brands differ on purpose: tone, dining program, drink packages, the way a suite guest is greeted. They rarely differ in how a booking is held, how a charge reaches the folio or how a push notification reaches a phone. Split the codebase along the first line. Share everything along the second.
NCLH is moving all three brands onto one Seaware platform
On October 22, 2026, Cruise Industry News reported that Regent Seven Seas Cruises and Oceania Cruises will adopt Versonix Seaware, while Norwegian Cruise Line will upgrade to its latest generation. Versonix describes Seaware as a foundation for reservations, inventory, pricing and distribution.
When the reservation core converges, the apps on top of it lose their last reason to stay apart. Three brand apps over one booking API can share the whole booking flow. Three forks each migrate on their own schedule, with their own bugs.
Vendors that build on the reservation core are ranked in our list of cruise line software development companies.
How we put this guide together
We read the pages that answer this query in search today. Expo's case study on Awaze shows three holiday rental brands shipped from one React Native codebase. Codemagic's white-label page and Capawesome's white-label page cover build and release pipelines. None of them deals with a ship, a cruise line or a reservation system shared across brands.
Platform rules come from vendor documentation read in October 2026. Requirement patterns come from Mercury's anonymized notes on cruise client conversations, and figures about our cruise programs from project records. Mercury Development builds this kind of software, so read this as an interested view.
Four ways to run several cruise brands at a glance
| Approach | What differs per brand | Cost of one bug fix | Breaks when | Fits |
|---|---|---|---|---|
| Separate repositories | Everything | One fix per brand, by hand | Shared rules drift apart | Brands that share no backend and no guests |
| Long-lived brand branches | Code that started equal and diverges | One fix, then one merge per branch | Merge conflicts cost more than the fix | Short experiments only |
| One codebase, build-time variants | App ID, icons, tokens, copy | One fix, one build per brand | A brand needs a different backend | Brands on the same backend |
| One codebase, variants plus runtime config and adapters | Also features, ship setup and backend calls | One fix, released to every brand | Flags pile up without owners | Groups with several lines, ship classes or reservation systems |
Keep one trunk and turn each brand into a build variant
A brand branch looks free on the day you cut it. Then every patch becomes a merge into each branch, and the branches drift.
Android has the alternative built in. Google's build variants guide lets you declare product flavors, and Gradle produces one variant per combination of flavor and build type. Each flavor can redefine its applicationId, so each brand lists separately on Google Play from the same source. Shared functionality sits in main/, and flavor source sets are where Google suggests you "change the branding of your app for different clients". Xcode targets do the same job on iOS.
Awaze did it in React Native: an EXPO_PUBLIC_BRAND environment variable selects the brand's settings, and EAS build profiles produce one binary per brand.
Then read the store rules. Apple's App Review Guidelines say in 4.3(a): "Don't create multiple Bundle IDs of the same app". Guideline 4.2.6 rejects apps made from a commercialized template unless the provider of the app's content submits them. So each brand app ships from the brand's own developer account, with its own content, and Apple's reviewers decide whether the apps differ enough.
Put the brand in design tokens, not in forked screens
Most of what makes one brand's app feel unlike another's is color, type, spacing, imagery and tone. Those are values. Store them as values, or a few years in every screen of one app starts to look like a different app.
The W3C Design Tokens Community Group published the first stable version of its specification, 2025.10, on October 28, 2025. It handles brand themes "without file duplication".
The rule for screens is short. A component reads semantic tokens such as surface.primary or text.muted, never a hex code and never a brand name. When a luxury brand needs a different layout for one page, build a brand-specific component and mount it in a named slot. The rest of the screen stays shared.
Gate brand and ship differences with flags that expire
Brands differ in what they sell, and ships differ inside a brand. One brand has a casino, another has none. That belongs in flags and ship configs, never in if (brand == ...) scattered through the code.
Pete Hodgson's feature toggles article names four kinds. Permissioning toggles change "the features or product experience that certain users receive", which is a brand or a ship. Release toggles let a feature ship to one brand first. He also warns that savvy teams treat toggles "as inventory which comes with a carrying cost".
So give every flag an owner and an expiry date. Keep brand and ship settings in a reviewed, typed config. A flag nobody owns becomes a fork in disguise.
Hide each cruise line's backend behind an adapter
Brands inside one group may share a reservation core, as NCLH's brands soon will, while onboard systems vary from line to line. Virgin Voyages runs its guest experience on the DeCurtis Experience Platform, which covers dining and activity reservations, contactless payments through the Band and a virtual queue.
A team that serves several lines, such as a concessionaire on other companies' ships, faces this every day. The app should not know which line it is on. It calls one internal API, and an adapter per line translates the shared model into that line's calls.
- Define the canonical model once: guest, cabin, booking, slot, charge.
- Write one adapter per line or reservation system. It owns that line's field names and its rules: when payment is taken, what a cancellation charges, which payment methods apply.
- Run contract tests for every adapter in every brand build, against recorded production responses. A line's test environment often behaves differently from production.
- Aggregate behind a backend for the apps, so a screen makes one call.
When the line's API is not ready yet, build against a contract, as our guide to mobile development when the backend is not ready shows.
Which approach fits your fleet
- Several brands on one reservation core: variants plus tokens, with a shared booking flow.
- Brands that differ by ship class or venue: add typed ship configs and permissioning flags.
- Apps that run on several lines' ships: an adapter per line behind one internal API.
- Forked brand apps today: pick the healthiest fork as trunk and move shared modules into it one at a time.
- Brands that share no guests or backend: separate repositories are honest.
Whatever the brand setup, the ship side needs its own source of truth, covered in our guide to offline-first mobile apps for ships.
What our cruise programs show
These details come from Mercury's project records for the OneSpaWorld program and for a cruise line program under NDA.
OneSpaWorld describes itself as the operator of health and wellness centers onboard cruise ships. Mercury's platform for its spa staff has been in production since 2018 on over 160 ships operated by multiple cruise lines. It runs as ReactJS web applications on onboard servers, and middleware connects it to OneSpaWorld's ship-side backend, its shore data exchange and APIs specific to each cruise line. Intake forms are branded and localized into several languages. Checkout prices dynamically with offers from both OneSpaWorld and the cruise lines, and the admin side covers voyage setup and configuration per ship.
The E-Forms platform in the same program runs on more than 1,000 devices used by over 3,000 staff members. Each form is one object with a version history of every question and answer, visibility rules and its own branding.
The second program, for a major cruise line that Mercury cannot name under NDA, has run since late 2021. It covers React Native food and beverage apps, dining host and tableside ordering tools, and backend components that aggregate data and functions from dozens of legacy microservices behind a new aggregating middleware for passenger apps.
How much a shared brand codebase saves is shown in our guide to cruise app development cost.
Fork a brand only when the business forks
Opinion, with the mechanism.
A brand branch is a decision you make once and pay for on every release. If two brands share guests, a reservation core and a loyalty match, they are one product, and the codebase should say so.
Change the vendor interview. Ask: "Show me the file that makes a brand a brand, and the last commit that fixed a bug in every brand at once." A team that works this way opens a config file. A team that does not opens a branch list.
Own the trunk. Mercury's About page states that all work is work-for-hire and the customer owns the code and all underlying IP.
Written by Alexey Rodionov, Lead Front-end Developer at Mercury Development since 2020. Alexey is a Google Developer Expert in Web Technologies and a Chromium contributor whose code ships in Chrome DevTools, Google's Bubblewrap and Microsoft PWABuilder. The architecture notes behind this article's account of Mercury's cruise programs come from the front-end practice he leads.
Running two or more brand apps? Start with a variance map
Tell us which brand apps you run and which systems each one calls. We will map what really differs by brand, ship and line, and what can merge back into one trunk, before you commit to a rebuild.