Document Number: 001
Subject of Record: APPLE NEEDS TO GET THEIR SHIT TOGETHER IN THEIR DEV TOOLING
Prepared By: TULIO CUNHA
Date Filed: APR 14, 2026
Classification: INTERNAL TECHNICAL MEMORANDUM

Apple Needs to Get Their Shit Together in Their Dev Tooling

SUBJECT BRIEF

WWDC polish meets shipping friction: why Apple’s dev stack still buries you in projects, flaky previews, and docs that skip the caveats—and what would actually fix the daily loop.

Opening

You can see it every June. The demos are clean. The APIs are framed as inevitable. The design language is immaculate. The docs look coherent enough to imply a philosophy underneath the stack. Xcode is presented as world-class. SwiftUI is presented as the future. Swift is presented as safe, expressive, and modern. Some of that is even true: Xcode 26 ships with Swift 6.2 and the SDKs for the 26-generation OS releases, and Apple is clearly still investing in the toolchain.

Then you sit down to ship a real app, and the story changes. The problem is not that Apple platforms are hard. Hard is fine. The problem is how much of the difficulty is artificial: project configuration weirdness, flaky indexing, opaque builds, fragile previews, and documentation that describes the happy path while omitting the caveats you will actually hit.

Apple keeps talking about intelligence features, coding assistants, and polished workflows, while the baseline experience still trains too many people to delete DerivedData and hope for absolution. Xcode 26’s own “What’s new” story leans on coding assistants, inline generation, and Playground macro previews. That work matters. It is still not the same thing as fixing the architectural paper cuts that have defined Apple development for years.

Xcode: the IDE that time forgot, then partially repainted

The editor itself is better than many developers admit. It feels native because it is native. Text looks sharp. Scrolling is smooth. Responsiveness has improved over the last few releases. If you care about a Mac-native editor, Xcode still has something most cross-platform IDEs do not.

And yet Xcode remains one of the biggest offenders against Apple’s own interface values. It is visually dense, full of tiny controls, overloaded with panels, and often weak on discoverability. It feels like a product that tried to become every developer tool at once: editor, build orchestrator, source control client, design surface, simulator launcher, signing console, profiling gateway, package UI, archive manager, test dashboard, doc browser, and now an AI shell. The result is not cohesion. It is accretion.

The core concept still feels wrong: the Xcode project

The modern norm is simple. The filesystem is the source of truth. Configuration lives in plain text. The build graph is inspectable. The editor is a client of that truth, not the owner of it. Xcode still behaves too much like an IDE-owned graph: projects, targets, schemes, build phases, groups, workspaces, signing state, derived metadata, and a project file that models more than most developers should have to think about. Apple’s documentation still frames app development in terms of projects and workspaces, not a manifest-first model.

That is why .xcodeproj feels cursed. It is not just a config file. It is a serialized representation of the IDE’s worldview. It can diverge from the actual folder structure. It turns routine collaboration into needless merge friction. It makes modularization more configuration-heavy than it should be. It makes the UI, not the repository, feel like the source of truth. In 2026, that is hard to defend.

The build system is evolving. The authoring model is not.

You can modernize the build engine and still leave most pain intact if the experience remains mediated through Xcode projects, schemes, workspaces, and IDE-owned state. Build transparency stays weak. Logs are still too often optimized for the Xcode UI instead of for humans trying to reason about what just happened. Cache invalidation still feels mystical. One-line changes can trigger work that looks wildly disproportionate. Type-checking failures remain slow and unhelpful far too often. Even when SwiftPM exposes more CLI surface than people assume, the command UX still feels verbose next to the best modern tooling ecosystems.

That is why CI on Apple platforms still feels worse than it should. Apple has a testing story: Xcode 16 and later include Swift Testing, described as expressive, scalable, and integrated with SwiftPM workflows. Swift Testing is a real step forward. Native app automation still does not feel normal. Too much of CI stays coupled to the Xcode worldview: schemes, simulator state, signing, entitlements, distribution flows, and a project model that is more fragile than a good CI substrate should be. Plenty of teams can wire better CI for web, Rust, Go, or backend work faster than for a serious Apple app—not because Apple development is uniquely sophisticated, but because Apple still piles incidental complexity on normal software engineering.

SwiftUI is the future. It is still a negotiation.

