So, no doubt by now you’ve been working with Xcode 5 for a while and noticed that there’s a good number of new features in it — personally, we’re looking forward to Mavericks Server running bots for us the most, never having to deal with a signing problem with Jenkins again will be none too soon — but probably haven’t had time to read up on them as thoroughly as you’d like, right?
If you took our advice in the Programming for iOS 7 roundup to go pick up the iOS 7 by Tutorials book, you’re up and running with all the essentials soon as you work through Chapters 9 to 15. If you didn’t, hey there’s another good reason to! In the meantime, the How To Use Git Source Control with Xcode in iOS 7 is free to read.
One thing they do give undeservedly short shrift to is the new documentation support though, which rather excites us. We were converted to appledoc enthusiasts in short order after finding it, adding a daily documentation build task to Jenkins last time we were leading a sizeable team; but it’s always annoying to introduce third party dependencies into your workflow — having that functionality in Xcode and tied right into code completion popups is pretty awesome:
The real awesome sauce on the awesome is that the compiler will verify your documentation. No, seriously:
… Clang parses the comments and can detect syntactic and semantic errors in comments. These warnings are off by default. Pass -Wdocumentation flag to enable warnings about documentation comments.
This will warn when the documentation’s variable names or return types don’t match the method signature.
Now that’s something we have never heard of in a development environment before. Sufficient reason to adopt this practice, NOW!
Another particularly promising callout is the improvements in autolayout. As we’ve documented, up to now its usage has been commonly … problematic. “Loathe with passion” would be a better way to characterize our experiences to date, actually; it seems the algorithm Xcode 4 used was “figure out what the user actually wants, then make up and throw in there with no warning a visibly non-functional set of constraints gleefully chosen to frustrate them as much as possible.” As noted here:
… In Xcode 4, the creation of a slightly complicated view was close to impossible because Xcode did too much to ‘help’ the developer, but didn’t give the developer any way of correcting it’s ‘help’…
Yes, indeed. You feel the pain? We feel the pain. But things are better now, so we’re told, and if you’ve avoided the whole problem so far, time to get on board:
… In iOS 6, Auto Layout was available and recommended, but not required. In iOS 7, Auto Layout has become more important, to the point of practically being required, because it facilitates the ability, provided by Dynamic Type, for users to select the font size to use in standard button, label, and text field controls, and then have the rest of the screen respond correctly to the change in font size…
… Because of Xcode 4’s over-helping in IB, many developers frequently reverted two the two other ways to implement Auto Layout based views: Visual Format Language (VFL) and manually instantiating NSLayoutConstraint objects. Thankfully, because of the improvements in IB you’ll probably not be using these methods as much in the future. I’ve found that views that were impossible to build in Xcode 4 IB can now be created quickly and easily in Xcode 5.
So yeah, we’ll give it another shot in the project we’re starting now and see if storyboards and auto layout have reached the point of tolerability yet. After we take another read through this thought-inspiring article:
Storyboards seem to be a big point of contention in iOS development. Some see them as wonderful additions, some as a poorly designed and pointless hindrance that Apple seems intent on force feeding us. There is one thing that’s consistent though: almost nobody is using them right…
If, like us, you’ve been inclined towards the “pointless hindrance” view thus far, check it out. Not convinced otherwise yet, but we’ll give his ideas a shot.
Another particularly nice convenience you might have skipped over is:
Not only do they sort out asset naming clutter, they let you build slicing and resizing into your assets and out of your code. Sweetness.
A lot of the tips in last year’s Xcode Grab Bag post are still applicable to Xcode 5 too; in particular we note that the Alcatraz Package Manager would be your go-to for plugin discovery, as soon as it gets sorted:
We’re working on releasing Alcatraz 1.0 for Xcode 5. Please be patient and don’t create issues until 1.0 gets released. Thanks!
In the meantime, should you feel like writing your own, check out
kattrali / Xcode5-Plugin-Template: “Basic template for creating a plugin for Xcode 5.”
A particularly nifty Xcode 5-only plugin is
ryanolsonk / LLDB-QuickLook: “Debugger commands to open images, views, and more using Quick Look.”
Here’s a great tip for dealing with The Dreaded Project Merge Conflict:
A while back, I discovered a script called sort-Xcode-project-file in the WebKit project, which sorts the Xcode project by running the following command:
perl sort-Xcode-project-file [Project].xcodeproj/project.pbxproj
I started using it to make files easier to find in my projects and just nicer to look at. After a while, I discovered that it helps a lot with merging the Xcode project file. If both sides of the merge are sorted, there are fewer differences when merging, and makes almost all merges either automatic or extremely easy to tackle…
and finally, here’s a nifty tip for having Instruments tell you where that mysterious stuttering is coming from:
(TL;DR – Select Record Waiting Threads in the Time Profiler track info-panel thing.)
h/t: Pretty much all the above links came from the last few issues of iOS Dev Weekly, which if you’re not subscribed to, you should be!