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:
Documentation in Xcode 5
The real awesome sauce on the awesome is that the compiler will verify your documentation. No, seriously:
2013-10-09: Matt Stevens points out -Wdocumentation, which is new in clang 3.2. From the Clang release notes:
… 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 risibly non-functional set of constraints gleefully chosen to frustrate them as much as possible.” As noted here:
iOS 7 Tutorial Series: Auto Layout in Xcode 5
… 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 + autolayout 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
Xcode Asset Catalogs
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, 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:
Easier merging of Xcode project files
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!
Xcode 5 Plugin Greatly Enhancing Built In Auto-Completion With Fuzzy Matching
Launch Arguments & Environment Variables
facebook / ios-snapshot-test-case is image matching for UIView/CALayers.
MoarFonts: “Use custom fonts for your iOS projects directly in Interface Builder, the WYSIWYG way”
OCLint: A static source code analysis tool for Objective-C and related languages
objc.io issue #6 has various articles on Xcode internals, CocoaPods, and Travis CI
larsxschneider / ShowInGitHub – “to open the GitHub page of the commit of the currently selected line in the editor window.”
Xcode Plugin Allowing You To Markup Links And Images Within Code And Console Output
Xcode Plugin Enabling Neater Code Alignment With Customizable Alignment Patterns
Xcode Plugin For Listing And Going Through To-Do And Fix-Me Items In Your Code
An Xcode Plugin Enabling Easy Use Of The Clang Source Code Formatting Tool
Code Pilot Goes Open Source and Gets Xcode 5 support
Project Statistics for Xcode: Major Update to V2 with Great Enhancements
dblock / fui will find imports unreferenced by code (note that storyboards do not count as code!)
Useful Xcode Build Phases
jfahrenkrug / StoryboardLint “A lint tool for UIStoryboard to find wrong classes and wrong storyboard/segue/reuse identifiers”.
Code Generation Tools To Reduce Errors Caused Storyboards And The Asset Manager
Xcode Plugin That Allows You To Automatically Extend Xcode Code Snippets With A Git Repository
Alcatraz: The Package Manager for Xcode
A Tool Enabling Easy Objective-C Dynamic Code Injection In Xcode And Appcode
8 Tips for working effectively with Interface Builder
__attribute__ directives in Objective-C
Xcode Debugger Quick Look
Some New Xcode Plugins For Enhancing Code Display, Interface Builder, And Code Completion
Clean up your projects with Xcode 5
Improving Debugging Workflow – Introducing MCSLLDBToolkit
NSHipster on Xcode Plugins
Tool: Xcode Plugin Providing A Nice GUI For Working With Cocoapods
Tutorial: Using Compiler Directives To Create Useful Custom Warning And Error Messages
Continue Reading →