Tag: Xcode 4

Put It on My Tab

In the Edge Cases1 episode “My First Xcode 4 Rant”, I talk about my frustrations dealing with the Xcode 4 window.

Apple has a response, kind of, in their WWDC 2012 video “Working Efficiently with Xcode”.2 There, (amid a lot of other helpful tips) they talk about “task-based tabs”. To get around the fact that Xcode makes no effort to configure its helper views for the kind of document you’re editing, they recommend manually creating customized layouts in their own tabs: a design tab for xibs, for example, where the utility pane is always present.

I’ve used Xcode 4’s tabs, and they don’t work for me.

For one, it’s clunky to have to make sure you only open certain documents in certain kinds of tabs. I want to switch between documents quickly. This usually means using the filter in the navigator pane to find the right file, then selecting it there, then using file history to go back and forth between that file and my previous files. All good stuff. But if I have to intermix that with, OK, now, you need to remember to go over here to open this file, well: by the time I remember to do that, I might as well just use the keystroke shortcuts to open and close the utility pane each time, no?

But the worst is Command-W.

You know what happens, after you lovingly spend minutes and minutes configuring your special tab with exactly the right spacing and exactly the right helper panes? That’s right, you accidentally hit Command-W, because your fingers have been trained for years to dismiss files this way. And when you do that, all your painstaking work is gone in an instant. Poof! (Actually, there’s no animation.) No undo. It’s just gone.

After doing that enough times, you stop spending a lot of effort configuring tabs.

But you still don’t escape, because even if you just have one working tab, you inevitably start arranging that tab how you want it to look. And if you have a second tab of any sort, such as the Debug tab that’s recommended in the session so that you don’t have to keep showing and hiding the debugger pane, Command-W kills your first tab dead.

And if you have no tabs, Xcode 4 closes your whole window, so you can’t even get used to one shortcut for views and one shortcut for windows. Frustrating.

And even if all that didn’t bother you that much, remember Rule Number 4 from “Would They Call It iCode?”: No UI Fiddling! Needing to manually set up your own tabs is the definition of UI fiddling. It’s as if Apple is saying, Go on, live in the trees, we recommend it! But instead of providing you with a treehouse, they just provide you with a bunch of lumber and nails. (And your house falls apart if you close the door too hard.)

Edit: OpenRadar 1814402

Edit 2: Inspired by Ole Begemann’s comment, I found this post by Brian Webster describing how he used Xcode custom behaviors (with keyboard shortcuts) to create custom tabs. Lots of good details. Don’t have time to address this in depth right now, but wanted to get it out there.

Final edit: Imagine every time you open a new file, Xcode’s window autoconfigures itself to the default layout for such a file (which you can change in prefs). For xib files, it shows the utility pane; for .m files, it hides the utility pane, but shows the assistant pane with the associated .h file. And further: it remembers any custom configuration for individual files, so if the last time you had Foo.m open, you also had its associated xib file open, it replicates that as well.

Custom actions can be very powerful. If I’d actually finished watching the “Working Efficiently” session before I wrote this post, I would have found out exactly how to set them up. They can “fix up” the layout options to an existing file, for example; you don’t need to create a new tab. Such things can help me out quite a bit.

But I still think it’s doubling down on the wrong approach. Too many extra steps you’ll have to do over and over, too much manual configuration of things Xcode should already know. And that’s all I have to say on the matter for now.

 

1. Note: despite the URL, which we chose because it would be laughable to expect “EdgeCases” to be available in 2012, the show is called “Edge Cases”, not “The Edge Cases Show”. Like, y’know, “Bono”, or something.

2. No direct link, but go to https://developer.apple.com/videos/wwdc/2012/, sign in, and search for the title. And if the website verbiage and my Twitter compatriots are to be trusted, you don’t even need a paid account to watch it.

Caveat-Slash-Manifesto

It has occurred to me, since I started writing and podcasting in more depth about Xcode 4, that a caveat is in order.

It’s not a secret that I worked at Apple for a bunch of years. It’s been in my About page on this blog since the beginning.

What I haven’t said publicly is that I worked on Xcode itself—the application—for all those years.

Is that a conflict of interest? Am I going easier on it because some of my code might live on somewhere in the newest version? Am I criticizing it more harshly as an ex-employee?

Hopefully, none of the above.

I did ship some features in Xcode 3. But I can say that, with one or two very trivial exceptions which I’ll avoid talking about here, there are none of my fingerprints on Xcode 4.

In my mind, that frees me to discuss it like any of you would.

Well, maybe not exactly like you would; I’ve been thinking a whole lot about developer tools, so I have more of an interest in exploring in detail the highs and lows of Xcode 4 than most other folks. And, unfettered either by personal involvement or Apple’s shroud of secrecy, I intend to continue doing just that.

