Searching iOS header files with Xcode

I’m often having to grep through various iOS frameworks in search of error codes that appear (“What the bloody hell does -10867 mean?”). This can be a bit annoying – especially while working with Core Audio – so I put together an Alfred workflow that does it for me.

Here it is – type “hs” (short for “header search”) then the text you want to search for, and it’ll give you matching results. Hit enter to open that file:line combination in Sublime Text, or edit the action script to work with the editor of your choice.

Search Xcode Header Files.alfredworkflow

Screen Shot 2013 04 01 at 11 54 24

Read More

Compiling Image Resources into a Static Library

I’ve recently been working on a static library for distribution to other developers — Audiobus — and I need to include a couple of graphical resources with the distribution. The usual solution to this is to include the resources separately in a bundle, and require the user to drop them in to their project along with the static library.

I thought I’d see if I could make the process just a little neater, and successfully devised a way to compile the images straight into the library, so the distribution remains nice and clean — just the library itself and a few header files.

Now, I can pop image resources into a folder, and after compiling, access them within the static library with:

UIImage *image = TPGetCompiledImage(@"Button.png");

It automatically handles “@2x” Retina images (although it doesn’t currently do “~ipad” versions).

Here’s how it’s done.

The magic is in a shell script which uses the xxd hex dump tool to create C code that represents the image data as a byte array, then creates around it a set of utilities to turn those arrays into UIImages on demand.

Along with it is a couple of template files — a header and implementation file — that describe the format of the derived code.

Finally, a little tweaking of the project in Xcode (with a brief foray into a text editor to work around some Xcode shortcomings) puts it all together.

Read More

Avoiding duplicate symbol issues when using common utilities within a static library

Screen Shot 2012 04 15 at 14 03 28I’m working on two projects right now that have static library products, to be given to other developers to use in their projects: Audiobus and The Amazing Audio Engine. In both cases, I’m making quite heavy use of my circular buffer code, TPCircularBuffer, which would result in duplicate symbol errors if the static library were linked with another project that used it.

In case the solution was useful to others, here’s how I worked around it: Use the preprocessor to rename the symbols automatically during the build phase.

This is done by adding a series of -DOldSymbol=NewSymbol flags to the ‘Other C Flags’ build setting – like -DTPCircularBuffer=ABCircularBuffer, for instance.

No more symbol conflicts.

Read More

An Xcode 4 template to create universal static libraries

I’ve created an Xcode 4 project template to create universal (armv6, armv7 and simulator) static libraries for iOS, based on Adam Martin’s script:

iOS-Universal-Library-Template

The existing static library template provided with Xcode only builds one architecture, which is not particularly suitable for distribution. A number of people have created scripts to create universal libraries, which require some mucking around with Xcode target settings to use.

This template draws on this work to provide all that is required to produce universal libraries – just select the ‘Universal Static Library’ type in the New Project/New Target dialog, and you’re all set.

Universal static library

Read More

Fixing Xcode 4’s symbolicate utility to get comprehensible crash logs

‘symbolicatecrash’ is the Developer Tools utility which replaces all those meaningless addresses from crash logs with actual symbol names and source code references. It lives at some obscure folder within /Developer – use find to dig it up and symlink it into /usr/local/bin if you wanna use it conveniently from the command line.

Anyway, after plenty of frustration, I noticed some chatter about the damn thing being busted in Xcode 4. Figures!

There’s an alternate third party version on GitHub, but this didn’t really help me – I still got inscrutable errors, so I took a look at the original.

The version that comes with Xcode 4 appears to have some problems distinguishing, say, an iPhone Simulator build of the app from a native build sitting in the Archives folder. I’d just see an error about otool and some binary living in the iPhone Simulator folder.

Digging into the errant symbolicatecrash source, I noticed that the code that finds the executable path tests each candidate using otool, but doesn’t seem to be able to comprehend the output from otool caused by running it on the wrong architecture.

So, replacing the rather unhelpful ‘die’ statement on line 323:

die "Can't understand the output from otool ($TEST_uuid -> '$otool -arch $arch -l $path')";

With a “No, it ain’t this executable” response:

return 0;

…solves the problem immediately. Now I can drag crash logs straight into the Organizer in Xcode, and it’ll symbolicate correctly.

Read More

Easy inclusion of OpenSSL into iOS projects

Oddly, iOS doesn’t provide any OpenSSL implementation at all — If you want to do anything with crypto (like checking signatures, checksumming, etc.), you have to build in the library yourself.

I came across a great XCode project wrapper for OpenSSL yesterday, by Stephen Lombardo. This is an XCode project file that contains a target to build OpenSSL from source, and works with both Mac and iOS projects. I made some modifications to it, in order to make it work by just dropping in the OpenSSL source tarball, without having to dirty up your source tree with the extracted OpenSSL distribution.

Here’s how to use it:

  1. Download the OpenSSL source.
  2. Put the downloaded OpenSSL source tar.gz into the same folder
    as openssl.xcodeproj (I put it in Library/openssl within my project tree).
  3. Drag the openssl.xcodeproj file into your main project tree in XCode.
  4. Right-click on your project target, and add openssl.xcodeproj under “Direct
    Dependencies” on the General tab.
  5. On the Build tab for your project’s target, find the “Header Search Paths”
    option, and add the path:
    > $(SRCROOT)/Library/openssl/build/openssl.build/openssl/include

    (Assuming you’ve put openssl.xcodeproj at the path Library/openssl — adjust as necessary).

  6. Expand your target’s “Link Binary With Libraries” build stage, and drag
    libcrypto.a from the openssl.xcodeproj group.

Then, you can just import and use as normal (#import, etc).

Download it here

Read More

Links for February 10th through February 27th

Links for February 10th through February 27th:

  • TinEye Reverse Image Search TinEye is a reverse image search engine. You can submit an image to TinEye to find out where it came from, how it is being used, if modified versions of the image exist, or to find higher resolution versions.
  • Traffic Shaping in Mac OS X | Mac Geekery "…Create several pipes that have a set bandwidth and other properties for all packets that get filed into them; you then add queues to those pipes that determine what priority certain requests will get in that pipe; then you add actual firewall rules to identify packets and file them into queues."
  • Brandon Walkin » Introducing BWToolkit BWToolkit is a BSD licensed plugin for Interface Builder 3 that contains commonly used UI elements and other useful objects. Using these objects is as simple as dragging them from the library to your canvas or document window. In particular, "No Code" preferences window and tabbed sheets.
  • Aussie iPhone app developers and the IRS? Discussion about tax details for Australian iPhone developers. It appears the advice from Apple on the tax form is incorrect for sales on the App Store.
  • google-toolbox-for-mac – How to do iPhone unit testing This is a quick tutorial on doing iPhone unit testing using the facilities in the Google Toolbox For Mac
Read More