Two of the most-upvoted threads on r/iOSProgramming this month say the same thing in different words: “I miss the programming aspect of iOS programming” and “Why would anyone start a new app today?”. The complaint underneath both is not really about LLMs. It is about signal. The phrase “iOS developer” used to mean someone who had written a non-trivial iOS app. In 2026, it can mean someone who shipped 14 apps in a week by prompting Cursor and copy-pasting the result.

If you are an experienced indie dev or a small team that values the craft, this is a real problem — for hiring, for code review, for community participation, for the App Store you compete in.

The actual problem is not AI, it is dilution

Most experienced devs I know use Claude or Cursor every day. The pattern that works: I write the architecture and the type signatures, I let the agent fill in the bodies, I review every diff. The agent is faster than me at typing and slower than me at structure.

What the threads are reacting to is a different pattern: the agent is given the architecture decisions too. The output ships. There is no review, no test, no understanding of why the code is shaped the way it is. When something breaks, the person who shipped it cannot debug it, because they did not write it.

That is the signal collapse.

Defend the signal in your own work

1. Write the structure by hand

Module boundaries, type definitions, public APIs, protocols, state machines — write these yourself. These encode decisions. A useful test: if you cannot in one sentence explain why a type exists, the agent should not be the one creating it.

2. Treat agent output like a junior PR

Read every line. Run the tests. Run the linter. Ask yourself: would I sign off on this if a human wrote it? The agent is not insulted by edits.

3. Keep a “no AI” zone for the parts that matter most

• Anything touching user data or privacy (HealthKit reads, Keychain access, network egress).
• Anything that interacts with App Review or notarization tooling.
• Anything in a critical-path bug fix where I need to fully understand the change.

Defend the signal when you review others

Set explicit terms before reviewing

Ask three questions:
1. Did you write this, or did an agent?
2. Can you walk me through the architecture without re-opening the code?
3. What tests exist?

If the answer to (2) is “no” and (3) is “none”, you are reverse-engineering it on someone else’s behalf. Charge for that, or decline.

Use a checklist that catches agent failure modes

• Force unwraps and try! — agents lean on these. Flag every one.
• Hardcoded strings used as identifiers — should be constants or enum cases.
• Concurrency boundaries — @MainActor annotations, Sendable conformance, actor isolation. Agents often get the surface right and the semantics wrong.
• Test coverage of error paths — agents test the happy path.
• Privacy manifest entries — required since iOS 17, agents routinely omit them.

Defend the signal in your public work

• Open-source one thing. Even a small Swift package with good tests and a tagged release establishes that you can build software end-to-end.
• Write up one bug. A precise post-mortem of a real debugging session is the highest-bandwidth signal you can publish.
• Talk at one local meetup. Five minutes about a real code-signing edge case filters out the noise.
• Maintain a personal blog with primary-source posts. Not tutorials regurgitated from Apple’s docs — actual problems you hit, actual fixes you found.

The agent cannot give a meetup talk about a real debugging session it doesn’t understand.

Tooling that helps

• swift-format / SwiftLint — run on every save.
• Tuist — project file generation; removes merge-conflict noise so review focuses on actual code.
• A local xcodebuild script — run before every commit.
• Claude Code or Cursor with a CLAUDE.md / .cursorrules file — tell the agent your conventions. Force-unwrap policy, naming rules, test requirements.

What this does not fix

It does not fix the App Store flooding with vibe-coded apps. It does not fix community moderation. But it does mean that your work, your hires, and your network can still encode craft. The signal does not disappear just because the noise floor went up. It just costs more to maintain, and the maintenance has to be deliberate.

---