I submitted my first app. Apple rejected it.

The email came in the morning. Not the right one.

The night before, I had submitted Souffle — my first app, three months of evenings and weekends. Build 81, the RC, the one that was finally going from TestFlight to the App Store. I had filled in every field in App Store Connect with care, rewritten the description four times, uploaded screenshots in three sizes. I was ready.

Apple, apparently, disagreed.

Four rejection reasons. Not one, four. The kind of email that makes you set down your coffee and read it three times to make sure you're not dreaming.

The tax trap

The first reason — guideline 2.1b — said the reviewer couldn't find my in-app purchases. The Tip Jar, the little "buy me a coffee" button I'd set up for people who wanted to support the project.

I spent ten minutes checking my code. Everything was in place. The IAPs were configured in App Store Connect, the StoreKit code worked in sandbox. What was wrong?

The answer was in a tab I'd never opened: Business. The Paid Apps Agreement. For in-app purchases to work — even in sandbox for reviewers — this agreement needs to be active. And for it to be active, you need to fill out tax forms.

US tax forms. From France.

A W-8BEN — the IRS form for foreign nationals. Name, address, French tax number. Then a U.S. Certificate of Foreign Status. Then the DAC7, a European anti-tax-evasion directive, mandatory since 2024. Three forms, twenty minutes of unexpected bureaucracy.

The nasty part: without these forms, Apple tells you nothing. No error, no warning. IAPs are just silently disabled in sandbox. The reviewer launches the app, doesn't see the Tip Jar, and slaps you with a rejection.

Twenty minutes of paperwork. A rejection that could have been avoided.

The medical disclaimer

Second reason — guideline 1.4.1. Souffle is a breathing app. To me, that's wellness, relaxation. To Apple, it's medical advice without a disclaimer.

And honestly, they're not wrong. The app offers cardiac coherence, logs sessions to Apple Health via HealthKit. Even though Souffle doesn't diagnose anything or prescribe anything, the topic is close enough to medical territory that Apple wants a safeguard.

The fix was a single sentence, added to the description: "Souffle is not a medical device. Consult a healthcare professional before making any medical decisions."

One line. Ten seconds to write. But you had to know it was needed.

The organization account

Third reason — guideline 5.1.1(ix). This one I did not see coming at all.

Apple considers that apps touching health — even wellness, even breathing — must be published under a Developer Organization account, not an individual account. An organization account means a business registration number, a legal entity, a DUNS number.

I have an individual developer account. No business, no legal entity. Just a developer who coded something in the evenings to help his father breathe.

I pushed back. Souffle doesn't provide personalized medical advice. The disclaimer is in place. The app doesn't write health data — it logs mindfulness sessions, that's it. I sent my response to Apple explaining all of this.

Waiting for their answer. This is the one that worries me most, because if Apple insists, I'll need to create a legal entity before I can publish. For a free breathing app.

The background audio

Fourth and final reason — guideline 2.5.4. The app declares background audio mode in UIBackgroundModes, but the reviewer didn't hear any sound in the background.

This one made me smile, because the code is correct. AVAudioSession is set to .playback, the audio continues perfectly when you lock the screen. But you need to start a breathing session, enable a soundscape, then lock — and the reviewer apparently didn't do that.

The fix: no code change needed. Just a response to Apple with the exact steps to reproduce. "Launch the app, start a session, enable a soundscape, lock the screen, wait — the audio continues."

Lesson learned: for any feature that doesn't trigger from the home screen, put the reproduction steps in the App Review Notes on the first submission. Reviewers won't guess.

What now

I fixed what I could. Tax forms filled, Paid Apps Agreement active, medical disclaimer added, detailed reproduction notes for background audio. The appeal on the organization account is sent.

Souffle is resubmitted. I'm waiting.

The first instinct after a rejection is frustration. Four reasons. None related to the code, the quality, the user experience. Four administrative, regulatory, procedural issues. The kind of stuff you won't find in any "How to publish an iOS app" tutorial.

Then you step back. And you realize that's exactly why the process exists. Apple checks that you've done things properly — not just that your code compiles. It's frustrating, but it's also why users trust the App Store.

What I wish I'd known before clicking "Submit":

Go to App Store Connect, Business tab, before anything else. Make sure all your agreements are active and your tax forms validated. It takes twenty minutes and saves you the dumbest possible rejection.

If your app is anywhere near health, wellness, breathing, meditation — add a medical disclaimer. Not tomorrow. Now.

Look into the organization account requirement for health apps. If you don't have a legal entity and might need one, start the process early. Business registration doesn't happen overnight.

And write detailed reproduction notes in the App Review Notes. Anything that can't be tested in two taps from the home screen, describe it. Reviewers don't have the time or the patience to figure out how your feature works.

The first Apple rejection is a rite of passage. It's not a wall — it's a toll booth. You pay in patience, paperwork, and humility, and you get through.

I'm waiting for the email. I'll keep you posted.

— Pato