Xcode

Tools to Help Test LocalizationApple provides some pretty slick tools to help with localization testing in your apps. I had completely forgotten about two launch parameters that make it possible to find those pesky layout problems early: NSDoubleLocalizedStrings - Any calls made to NSLocalizedString will double the strings to simulate languages with longer words, like German.NSShowNonLocalizedStrings - Replaces any text from NSLocalizedString that doesn't have an entry in a strings file.AppleTextDirection - Simulates a Left to Right language.In Xcode 7 there is an easier way to provide these options. Edit the scheme for your app, click on the Run section, then the Options tab. You'll see Application Language has two options - Double Length Pseudolanguage and Right to Left Pseudolanguage. There is also a check box for Show non-localized strings. These three options are equivalent to the launch arguments above. ...

Here's a quick script that deletes and recreated all of your iOS simulators in Xcode 7. Use it when you get the duplicated nightmare or if you just want to reset everything: https://gist.github.com/cabeca/3ff77007204e5479f7af

In iOS 9 Apple has introduced a number of new shiny things for UIKit Dynamics. One of them is UIFieldBehavior which describes magnetic, electrical and spring fields of influence. Fields are hard to debug (even in real life!) so Apple decided to provide a debug mode on UIDynamicAnimator. The trick is the debug mode isn't published in the headers. Why? Who knows. They mentioned it quite plainly at WWDC 2015 and said you have to turn it on in the LLDB debugger. ...

I've been noticing on my Mac OS X Mavericks 10.8 Server I have running in a data center has been filling up its Time Machine volume way too quickly. The backups are continually huge and only about a week fits on the second hard drive inside of the Mac mini. Every time the machine backed up it was taking up so much room that previous backups had to be deleted. ...

The WordPress for iOS project had a number of unit tests using Core Data and a custom asynchronous test helper. The helper used a semaphore in a global scope and a bit of method swizzling to give a wait/notify mechanism. The problem with this solution was the global semaphore and poorly written tests causing a conflict. Tests would call the ending wait and previous tests running Core Data would fire off notifies causing a mismatch between the original test and the recipient of the message to pass by the current semaphore. ...

If you run unit tests inside of Xcode, you may wish to turn on the behavior to show the test results after they run. Go to Preferences in Xcode.Click on the Behaviors tab.Click on Succeeds.Check the box shown and select "Show" then "Test Navigator".Repeat step 4 for Fails as well.Now when your tests finish (failed or succeeded) you'll see the pretty green or red marks.

In the spirit of yesterday's post, I'm going to list out what I use every day in terms of software. This isn't exhaustive but it's pretty darn close. General Utilities1Password - Probably the best password manager out there combined with mobile appsCloudup - quick way to share images, videos, text (ask me for a referral code)Coffitivity - coffeehouse sounds to help boost productivityCyberduck - SFTP clientDaisyDisk - finding where all my space has goneDropboxEvernote - where I keep my larger notes, graphics, PDF filesParallels Desktop - for the occasional booting of old Mac OS & Windows VMsRadium - menu bar radio streamingRdio - monthly subscription-based song streamingRescueTime - track my app usage to determine if I'm distractedSimplenote - for my quick note taking needsSkype - sadly yesSlack - communication for our team - web socket-based system like HipChat but betterGraphicsAdobe Photoshop CC - go-to app for image editingAperture (more for personal use)Balsamiq Mockups - easy mockupsBartender - organize your menu bar extras areaCamtasia 2 - screen castsColor PickerJoin.me - easy screen sharing - I use it more for helping people fix computer problems remotelyPixelmatorSnagItDevelopment - GeneralBase - for digging around SQLite files; especially handy debugging Core DataCharles - proxying application for testing remote callsHockeyApp - binary distribution for testingKaleidoscope - arguably the most beautiful diff tool - ignore whitespace is still not a feature :(PHPStorm - for when I have to get into WordPress and WordPress.com API codingTextMate - Still my favorite text editorTextual - Mac IRC clientDevelopment - iOSAppCode - alternative IDE for Objective-C - I switch between Xcode and here for specific reasons (future post?)iExplorer - could not live without the ability to dig around device filesystemsPaintCode - easiest way to get Core Graphics code from images or hand-drawn UI elementsReflector - transmit your iOS device screen to your computer for recordingSpark Inspector - interactively debug your UIView layers & NSNotificationCenter callsXcodexScope - helpful UI tools for your MacDevelopment - AndroidAndroid StudioGenymotion - Android VM manager - lurv

Giving a presentation with Xcode on screen? Don't forget about Presentation mode in Fonts & Colors! It doesn't help with the text size in the navigator but at least everyone will see your code nice and clear!

I've gone back and forth on the debate with whether or not we should be checking in the dependencies for a project supplied by CocoaPods. In the past I felt it was best to only check in the Podfile and maybe the lock file. I believe I've finally made a decision with recent experiences and my development practices with Git. I'm checking in the whole effing workspace. Why? Every branch, especially master, should be compilable and archivable up to a point. Caveat 1: Xcode is a piece of shit sometimes and will break things because it can between versions. Caveat 2: Provisioning Profiles. CocoaPods is a well-maintained tool, however, Specs are a crap-shoot. Specs can disappear. Specs can be unofficially maintained. Specs can be wrong. Checking in your Pods directory ensures the best possible snapshot of the pre-binary code. Forcing a pod install every time someone checks out code doesn't ensure the same state of code is maintained for testing bugs in previous versions. You may decide to drop Pods support and forget how to use it. Wouldn't it be nice to do diffs on your dependency classes? Xcode Bots doesn't work well enough yet with CocoaPods for me to want to install Pods every build I'm also not sold on Xcode Bots itself - it's quite unreliable and likes to smoke my server's CPU. CocoaPods needs to not be a hinderance - its pretty innocuous when the risky work (installing Pods) is done and checked in. That sums up my thoughts. I primarily work on WordPress for iOS which is a heavily forked and contributed to repository. I don't think the project could be a success with the amount of branching and pull requests performed if we didn't check in the Pods directory.