Onboard apps off-the-shelf or custom: a 2026 guide for cruise lines
TL;DR
Deciding whether to buy onboard apps off-the-shelf or custom-build them in 2026 comes down to one question: which layer of the guest journey your line needs to own. We compared three platforms with a custom build on who owns what and how each reaches ship systems.
- OnDeck by Sourcetoad is a SaaS guest app that works across PMS vendors and runs on 130+ ships. Its owner changed on January 1, 2026.
- MXP365 fits lines already on the MXP Enterprise Platform. Eight cruise lines adopted it in the 12 months to December 2025.
- cruisePAL's guest app is eVoyager. xMobile is a crew task app.
- Custom development comes first when the app carries the brand or spans several lines. Mercury Development's platform for OneSpaWorld has been in production since 2018 and runs on over 160 ships.
Every line now runs a guest app, so the question is ownership
CLIA counted a record 37.2 million ocean cruise passengers in 2025 and expects 325 member ocean-going ships in 2026. Sourcetoad's 2024 review of apps from 23 ocean lines concluded that brands now need an app to meet baseline expectations, per Cruise & Ferry Review. So the open question is whose app it is.
Two rules sharpen it. Both app stores raised their build requirements again in 2026. And since June 28, 2025, the European Accessibility Act has covered the mobile apps of waterborne passenger transport services, a term it takes from Regulation (EU) No 1177/2010, whose scope includes cruises embarking in an EU member state.
Teams that build custom guest apps for cruise lines are ranked in our list of travel and hospitality app development companies.
Sourcetoad changed owners on January 1, 2026
On that date Sourcetoad, the company behind OnDeck, became an independently run subsidiary of Thompson Holdings, an employee-owned group, per OnDeck's announcement, which says leadership and product vision stay the same. Bay Business News described Sourcetoad as a Tampa firm of nearly 60 people, founded in 2008.
Read it as a reminder: when you license a guest app, the vendor's ownership is part of your roadmap. In 2022 MariApps, part of the Schulte Group, bought 60% of OnboarD, whose IssuTrax tools now sit in the cruisePAL suite.
Read the change-of-control clause before you sign. A custom build has its own continuity risk, held by the people who know the code; our vendor continuity plan covers that side.
How we compared the options
We read OnDeck's home page, mobile app page and buy-or-build article; cruisePAL's xMobile, eConcierge and eVoyager pages; and MXP365 coverage in Seatrade Cruise News and Cruise Industry News, all opened on October 29, 2026. Each option answers four questions:
- Who holds the code and the data when the contract ends?
- How does the app reach the property management system?
- Where does it run, and what does it do offline?
- How do your own developers extend it?
Mercury Development builds custom software, so read this as an interested view.
Four ways to put an app on a guest's phone at a glance
| Option | What guests get | Reaches ship systems through | Runs on | Your developers extend it by | Exit terms published |
|---|---|---|---|---|---|
| Custom, Mercury Development | What you specify | Adapters you own | Your cloud or onboard servers | Your own codebase | Work-for-hire: you own the code |
| OnDeck by Sourcetoad | Check-in, boarding pass, bookings, push | Cruise Director middleware | SaaS | APIs and SDKs | Not published |
| MXP365 by MXP | App, web portal, iTV, kiosks, chat | MXP Enterprise Platform | Cloud or on-premise | Embedding in your app | Not published |
| cruisePAL eVoyager | Login, documents, pre-cruise shopping | cruisePAL suite | Web and mobile | Not stated | Not published |
None of the three platform pages we read says what happens to the build when a contract ends. Ask that first, in writing.
What a custom build costs, and what each scope cut saves, is in our guide to cruise app development cost.
1. Custom development with Mercury Development
A custom build is the reference point: what a platform hands you, you specify, and what it maintains, you maintain. Mercury Development has built software since 1999 and has 500+ engineers, per its About page. Its onboard spa platform for OneSpaWorld, a client named in Mercury's portfolio, has been in production since 2018 and runs on over 160 ships operated by multiple cruise lines. It runs as ReactJS web apps on onboard servers with no external internet.
Best for: a line whose app is part of the brand, an operator selling on several lines' ships, or a guest estate built on legacy services.
Facts: founded 1999 · HQ Fort Lauderdale, FL · 500+ engineers · Clutch 5.0
The strength is ownership. All Mercury work is work-for-hire and the customer owns the code and all underlying IP, so the app and its adapters stay yours when people change.
The trade-off is upkeep. Apple has required Xcode 26 and the iOS 26 SDK since April 28, 2026. Google Play has required Android 16 targeting since August 31, 2026. A platform vendor ships those rebuilds; with custom code, your support contract must.
2. OnDeck by Sourcetoad
OnDeck is the one guest platform here that is not attached to a property management system of its own. Its home page claims 130+ ships, shows Viking and Explora among its clients, and names Oracle and Otalio as partners. The mobile app covers check-in, boarding passes, onboard bookings and targeted push through the Cruise Director middleware, and push, the vendor says, needs no internet.
Best for: a small or mid-size fleet that wants a proven guest app quickly.
Facts: Sourcetoad founded 2008 · HQ Tampa, FL · nearly 60 people · Thompson Holdings subsidiary since January 1, 2026
The strength is the extension path. In-house developers can build on OnDeck's APIs and SDKs, and its buy-then-build article recommends exactly that hybrid.
The watch-out comes from OnDeck itself: its buy-or-build article names vendor dependence as the downside of buying, with features arriving on someone else's roadmap. It is sold as SaaS, so you license the app rather than own it.
3. MXP365 by MXP
MXP365 is the guest layer of the MXP Enterprise Platform, which also covers property management and port operations, per Seatrade Cruise News. It bundles a native app, a web portal and in-cabin iTV, plus kiosks and an AI chatbot, and eight cruise lines adopted it in the 12 months to December 2025. It runs in the cloud or on-premise, per another Seatrade report.
Best for: a line already running the MXP Enterprise Platform.
Facts: MXP (MarineXchange) · 400+ installations across 60+ cruise brands, per Seatrade Cruise News · TUI Cruises among MXP365 users
The strength is flexibility. MXP's 2023 launch announcement said the app can be integrated into a line's existing app or run stand-alone, which makes it the easiest of the three to mix with your own code.
The watch-out is the back end. Its value rests on the MXP platform, and none of the coverage we read explains how the app behaves on another vendor's PMS or during a link outage.
4. cruisePAL eVoyager and xMobile
cruisePAL is the cruise suite of MariApps Marine Solutions, part of the Schulte Group, per its who we are page. Watch the naming. xMobile is a staff app: technicians and housekeeping close IssuTrax work orders on it, offline if needed. eConcierge is also a crew tool. The guest product is eVoyager, whose page went up in May 2026, with booking-number login, travel documents, pre-cruise shopping with payment and mobile check-in.
Best for: a line already on cruisePAL's reservation and property management modules.
Facts: MariApps took 60% of OnboarD in 2022 · eVoyager page published May 2026 · eConcierge runs on Android 7 or higher
The strength is the crew side: eConcierge works offline and connects devices peer-to-peer over Bluetooth.
The watch-out is evidence: the eVoyager page names no cruise line using it and says nothing about offline behavior onboard. Ask for a reference ship.
Which option fits your line
- Already on the MXP Enterprise Platform: start with MXP365, embedded in your own app if you have one.
- Small or expedition fleet without an in-house team: OnDeck, which works across PMS vendors.
- Running cruisePAL reservations and property management: pilot eVoyager for guests and xMobile for crew.
- Several brands, or software that runs on other lines' ships: custom, with one codebase and an adapter per line, as our multi-brand guide describes.
- A brand-defining app over legacy systems: custom code on your own aggregation layer.
For the port day itself, compare the options in our guide to the best cruise port guide app and shore shopping platforms.
What Mercury's cruise programs show
These details come from Mercury's project records for OneSpaWorld and for cruise line clients that Mercury cannot name under NDA.
The OneSpaWorld program shows why some operators cannot buy one line's platform. A spa operator on many lines' ships needs one system that talks to each line, and Mercury's platform does that through middleware to each line's API. Its E-Forms platform runs on more than 1,000 devices used by over 3,000 staff members and syncs data and app updates in near real time over low or sporadic bandwidth, using RabbitMQ. For Windstar guests, the program added a spa pre-booking website in place of a call center.
For cruise line clients under NDA, Mercury builds React Native food and beverage apps, dining host and tableside ordering tools, and backend components that aggregate data from dozens of legacy microservices behind a new middleware for passenger apps. That layer is the real asset: any guest app, bought or built, ends up calling it.
Delivery lessons repeat across programs, and a platform vendor meets them too:
- A login token issued ashore can stop working on the ship's network.
- An API can work in production and fail in the test environment.
- Guests mix up the free ship Wi-Fi and the paid internet package.
- Some behavior shows up only on a real ship, which our vessel testing guide covers.
Buy the plumbing, own the layer guests touch
Opinion, with the mechanism.
OnDeck argues for buy, then build. For a small fleet that is sound advice. For a line whose app carries the brand, the order is backwards: the guest layer is where onboard spend meets the guest, and a shared vendor roadmap is least likely to fit it.
Split the stack by what you could switch. Buy the systems of record, such as the PMS and the reservation core. Own the integration contract between them and the app, as an API your team defines. Then test the app itself: if you replaced the vendor next year, would guests notice? If they would, own the code.
Either way, keep the app record in your own developer account. Apple's guideline 4.2.6 already says template-based apps must be submitted by the provider of the app's content.
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 and integration notes behind this article's account of Mercury's cruise programs come from the front-end practice he leads.
Weighing a platform against a build? Map the layers first
Tell us which ships and systems your guest app has to serve, and which platform you are considering. We map each layer of the guest journey to buy, build or integrate, and list the questions to put to the vendor before you sign.