{"id":53226,"date":"2026-09-17T14:32:38","date_gmt":"2026-09-17T18:32:38","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=53226"},"modified":"2026-09-17T14:32:38","modified_gmt":"2026-09-17T18:32:38","slug":"xcodes-new-xcproj-files-are-json","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2026\/09\/17\/xcodes-new-xcproj-files-are-json\/","title":{"rendered":"Xcode’s New .xcproj Files Are JSON"},"content":{"rendered":"

Apple<\/a>:<\/p>\n

\n

Xcode now supports a JSON-based project format (.xcproj) that’s more readable, merge-friendly, and easier for coding agents to edit. Enable it in the file inspector. Projects using .xcproj also open in earlier versions of Xcode 27. Learn more in Updating your Xcode project configuration file format<\/a>.<\/p>\n<\/blockquote>\n\n

Fatbobman<\/a>:<\/p>\n

\n

[The] new project.xcproj<\/code> caught my eye. What it replaces is project.pbxproj<\/code>, the build graph inside the .xcodeproj<\/code> bundle, not the bundle itself.<\/p>\n

[…]<\/p>\n

In the age of agents, the drawbacks of pbxproj<\/code> are amplified further. A great many IDs carry both object identity and cross-references, so an agent modifying a project usually has to locate the right object in a flat table, then update several mutually referencing places in step, all while trying to keep the serialized output faithful to Xcode’s conventions.<\/p>\n

[…]<\/p>\n

From a flat ID table to a tree that mirrors the UI: instead of dumping everything into objects<\/code>, it unfolds into structures like files<\/code> \/ targets<\/code> \/ build-settings<\/code>, so diffs look closer to the operations you actually performed in the interface;<\/p>\n

The direction of relationships is reversed: a file can declare which targets it belongs to via target-membership<\/code>, so adding a file no longer means editing several mutually referencing places at once;<\/p>\n<\/blockquote>\n\n

Simon B. Støvring<\/a>:<\/p>\n

\n

Developers have been screaming for a friendlier Xcode project format for years. I’m one of them.<\/p>\n<\/blockquote>\n\n

Tony Arnold<\/a>:<\/p>\n

\n

I’ve been waiting for something like this for most of my career! 🎉<\/p>\n<\/blockquote>\n\n

Rob Napier<\/a>:<\/p>\n

\n

It does feel like another case of “we’ve quickly done a thing to help AI that we’ve been unwilling to do for years to help humans.” I’m seeing that happen across the industry.<\/p>\n

It is very welcome and appreciated, and lots of thanks to the teams involved. It’s also frustrating that it took “it can help AI” to make it happen.<\/p>\n<\/blockquote>\n\n

Apple<\/a>:<\/p>\n

\n

xcode-project-format<\/code> is a Swift library for reading, writing, and manipulating Xcode’s JSON-based project.xcproj<\/code> format. It models the format as a rich set of value types nested under a single namespace, XCSchema<\/code>, so consumers get precise, typed access to a project’s structure instead of hand-parsing JSON.<\/p>\n

The goal is to give the ecosystem a shared, accurate model of the Xcode project format — so tools like generators, linters, verifiers, and validators don’t each have to reverse-engineer the format from scratch.<\/p>\n<\/blockquote>\n\n

Helge Heß<\/a>:<\/p>\n

\n

Didn’t most people switch to local SPM projects anyways? Those are the new xcproj that have to be replaced with sth sensible 🙃<\/p>\n<\/blockquote>\n\n\n

Fatbobman<\/a>:<\/p>\n

\n

What the community has actually been waiting years for is a project manifest along the lines of Package.swift<\/code>: something written by people, read by people, and reviewed by people, rather than a more modern encoding of the IDE’s internal database.<\/p>\n<\/blockquote>\n\n

Previously:<\/p>\n