The Impossible Journey To Get An Apple Developer Account: Part 2

The Impossible Journey To Get Apple Developer Accounts

Rust in the Vibe Coding Era

Apple finally told us how to give them our money. It still did not work.
In <a href="/blog/the-impossible-journey-to-get-apple-developer-accounts">Part 1</a>, we wrote about our attempts to create Apple Developer accounts for businesses whose apps we were helping launch.
At the time, we were about two weeks into the process.
We are now approaching two months.
We still do not have the developer account.
<h2>Apple Business Is Apparently the Answer</h2>
After enough support calls and transfers, we finally reached someone at Apple who seemed to understand the problem.
They told us that, for this use case, we should first create an Apple Business Manager account. That would allow the company to create managed Apple accounts for its employees, which could then presumably be used to enroll in the Apple Developer Program.
Great. An actual path forward.
Creating the Apple Business account required submitting business ownership and verification documents. We submitted everything and waited.
And waited.
Eventually, we called Apple to ask what was happening.
It turned out Apple had sent an email requesting additional documentation. The email had gone to spam, so we never saw it.
That part is not entirely Apple&#39;s fault. Spam filters happen.
What was less understandable was that the Apple Business dashboard continued to say the application was pending without showing any indication that Apple was waiting for additional documents. There was no warning, outstanding task, notification, or visible request in the dashboard.
From our perspective, the application was simply sitting in a queue.
Once we discovered the missing email, we submitted the additional forms. After several more days, the Apple Business account was finally approved.
Progress.
Or so we thought.
<h2>The Email Address That Is Not an Email Address</h2>
Apple Business Manager gives users managed Apple accounts with usernames that look something like this:
<pre><code class="language-text">name@businessname.appleaccount.com</code></pre>
That looks like an email address.
It is not, however, an email inbox.
Messages sent to it do not reach the user. It is effectively a username formatted like an email address.
This distinction became important almost immediately.
Using the new managed Apple account, we enrolled in the Apple Developer Program. This time, the enrollment form actually let us through.
The status changed to:
<blockquote>Your enrollment is being processed.</blockquote>
We waited another week.
Nothing happened.
The account remained pending, and we received no communication explaining what Apple needed from us.
So we called support again.
Apple had requested more documents.
Where had they sent the request?
To the managed Apple account—the email-shaped username that does not receive email.
Apple had created an account identifier that looked like an email address, accepted it as the contact address for a developer enrollment, and then sent a required document request to an inbox that did not exist.
<h2>Fixing the Email Address Apple Gave Us</h2>
There is a way inside Apple Business Manager to associate a managed Apple account with a real email address.
We updated the account.
That change did not immediately propagate to the Apple Developer system. We had to wait another day or two before the developer account recognized the new address.
Before the change propagated, we could not even file an Apple Developer support ticket. The support form rejected the email address as invalid.
To summarize:
<ol><li>Apple gave us an account name formatted like an email address.</li><li>Apple used that address for the developer enrollment.</li><li>Apple sent required documents to that address.</li><li>The address could not receive email.</li><li>Apple&#39;s own support system then rejected the address as invalid.</li></ol>
Once the real email address finally propagated, we were able to submit another support request.
Apple confirmed that the document request had been sent to the unusable address and agreed to resend it.
This time, we received it.
We submitted the documents.
Surely, this was the end.
<h2>Three More Weeks of Waiting</h2>
It has now been approximately three weeks since we submitted the requested documents.
The enrollment is still pending.
We called Apple again today. Their answer was that the review team is extremely backed up and they cannot provide any estimate for when the enrollment will be completed.
There is apparently no escalation path, no published review timeline, and no meaningful status information beyond &quot;pending.&quot;
We have now spent nearly two months trying to create an account that costs $100 per year.
We are actively trying to pay Apple.
Apple will not let us.
<h2>The Developer Portal Barely Works</h2>
The enrollment process is not even the only problem.
When attempting to log back into <code>developer.apple.com</code>, we regularly encounter HTTP 502 errors or infinite redirect loops.
The only reliable workaround we have found is to open Chrome&#39;s developer tools and manually clear cookies for both Apple&#39;s developer domain and its federated identity domain. After deleting those cookies, we can usually attempt the login flow again.
That is not a reasonable requirement for accessing a developer account.
We are professional software developers. We know what cookies, federated authentication, redirect loops, and HTTP status codes are. We can inspect network requests and experiment until we find a workaround.
What happens to a small business owner who cannot do that?
They probably conclude that the website is broken—which it is—and give up.
A person should not need browser debugging tools to log into the website required to publish an iPhone app.
<h2>A Bureaucratic Dead End</h2>
At every stage of this process, Apple&#39;s systems have failed to communicate what is happening:
<ul><li>The Apple Business dashboard did not indicate that additional documents were required.</li><li>A critical document request was sent to an address that could not receive email.</li><li>The support form rejected the account identifier Apple itself created.</li><li>Email changes took days to propagate between Apple systems.</li><li>The Developer portal repeatedly entered redirect loops or returned 502 errors.</li><li>The enrollment review has now taken weeks with no timeline or escalation path.</li></ul>
Any one of these problems would be frustrating.
Together, they form a process in which nearly every step requires calling Apple Support to discover information that should have been visible in the product.
And every support interaction seems to reveal another disconnected system, another invisible status, or another department that cannot tell us what happens next.
<h2>Please, Apple, Take Our Money</h2>
We still want to build and launch iOS apps.
Our clients still want to publish their apps.
We still want to give Apple its $100.
It should not take two months, repeated support calls, business verification documents, multiple email-address migrations, browser debugging tools, and an indefinite manual review to accomplish that.
Apple became one of the most valuable companies in the world by building products that made complicated technology feel simple.
This process feels like the opposite.
It feels like dealing with early-2000s Microsoft: fragmented systems, opaque bureaucracy, broken authentication, and the sense that the company is now so large that no one is responsible for the complete customer experience.
We hope Apple eventually becomes the company people fell in love with again.
For now, our enrollment is still pending.

