Rss

Xcode Treasures Now Available

Announcement from Pragmatic Progammers today: Xcode Treasures: Master the Tools to Design, Build, and Distribute Great Apps is now in beta.

So, this is the book that I’ve been cagily dropping hints about on Twitter for months, and that I showed off at CocoaHeads Ann Arbor two weeks back. I’ve also started creating videos for it as part of invalidstream, where you can already check out demos from the Debugging chapter (parts 1, 2, and 3).

Targets

Let’s hold up: WTF is this book anyways? Is it a new version of the Prags’ introductory iOS 8|9|10 SDK Development book? Nope, we decided to something radically different this year, something for readers at different stages of their development.

Xcode Treasures is about Xcode itself, not about any of the SDKs. In fact, while the default mindset is Swift + iOS, the book contains examples for iOS, macOS, tvOS, and watchOS, written in Swift, Objective-C, and even plain ol’ procedural C. The idea is, I’ll use whatever form best suits the topic at hand. Want to see how the Address Sanitizer works? You’ll need to write some crashing C code for that. Interested in Auto Layout? I think you get the gist better by making a Mac window with Auto Layout and resizing it yourself: you get real time feedback on how your constraints are being applied.

None of the examples are so hard or so deep that you can’t at least get the idea of what’s going on, even if it’s out of your usual wheelhouse. And if it inspires you to try out one of the other Apple platforms or languages, better yet.

Because the thing is, the real goal of the book is to come to a deeper understanding of Xcode itself. Think of how you usually use it: you start with a template like “Single-View App for iOS” or “Metal Game for Mac”, or “TVML App” and it’s all set to build and run as-is, even with no functionality. Then you start adding code and art. And sooner or later, you find that you have some sort of unusual or advanced need, and maybe you can’t figure it out because all the time you saved by starting from a template rather than building a project from first principles meant you never had to see how Xcode really works.

At this point, maybe you conclude that Xcode is dumb and can’t do what you need, when really you’ve only ever used 10% of what Xcode can do, and there’s not a clear path to see how the other 90% works.

Xcode view debugging

Preferences

Doing something different than the usual beginner book was one of my inspirations for writing this book, but there was another: I want to answer the sort of lazy cynicism that has emerged about Xcode in some developer circles. So much of social media rewards takedowns and hot takes, so you can always collect social status just by ripping on Xcode. Problem is, newcomers to development on the Apple platforms see this and emulate it as a means of elevating their own status within the community. Of course, that’s not specific to Apple developers: if you want instant street cred among anime fans, just tweet “Sword Art Online sucks” and everyone will tell you how right and good you are. Same goes for throwing around the term “late-stage capitalism” like you are genuinely credentialed to predict the future of world economics. Dump on stuff and people will reward you for it. Even as a life-long pessimist, I’ve grown tired of this racket.

The book’s working title was No Regrets Xcode, and at one point, I toyed with proposing Xcode for People Who Hate Xcode as a title. But a full-throated defense of Xcode is an essay or a blog, not a programming book. Instead, I hope to prove by example — many, many examples — that Xcode is better than you think it is.

Now, I’m not blindly loyal either. I see all those 1-star reviews for Xcode on the Mac App Store. And one of my tech reviewers pointed out that despite my cheerleader-y tone, he has filed hundreds of bugs with Xcode, and I’m sure they’re all valid.

My argument is this: to me, Xcode is indeed plagued by the same reliability problems that affect most Apple software in the current era (c.f., Marco Arment’s Apple Has Lost the Functional High Ground). It’s worse because we as developers depend on Xcode to get our work done. But how do you think people who depend on the Pro video apps feel right now? High Sierra has a been a disaster for them, and as just a part-time video guy, I’m often hobbled by lock-ups in Final Cut Pro, or this insane bug in Compressor where output files were many times larger than configured, but only on the 2013 Mac Pro (I was not happy about this one). And let us not even speak of iTunes and its myriad problems.

So, yes, Xcode is flawed. But is it fundamentally flawed? Is there some core concept — its multi-paned single window UI, its scriptable build system, the nature of app bundles and code signing — that makes it impossible for Xcode to ever be good? I don’t believe anyone is making this argument. The closest you get to this is storyboard haters who build their UIs in code. I disagree with that camp, but even if I didn’t, that alone is not enough to relegate all of Xcode to junk status.

