Three Attempts at an Apple Developer Account, and Why the Third One Was Personal

An Apple Developer account is the toll booth between “my app runs on my Mac” and “my app runs on someone else’s Mac” — and on macOS, there is no toll-free lane. I learned that the slow way: three separate enrollment attempts over the life of this project, the first two under company names, both of which died in Apple’s verification purgatory. The one that finally worked, the one I did this week, was personal. Here’s the whole thing, including the part where my unsigned test build showed up on a colleague’s Mac mini as “damaged” and offered to move itself to the Trash.

TLDR

What You’ll Gain:

The actual reason a Mac app you built won’t open on someone else’s machine (it’s not a bug — it’s Gatekeeper)
Why “just right-click and Open” stopped being advice you can give non-technical testers
An honest pros/cons of enrolling your Apple Developer Program as an individual vs. an organization — from someone who tried both and only finished one
A realistic timeline and the specific failure modes that ate two of my attempts
Bottom Line Value: If you’re a solo builder shipping a Mac app, enroll as an individual on day one — the org route costs you weeks you don’t have, and you can restructure later.

The catch I want named up front: I’m writing this while waiting for the third enrollment to clear. So this is a field report from inside the toll booth, not a victory lap. Date-stamped 2026-06-24, macOS 26.5.1, Tauri 2.

The moment the problem stopped being theoretical

For weeks, “ship it” meant building a .dmg on my machine, double-clicking it, and watching VoiceCatcher launch. Works on my machine. Famous last words of every developer who has ever lived.

Then I needed two people — real testers, not me — to install it. I AirDropped the build to a Mac mini. The mini thought about it for a second and said:

“VoiceCatcher is damaged and can’t be opened. You should move it to the Trash.”

It was not damaged. I had built it four minutes earlier. It launched fine on the machine that built it. But the mini had never seen this app, the app had no Apple signature, and AirDrop had stamped it with a quarantine flag. On macOS, that combination doesn’t get a warning — it gets a death sentence.

Here’s the part that surprised me, and the reason I’m writing this: the old “right-click the app and choose Open” escape hatch doesn’t work for this anymore. That trick still exists for the milder block — the “unidentified developer” warning. But the harsher “damaged, move to Trash” state on current macOS gives you no right-click override at all. The only GUI escape is a buried “Open Anyway” button in System Settings → Privacy & Security that doesn’t reliably appear for the “damaged” tier. The reliable fix is a Terminal command. And I’ll tell you exactly what I told myself when I realized that:

I am not talking two non-technical testers through xattr -dr com.apple.quarantine. That is not a beta test. That is a hostage negotiation.

Why won’t my Mac app open on someone else’s computer?

Because macOS Gatekeeper sorts every downloaded app by two things at once — whether it’s signed/notarized, and whether it carries the quarantine flag that AirDrop and browser downloads slap on. Here’s what I actually saw on macOS 26.5.1 this week, not a permanent law of the universe (Apple keeps hardening these messages release to release):

What the user saw	GUI override available?	What triggered it
Opens, no dialog	N/A	App is notarized by Apple
”Unidentified developer”	Right-click → Open works	Quarantined, signed but not notarized
”Damaged, move to Trash”	No reliable GUI override	Quarantined and failing Gatekeeper assessment — for me, an unsigned AirDropped build

One nuance worth getting right, because a sharp reader will catch it: the trigger for that bottom row is the quarantine flag, not the lack of a signature by itself. An unsigned app I build and run locally — no quarantine — opens fine. It’s unsigned plus quarantined (AirDrop did that) that produces “damaged.” That’s why the quick-and-dirty fix is removing the quarantine flag, and why that fix is useless for testers (their download re-applies it). I was in the bottom row. The only way out of it permanently is the top row. And the top row requires a Developer ID certificate, which requires a paid Apple Developer Program membership. There is no free tier, no clever flag, no App Store-free side door that produces a clean double-click install. Apple has spent the last several macOS releases bricking those side doors on purpose.

So the toll booth. Which brings me to my three attempts to pay it.

Three attempts, two dead ends, one personal account

Attempt one and two: the company route

Both of my first two enrollment attempts were under company names — entities tied to the broader portfolio I’m building. On paper this is the “correct” move. Apps published under an organization show the company name as the developer. It looks legitimate. It separates the business from the human. Every “how to set up your Apple Developer account properly” guide nudges you toward the org enrollment like it’s the adult choice.

Both attempts never completed.

The org enrollment route requires a D-U-N-S number (a business identity number issued by Dun & Bradstreet), and Apple independently verifies that your legal entity matches what D&B has on file, which matches what you typed in, which matches a real person with authority to bind the company. When any of those records is even slightly out of sync — a slightly different address, an entity that’s too new to be fully propagated through D&B, a name with an LLC suffix in one system and not another — you don’t get a clear error. You get silence. You get “we’ll review it.” You get a support thread that goes quiet.

I’m not going to pretend I have a clean root-cause for why each of mine stalled. That’s the honest truth and it’s also the point: the org route fails in ways you can’t debug from the outside. It’s a verification process happening in systems you can’t see, on a timeline nobody commits to. Twice I waited, twice it didn’t resolve, twice I had other fires and let it drop.

Attempt three: personal, paid, done in minutes

This week I enrolled as an individual, under a personal email, and paid the $99. The individual enrollment skips the D-U-N-S dance entirely — Apple verifies a person, not an entity, and they already know how to verify a person via your Apple ID. (Individual enrollment can still ask for ID upload or a verification callback in some cases — it’s not guaranteed frictionless. It just wasn’t, in my case.) The wall that killed attempts one and two — the entity verification queue — isn’t in this path at all.

