We all use Xcode every day, so why not use it smarter?
Xcode is a tool many of us use every day and all day, but it’s also a tool with so many options that it’s hard to find them all. In fact, some features almost feel like they’ve been hidden, partly because Xcode is a very old application that has received dozens of updates and upgrades over the years, but partly also because it has so many features there just isn’t room to give them all the space they deserve.
You’ve probably read Xcode tips and tricks before – I’ve written a few of them in my books and videos! – so here I want to focus on five specific tips that most people don’t know about. So, here are 5 new Xcode tips and tricks you can use immediately to work faster and more productively in Apple’s one and only development environment…
Who changed this line of code last? Which commit modified this method, and why?
When you’re working in a large code base alongside other developers, these kinds of questions crop up all the time, and Xcode has a simple viewing mode to answer them immediately: Blame View.
Source control blaming allows you to look at each line of code in your project to see which developer last modified it, what their commit message was, and compare that version against the previous one to see the change.
Xcode has a specific blame viewer built in, and you can activate it by opening any code file in your project then going to the View menu and choosing Version Editor > Show Blame View.
When Blame View is activated, a new panel will appear to the right of your source file, showing the name of the person who last changed the file, the date of the change, and their commit message.
Even better, if you hover over a particular change you’ll see an “i” button appear – if you click that you’ll see options to show the files that were modified in the commit and to open that commit in a comparison window.
Storyboards can be hard enough to manage at the best of times, but if you occasionally find yourself moving something that really ought to stay still, you should lock it.
Yes, lock it: Xcode can mark it as fixed so that no one can move the object or change any of its properties – you’ll never accidentally drag that button inside that scroll view again!
To try it out, select any object on your storyboard canvas, then activate the identity inspector – that’s Alt+Cmd+3 if you like keyboard shortcuts.
Now look for “Lock: Inherited (Nothing)” and change it to be “All Properties”, and you’re done – you can no longer adjust any of the properties in that view, or even move it.
Xcode’s log window is a great place to show messages from your app or other frameworks while you’re debugging, so it’s a real shame that both Xcode and iOS use that space to vomit hundreds of lines of meaningless nonsense at you.
And yes, I’m looking at you, “if we're in the real pre-commit handler we can't actually add any new fences due to CA restriction.”
Fortunately, there’s a small change you can make to hide these messages: hold down Alt then go to the Product menu, and choose “Run…” to customize your Run schema. Now select its arguments tab and add a new environment variable called
OS_ACTIVITY_MODE. Give it the value “disable”, and you’ll never see nonsense Xcode logs again – much better!
A modern iOS app supports everything from 12.9-inch iPad Pros down to iPhone SE, with iPhone X’s notch thrown in for good measure. That’s an easy feat to accomplish, but it’s a hard feat to accomplish well, and that’s where storyboard previews come in.
When you’re designing in Interface Builder, Xcode can show you what your current view controller looks like in any number of alternative layouts. For example, you could be designing for iPhone 8 in portrait, and have IB show you iPhone 8 landscape, iPhone X, iPad Pro 12.9-inch in portrait, and iPad Pro 9.7-inch in landscape with split view – all at the same time.
This means you can make a small change and see how it looks everywhere else, without having to try a variety of simulators or devices.
To try out storyboard previewing, select a view controller inside your storyboard and activate the assistant editor. By default you’ll see the Swift file that powers the view controller you selected, but if you look in the bar directly above your code you should see “Automatic” with two overlapping circles.
Click that, and choose Preview > Main.storyboard instead, and now you’ll see a live device preview. At the bottom of that window you’ll also see a + button where you can add a variety of devices and configurations, and when you bring one in you can hover over it to find a rotate button to try other orientations.
Bonus: in the bottom-right corner you’ll see your current language, e.g. “English”. Click that and choose Double-Length Pseudolanguage instead to see how your user interface responds to longer strings.
A maxim everyone should live by is “test your app like you hate your app,” and what it means is that if your app can survive being battered by someone who is intentionally trying to destroy it / hack it / crash it, then it should be in pretty good shape for the real world.
So, I present to you the single most important shortcut you can use while testing your apps in the iOS Simulator: Shift+Cmd+M. This triggers a memory warning: it simulates your app using enough RAM that it caused memory pressure, which forces the system to take emergency action.
That action usually involves terminating background apps, clearing out caches, and asking the foreground app to reduce its load if possible. Any of those could potentially cause problems with your app, but rather than ship and hope for the best you should simulate memory pressure yourself.
So, use Shift+Cmd+M while your app is running – try it on every view controller to make sure no important data gets lost, try it when it’s running in the background, try it when you know data is being saved and loaded. In short, simulate memory warnings at the worst possible times to make sure your app recovers – test your app like you hate your app!
Paul Hudson is the creator of Hacking with Swift, the most comprehensive series of Swift books in the world. He's also the editor of Swift Developer News, the maintainer of the Swift Knowledge Base, and a speaker at Swift events around the world. If you're curious you can learn more here.
Link copied to your pasteboard.