Passing App Review with an app that needs your Mac

Six commits before breakfast.

The fixes were written in Luminair sessions, and every commit that morning carries a Claude co-author line. They also happened fast, which is the point of an agent harness when a review clock is running.

This post was drafted the same way, from the phone app's source and its history. Where the code tells a story in its comments, we quote it.

More apps, and more rules.

Apple's review has been adjusting to AI from two directions. On 13 November 2025 it revised its guidelines, and TechCrunch reported the added sentence in 5.1.2(i): “You must clearly disclose where personal data will be shared with third parties, including with third-party AI, and obtain explicit permission before doing so.”

In March 2026 MacRumors, citing The Information, reported that Apple had blocked updates to vibe coding apps such as Replit and Vibecode, which it said breach rules “prohibiting apps from executing code that alters their own functionality or that of other apps.” In April 9to5Mac summarised the other side: new apps in the App Store were “growing 30% to nearly 600,000 compared to 2024”, a surge the report ties to tools like Claude Code and Codex. Apple said its team “processes 90% of submissions within 48 hours”.

A lot more apps are being built with agents, and review is paying closer attention to what AI apps do. Luminair's phone app sits in the middle of that: it is an AI app, built with AI, whose whole job is to talk to agents running somewhere the reviewer cannot see.

Google, and an equal alternative.

The phone app offered Google sign-in. Guideline 4.8 says an app that uses a third-party or social login “to set up or authenticate the user's primary account with the app must also offer as an equivalent option another login service”, one that limits data collection to name and email, lets users keep their email private, and does not collect interactions for advertising without consent. Apple rejected the build on that basis.

The first commit of the morning, at 05:54, added native Sign in with Apple. It uses the system sheet, sends Apple a hashed one-time nonce and hands the raw nonce to Firebase, so the Apple identity becomes a normal account through the same landing code as every other sign-in. The black Apple button sat above the Google one, as Apple's design guidance asks, and the entitlement went into both app build configurations.

A few steps still needed a human in Apple's and Firebase's consoles: enabling the capability on the app ID, regenerating the provisioning profile and turning on the Apple provider. The commit message lists them as a checklist rather than pretending the code alone was enough.

“Searching Connection…”

The second finding was harder, because it was not a bug. Guideline 2.1(a) asks for complete submissions and says to “include demo account info (and turn on your back-end service!) if your app includes a login.” The commit that answered it describes the problem in one line: a reviewer signing in with no Mac online “only sees a 'Searching Connection…' waiting screen”.

That screen is correct for a real user. You are signed in, your Mac is off, and the phone is waiting for it to come online. For a reviewer it is a dead end: there is nothing to tap, no session to open, nothing to judge. A demo login alone would not have helped, because a demo account with no computer behind it looks exactly the same.

The guideline also mentions a built-in demo mode, with Apple's prior approval, for apps that cannot provide a demo account. Luminair's answer ended up somewhere between the two: a real sign-in step that leads into a workspace that needs nothing behind it.

The phone signs in as your computer's account.

By 07:04 the morning's work had changed the phone's front door. Instead of a separate login, the desktop app mints an eight-character code, valid once and for ten minutes. The phone trades it for a session on the same account, and any older active codes are retired. The reviewer notes written at 07:35 put it simply: “the phone is a window into an existing desktop account”. Today the signed-out phone screen shows one thing, the eight-square code gate.

That design also answered the reviewer problem. A code can be reserved. The first version pinned a permanent code to a server-side demo account whose chats ran in a clamped “valet mode”: a separate, spend-capped key, forced to Sonnet, no extended thinking, a short reply ceiling and no desktop mirror. The next day the reserved code moved entirely onto the device:

// App Store review (guideline 2.1a): the reserved demo code drops straight into
// the self-contained demo, no Mac, no pairing, no network.
if (isDemoCode(code)) {
  // persist, so a relaunch mid-review lands back in the demo
  localStorage.setItem("ow:demo", "1");
  await afterCloudSignIn(DEMO_USER);
  return DEMO_USER;
}
const u = await redeemCode(code);         // everyone else: the real pairing path

The flag matters more than it looks. Reviewers relaunch apps. Without it, a relaunch would drop them back on the code gate, and the next reviewer note would be about that. The same notes also told Apple what the phone does not do: it “does not run code or a terminal”, which stays on the computer.

Real enough to review, sealed from real accounts.

The demo workspace is built on the phone: seeded conversations, projects, and later a queue and a Branch Out result to show those features too. It presents itself as connected, so nothing shows the waiting screen, and it lands the reviewer straight in the first conversation. Sending a message gets a local reply that explains it is a demo, so a tap never hangs waiting for a Mac.

The harder part is making sure demo mode can never leak into, or out of, a real account. The app checks one process-wide flag at every point where it would reach the outside world. The app's main file reads that flag in 16 places today.

The fence was tested the hard way at least once. A comment added on 8 August explains why the code-entry path must also set the signed-in user: without it the app stayed on its empty onboarding screen, “the black screen the reviewer hit”. The relaunch path already did it; the fresh code-entry path forgot. That one-line gap is exactly the kind of thing a reviewer finds first.

The demo has had a second life since. The same seeded workspace, with build flags that land on the list or open a chat on iPad, produced the App Store screenshots in September.

If your app needs a second device.

1. 1Walk your own review path on a clean phone with the other device switched off. Whatever you see is what the reviewer sees.
2. 2Give the reviewer a door that needs nothing behind it, and put it in the same place real users enter, so you are not reviewing a different app.
3. 3Fence the demo with one flag checked at every network edge, and make sign-out clear it.
4. 4Persist demo state across a relaunch. Reviewers relaunch.

The team also keeps a written playbook for review feedback in its Journal. Its first rule is “Fix the cited cause first”, and another is that “Uploaded” is not “submitted” is not “in review”: check each step against the real state before saying it happened.

Checked, and not claimed.

Sources

• TechCrunch · 13 November 2025Apple's new App Review Guidelines clamp down on apps sharing personal data with 'third-party AI'
• MacRumors · 18 March 2026Apple Quietly Blocks Updates for Popular 'Vibe Coding' Apps
• 9to5Mac · 6 April 2026App Store sees 84% surge in new apps as AI coding tools take off
• Apple DeveloperApp Review Guidelines