Mobile development when the backend is not ready: 2026 cruise guide
TL;DR
Mobile development when the backend is not ready still works in 2026 if the team builds against an agreed API contract with mock data, logs every client dependency with an owner and a date, and starts the clock only once access exists. Cruise app programs stall on access, unfinished APIs, QA that differs from production and missing test data.
- Collect VPN, accounts, API docs and store access before kickoff.
- Only an App Store Connect Admin can create team API keys, and the private key downloads once.
- TestFlight builds expire after 90 days, so store access needs its own date.
- Mercury Development's onboard spa software for OneSpaWorld has run on over 160 ships since 2018.
Why cruise app programs stall before the first sprint
Demand is not the bottleneck. Seatrade Cruise News, citing CLIA, reported 37.2 million ocean cruise passengers in 2025, up 7.5% from 34.6 million in 2024. Guest and crew apps for that fleet sit on systems the cruise line owns and the app vendor does not.
A mobile team can draw screens on day one. It cannot call an API it cannot reach, sign in with an account nobody created, or test a flow whose data lives only in production. Each of those waits on someone at the client who has a day job.
Teams lose time this way even in-house. Atlassian's 2025 developer experience research, a survey of 3,500 developers and managers, found that half of developers lose 10 or more hours a week to inefficiencies, and named finding information such as docs and APIs the top friction point. Put a VPN request and a ship in the way, and every search becomes a ticket in someone else's queue.
Apple and Google raised the release bar in 2026
Two store deadlines passed this year. Since April 28, 2026, Apple requires apps uploaded to App Store Connect to be built with Xcode 26 or later, using the iOS 26 SDK or its siblings. Since August 31, 2026, Google Play requires new apps and updates to target Android 16, API level 36.
Neither rule is hard to meet. Both assume someone can upload. On cruise programs the store accounts belong to the cruise line, and a vendor without a role in them cannot ship a compliance update, however ready the code is.
How we put this guide together
We read the pages that answer this question today: Surf's mock server story, Evil Martians' contract-first guide, Nabil Kazi's Mockoon walkthrough and a FitGap guide to environment readiness from January 2026. Each covers mocking or access. None covers both, and none deals with a ship.
Platform docs were read in October 2026. Cruise patterns come from Mercury's delivery records, without client names or counts. Mercury Development builds this kind of software, so read this as an interested view.
Four blockers at a glance
| Blocker | What the team sees | Who can fix it | First move |
|---|---|---|---|
| Access | No VPN, no identity account, test accounts that expire | Client IT and security | Send the access checklist with the contract |
| API not ready | Endpoint missing, undocumented or short of fields the design needs | Client backend team | Agree a contract, build on mock data |
| QA differs from production | A call works in production and fails in QA | Client platform team | Log each difference as a dependency with an owner |
| No test data | Empty QA, accounts that cannot reach the flow | Client product and QA | Script synthetic guests for every role and voyage state |
The pre-kickoff access checklist
Send this list with the contract, not after kickoff. Every line gets a named owner at the client and a date.
- VPN access for each engineer, with the approval path and lead time written down.
- Identity accounts in the client's directory, and the groups each role needs.
- Test accounts per guest and crew role, with expiry dates and the person who renews them.
- QA and staging URLs, checked from the vendor's network on day one.
- API documentation, sample payloads and the error codes each endpoint returns.
- App Store Connect access with a role that can upload builds and manage TestFlight. Per Apple's documentation, only an Admin can generate team API keys, and the private key downloads a single time.
- Play Console access. Only the account owner or an admin can invite users, per Play Console Help, and the Play Developer API guide invites a service account for automated uploads the same way.
- Signing certificates, push notification credentials and SDK keys for analytics and crash reporting.
- A test window on a ship, if any feature depends on the onboard network.
Store access deserves its own date. TestFlight allows up to 100 internal and 10,000 external testers, drops a build after 90 days, and may review the first build sent to external testers. A team that gets store access in launch week cannot absorb that review.
Build against a contract and mock data
Waiting for the backend is the expensive option. Agree the shape of each call, then build against a fake that honors it.
- Write the contract in OpenAPI before either side codes. Prism turns an OpenAPI v2 or v3 document into a mock server and later works as a validation proxy in front of the real API.
- Mock inside the app for fast UI work. Mock Service Worker ships a React Native integration, @msw/react-native, and its own docs say to use it at your own risk because React Native lacks some browser APIs.
- Hide unfinished flows behind release toggles. Pete Hodgson's feature toggles article describes them as a way to ship incomplete code paths as latent code.
Mock data has to look like production data. Build fixtures from real responses with personal data replaced, and include the ugly cases: a guest with two bookings, a dinner slot that sold out. On iFund for HSBC, Mercury built a test server with obfuscated test data that simulated HSBC's environment, then integrated with HSBC's servers near the end of the project.
Mocks hide performance and missing fields. Add contract tests such as Pact as soon as a real endpoint exists, so a field the design needs fails a test instead of a demo.
If the same app serves several brands, the contract sits behind one adapter per line, as in our guide to one codebase for multiple cruise brands.
Keep a dependency register with owners and dates
A RAID log tracks risks, assumptions, issues and dependencies, and TechRepublic's guide puts an owner and a due date on every item. For a cruise app, give dependencies their own register and review it with the client's product owner weekly.
| Column | What goes in it |
|---|---|
| Dependency | Dining reservation API returns venue capacity |
| Client owner | A named person, not a team |
| Date needed | The sprint that starts the screen |
| Date promised | What the owner committed to |
| Blocks | Screens and store builds waiting on it |
| Fallback | Mock in place, release toggle off |
| Status | Open, at risk, delivered, verified in QA |
Two rules keep it honest. Every blocked ticket links to a row. A row closes when the team verifies it in QA. A status message alone never closes it.
The same register works outside cruise, as our breakdown of healthcare software project delays shows.
Close the gap between QA and production
The Twelve-Factor App names three gaps between development and production: time, personnel and tools. Cruise programs add a fourth, the ship.
Patterns we have seen on cruise programs:
- An API works in production and fails in QA, so nobody can test the flow before release.
- A login token issued ashore stops working once the guest joins the ship network.
- An endpoint exists but lacks metadata the approved design needs.
- Some behavior reproduces only on a real ship, on its network and hardware.
Log each one as a dependency with an owner. Keep an environment matrix: every integration, its QA and production URLs, and whether QA returns real-shaped data. Run the same contract tests against both. If a call can only be verified in production, agree who checks it and before which release.
The last part of that gap only closes on board, which is why we plan real-vessel cruise ship app testing.
Tie the deadline to client readiness
A date that ignores access is a guess. Each milestone should name the dependencies it needs and move when they slip.
- Split build scope from readiness scope in the statement of work. The vendor owns the first, the client the second.
- Date features relative to readiness: a set number of sprints after the last dependency is verified in QA.
- Price discovery and stabilization as their own line, so waiting does not quietly burn the build budget.
- Cut instead of stretching. When a dependency slips, keep the feature behind its toggle and ship the rest.
How to read the dates in a vendor bid is covered in our guide to the software development timeline estimate.
What our cruise programs show
Mercury's onboard spa platform for OneSpaWorld, which describes itself as the operator of health and wellness centers onboard cruise ships, has been in production since 2018 on over 160 ships operated by multiple cruise lines. It runs on onboard servers without external internet and reaches each cruise line's API through middleware. Its E-Forms platform serves 1,000+ devices and over 3,000 staff members, syncing data and app updates in near real time over low or sporadic bandwidth.
For cruise line clients Mercury cannot name under NDA, we build React Native food and beverage apps, dining host and tableside ordering tools, and backend components that aggregate dozens of legacy microservices. Most patterns in this guide come from that work: expiring test accounts, slow VPN access and APIs that work only in production.
How blocked time shows up in a cruise budget is broken down in our guide to cruise app development cost.
Access is part of the build
Most proposals treat access as a kickoff formality. It is the first deliverable, and the client produces it. A program that starts the clock before accounts exist pays engineers to read documentation that may be wrong.
Change the vendor interview. Skip "have you built a cruise app". Ask: "The dining API will be late and QA does not match production. Show me your mock and how the date moves." A team that has done this opens its dependency register. A team that has not promises to be flexible.
Keep what the team builds while it waits. Mercury's About page states that the customer owns the code and all underlying IP, mocks and fixtures included.
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 integration notes and release checks behind this article's checklist come from the front-end practice he leads.
Starting a cruise app program? Check access before the first sprint
Tell us which systems your app will call, who owns each one and what your vendor can reach today. We will turn that into an access checklist and a dependency register with owners and dates, so your first sprint builds features instead of waiting for accounts.