Part two of our firsthand account of trying to create an Apple Developer account through Apple Business Manager, including missing document requests, invalid managed email addresses, login failures, and weeks of unexplained delays.

Two months, multiple support calls, broken email routing, and Apple still will not take our money.

Jordan Sullivan

Co-Founder

Apple charges $100 a year for an Apple Developer account. That is annoying, but understandable. That friction probably keeps some low quality accounts and apps out of the app store. What is EVEN MORE frustrating though is not even being able to give Apple that $100 dollars.
<h2>A Broad Issue</h2>
We have several clients that are trying to launch iOS apps that we built. We have been helping them create (at least trying to help) Apple Developer accounts for their organizations.
They don&#39;t want to create accounts with their personal iClouds for obvious reasons. These are businesses with business emails and they want to keep things separate. One client even tried to use their personal iCloud but they were not able to create an organization developer account.
First, we tried to set them up new Apple accounts with their business emails. After going through the signing flow, verifying their email, and then trying to verify their phone number, they land on a cryptic message: &quot;Your account cannot be created at this time&quot;. No explanation, no way to move forward, no next action.
<h2>Apple Business WTF?</h2>
After some googling, we found one suggestion was to create an Apple Business account so that employees can have dedicated users under the business. We set one up for one of the clients and have been waiting for 11 business days to get it approved. The dashboard helpfully says it will be approved in 5 days. Lies.
<h2>Apple Support Circus</h2>
For both clients, we have parallel support threads going. We keep getting transferred to other departments, which means scheduling calls for the next day. Often, the calls get scheduled in the wrong timezone, which is delightful. There is no clear path to get this dealt with through their support pages or channels.
<h2>Not Just Us</h2>
When you Google for this problem, there are many Apple threads and Reddit posts detailing people with the same issues. Some workarounds include using their mom&#39;s phone number instead, going to a cafe and using their internet to fill out the form from a different IP, and trying to contact support. This seems to be a broad issue and it is insane that it seems to be unaddressed by Apple for at least the last year.
<h2>Please Let Us Give You $100, Apple</h2>
At the time of publishing this article, we are 2 weeks into trying to get accounts for 2 clients and still can&#39;t get in. This is frustrating us and this is frustrating our clients. It&#39;s baffling that a company that used to be so user-centric has created a early-2000&#39;s-Microsoft-like monstrosity of impenetrable bureaucracy. If anyone has any other ideas or works at Apple and can throw us a bone, please let me know: matt AT dioko.ai
<h2>Update! (August 2026)</h2>
We have written a part 2, the saga is not finished yet. <a href="/blog/the-impossible-journey-to-get-apple-developer-accounts-part-2">Read that here.</a>