That’s attempt three. As I write this, it’s processing — individual enrollments typically clear in minutes to a few hours, occasionally up to 48 hours — and the moment it does, I can mint a Developer ID certificate and notarize the build that’s currently scaring Mac minis.

Should a solo builder enroll as an individual or an organization?

Here’s the trade-off, from someone who paid for the lesson:

Individual enrollment — pros:

It actually completes. No D-U-N-S, no entity verification, no opaque review queue. Apple verifies you, the person.
Fast. Minutes to hours, not weeks.
One fee. $99/year, same as the org tier.
You can ship today. For a solo builder whose blocker is “I need two testers to install this,” this is the only path that unblocks you this week.

Individual enrollment — cons:

Your personal name is the developer of record. On the App Store and in some signing contexts, apps show under your name, not a company. For a privacy-first product, there’s a mild irony in your legal name being the brand.
Tax and liability live with you, not an entity. This is a real consideration if the app makes money, but it’s a later problem, and one your accountant solves, not Apple.
Migrating to an org later isn’t a one-click toggle. Apple doesn’t convert an individual account into an organization. Moving published apps to a new org account is a real, if surmountable, chore down the road.

Organization enrollment — pros:

Company name as developer. More legitimate-looking, cleaner separation of business and self.
Multiple team members, roles, proper access control. Matters when you’re not solo anymore.

Organization enrollment — cons:

The D-U-N-S verification wall. This is where my first two attempts died. If your entity is new or your records aren’t perfectly aligned across Apple, D&B, and your own paperwork, you can lose weeks with no clear error.
Slower, and failure-prone in ways you can’t self-diagnose.

My unhedged opinion

Enroll as an individual on day one. The “do it properly with a company” instinct is a trap for a solo builder — it optimizes for a legitimacy you don’t need yet at the cost of the one thing you do need, which is the ability to put your app in a stranger’s hands this month. The company structure is a problem you want to have later, because it means you have revenue and users worth restructuring around. Until then, the org route is buying you a nicer-looking developer name in exchange for shipping nothing. That’s a terrible trade.

Two failed company enrollments cost me, in aggregate, more calendar time than the entire rest of this project’s distribution work. The personal one took the length of a coffee.

Is an Apple Developer account enough to ship a Mac app? (No — signing is only step one)

A thing I want to be honest about, because the “just get a Developer account” advice undersells the work: the account is the prerequisite, not the finish line. Once attempt three clears, the path to a tester-ready DMG is still four steps, none hard but all real:

Confirm the membership is active at developer.apple.com/account and grab your 10-character Team ID.
Create a Developer ID Application certificate — easiest through Xcode’s Accounts pane, which drops the cert and its private key straight into your keychain (the manual web-portal route makes you hand-juggle a certificate signing request and a private key, which is exactly the kind of thing you’ll get subtly wrong at 11pm).
Create a notarization credential — an app-specific password from appleid.apple.com, stored once via xcrun notarytool store-credentials so it lives in your keychain and never in your repo.
Sign, build, notarize, staple — I’ve got a script (sign-and-notarize.sh) wired to run the Tauri build, submit the .dmg to Apple’s notary service, wait for the ticket, and staple it to the DMG so it validates offline.

Full disclosure, because it matters: I have not run step 4 end-to-end on this new account yet. Enrollment is still processing as I write this, so the certificate doesn’t exist yet, so the pipeline hasn’t fired on a real Developer ID. Steps 1–4 are documented from Apple’s process and the script that’s sitting in my repo, not from a victory I’ve already had. The follow-up post is where I get to say “it opened clean on a Mac that’s never met me” — or where I get to document whatever broke. When step 4 does run clean, the bottom-row “damaged” death sentence becomes a top-row silent double-click. That’s the whole prize.

The Human Reality

I felt genuinely stupid when the Mac mini called my build “damaged.” Not because the fix was hard — because I knew this. I had a half-memory of doing code signing on the legacy version of this app, a vague sense that there was “some keyboard shortcut to allow it.” I burned a real chunk of an afternoon chasing that ghost — right-click Open (gone for this case), the Settings → Privacy “Open Anyway” button (didn’t reliably appear) — before I accepted the thing I already knew: there is no shortcut. There’s a $99 toll and a verification process, and I’d been avoiding paying it properly for two attempts and a company name’s worth of ego.

The relief when I clicked “enroll as an individual” and it just proceeded — no D-U-N-S field, no “we’ll review your entity” — was disproportionate. It was the relief of stopping doing the hard version of a thing that has an easy version.

What This Means for Us

If you’re building a Mac app as a solo person or a tiny team, internalize this before you write your first line of distribution code: the moment your app needs to run on a machine you don’t own, you are in Apple’s signing system, and the only fast way in is the individual Developer Program. Don’t romanticize the org account. Don’t burn two attempts and a month learning that D-U-N-S verification can swallow you whole. Pay the personal toll, ship to your testers, and restructure into a company when you have the revenue to make that a fun problem instead of a blocking one.

I’ll write the follow-up once attempt three clears and I’ve got a notarized DMG that opens clean on a machine that’s never met me. Assuming Apple’s verification queue and I stay on speaking terms.

Next steps you can take today:

If you’re pre-distribution: enroll in the Apple Developer Program as an individual now, so it’s clearing while you build. (developer.apple.com/programs)
If you already hit the “damaged” wall: it’s quarantine + unsigned, not a corrupt build. The permanent fix is notarization; the temporary one is removing the quarantine flag, which is fine for your machines and useless for testers.
If you started an org enrollment that’s stuck: don’t wait on it. Enroll individually in parallel and unblock yourself. You can sort the entity out later.