The Impossible Journey To Get Apple Developer Accounts

Rust in the Vibe Coding Era

AI Automation vs Zapier Automation: Where AI Actually Helps

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

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.

Jordan Sullivan

Co-Founder

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.

Alec Dibble

Advisor

Zapier-style automation and AI automation solve different problems.
Traditional automation is great when the work follows a predictable rule:
<ul><li>When a form is submitted, create a CRM record</li><li>When a deal closes, send a Slack notification</li><li>When a file lands in a folder, copy it somewhere else</li><li>When a status changes, send an email</li></ul>
AI helps when the workflow is less structured:
<ul><li>An email needs to be classified</li><li>A PDF needs fields extracted</li><li>A support thread needs a summary</li><li>A CRM record needs enrichment</li><li>A knowledge base needs to answer a question</li><li>A request needs human review because confidence is low</li></ul>
The best systems often use both.
<h2>Traditional automation is best for clear triggers and rules</h2>
If the trigger, condition, and action are obvious, use traditional automation.
Examples:
<ul><li>Sync a lead from a form to a CRM</li><li>Notify a channel when a ticket is tagged urgent</li><li>Move a file after approval</li><li>Create a task when a field changes</li></ul>
These workflows do not need a model. They need clean rules, stable APIs, and reliable system behavior.
Adding AI to this type of work can make the system slower, more expensive, and harder to debug.
<h2>AI automation helps when the input is messy</h2>
AI becomes useful when the workflow has unstructured inputs.
Examples:
<ul><li>A customer writes a long support email with unclear intent</li><li>A vendor sends a PDF with fields in different places</li><li>A client uploads mixed financial documents</li><li>A prospect submits a form with incomplete company details</li><li>An employee asks a question that requires searching SOPs</li></ul>
These inputs are hard to handle with simple rules because the structure changes every time.
That is why <a href="/services/ai-features-workflows">document intake automation</a> and <a href="/services/ai-features-workflows">support triage automation</a> are common AI workflow candidates.
<h2>AI automation needs review design</h2>
Traditional automation is usually binary. A rule matches or it does not.
AI automation has confidence, ambiguity, and failure modes.
That means the workflow needs:
<ul><li>Confidence thresholds</li><li>Review queues</li><li>Exception routing</li><li>Source references</li><li>Human approvals</li><li>Logging and feedback</li><li>A way to track corrections</li></ul>
Without those controls, AI automation becomes a hidden decision-maker. That is where risk grows.
<h2>The strongest pattern is AI plus deterministic automation</h2>
The practical architecture often looks like this:
<ol><li>Traditional automation detects the trigger.</li><li>AI classifies, summarizes, extracts, drafts, or recommends.</li><li>Rules decide whether the result can proceed or needs review.</li><li>Humans handle exceptions and sensitive decisions.</li><li>Traditional automation updates systems of record.</li></ol>
For example, a support triage workflow might use AI to classify a ticket and draft a response, while deterministic rules route high-priority billing issues to a human queue.
<h2>Use AI when the workflow needs judgment support</h2>
AI is useful when a person currently spends time interpreting messy context.
Examples:
<ul><li>&quot;What type of request is this?&quot;</li><li>&quot;What information is missing?&quot;</li><li>&quot;Which customer does this belong to?&quot;</li><li>&quot;What is the short summary?&quot;</li><li>&quot;Which policy applies?&quot;</li><li>&quot;What should the reviewer look at first?&quot;</li></ul>
These are not pure rules. They are judgment-support steps. AI can make them faster, especially when a human remains responsible for the final decision.
<h2>Use traditional automation when reliability matters more than interpretation</h2>
If the workflow only needs to move data from one place to another, keep it deterministic.
Examples:
<ul><li>Record creation</li><li>Status updates</li><li>Notifications</li><li>Scheduled reports</li><li>File movement</li><li>Basic field syncs</li></ul>
These steps should usually be stable, inspectable, and easy to retry.
<h2>When this matters</h2>
This matters when a team says, &quot;Could we just do this in Zapier?&quot;
Sometimes the answer is yes. That is good. Use the simple tool.
But when the workflow includes messy language, documents, summaries, search, classification, confidence, and human review, the team needs a broader <a href="/services/ai-features-workflows">AI workflow automation</a> design.
The point is not AI instead of automation. The point is using AI only where interpretation creates leverage, then using deterministic automation to move the work safely.

Traditional automation handles predictable rules. AI automation helps when workflows include messy language, documents, classification, summaries, and human review.

Let's Talk

Recent notes from Dioko

The Impossible Journey To Get Apple Developer Accounts

Rust in the Vibe Coding Era

AI Automation vs Zapier Automation: Where AI Actually Helps