We Built a Party App. Then We Met the App Review Gods.

Or: how two chosen display names and one session title turned a tiny audio recorder into a two-week compliance odyssey.

Every developer tells themselves the same lie before a launch: “It’s a small app. This’ll be quick.”

Reader, it was not quick.

This is the story of shipping PartyCorder — what it does, why it confused two of the biggest review teams on the planet, and what actually happens behind the curtain when you press “Submit for Review” on Apple’s App Store and Google Play. If you publish apps for a living, some of this will feel like looking in a mirror. If you don’t, consider this a friendly warning about what “just put it in the store” really means in 2026.

First things first: what even is PartyCorder?

PartyCorder is a party audio recorder with a twist that turns out to be the whole problem.

Here’s the pitch: only the host’s phone records. The host starts a session, the app keeps a rolling audio buffer of the last 30–60 seconds, and that’s it. Guests join the session with a random 5-letter party code and — crucially — their phones don’t record anything. Guests are basically a big red “REMEMBER THAT” button. When something hilarious happens at the party, any guest can tap it, and the host’s phone quietly saves the last few seconds as a clip. All the audio lives on the host’s device and nowhere else.

Think of it as a group-powered “wait, rewind, what did he just say?!” for real life.

You can read all about it and grab it here:

→ PartyCorder on losandros.com

• Android: available now on Google Play
• iOS / App Store: now live — and after you read the rest of this post, you’ll understand exactly why that took a little longer than planned.

The “community features” that started it all

Here’s the part that’s almost funny in hindsight. PartyCorder’s entire social surface area is:

1. Your display name — so the crew list shows who’s in the session.
2. The session name — which the host types in when starting the party.

That’s it. No profiles, no messaging, no photos, no public feed, no audio shared between users, no directory of parties to browse. Two text fields. And yet, in the eyes of an app store, two text fields that a human can type into = user-generated content. And user-generated content brings the full rulebook down on your head, whether your app is a global social network or a glorified stopwatch with a name label.

That’s the lesson tattooed on my soul now: it doesn’t matter how small the door is. If a user can type a word through it, you’re a UGC app.

A timeline (with one very important gap)

Let me walk you through the two weeks, because the shape of it is the real story.

• Mon, July 7 — Rejection #1. Apple’s first reply is the “Guideline 2.1 — Information Needed” template. They want a screen recording, a device list, a description of the app’s purpose, external services used, regional differences, the works. An automated check also flags that the app “may include a login” and asks for a demo account.
• Tue, July 8 — “There is no login.” I explain there are no accounts, no registration, no passwords — just a host/client pairing model with a session code. I add the info to App Review. Same evening, Apple comes back with a brand new issue: Guideline 1.2 — User-Generated Content. (Reviewed on an iPad Air 11-inch M3, if you’re keeping score.) The two typed text fields have been spotted.
• Wed, July 9 — The clarification. I write back explaining that PartyCorder’s UGC scope is genuinely tiny: no audio is shared between users, sessions are private and invite-only via a code, and the only thing anyone sees of anyone else is a display name and a session title. But I also commit to building the full UGC safety suite anyway. Videos attached.
• Thu, July 10 — “The issues still need your attention.” Apple is unmoved. Guideline 1.2, round two. Build (32).
• Fri–Sat, July 11–12 — THE LONGEST BRACKET IN APP REVIEW HISTORY. And here’s the gap. For two glorious days, nothing happened on App Store Connect — because I was playing in a 5-on-5 basketball tournament. Sometimes the most important thing you can do for your app is put the phone down and go box out a stranger for a rebound. The submission queue does not care about your jump shot, and honestly, that was healthy. Zero commits. Zero replies to Apple. Full send on the fast break. The only bracket that mattered that weekend had a hoop at the end of it.
• July 18–19 — Heads-down, then resubmit. Back at the desk, I built and shipped the whole moderation kit (more on that below) and resubmitted with a screen recording of every required flow. Build (35).
• Mon, July 20 — Plot twist. Apple now moves off the UGC issue and onto Guideline 2.1(a) — Information Needed, reviewed this time on an iPhone 17 Pro Max. Their new ask: give us a demo account with pre-populated content — “such as the letter code from the host” — because “a demo video showing the app in use is not sufficient.”
• Tue, July 21 — The Demo Mode reply. I explain, again, that there are no accounts to hand over credentials for… and point them to the thing I built specifically for this: a Demo Mode and a magic join code (DEMOX) that spins up a fully simulated session — pre-populated crew list, filled audio buffer, all features reachable on a single device with no second phone and no internet. Reviewer opens the app, taps two buttons, sees everything.
• Wed, July 23 — One more round. Apple is back. iPad Air 11-inch M3 again, Build (37), Guideline 2.1(a) once more. This time they ask specifically for “the 4-letter code in order to join the party” — worth noting: the code is 5 letters, not 4, but let’s not get distracted. They reiterate that a demonstration mode is acceptable, that a video is not. So I send a step-by-step walkthrough for both flows: HOST (tap “HOST THE PARTY” → scroll to “DEMO MODE” at the bottom of the pre-live screen) and GUEST (tap “JOIN THE PARTY” → enter D · E · M · O · X on the A–Z keypad → enter any display name → accept community standards → join). Video attached again. Credentials: still none. There are no usernames or passwords anywhere in this app.
• Wed, July 23 — The gods have spoken. Hours later, same day: “Congratulations! Review of your submission has been completed. It is now eligible for distribution.” PartyCorder is live on the App Store.

Seventeen days. Eight messages. Three different review devices. One basketball tournament. And in the end, two taps into a Demo Mode was all it took.

Why the concept is genuinely hard to understand

I want to be fair to the reviewers here, because I think this is the crux of it.