SwiftUI deserves praise and criticism in equal measure. On good days, it is one of Apple’s best ideas in years. The declarative model is elegant. The code can be beautiful. The framework is still moving: recent updates add APIs and deeper design-system integration, and WWDC25 added new sessions on SwiftUI performance, concurrency, spatial layout, and the 26-era design language. SwiftUI is not stagnating.

SwiftUI still has a black-box quality that makes real apps harder than Apple admits. Layout is too often something you discover experimentally rather than understand from first principles. State management has improved, but ownership, observation boundaries, update propagation, and patterns for nontrivial apps still confuse people. Complex navigation remains touchier than it should be. On macOS, SwiftUI still often feels like the less-loved child: workable and improving, but not yet sufficient by itself for many truly desktop-class apps.

Apple’s own recent SwiftUI work makes the tension visible. Dedicated WWDC sessions on optimizing SwiftUI performance with Instruments, exploring concurrency in SwiftUI, and mixing SwiftUI with RealityKit or AppKit-adjacent features are evidence of a living framework—and evidence that the easy story only gets you so far.

SwiftData is getting better. That is not the same as “trust it blindly.”

Documentation looks complete right up until you need it

Apple’s documentation is often excellent at showing what an API is supposed to do on the happy path. It is less reliable when you need to know what breaks, what is underspecified, what behaves differently across platforms, what gets awkward in large codebases, or what migration traps other developers already hit. The official pages for Xcode, SwiftUI, Testing, and SwiftData present polished summaries of intent. They are far less likely to carry the candid caveats experienced developers actually search for.

That is why so much practical Apple knowledge still lives outside Apple: blog posts, forum threads, old GitHub issues, conference talks, random gists, and tribal memory. The docs look complete, but the working developer experience is still full of folklore. When Apple deprecates APIs, migration guidance is often directionally useful but not conceptually exhaustive. When toolchain bugs appear, Feedback Assistant can feel more like a submission chute than a conversation. The subtle result is corrosive: people internalize that the polished official story is only half the story.

The pretension problem

Apple’s tooling culture still projects the idea that development on Apple platforms is seamless if you are doing it correctly. The demos work. The visuals are composed. The docs are serene. The marketing language around Xcode 26 talks about productivity, coding intelligence, improved testing, and integrated workflows.

Real projects are not WWDC demos. They have history: CI constraints, dependency graphs, migration baggage, signing problems, old targets, weird package resolution failures, AppKit and UIKit escape hatches, and layout bugs that reproduce on one platform on alternate Tuesdays. Apple rarely acknowledges that texture in public. When the tooling fights you, it can feel like you are the problem.

That stance is getting riskier. Apple operates in a more competitive environment. Alternative distribution is not theoretical anymore: Apple’s EU documentation and MarketplaceKit materials acknowledge the post–iOS 17.4 world of alternative marketplaces and new distribution paths, while EU business terms continue evolving. Developers have more leverage, more platform choices, and more viable cross-platform stacks than a few years ago. In that world, developer experience is not a side issue. It is a competitive feature.

Swift is great. That raises the stakes.

Swift is excellent. Swift 6’s data-race safety model is a real achievement, and Swift 6.2 continues steady, serious evolution. The language is expressive, fast, and unusually pleasant for something that can work close to the metal. Swift Package Manager is useful and still improving. Swift Testing is promising. Swift Build could become a major structural improvement.

That is exactly why the tooling situation feels frustrating. The platform has the raw ingredients. The ecosystem does not need fairy dust. It needs product discipline. Apple needs to treat developer tooling as a first-class product area, not as an accessory to the platform story: a clearer architectural direction for app projects, better build transparency, faster iteration on Xcode stability, documentation that includes caveats—not only aspirations—a feedback loop that feels real, more honesty about where SwiftUI still falls short on macOS, and less obsession with demo gloss relative to what happens after week three of a real production app.

Because if Apple does not make the daily experience better, the best developers will do what developers always do: route around the pain. That would be a shame, because this ecosystem is still worth fighting for. It is long past time for Apple to stop acting like the fight is not happening.

Key takeaways

REFERENCES // TRACEABLE SOURCES

[r1]
Tuist – sane Xcode projects at scale
[r2]
Swift.org

END OF MEMORANDUM

Filed notes on the machine.