But I figured you should hear about my…particular background now rather than later.

Build So Good

Continuing in my series of posts praising Xcode 41, I’d like to talk about the build confirmation sheet. This one:

If you press Command-B while Xcode 4 is already building, Xcode will bring down a sheet over the project window, saying “Stop build? A build action is already running”. There is also an option to not show the alert again.

Now, if I ever actually had to press that Stop button, this would not be a praise post. This would be the other thing. But in fact, under normal circumstances2, I never press that button. What happens instead is that Xcode chugs away on the current build, and then when that build is done, the sheet goes away, and a new build automatically starts.

This is so exactly what I want Xcode to do, it almost hurts.3

The sheets becomes a little UI reminder: Hey, you may have to wait a little longer for the build you just scheduled. And it’ll be easy to tell when it actually starts, because the sheet will animate away. I almost always want to wait for the build to finish anyway before doing anything else; I want to see whether the code I just wrote compiles without error and warning. So the sheet doesn’t impede me at all. It fits in with my workflow exactly.

And it’s been in Xcode 4 since the very beginning, as far as I remember.

1. If, on the other hand, you want to hear me complain about Xcode 4, follow me on Twitter. Or just read the second footnote. ↩︎
2. Under abnormal-but-still-frequent circumstances in Xcode 4.3, alas, the build never finishes, and I eventually have to force-quit Xcode to complete a build again. ↩︎
3. While it might seem logical to want a toggle, in practice, that’s not the case. Incremental builds never take long (if they don’t take forever, see above), so waiting isn’t hardship, and a toggle would always require two taps of Cmd-B, and having to be sure you get the timing right, or you’ll stop your own build. ↩︎

Upgrading to the Next Model

Xcode’s new Core Data model file format, introduced with Xcode 4.1 in 2011, never made any waves in Cocoa development blogs that I saw.1 Which is a shame, because it’s a pretty kick-ass improvement. Instead of a binary plist format (more specifically, Cocoa objects serialized directly to disk in a binary plist format), it’s eminently readable and diffable XML.

It reminds me, for two reasons, of Mark Pilgrim’s complaint about Apple’s switch from the standard .mbox format to the (Spotlight-friendly, but undocumented) .emlx format in Mail.app in Mac OS X 10.4, which was part of his rationale (last straw?) for leaving the Mac ecosystem and moving to Linux. (See this Daring Fireball article about it, since Pilgrim’s blog posts are now only available via the Wayback Machine.)

For one, it’s because my experience with the new format involved what I remember to be an involuntary switch. The details are a little fuzzy for me now (a good reason to write these blog posts in a more timely manner), but I recall my edits being saved in the new format without my having done anything to warrant it, and without any prompting on Xcode’s part. Just like Mark’s experience in Mail. If Xcode did make a habit of that, I would be rather annoyed, and for the same reason. (As an aside, I go on about this at some length in my first podcast (link forthcoming2 due to this mistaken remembrance. See the second podcast for followup, or just read the rest of this post.) I’m a sophisticated enough user that I care about format switches, mostly for the sake of backwards compatibility. For non-technical users, losing that compatibility might be fine. Developers, however, are by their nature not non-technical users.

It turns out, I can’t reproduce that experience now with fresh reinstalls of Xcode 4.0.2, 4.1, and the latest Xcode 4.3.2. Instead, the only thing that changes the format is for you to explicitly change it in the model’s inspector pane. Which is great. Exposing that level of control over a file’s format is exactly what a developer tool should do. And they do it for other important file types too, like xibs. So, kudos.

For two, it’s because this is kind of Mark’s experience in reverse. Going from a less standard format to a more standard format. (I did say “kind of”.) While it isn’t documented, it is uncluttered, as far as I can tell, by the kind of unreadable binary garbage that pollutes other XML file formats. Entities are referred to solely by name, not UUID. Attribute titles are simple and understandable. From a practical perspective, this will make the SCM diffs you do every day far more useful and enjoyable. But I could also see someone using a script to mechanically put together a Core Data model file, much more easily than you would put together an Xcode project file. And going further, I could see someone writing a third-party Core Data modeling tool that spits out one of these. I’m almost surprised someone hasn’t done it already, though the Xcode 4 Core Data modeling tool is good enough (and free) that there probably isn’t much demand for it.

1. Is it because everyone used the Xcode betas but couldn’t talk about them, so by the time Xcode was publicly released, it was old news? I also remember thinking that there weren’t that many people talking about Xcode 4 on its release, despite it being a vast change. ↩︎
2. Yes, there’s going to be a podcast soon. I’m collaborating with Wolf Rentzsch on it. Patience. (I.e. I won’t answer questions about it just yet.) ↩︎