A review team sees hundreds of apps. Their mental model is built from patterns: app has a text field — probably UGC. App has people joining a “session” — probably accounts. App is social — probably needs demo credentials. Those heuristics are correct 95% of the time, which is exactly why they’re used.

PartyCorder lives in the awkward 5%. It feels like a social app (there’s a crew list! there are names!) but it has no accounts. It looks like it shares content (people join a session!) but no audio ever leaves the host device. It has the silhouette of three different app categories and belongs cleanly to none of them. When your app doesn’t match the pattern, every automated check and every human reviewer has to stop and actually think — and the safest thing for them to do when confused is to say “provide more information.”

So the difficulty in publishing wasn’t really about the code. It was about explaining an unusual architecture to someone who has 90 seconds to evaluate it. The fix wasn’t just building features — it was building a demonstration of the app that requires no explanation at all. Which is why Demo Mode exists now. Turns out the best compliance feature is one that lets a stranger understand your app without reading a single paragraph.

What the UGC rulebook actually demands

For anyone facing the dreaded Guideline 1.2, here’s the full checklist Apple wants to see — and what we built for two little text fields:

• A EULA with zero-tolerance language, shown before you can join — we added a “Community Standards” section to the Terms of Use with an explicit no-tolerance clause for offensive names and abusive behavior.
• An agreement gate — a “View Terms of Use” link and a checkbox that keeps the JOIN button disabled until you accept. No bypass.
• Automated content filtering — every display name runs through a word filter at entry, so offensive names are blocked before anyone else ever sees them.
• A flag mechanism — any participant can report any other from the crew list; it writes a moderation log entry and visibly flags the reported user.
• A block mechanism — instantly removes someone from your view (no server round-trip) and auto-files a report to the developer.
• A host kick — removes a guest from the session and stops them rejoining.
• A 24-hour response commitment — documented in the Terms and Privacy Policy.

If your app has so much as a comment box, save this list. You’ll need all of it.

Meanwhile, on the other side of the fence: Google Play

Android shipped first, and the contrast is instructive.

Apple’s process is human-first: a real reviewer opens your app on a real device (they name the device and OS in every message — iPad Air M3, iPhone 17 Pro Max), and the whole thing is a conversation. You reply, they reply, back and forth, sometimes for days. It’s high-touch, occasionally maddening, and when it goes sideways it goes sideways in prose.

Google Play is policy-and-declaration-first: you fill out a Data Safety form, declare your target audience and content rating, provide a privacy policy, and meet the target-API-level requirement. Then you submit… and you wait. In our case Google took a full six days to approve PartyCorder — and here’s the punchline: they asked for nothing. No messages, no clarifications, no demo account, no “show us the moderation flows.” Just six days of radio silence and then, quietly, a green checkmark. The exact same two text fields that sent Apple into a two-week interrogation didn’t earn so much as a raised eyebrow on Google’s side.

Which tells you everything about the difference in temperament. Apple is the reviewer who wants to watch you use the app and will keep the conversation going until they’re satisfied. Google is the reviewer who takes your paperwork into a back room, disappears for the better part of a week, and comes back with a stamp and no small talk. Apple asks “show me it works.” Google asks “did you declare it correctly?” — and if the answer is yes, it just… approves. Both have UGC and objectionable-content policies on the books; only one of them made us film ourselves tapping the flag button on a physical device.

Neither is easier, exactly. Apple’s process is high-touch and can spiral, but at least you always know what it wants. Google’s is low-touch and mostly painless, but the silence can be its own kind of stressful — six days of “is something wrong, or is this just how long it takes?” with no way to tell which.

The takeaways, if you’re about to do this to yourself

• Any typeable text field makes you a UGC app. Plan the moderation suite before you submit, not after Apple finds the field for you.
• Your architecture is not self-evident. If your app breaks the reviewer’s mental pattern, build a demo path that explains itself in two taps. A “demo mode” beats a demo video every time — Apple literally told us the video wasn’t enough.
• “No accounts” is a sentence you will say many times. Automated checks assume login flows. Be ready to prove the negative.
• The two platforms have different temperaments. Apple wants a live demonstration and will talk to you until it’s happy. Google wants accurate paperwork, then goes quiet — ours took six days and asked for nothing. Prepare for both the interrogation and the silence.
• Sometimes the right move is to go play basketball. The queue will still be there Monday, and you’ll argue your case better with a clear head.

One serious note before you hit record

We keep the tone light around here, but this part isn’t a joke: in most places it is illegal to record people without their knowledge or consent. Recording laws vary by country and even by state or region — some require everyone in the conversation to agree, not just the person holding the phone. PartyCorder is built for fun, shared moments among people who want to be part of the memory, so please use it that way.

The rule of thumb is simple: make sure everyone in earshot knows the party is being recorded and is happy about it. Tell your guests, get a thumbs-up, and if anyone isn’t comfortable, don’t record. It’s their voice too. Good vibes only — legally and socially.

For the full details on how the app handles your data and what you’re agreeing to when you use it, please read:

• Terms of Use
• Privacy Policy

Both are also available inside the app from the Settings screen.

Grab it (responsibly)

PartyCorder is live on both Android and iOS. Start a session, make sure your crew’s on board, and let your friends immortalize the best (and worst) things anyone says at your next party:

• Get it on Google Play (Android)
• Get it on the App Store (iOS)
• Everything on losandros.com

The App Store gods said yes. Maybe don’t name your session anything the word filter would blush at.

One last thing worth mentioning: all store assets, screenshots, and translations for PartyCorder — as well as the release notes — were created and uploaded with the support of App Store Manager. If you’re shipping on both platforms, it’s the tool that keeps the whole process sane.