A firsthand look at the frustrating, support-heavy process of trying to create Apple Developer accounts for client iOS app launches.

Apple, please take our money. This side quest was not in the launch plan.

AI has changed the way software gets written.
A lot of teams are now using AI to generate first drafts of features, explore unfamiliar frameworks, scaffold systems, write tests, refactor code, and move faster through the boring parts of implementation. Some people call this “vibe coding.” The phrase is a little unserious, but the underlying shift is real: developers are increasingly steering, reviewing, correcting, and integrating code instead of typing every line by hand.
That creates a new question for engineering teams:
What languages and platforms work best when AI is part of the development process?
The answer is not just about which language an AI model can write most easily. The better question is which language helps generated code stay understandable after it lands. Agentic development works best when the system itself encourages clear boundaries, explicit contracts, narrow interfaces, and code that can be reviewed without reconstructing a pile of hidden assumptions.
For us, Rust has been one of the strongest answers so far.
<h2>Promising Results</h2>
At Dioko, we have been using Rust across native app development, cross-platform app development, and backend development. We did not come into this as long-time Rust experts. We had strong engineering fundamentals, but not a deep production Rust background. We have been learning it by building with it, reading, testing, refactoring, and using AI as a development accelerator.
So far, the results have been extremely encouraging.
Rust has given us a rare combination: high performance, strong correctness guarantees, great portability, a modern package ecosystem, and a type system that makes AI-generated code much easier to validate, constrain, and improve.
More importantly, Rust pushes both humans and AI agents toward stronger architectural boundaries. That may be the single most important thing for keeping agentic code manageable, readable, and clean.
<h2>Rust gives AI a better surface area to work with</h2>
One of the biggest problems with AI-generated code is not whether it can produce something plausible. It usually can.
The harder problem is knowing whether the generated code is actually right.
In dynamic languages, a lot of mistakes hide until runtime. Wrong shapes, missing fields, bad assumptions, nil errors, invalid states, forgotten edge cases, and weak boundaries can all survive the first generation pass. You may not find them until a test hits the exact case, or worse, until production does.
Rust changes that dynamic.
Rust’s type system, ownership model, exhaustive pattern matching, and compiler checks create a much tighter feedback loop. AI can generate code, but the compiler immediately acts as a rigorous reviewer. It does not care that the code looks reasonable. It cares whether lifetimes, ownership, borrowing, types, traits, match arms, and error handling are actually coherent.
That matters enormously when working with AI.
The compiler becomes part of the development workflow in a stronger way. You can ask AI to write or refactor something, run the compiler, feed the errors back into the loop, and converge toward code that is not merely syntactically valid, but structurally aligned with the program.
This does not replace human understanding. It raises the quality floor.
<h2>Rust makes boundaries harder to ignore</h2>
The most important thing Rust gives an AI-assisted workflow may not be speed, memory safety, or even compiler feedback in isolation.
It may be boundaries.
AI-generated code has a tendency to sprawl when the surrounding system lets it. Responsibilities blur. Data gets passed around too loosely. Optional states leak into places that should not know about them. Shared mutable state appears because it was the easiest path to a plausible answer. Interfaces grow wider than they need to be.
Rust fights that drift at the language level.
Ownership forces you to decide where data lives. Borrowing forces you to decide how access works. Traits force you to name capabilities. Enums force you to model states explicitly. Modules, visibility rules, and type boundaries make it harder to smear responsibility across the codebase without being noticed.
That does not mean Rust automatically produces good architecture. It means the path of least resistance is often closer to good architecture than it would be in a looser environment. The developer still has to make design decisions, but Rust keeps pulling those decisions into the open.
That is extremely valuable when agents are writing or modifying code. The system gives the agent less room to quietly improvise around unclear ownership, unclear state, and unclear module edges. Generated code has to fit through the boundaries that already exist, or the mismatch becomes visible quickly.
<h2>Strong types are self-documenting architecture</h2>
Rust’s type system is not just about catching bugs. It also makes code easier to reason about.
A well-modeled Rust system tells you a lot just by looking at the types. What is optional? What can fail? What state transitions are allowed? What data owns what? What can be shared across threads? What can cross an API boundary? What is impossible by construction?
That is valuable for humans. It is also valuable for AI.
When the codebase has strong types, clear enums, explicit error types, trait boundaries, and narrow data models, AI has more context embedded directly in the code. The code becomes less dependent on tribal knowledge, comments, or external documentation. The shape of the program carries more of its own meaning.
For an agency, that is a big deal.
We often need to move across projects quickly. We need to understand a system, extend it safely, and avoid creating fragile code that only works because one developer remembers every implicit assumption. Rust rewards making assumptions explicit. That makes it easier for both humans and AI agents to work inside the system without accidentally violating its invariants.
<h2>Runtime guarantees matter more when generation gets faster</h2>
AI lets teams produce code faster. That is useful, but it also increases the risk of producing more broken code faster.
This is where Rust’s runtime model is especially appealing.
Rust gives you memory safety without a garbage collector. It gives you strong concurrency guarantees. It makes many categories of bugs harder or impossible to express. It forces you to deal with failure paths instead of casually ignoring them. It makes shared mutable state something you have to justify, not something you accidentally create.
These are not academic benefits.
They matter when building native applications. They matter when building cross-platform libraries. They matter when building backends where performance, latency, resource usage, and reliability are all part of the product experience.
When AI is generating or modifying code, runtime guarantees become even more important. The faster the implementation loop gets, the more you want the language and compiler to constrain the possible damage.
Rust does that unusually well.
<h2>Rust is fast enough to change product decisions</h2>
Performance is not always the bottleneck. Plenty of products do not need maximum speed.
But performance still changes what you can comfortably build.
Rust is fast. Not “fast enough if you scale horizontally and cache aggressively.” Actually fast. It is suitable for native code, CLIs, servers, media processing, file processing, sync engines, local-first applications, embedded-adjacent work, and performance-sensitive backend systems.
That creates optionality.
You can write a core engine once and expose it to multiple platforms. You can move work client-side without dragging in a heavy runtime. You can build local-first features that feel instant. You can process data efficiently without defaulting to a large cloud bill. You can deploy small binaries with predictable resource usage.
For our work, this has been one of the most exciting parts.
Rust is not just a backend language. It can be the core of a product architecture. You can use it for native app internals, shared cross-platform business logic, backend services, workers, tools, and performance-critical modules. That flexibility is exactly the kind of leverage small senior teams need.
<h2>The ecosystem is mature enough now</h2>
A few years ago, the knock on Rust was that it was powerful but inconvenient. Great language, rough ecosystem.
That critique is less true now.
Rust now has a solid ecosystem for web services, command-line tools, serialization, async runtimes, database access, native integrations, cross-platform application logic, testing, observability, and deployment. Not every part of the ecosystem is as mature as the equivalent JavaScript, Python, Java, or Go world, but the foundation is strong enough for real production work.
You can build serious systems with Rust today.
The tooling is also refreshingly direct. Cargo is excellent. Dependency management is straightforward. Formatting and linting are standardized. Builds are reproducible enough to feel sane. Deployment can be as simple as shipping a binary or containerizing a small service.
There is less ceremony than many people expect.
That simplicity pairs well with AI-assisted development. The fewer custom build steps, hidden framework conventions, and fragile runtime assumptions a stack has, the easier it is to keep AI-generated work grounded.
<h2>Rust works well for cross-platform development</h2>
One of the more interesting uses of Rust is as a shared core across platforms.
Instead of rewriting the same logic for iOS, Android, desktop, and backend environments, Rust can often sit underneath the platform-specific UI layer. The UI can remain native or framework-specific, while Rust handles the logic that benefits from correctness, portability, and performance.
That can include things like:
<ul><li>Local data models</li><li>Sync engines</li><li>File processing</li><li>Licensing systems</li><li>State machines</li><li>Audio or media processing</li><li>Cryptographic workflows</li><li>Business logic shared across clients and servers</li><li>Offline-first application logic</li></ul>
This is especially useful when building native or semi-native applications where the UI needs to feel platform-appropriate, but the core logic should be consistent everywhere.
AI makes this approach more accessible. It can help generate FFI bindings, scaffold platform interfaces, explain compiler errors, and translate architectural intent into Rust modules. But Rust keeps the boundaries strict enough that the generated code has to earn its way into the system.
<h2>Rust is not a substitute for understanding the code</h2>
This is the part that matters most.
We do not think the future of software is developers blindly accepting generated code.
That might work for prototypes. It might work for throwaway internal tools. It might even work for early experiments where the cost of being wrong is low. But for real products, someone still needs to understand the system.
AI can generate code. It can explain code. It can refactor code. It can propose architectures. It can write tests. But it does not own the consequences.
The engineering team does.
That is why Rust has been such a good fit for us. It supports an AI-accelerated workflow without encouraging a careless one. It lets us move faster while still forcing us to confront the structure of the program. If a boundary is unclear, Rust makes us sharpen it. If something is wrong, the compiler often tells us. If a state is invalid, we can model it out of existence. If an error can happen, the code has to decide what to do with it.
Rust does not remove the need for discipline. It rewards discipline.
<h2>The learning curve is real, but manageable</h2>
Rust has a reputation for being difficult. That reputation is not completely unfair.
The ownership model takes time. Lifetimes can be confusing. Async Rust has sharp edges. Some libraries are less mature than their equivalents in older ecosystems. You will occasionally fight the compiler, especially early on.
But our experience has been that the learning curve is more acceptable now than it used to be, especially with AI assistance.
AI is very useful for explaining compiler errors, suggesting more idiomatic patterns, comparing design options, and helping translate a concept from another language into Rust. The key is not to accept everything it writes. The key is to use it as an interactive tutor and implementation partner.
That has made Rust feel much more approachable.
We are still learning. We are still self-educating. We are still developing taste around what belongs in Rust, what should stay in a higher-level language, and where the complexity tradeoff is worth it.
But the direction is clear: Rust is giving us capabilities we want more of.
<h2>More teams should consider Rust</h2>
Rust is not the right tool for every project.
If you are building a simple CRUD app, a marketing site, or an admin dashboard, Rust may not be the highest-leverage choice. If your team is already extremely productive in another stack and performance or correctness constraints are modest, switching languages for trend reasons would be a mistake.
But for many modern products, Rust deserves more serious consideration.
Especially when the product involves native functionality, cross-platform logic, performance-sensitive systems, local-first architecture, reliability-critical workflows, or long-term maintainability, Rust can be an excellent foundation.
And in the AI-assisted development era, its advantages become even more relevant.
The type system documents intent. The compiler catches structural mistakes. The ownership model pushes stronger boundaries. The runtime model eliminates entire classes of bugs. The performance profile opens up product options. The deployment model stays relatively simple. The ecosystem is now broad enough for real work.
That combination is rare.
For us, Rust has become one of the most exciting tools in the current software landscape. Not because it lets us stop thinking, but because it helps us think more clearly. Not because AI can magically write perfect Rust, but because Rust gives AI-generated code a much stricter and better-bounded environment to operate within.
That is exactly what we want from a modern engineering stack.
Fast iteration is good. Fast iteration with guardrails is much better.
Rust gives us both.

Rust in the vibe coding era: why Rust’s boundaries, type system, runtime guarantees, speed, and portability make it a powerful fit for AI-assisted native, cross-platform, and backend development.

Let's Talk

Recent notes from Dioko

The Impossible Journey To Get An Apple Developer Account: Part 2

The Impossible Journey To Get Apple Developer Accounts

Rust in the Vibe Coding Era