Fixing Layer Transparency Issues in Xcode

If you’re looking to get higher frame rates and general application performance tweaks from your iOS application, you may need to take a look at transparent settings on your subviews. Any time you set a subview to be transparent, the OS has to blend multiple layers together to figure out the end flattened result. This blending takes CPU cycles and can impact performance of your app – especially in something as simple as a UITableViewCell.

Luckily there is an easy way to find these problems using Xcode’s companion tool, Instruments.

One of the instrumenting tools you can use on an app deployed to a device is Core Animation. The Core Animation instrument has a bunch of fancy switches you can flip.


That will turn on a visual indicator to show where multiple transparent layers exist on the screen. For example, the main table view of my app MigraineDiary shows the following:


To get your app into Instruments, simply select the “Profile” menu item under “Product”. This will build your app and launch Instruments. Make sure you have your device selected and not the iOS Simulator. Any areas that are heavily colored in red should be reviewed by you to ensure you’re not setting layers transparent that don’t need to be. This includes using [UIColor clearColor]!

You’ll notice transparency indicators in red on system components like the tab bar and nav bar. There isn’t much you can do about these, so you can really just ignore them. If you’ve overridden behaviors, however, you may wish to review your code to make sure you’re not breaking something.

iTunes Connect – Invalid Binary

I spent the past week pulling out my hair trying to submit an update for Centare’s EyeOnWeather application to iTunes Connect.  I kept getting a reject from the system and all I got for an error message was “Invalid Binary.”  THANKS, THAT’S SOOPER.

Eventually I ended up attempting to contact iTunes Connect Support for further details.  I thought it might have been missing icons, malformed Info.plist, something.  I haven’t changed anything in the project drastically with how it builds, so I was at a loss.  Turns out, I was picking the wrong provisioning profile in my setup.  Man I felt stupid.  Ends up that I’m not crazy – Apple’s documentation on how to set up your project for building still only references Xcode 3.  Awesome for the rest of the world using Xcode 4.  Here are some tips I got from Apple iTunes Connect support for pulling in information to submit to their developer team:

(replace 'path/to/" with the actual path to your application):

codesign --verify -vvvv -R='anchor apple generic and certificate 1[field.1.2.840.113635.] exists and certificate leaf[field.1.2.840.113635.] exists' /path/to/

codesign -dvv /path/to/

- This command is useful to see what certificate was used to sign your app. If under the section labeled "Authority" it says iPhone Developer, this means that your app was signed with your Developer Certificate. If it says iPhone Distribution, this means that it was signed with your Distribution Certificate.

codesign -d --entitlements - /path/to/

I ended up pulling the file out of my archive bundle to be sure I was testing what I sent up to iTunes Connect.  You can also just do a “Build for Archive” and then right click your .app in Xcode under Product and “Show In Finder”.  Drag that file into Terminal and it’ll paste the full path & filename.

Running those commands gave me confirmation of this – I was code signing with my developer profile.  Even though you pick the Distribution certificate in the submission window for uploading, it doesn’t change the signature of the app.  The solution was to go into my setup for the build and change the Code Signing Identity for the “Release” configuration to the Distribution profile.  I deleted the old “Distribution” build configuration that I had created back in the Xcode 3 days as it’s no longer appropriate.

This link is the defacto WTF help me document for code signing in Xcode 4:
Technical Note TN2250 – Understanding and Resolving Code Signing Issues

Xcode WTF are you doing?!

I didn’t start developing in Xcode “for real” until this year but I’ve played around with Xcode for a number of years.  Over that time, I’ve screwed around with settings and changed defaults.  It got to the point where following screen shot examples weren’t matching up, #pramga marks in my code weren’t showing up correctly in the code editor method drop down list and on and on.  Perusing through Xcode Workspace Guide, I found this handy little suggestion from Apple:
To reset Xcode to its factory settings for the logged-in user, run these commands in Terminal:

> defaults delete
> rm -rf ~/Library/Application Support/Xcode

After doing this, I had to re-add my Subversion repository, move my build folder to the /tmp directory, and pick my text editor color scheme again.  However, I now have a functioning Xcode and things seems happier again.  Yippy skippy!

Xcode & Snow Leopard – Logical unit tests hanging

I haven’t written unit tests before in Xcode.  I started to read Apple’s article on unit testing with iPhone development because I wanted to follow sound development principles with an agile approach.  Not long into the guide, I got stuck.  Literally.  Using Xcode 3.2 on Snow Leopard caused Xcode to lock/hang during the build of the logical unit test.  Same results after iPhone SDK 3.1 came out.  I couldn’t find anything online either except a few people experiencing the same issue.  In the system console (not Xcode console) I was seeing:

9/18/09 8:35:29 PM Xcode[669] -[XCBuildLogCommandInvocationSection setTestsPassedString:]: unrecognized selector sent to instance 0x2009b7620
9/18/09 8:35:29 PM Xcode[669] -runOperationInBackground raised an exception: -[XCBuildLogCommandInvocationSection setTestsPassedString:]: unrecognized selector sent to instance 0x2009b7620

Xcode[669] -[XCBuildLogCommandInvocationSection setTestsPassedString:]: unrecognized selector sent to instance 0x2009b7620

Xcode[669] -runOperationInBackground raised an exception: -[XCBuildLogCommandInvocationSection setTestsPassedString:]: unrecognized selector sent to instance 0x2009b7620

Needless to say, I was losing my mind. Finally, a user in the Apple Developer forums, “cde”, posted the following gem:

We have recently discovered the root cause of this problem.

People who are affected can work around it by (I hope you’re ready for this)…

…changing the Time Zone on your Build machine away from Central Daylight Time.  (In six weeks you can change it back, and people in Mountain Standard TIme will be affected.)

No, seriously.  Give it a try.

The problem is a single-character typo in a regular expression that parses the date stamp of the unit test. It causes it to miss the beginning of unit tests that are executed at -0500 or +0500 relative to GMT, so the end of those unit tests is unexpected, and it causes the build log parsing logic to initially hang and eventually crash.

As has been said, “Then I decided to use regular expressions, and I had two problems…”

So until it’s fixed, change your timezone to Pacific time.

Xcode SCM & build directory

Xcode has a build directory inside of your project, which you shouldn’t be including in your source code management repository.  Simply said, those files change so much and are “discardable”.  There is no way to easily exclude this directory from your repository.  The accepted way to fix this (after some digging) is to simply move the build directory for Xcode to a temporary folder.

To move the build directory, click on the Xcode menu in your menu bar, and click on Preferences.  Change the folder under “Building” to a temporary folder.  I created a tmp directory in my user folder.

Xcode Preferences Build