|
|
|
|
|
|
by eschaton
18 days ago
|
|
|
Xcode’s a lot more than a wrapper for UNIX utilities. For example, it has an entire build system. It doesn’t just invoke xcodebuild under the hood—and even if it did, xcodebuild uses the exact same code to build your projects as the IDE. Most of the problems that I saw people have with Xcode over the two decades that I worked on it were the result of one fundamental problem: They wanted to work a different way than Xcode is designed to work, and jumped through a ton of hoops to do so, and then blamed Xcode for not accommodating their intentional working at cross-purposes. A good example: An app that considered itself “large” because it had a thousand tiny static library targets each with only one to three or so ObjC classes. Far smaller than Xcode itself, but because they insisted on working that way—for no real articulable benefit besides “that’s how we want to work”—their project took hours to build from scratch instead of minutes like much larger projects that have many fewer targets. |
|
|
In my experience, it’s quite “crashy.” It often locks up so bad, that I need to force-quit (or force-restart the Mac). I end up doing that once a day, or so. I suspect that many of the performance and stability issues, have to do with resource usage. It’s a damn big app.
It can also end up in strange states, where portions of the UI fall “out of sync,” and the app needs to be restarted. Some operations (like opening a storyboard, or stopping at a breakpoint) introduce massive delays.
It’s not a denigration, calling something a UI shell. I’m working on one, right now. The engine and backend were done in April (started in February), and all the work since, was on the UI shell. I probably could have shipped something that “ticked all the boxes,” in May. It’s almost done, but there’s still a couple of months of testing, ahead.