Creating storyboard segues

Connections

So yeah, I’m playing a contrarian game here. That’s why the cover of the book is such a wonderful design that everyone fell in love with when we saw it. On the one hand, gold + apple. But it’s also the Golden Apple that goddess of discord Eris used to spark an argument between rival goddesses and, ultimately, lead to the Trojan War. With all the arguments about Xcode, what better thing to put on the cover than the literal icon of strife?

But I’m also reminded of another contrarian play. MacAddict magazine launched at the nadir of the Mac, in September 1996, when the Mac was getting walloped by Windows 95. And yet look at the cover of the first issue: “Why the Mac’s future is bright”.

And you know what, they were right. Even despite the fact that not only were the financials bad, but the Mac itself had a lot of problems: this was the era of Type 11 errors destroying all your work, and software companies goosing their stock price by publicly announcing they were dropping the Mac. In fact, this first issue even has a cover feature on how great OpenDoc is, even though OpenDoc turned out to be a software architecture wrong turn that eventually fizzled out.

MacAddict worked because its writers, editors, and readers knew that if you looked past these problems, the fundamental vision of the Mac as a tool for creation and communication was far more compelling than the Corporate Obedience mindset that Windows offered.

So, I’m making the case that it’s time to take a fresh look at Xcode. Acknowledge the bugs, sure. Hope that they get better. But beyond that, look at how nice the code editor is (and how you can customize it to suit your own tastes). Look at how the build system is smart about resolving dependencies, how you can set up your own build properties on a per-configuration basis or even run arbitrary scripts during the build, or run the whole thing from the command line and let Jenkins handle your CI. Think about how app slicing and on-demand resources make things better for your users by making smarter use of their limited on-device storage, and how Xcode gives you a UI for managing these assets visually. Behold the wonderfully clever power of LLDB to give you powerful breakpoint capabilities, and tools like Instruments, Main Thread Checker, Address Sanitizer and more.

Retain cycle debugging UI

Build and Run

The beta book launching today has 7 chapters. Three more are fully written and will roll out over the next few weeks. Two more are still being written. After incorporating errata fixes and other feedback from readers, this should result in a final book in August or so. With books from the Prags, I always advocate getting the eBook or an eBook-plus-paper bundle directly from the Prags, because you get updates, and it includes all the formats you’d need: ePub for iBooks, .mobi for Kindle, and PDF.

[Update: Currently, only the ebook is available, because they can’t charge for something that won’t ship within 30 days, and the print edition is further out than that. ebook buyers will get a coupon offering upgrade pricing to the ebook + print bundle when it’s ready. Details on the Prags’ Beta Books FAQ.]

The book’s home page also include three samples that you can check out for a taste of what’s covered. It was hard to pick, but I went with embedded scenes, code snippets, and build phases. All of these contain tricks and techniques you can apply to your own work right away.

I’m also really fortunate that editor Tammy Coron is also a long-time Xcode user, so she’s able to give me detailed feedback and have a fresh set of eyes on where the material does and doesn’t flow well, is and isn’t helping. Along with a lot of tech reviewer feedback (some of which I’m still working through), that’s making this a better book.

Hopefully you’ll all enjoy this deep dig into the depths of Xcode!

Comments (3)

  1. Heath Borders

    I disagree with the comparison to the Mac at its Nadir. At that time, Apple wasn’t one of the largest and wealthiest companies on the planet. Apple has been flush with cash for 10 years, and has been one of the biggest companies in the world for at least 5. If they won’t prioritize developer experience now, they certainly won’t later when the iPhone hits critical mass, growth slows, and it becomes less profitable.

    The book sounds great! It sounds like the exact resource I would have loved in my second 6 months of developing on the platform.

  2. Colin Wilson

    I bought the beta from Pragmatic. Very pleased with it. The section on Storyboard References has already helped me with a project I’m working on.

    Note that the Pragmatic forum is not available because of the FOSTA-SESTA act of 2017 – so you want to provide an alternative place for feedback.

    A suggestion – a chapter on Localization would be a useful addition.

Leave a Reply

Your email address will not be published. Required fields are marked *