Xcode Through the Years
Cory Bohon (tweet, Hacker News):
As we begin 2022, it has been almost 20 years since Apple released Xcode to developers as the predominant way to create Mac apps.
[…]
This was a revolutionary idea, and Apple put itself in direct competition with the commercially available IDEs like CodeWarrior that developers were using at the time to build apps for the Mac. It would take a few years, but Project Builder (and its successor, Xcode) would become the dominant IDE for developers building apps on the Mac — especially as Apple began developing new platforms like the iPhone and essentially locked developers into using Xcode for building apps for those platforms.
[…]
In 2010, Apple took the development community by surprise when it announced Xcode 4, a ground-up rewrite of the interface that merged two major development apps, Interface Builder and Xcode, into a single app.
I have special affection for ProjectBuilder (without the space) and Xcode 3.
These days, having learned to heavily use .xcconfig files and made peace with the single-window workflow and linking groups and folders, I’m reasonably happy with it. Interfacewise, the last several versions have brought welcome tweaks. It seems to be at a local maximum.
The main pain points right now:
- The delay every time I run a unit test.
- Testing commands sometimes run the wrong tests or do nothing at all.
- Profiling unit tests doesn’t work
- Compilation still erroneously fails sometimes until I clear the derived data.
- Syntax coloring and Command-click symbol navigation are often wrong (usually for Swift).
- Giant generated Swift header files are hard to use.
- Auto-indentation with closures and generics is not great.
Previously:
- Slow Testing With Xcode 12.5 and Big Sur
- Apple Developer Tools Memory Lane
- Deleting DerivedData the Right Way
- Xconfig and XcodeBuildSettings.com
- Profiling Mac Unit Tests
- The Unofficial Guide to xcconfig Files
- How to Make Xcode’s UI Work for You
- On Apple’s SwiftUI Header File Documentation
- Xcode 4
- Xcode UI Improvements
- Xcode Unit Test Bugs
- Xcode 3.2
- IDEs
- Mac OS X 10.3 Developer Tools
- Productivity
- That Finder Thing
Update (2022-01-31): Steve Troughton-Smith:
Xcode 4 was the beginning of the end for Interface Builder. What was a fast, reliable, extensible external tool became bogged down with storyboards & autolayout, and accidentally clicking on NIBs became something that’d make you cringe and wait for Xcode to finish beachballing
I am fully convinced that the direction Interface Builder took poisoned the well for iOS development in a way that now makes SwiftUI feel far more appealing than it deserves to be, just as a breath of fresh air and escape from autolayout constraints 😂
Interface Builder should have remained a separate app. It worked better with more screen real estate and a menu bar tailored for it.
After all, any significantly large app includes resources created in separate apps (e.g. for images, video, sound).
It seems like Interface Builder was built into Xcode to offer an easier onramp for novice developers, with the side effect of permanently hampering it as a tool for professional developers.
I wouldn’t have a problem with Interface Builder remaining built into Xcode, if I could just open my storyboards in a separate full-sized window. Setting everything up at 50% is an unbelievable drag.
10 Comments RSS · Twitter
I don't understand the comment about Xcode 4 being "a ground-up rewrite of the interface that merged two major development apps, Interface Builder and Xcode, into a single app. This merger meant that opening XIBs would no longer require opening Interface Builder separately."
I'm not sure what is meant by "opening separately". With Xcode 3, you double-clicked a UI element to open it. With Xcode 4, you single-clicked a UI element to open it. I'm sure it was a lot of work for the developers at Apple, but the impact on developers using these tools was pretty minimal.
@Sam I thought the impact of the merger was substantial because it affected the menu structure, window sizing and layering, etc. I thought Interface Builder was easier to use as a separate app. The Xcode 4 interface was also very different, even aside from integrating IB.
Any time major apps merge, the menu bar invariably becomes either more cluttered (as it encompasses the aggregate functionality) or less static (dynamically showing functionality depending on context, which hinders discoverability). See also: iTunes eventually subsuming apps such as the iPod Firmware Updater and iSync. And of course, for the reverse, Music/TV/Podcasts each being a little simpler than their ancestor.
But I guess Apple did studies and found that having Interface Builder be a separate app confuses newcomers? I dunno.
Sören, you forgot Apple's favorite option: drop features so the menubar can stay the same!
But color me skeptical that Apple has done any significant user testing since Tog left. Or that they care that much about the Xcode newcomer experience. I've heard a million complaints about Xcode from newcomers, but never anything related to that.
Interface Builder as a separate app was not working efficiently when it came to linking IBOutlet code to nib/xib views/widgets.It's more difficult to sync 2 apps than 2 plugins of the same app.
But even after all those years, the new workflow still does not fully work as promised. You still basically needs to select/open a xib file to finally see in your class @interface declaration which outlets are connected. Also I'm quite dubitative that connecting the IBOutlet code to the views is really used that much.
I'm quite happy with Xcode, but maybe that's got something to do with the fact that my code is 100% ObjC, and I rarely use Interface Builder.
I still miss IB as a separate application with its own menus. Switching between modal/contextual interfaces (via tiny, cryptic tabs icons) in Xcode 4 was such a huge (and annoying) change, I lost interest in Mac development as a hobby, and have never really learned how to use it. Inspector panels and separate windows were a better use of limited screen real estate, rather than having your content view clipped by two giant outline views on the left and the column (reverse-drawer?) filled with inspector tabs on the right.
The loss of the debugger and console was another unfortunate change. They basically took everything I hated about Visual Studio and brought it to the Mac, so I've always blamed the Xcode 4 changes on Windows refugees who suddenly switched to iOS development.
I'm with @Old Unix Geek on Shark: it was fantastic. Shark felt fast and lightweight, but also gave you a lot of useful information, rather than a lot of confusing and shiny widgets (and slowing your machine to a crawl). I fixed a lot of leaks and sneaky memory smashers with MallocDebug and OmniObjectMeter, back in the day, too. Oh well.
I must say, though, I don't remember Xcode 3.0 with any fondness. Apple used it to dogfood Obj-C garbage collection, and overnight my two-year-old PowerBook became unusable for editing class files, because the GC thread interrupted editing. A senior Apple engineer finally admitted in email that single-processor machines were basically unusable, but didn't have a workaround. I had one class in particular where just editing the implementation would cause 100% CPU usage on both processors of my G5 cheesegrater tower.