[dalemyers]

While I don't disagree that the pbxformat is awful, there are some reasons behind the design. Take the example of PBXBuildFile in the article. Here's a quote:

> There is no other data in this object. Its only reason for existing, as far as I can tell, is to point to the actual PBXFileReference object which contains the filesystem path.

Now, that statement is true most of the time. But not always. Let's say you have a file in two targets (targets ~= binaries). In one of those targets, you need to set a build flag, but not the other, how do you do it? Well, you set it on the PBXBuildFile, rather than the PBXFileReference. In otherwords, you can have 2 different PBXBuildFile's, with 2 different sets of flags, pointing at the same actual file on disk.

Whether that's a good design or not is definitely up for debate, but I wanted to clarify that there are reasons behind everything.

Going further:

> Since everything has a unique ID, a reasonable expectation would be that a) it would be unique per object and b) you would use that ID to refer to the target. Neither of these are true. For example let's define a single build target, which in Xcode/CMake parlance is a PBXNativeTarget. Since plist has a native array type, the target's sources could be listed in an array of unique ids of the files. Instead the array contains a reference to a PBXSourcesBuildPhase object that has a few keys which are useless and always the same and an array of unique ids.

Let's take a sub-statement here first: > Since everything has a unique ID, a reasonable expectation would be that a) it would be unique per object

The author claims this is false, but I've never seen a case where this hasn't held up. Numerous libraries depend on this fact.

> you would use that ID to refer to the target

Also claimed as false, but you do. The argument the author makes talks about the build file stuff I mentioned above, so they may just be misunderstanding or have mis-spoken/written.

Just to re-iterate, I'm not a fan of this format at all. I'm actually in the middle of converting a million line project to use XcodeGen just so I can get away from it. But everything does have a reason.

[xbar]

It is not necessary for bad software to remain bad. There may be a reason for some decisions, but it does not mean that such decisions must be permanent.

Xcode 12 UX is an example where Apple seemed willing to invest. There may be reasons pbxformat is bad, but there is no reason Xcode 13 or 14 couldn't address them. After all, it's only software.

[ASalazarMX]

Apple controls the whole ecosystem, and third parties just can follow. If only Apple put the same effort in improving the development environment as they did during the introduction of Swift.

[dalemyers]

Agreed. I've been expecting Apple to replace this format with a much more diffable one for years. I doubt that will happen now with the new support for Swift packages and the xed command.

[reaperducer]

they may just be misunderstanding or have mis-spoken/written

90% of the tech rant blog spam on HN is people who don't fully understand the tool they're using.

Something doesn't work the way they expect for their particular project or their specific need, and they blather on about how bad it is.

When the reality is that these things are often done for a reason, but the author's myopia prevents him from understanding that there are other people doing other things in the world.

[Apocryphon]

It could certainly be mitigated if the creator of the software published less opaque documentation about it.

[dalemyers]

This is 100% true, but it's also one of the more difficult things in life to understand. It's one thing to know that other people have other experiences and needs, but it's another to really constantly feel that.

I'd like to see more assumption of positive intent on here, but it's definitely a hard task. I hope I didn't offend the original author here. I tried to ensure that I explained without chastising.

[Cloudef]

There might be reasons for everything, but all those reasons soon become irrelevant when you try to merge a code that also changed the project file. Have fun. Xcode project generators at least solve this somehow, but they'll always play the chicken & egg game with upstream, and something won't work properly or needs nasty hacks.