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.

Update: Fellow dev Cocoanetics pointed out that they’d solved a similar problem, and have a great write-up on how they create compiled resources using custom build rules on their blog.

The Image Resources

…Just a bunch of png files within a folder inside your project directory. The script assumes there are normal and retina (@2x) versions of each.

The Template

These are the template source files from which the end result will be derived. It contains a few tags that the accompanying shell script will process. I created it in Xcode, placing it within the same folder as the source png images, but removed it from the target’s compile phase, as we’ll be adding the derived source instead.

First the header, TPCompiledResources.h:

//
//  TPCompiledResources.h
//
//  Created by Michael Tyson on 13/05/2012.
//  Copyright (c) 2012 A Tasty Pixel. All rights reserved.
//
 
#import <UIKit/UIKit.h>
 
UIImage *TPGetCompiledImage(NSString* name);

And the implementation file, TPCompiledResources.m:

//
//  TPCompiledResources.m
//
//  Created by Michael Tyson on 13/05/2012.
//  Copyright (c) 2012 A Tasty Pixel. All rights reserved.
//
 
#import "TPCompiledResources.h"
 
/*{%IMAGEDATA START%}*/
/*{%IMAGEDATA END%}*/
 
UIImage *TPGetCompiledImage(NSString* name) {
    /*{%LOAD_TEMPLATE%}
    if ( [name isEqualToString:@"ORIGINAL_FILENAME"] ) {
        static UIImage *_SANITISED_FILENAME_image = nil;
        if ( _SANITISED_FILENAME_image ) return _SANITISED_FILENAME_image;
 
        if ( [[UIScreen mainScreen] scale] == 2.0 ) {
            _SANITISED_FILENAME_image = [[UIImage alloc] initWithCGImage:
                                                     [[UIImage imageWithData:[NSData dataWithBytesNoCopy:SANITISED_2X_FILENAME 
                                                                      length:SANITISED_2X_FILENAME_len freeWhenDone:NO]] CGImage] 
                                                                   scale:2.0 
                                                             orientation:UIImageOrientationUp];
        } else {
            _SANITISED_FILENAME_image = [[UIImage alloc] initWithData:[NSData dataWithBytesNoCopy:SANITISED_FILENAME 
                                                                                           length:SANITISED_FILENAME_len freeWhenDone:NO]];
        }
 
        return _SANITISED_FILENAME_image;
    }
    {%LOAD_TEMPLATE END%}*/
 
    /*{%IMAGELOADERS START%}*/
    /*{%IMAGELOADERS END%}*/
    return nil;
}

The Shell Script

Here’s the script that does all the work. The script looks for all “png” images in the given folder, then creates C code representing each image along with wrapper code to give access to the image byte arrays, with help from the template.

This script goes into a “Run Script” phase, placed at the beginning of the library’s build process.

#!/bin/sh
 
# Where the images are (get this from the first "Input Files" entry)
RESOURCES_FOLDER=`dirname "$SCRIPT_INPUT_FILE_0"`
 
# The name of the source template, minus extension
SOURCE_NAME="TPCompiledResources"
 
# Create C arrays, representing each image
tmp="$TEMP_FILES_DIR/compile-images-$$.tmp"
cd "$RESOURCES_FOLDER"
for image in *.png; do
    xxd -i "$image" >> $tmp.1
done
 
# Read the code template
TEMPLATE=`sed -n '/{%LOAD_TEMPLATE%}/,/{%LOAD_TEMPLATE END%}/ p' "$RESOURCES_FOLDER/$SOURCE_NAME.m" | sed '1 d;$ d'`
 
# Create loader code for each image
for image in *.png; do
    if echo "$image" | grep -q "@2x"; then continue; fi
    ORIGINAL_FILENAME="$image"
    SANITISED_FILENAME=`echo "$ORIGINAL_FILENAME" | sed 's/[^a-zA-Z0-9]/_/g'`
    SANITISED_2X_FILENAME=`echo "$SANITISED_FILENAME" | sed 's/_png/_2x_png/'`
    echo "$TEMPLATE" | sed "s/ORIGINAL_FILENAME/$ORIGINAL_FILENAME/g;s/SANITISED_FILENAME/$SANITISED_FILENAME/g;s/SANITISED_2X_FILENAME/$SANITISED_2X_FILENAME/g" >> $tmp.2
done
 
# Create the source file from the template and our generated code
sed "/{%IMAGEDATA START%}/ r $tmp.1
1,/{%IMAGEDATA START%}/!{/{%IMAGEDATA END%}/,/{%IMAGEDATA START%}/! d;}
/{%IMAGELOADERS START%}/ r $tmp.2
1,/{%IMAGELOADERS START%}/!{/{%IMAGELOADERS END%}/,/{%IMAGELOADERS START%]/! d;}" "$RESOURCES_FOLDER/$SOURCE_NAME.m" > "$DERIVED_FILE_DIR/$SOURCE_NAME.m"
 
# Copy the template header file in
cp "$RESOURCES_FOLDER/$SOURCE_NAME.h" "$DERIVED_FILE_DIR/$SOURCE_NAME.h"
 
rm "$tmp.1" "$tmp.2"

The “Run Script” phase that hosts this script also needs a couple of additions, to tell Xcode what the inputs and outputs to the script are: In the “Input Files” section, the path to the image resource folder, with a “*.png” wildcard at the end, and also the path to those template files, TPCompiledResources.{h,m}. Finally, the two output files go in the “Output Files” section:

Project Setup

Now it was just a matter of setting up the project to include the derived source files in the build. This was a bit messy and took a little doing, but with guidance from this article by Ben Zado on file references relative to DERIVED_FILE_DIR, it wasn’t too painful:

1. Build, in order to generate the derived source files.
2. Navigate to the derived sources folder within the build products, and drag the TPCompiledResources.{m,h} into the project, placed within a new group (I called the group “Derived Sources”).
3. The path type for those files (accessible from the properties viewer — Cmd-I) should be “Relative to Enclosing Group”, and consequently the “Path” field should just show the filename, with no path component. This was a bit touch-and-go for me, and I had a hard time making this happen, so I left it as-is for now, fixing it manually later in step 8.
4. Under Xcode Preferences » Locations » Source Trees, add an entry with setting name “DERIVED_FILE_DIR“, display name “Derived Files” and path “$(DERIVED_FILE_DIR)“.
5. Set the path type for the group containing the two derived sources to “Relative to Derived Files”.
6. Quit Xcode, and open the project.pbxproj file from within your project’s bundle.
7. Find the “Derived Sources” group (or whatever it was named in step 2), and delete the “path” property from the list of attributes.
8. I had to also find the TPCompiledResources.{m,h} file sections and delete the “path” attribute for those, too.
9. Reopen Xcode, and build — it should be good to go (don’t worry that the derived sources are shown in red in the project group — Xcode’ll find them).

Now that’s done, images can be accessed by TPGetCompiledImage(@"ImageName.png"). Yay!

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.

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.

You’ll wanna edit the extension to put in your API key and Team ID, then just select a file in Alfred, type ‘testflight’ (or an abbreviation thereof) and enter, then enter a build summary, and off it goes. Result will appear in Growl.

Upload to TestFlight.alfredextension.zip

It’s called The Amazing Audio Engine, and it represents the product of years of experience with iOS audio. It’s a sophisticated iOS audio engine that lets developers skip the Core Audio learning curve, and get on with writing great software.

The tech behind this is what drives Loopy and Loopy HD, as well as the in-development Audiobus app.

Subscribe at theamazingaudioengine.com to be kept in the loop as it approaches launch time.

Some of the features:

• Automatic mixing of multiple audio signals with per-channel volume and pan controls.
• Built-in support for audio filtering and effects, including the ability to form complex filter chains, constructing channel groups, or even whole trees of groups, and filtering them as one composite signal.
• Built-in support for audio input, including optional use of the Voice Processing IO unit, for automatic echo removal – great for VoIP.
• Record or monitor the output of the whole audio system, for in-app session recording, or get the output of one channel, or any group of channels in the processing tree.
• Support for any audio format (AudioStreamBasicDescription) that the hardware supports: Interleaved, non-interleaved, mono, stereo, 44.1kHz or any other supported sample rate, 16-bit, 8.24 fixed floating-point – whatever you need for your project.
• Very light, efficient engine, designed from the ground up for speed. All Core Audio code is pure C; no Objective- C or BSD calls, no locks, no memory allocation.
• Efficient mixing of input signals, using Apple’s MultiChannelMixer.
• Fast, lock-free synchronisation mechanism, enabling developers to send messages to the main thread from the Core Audio context, and vice versa, without locking or memory allocation from the Core Audio thread. Message sending from the main thread is two-way, and can be asynchronous, with a response block, or synchronous.

If you’re using TPCircularBuffer at all, I recommend updating!

This dramatically simplifies the use of a circular buffer — you can use chunks of the buffer without any need to worry about where the wrap point is.

See the new implementation, which is thread-safe with one consumer and one producer, with no need for locks, making it perfect for use with high-priority Core Audio threads, on GitHub: TPCircularBuffer.

There’s a basic example of its use over on the original post.

I bet I’m not the only one, but of course reality struck and we realised that the App Store aint that kind of beast. Like any other product, an app needs to be actively presented to the world on a regular basis, and needs to be nurtured to keep it fresh and relevant.

I say “we” because at this point, my partner Katherine joined me after this particular revelation, and became A Tasty Pixel’s part-time marketing director and PR strategist — it’s taken two of us to keep A Tasty Pixel’s wheels turning smoothly, and we still have a lot to learn.

I thought I’d take a moment to reflect on some of the lessons we’ve learned in the past year, in which we’ve released a relatively successful travel planning and travel assistant app, The Cartographer, a very successful live looping app, Loopy, and its big brother Loopy HD, and tried a bunch of promotion strategies, some successful, some not, and some that haven’t yet run their course.

Stating the obvious: It’s not enough to just build it

Just for the record, and I’m sure we all know this now, but “build it and they will come” doesn’t cut it on the App Store. Maybe it did in Month One, but now, you might as well not start if you’re not going to devote a goodly amount of time to promoting your app, because it just won’t get anywhere amongst the hoards of other apps.

Don’t expect everything to work

Perhaps the biggest, or at least most helpful, lesson we learned was not to expect everything to go as planned, and not to get too down if a strategy didn’t pan out.

It’s often impossible to predict which things will be successful and which not, but we found it helpful to consider the payoff for the successful strategies being spread around amongst all the strategies, successful or not — that way, we could be pleased about the ones that paid off, and philosophical about the ones that didn’t! The trick is just to keep at it, and keep being creative.

High quality attracts attention

Please excuse a moment of immodesty: I’d like to think my apps have a fairly high standard of quality, and it would appear that making “premium” apps really does pay off!

It’s not entirely “build it and they will come”, but having an app that looks great and that customers love gives you a big head-start in the PR game. Word of mouth is huge on the App Store, and the mouths in question produce more words about great apps.

What’s more, a feature by Apple, which generally only happens to high-quality apps, can make a massive difference, both in the short and long term, and gives an app a great “social proof” bump.

Incidentally, this goes for the app site too. Sites like App Sites reward beautiful designs, and you can get picked up on various design blogs too — we’ve had quite a bit of traffic lately from Blog Du Webdesign, for example. And the same goes for demo videos. The Cartographer’s demo got a huge response, and got a lot of word of mouth, just about the video itself:

So: Put in the extra sweat-and-tears. It’s worth it.

Influencers

Sometimes, depending on the nature of the app, a good word from an influencer in the area can be huge.

For example, when Loopy was in pre-release, I made contact with a musician I’m a big fan of, Dub Fx (you might know him from this video, which went viral a couple of years ago). Ben was very interested in the app, and threw his not inconsiderable support behind it, unleashing this amazing demo video:

…our jaws were dangling around our knees when I found that in my inbox! We’ve since decided to work together — look out for the Dub Fx app some time next year!

That was the success story — our experience with The Cartographer was quite different, though. Katherine spent months upon months getting to know travel bloggers, interacting on their blogs and via various social media, hoping to make connections and get to introduce the app to some of them.

The good news is that we made some really good new friends out of the process, which makes it all worthwhile as far as I’m concerned. But as a marketing strategy, it was a total bust. As it turns out, many travel bloggers seem to be quite unresponsive — some of them, despite lots of friendly comments and other interactions, never even noticed us! Some did, and kindly give us a mention on their blogs, but this didn’t seem to have any effect!

It turns out, as Katherine discovered in an industry report, the places that travellers (our target audience) go on the Internet: Not travel blogs! Travellers visit airline sites, hotel websites, TripAdvisor and forums, Lonely Planet’s forums…all places that we have no hope of exerting any influence at all (those forums, by the way, are militantly moderated for anything that even loosely resembles product mentions). So, we did the best we could, given the options, but it’s a really difficult market.

So, I suppose the lesson there is tread carefully, do your research, and spend the time strategically — be aware that the payoff might be huge, or it might be nil. If we’d known in advance how poorly the months of work Katherine put into meeting travel bloggers would turn out, we might have invested less time in it. We may have even decided to find an alternative target market.

Reviewers

There are a lot of app review sites out there, now. It’s just insane — it seems like every man, his dog, and several of his goldfish have app review blogs. Back at the start, Katherine put in a huge number of hours and built us a spreadsheet of the most important reviewers. With that done, whenever we do a release, she spends half a day (that’s how long it takes, or more!) emailing and filling out web forms of reviewers.

Most of them never respond, especially the big ones — they get such a barrage of review requests, it’s not hugely surprising. Many blogs offer paid reviews, but we haven’t gone down that track yet, so, nothing to report there. But many have responded, and every review helps, both for the social proof and word-of-mouth, and for the SEO.

Honestly, we haven’t yet collected hard stats about the proportion of reviewers who contact us in response to our initial contact, and how many are contacting us of their own accord. Many of the significant reviews we’ve had have happened independently of us tracking down and contacting the reviewers in question, though.

So, we’re still undecided about whether the amount of time invested in telling reviewers about our products is really paying off. I think we’ll always do it for initial releases, and possibly for major, major updates, though.

Journalists

This is something we want to do, but haven’t really pursued a whole lot — finding relevant journalists and contacting them directly. We’ve found contacts for a few, but they always seem to be out-of-date and emails just bounce.

So, this seems like a good thing to do, but still TBD.

Press releases

Press releases seem to have two main benefits — they help with SEO, which helps users find your app — and they marginally increase the likelihood of getting picked up and getting some free media.

We’ve been doing regular monthly press releases via PRWeb (a.k.a. Vocus) for a few months now, after previously only doing a big one (via PRWeb) for launch, and a couple smaller ones (via the much cheaper PRMac service) for updates.

Vocus talked us into signing up for a 12 month subscription (for a thousand-and-something $), which includes one release a month, and a representative who helps suggest topics, and checks over our drafts. Our representative Rebecca has been great with both, and has been very responsive with answering our dumb questions along the way.

We’ve been pseudo-picked up by a few nice sites like the San Francisco Chronicle, although it’s automated and I don’t know how much of a direct difference it actually makes. At the moment, loopyapp.com’s page rank is at 4, which is not bad at all, some of which is presumably thanks to our releases, and we seem to rank fairly well with most of the google searches we want to be associated with. An interesting side note is that quite a lot of our referred web traffic is coming straight from PRWeb, which surprised me.

As with a lot of these strategies, I can’t say for sure whether it’s been a huge success so far — it’s hard to determine the cause of a good page rank, for example — but my gut feeling is that it’s worthwhile; it makes sense.

Social media

I never “got” Facebook up until quite recently, but now I can’t get enough — after being a staunch Twitter user for quite a long time, I’ve discovered that Facebookers are amazingly engaged. I remember hearing somewhere that one Facebook follower (…”like”-r?) is worth several Twitter followers, and that rings true. I have a great time hanging around on the A Tasty Pixel Facebook page and interacting with people there, as opposed to Twitter, which is sometimes a little bit like shouting into a black hole.

Google+? I have no bleeding idea. Anyone?

Anyway, it’s important to engage with your customers on both, but particularly Facebook, and there’s lots of scope for interesting interactions with customers. For example, I’m about to start building effects into Loopy, and I was curious about what people most wanted to see. So, I created a poll on the Facebook page, and got a great response (“More Cowbell” coming right up…).

I quite like being able to “be me” on Twitter and Facebook, to show what I’m up to, get feedback on stuff as I’m making it, and to respond straight away to people. I get to present a personal face, instead of being A Company.

As Loopy is a music-creation app, it also hooks straight into SoundCloud, and has a very active SoundCloud group which I find myself trawling every morning — a great entertainment. One of the unexpected benefits is that I’ve met quite a few talented and lovely people though SoundCloud, some of whom have gone on to become testers and advisors, and help shape Loopy.

Customer support

While this isn’t promotion-related, I’ve been in the position (being a one-person dev company) to interact with customers directly, and I make a point of responding almost immediately when possible, and doing my best to address problems straight away. On a couple of occasions, the customer’s helped me identify a time-sensitive issue — they’re using The Cartographer and are about to go away on holiday — and I’ve had a fixed ad-hoc build out to them within a couple of hours, which has been very satisfying on both sides!

Customers love the straight-to-developer contact and the fast replies, and quite a few people have gone on to become very vocal supporters, which has been great. A very positive support experience goes a long way towards building goodwill, and I think it’s super-important. It also feels really satisfying, so in my option, there’s no reason not to go all-out!

Expertise

Tim Ferriss encourages product creators to position themselves as authorities in the area targeted by the product, to give the product more clout and attract more attention. The idea is, if your app is targeted at a particular area, and you have experience in that area, then write: write on your own blog, and seek out others to do guest posts on (make sure it links back to you!).

We’re spending a few years travelling in a motorhome around Europe as we set up A Tasty Pixel and Katherine’s art business, and The Cartographer was built as a result of our experiences travelling. So, (I say “so”, but actually we were already blogging as a journal for ourselves — but let us conveniently ignore that fact) we keep a travel blog, which brings in some traffic. But not much — honestly, this is a terrible example, and we’ve had very few results, possibly because of the nature (and diminutive size!) of our audience. Were we to focus on promoting our blog more and making it less “this-is-what-we-did” and more “this-is-what-you-can-do”, we might see more response, but our priorities lie decidedly elsewhere — traditional travel blogging: not our bag, baby.

But, I know this can work — I know it’s an extreme example, but look at Trey Ratcliff, the HDR photography authority, and his app 100 Cameras In 1. They got onto CNN, ferchrissake, and pretty much every other media outlet you can imagine!

Paid advertising

This is the next frontier, for us, and I’m fairly excited about it. Everything I’ve mentioned up to this point has been about “free media”, but advertising is a whole new category to explore.

With that said, I’ve had two initial forays into ads: Facebook, and AdMob, and both have been total failures.

To an advertiser, Facebook is like a giant damn candy shop. (I felt really weird when I read this recent Joy of Tech, and found myself drooling a little bit by the fifth panel…). The kind of targeting options available are just a-mazing — you can target people from their age, gender and location, right down to their areas of interest (which is insanely cool), and even down to targeting users who like one particular competitor’s product.

Despite the cool factor, it turned out to be pretty much a total bust for attempt 1 — we were paying a stupid amount per click, compared to the actual amount we would earn per sale. We spent $75, and got…45 clicks. That’s $1.60 per click, which represents about 75% of our actual take per sale, and it’s very unlikely even 10% of those clicks resulted in a sale.

At the time, I was choosing to bid per thousand clicks (CPM), instead of per click (CPC), but the reason I chose to was that the recommended CPC was well above what I was prepared to spend.

The lesson there is that Facebook users aren’t ready to buy straight away. A friend who works in advertising reported good results marketing the Facebook page instead of the product, so that users who are interested can hang around for a while, get to know you, and then you can market to them later. I’ll try this soon, and I’m hoping that the mechanics of a social ad (with a “Like” button on the ad, instead of a click to navigate away from the current page) will result in higher (and cheaper!) conversions.

I found similar results with AdMob — we got a much, much better cost per click (I was playing with the minimum bid of 29c per click), but even at 29c/click, in order to break even for our $2.99 app, 1 in 7 people who click the ad would have to buy it, which I think is far-fetched.

So, as far as direct advertising goes: As someone who earns just over $2 per sale, we just can’t afford it! My next experiment: Trying to use Facebook to increase our social reach, instead.

Summary

It’s become abundantly clear to us that app promotion is a job in itself, and it’s one that can scale right up to the amount of time you have available. They key is to be constantly creative, and to be out there, all the time, chipping away.

Almost everything’s a shot in the dark, and while many strategies may yield no results at all, some might be a big break (like meeting Dub Fx, for us), so it’s important to just keep on trying.

Apple give you absolutely no help in tracking the success of any particular strategy, unfortunately, although there are tricks you can use to help track where some of your sales are coming from.

The PR thing is just as important as actually creating the app; it’s hard, and it’s constant, and it means that running a software development company is anything but a “passive income”. Fortunately for me, I love it to bits!

I’m doing some experiments with advertising my live looper app Loopy lately, and want a way to track the success of various approaches. It occurred to me that the totally freeform nature of the LinkShare “signature” field (which you can use to track traffic sources) lends itself to an even more flexible approach than that presented in the Mobile Orchard article.

Here’s a way to use that signature field to report the domain name of any referrer who links either to the app page, or to a download link (like, say, http://loopyapp.com/download).

This way, if, say, TUAW link to your app site, if someone clicks through then clicks the download link on your app site and buys, the resulting order will be reported as coming from TUAW. If someone clicks through from your Facebook page, it’ll come up as coming from Facebook. You can even modify the script further to report more precise details (like the path), if you like.

It assumes you’re using PHP, but the principle’s the same for any other language (BYO code, though ;-)).

Step 1: Sign up to LinkShare

First, if you haven’t already, Sign up to the LinkShare program — Once you’ve created a LinkShare account, join the Apple affiliate program via the “Programs” tab. After 3 days, you’ll get an email welcoming you to the program, and you’ll be good to go.

Step 2: Create a product link

Once you’re admitted to the program, open up the “My Advertisers” sub-tab from the LinkShare Programs tab, and open the “Link Maker Tool”. This lets you search for products, and create a link that will open up your app’s App Store page, and will be associated with your LinkShare account.

Step 3: Create a download redirection script

Now we’re going to set up a script on your app site which will redirect the visitor to the URL you just created (which in turn, redirects straight to the App Store page). It’ll add a “signature” parameter to the URL, which corresponds to the original referrer, so you can track where orders came from.

Create a file called ‘download.php’ in the root of your app site, with the following content, with your LinkShare URL inserted where indicated:

<?php
// Replace the following URL with the LinkShare URL you created
$linkshare_url = "http://click.linksynergy.com/fs-bin/stat?id=/yGrgMJzFG0&offerid=146261&type=3&subid=0&tmpid=1826&RD_PARM1=http%253A%252F%252Fitunes.apple.com%252Fapp%252Floopy%252Fid300257824%253Fmt%253D8%2526uo%253D4%2526partnerId%253D30";
 
session_start();
$referer = $_SESSION['original_referer'];
if ( !$referer ) $referer = $_SERVER["HTTP_REFERER"];
 
if ( $referer ) {
    $signature = preg_replace("@https?://(?:www\.)?([^/]+?)(?:\.com)?/.*@", "$1", $referer);
} else {
    $signature = preg_replace("@^(?:www\.)?(.+?)(?:\.com)?$@", "$1", $_SERVER["HTTP_HOST"]);
}
 
$signature = preg_replace("@[^a-zA-Z0-9]@", "", $signature);
 
header("Location: ".$linkshare_url."&u1=".$signature);
?>

This script looks for the original referrer in a session variable (which we’ll set up in the next step), so that the domain of the site that links to your app site is used, not just your app site’s domain. Then it creates a properly-formatted signature parameter (just alphanumeric), appends it to your LinkShare URL, and sends the viewer onwards.

Bonus points: I prefer to get rid of the ‘php’ extension to make the URL a bit cleaner. Pop the following into your .htaccess file to access ‘download.php’ as just ‘download’:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME}.php -f
RewriteRule . %{REQUEST_FILENAME}.php [L]
</IfModule>

Step 4: Remember the referrer

Now, on the landing page script for your app site (or the site header), pop this in at the very start:

<?php
session_start();
if ( !$_SESSION["original_referer"] ) $_SESSION["original_referer"] = $_SERVER["HTTP_REFERER"];
?>

This stores the original referrer URL in a session variable, to use when we actually link the viewer through to the App Store.

Step 5: Test it

To make sure everything’s working properly, open download.php again, and replace “header” at the bottom with “echo”, so that instead of redirecting the browser, we just print out the URL where we would be redirecting to.

Open your appsite/download URL, and make sure the URL ends with “&u1=appsite“. That’s for direct visitors. Now, click through to your app site from another site, then click your “download” link. You should now see the name of the original site you linked from as the “u1″ parameter at the end of the URL.

Once you’re satisfied that you’re good to go, make sure you replace “echo” with “header” again.

Step 6: Track

Now that you’re ready to track referrals, you can give out your http://yourappsite/download URL as your app’s direct iTunes download link (to reviewers, in your press releases, etc).

You can view a report showing clicks and orders associated with each referrer on the LinkShare page — create an advanced report by clicking the “Advanced Reports” sub-tab, then select your desired date range (I use “Since Last Payment”, and under “Report Type”, select “Signature Activity”. Hit “View Report”, and you’ll see your clicks and sales versus each referrer (“Member ID”, on the report).

Voila! Omnipotence achieved.

Addendum: This technique works for tracking referrers, but if you’re wanting to track the performance of ads (say, with AdMob), you’ll want to use your original LinkShare URL, with a custom “&u1″ signature parameter. As ad platforms like AdMob link directly (and don’t, as far as I know, send a referer parameter), this script won’t pick up that it’s from your ad platform.

Addendum 2: LinkShare’s reports don’t distinguish between products, so if you’ve multiple apps, you might want to add a prefix to your signature parameter to tell ‘em apart. You could, say, replace that header("Location: ".$linkshare_url."&u1=".$signature); line with something like header("Location: ".$linkshare_url."&u1=myapp".$signature);.

Hands up, backing away

Disclaimer: I am not at all an expert in realtime programming, or Mach, or iOS-device optimisation, so this is pretty much a fumble in the dark. I won’t be at all offended if anyone wishes to shoot me down and offer a more sensible solution — in fact, please do! Until then, watch as I stumble on…

Also note that there are often ways to eliminate the need for precise timing of this nature, by architecting code appropriately — when it comes to audio, for example, CoreAudio provides a very accurate time base in render callbacks. For things like metronomes or audio synthesizers, it’s always better to establish a starting time, and use the difference between the current time and the starting time in order to determine state, rather than using a timer to advance the state. Still, sometimes, you just need a timer…

What the blazes?

So, I’m working on an update to Loopy, which uses a shared clock object to synchronise tracks and a variety of events (like user interface updates or timed track manipulations). A tester noted that the mute/unmute quantisation feature that I’ve recently implemented, which will mute or unmute a loop at its starting point (rather than whenever you tap it), tends to overshoot a little, resulting in a small part of the beginning of the loop being audible.

Of course, there are other solutions to this particular problem (like stopping or starting playback from the audio render callback, and using Core Audio’s timestamps for exact timing), but I use timers in other places outside Core Audio’s domain, which makes Core Audio’s timing mechanism unavailable, and I wanted to see how accurate I could get the timing.

Our friend, mach_wait_until

I read in several places mention of the Mach API utility mach_wait_until (from mach/mach_time.h), which is very low-level and supposedly fairly accurate. So, based on that lead, I put together an Objective-C singleton class that launches a high-priority thread, and uses said thread to schedule events.

An NSArray of events are maintained, and a scheduleAction:target:inTimeInterval: routine creates and adds events to this array, then pokes the thread.

The thread grabs the next event in sequence, then uses mach_wait_until to sleep until the time of the next event arrives, then performs the specified action on the target. It’s kinda a DIY NSRunLoop.

Here’s a comparison between this technique, and just using performSelector:withObject:afterDelay: (which schedules a timer on the NSRunLoop), observed while performing various scheduled events within Loopy running on my iPhone 4 with the debugger, and derived by comparing the time of event execution with the event’s scheduled time:

That was attempt number 1: This seems to give us about 11.4ms better accuracy on average (three times more accurate).

Not bad, but it turns out mach_wait_until isn’t really that accurate, particularly if there’s a bunch of other stuff going on in other threads.

Spinning, for fun and profit

For my second attempt, the thread performs a mach_wait_until until just before the event is due, then performs a spin lock until the time arrives, using mach_absolute_time to compare the current time with the target time.

This gave further improved results — here’s that table again, but with the new scheme added, with a few different spin lock times:

It appears that the more stuff there is going on in other threads, the more likely the mach_absolute_time call is to overshoot. So, the more time spent in the spin lock, the more leeway mach_absolute_time has to wait too long. Of course, that’s at the cost of making the CPU twiddle its thumbs for the duration.

Better than a punch in the knee

The results weren’t quite as fantastic as I’d hoped — still within the same order of magnitude, that’s for sure — but the average case for the 200ms spinlock approach is 14ms, or 5.8 times, more accurate than the traditional approach, and the minimum case is dramatically better.

You know, I think if I was aware of the results in advance, I might not bother, but I’ll stick with my hard-won 14ms now that I’m here (that’s 617 audio samples, I’ll have you know).

If anyone’s curious about the implementation (or wants to take a stab at doing better), here it is, along with a wildly simplistic commandline test app: TPPreciseTimer.zip

Now to get back to some real work.

Addendum: GCD follow-up

Chris in the comments below suggested trying a GCD-based approach, using dispatch_after. Curious, I rigged it up, and these are the stats, collected the same way as above, added to the prior table:

So, they appear pretty much the same as the NSRunLoop stats.

I’ve just discovered a critical issue with Sparrow that I thought others should be warned of. It just bit me, big-time, when in the middle of an important negotiation with a third party, an earlier unpolished draft was sent out instead of the final email, when I experienced a momentary Internet connection dropout.

Sparrow has an issue where hitting “Send”, in unreliable network conditions, on a draft message that has been modified, results in a prior copy of the message being sent, rather than the latest version.

To replicate this issue reliably:

1. Create a new message (Cmd-N)
2. Specify a recipient (oneself), subject, and some body content (say, the letter “A”)
3. Hit “Save”, to save the draft
4. Change “A” to “B”, then disconnect the network connection (in my case, turning off the radio on my external WiFi adapter), then hit “Send”. Sparrow will report a failed connection, and will keep the outgoing message with state “Pending”
5. Restore network connection. Upon detecting the restored connection, Sparrow will proceed to send the message
6. Check email. Received test email will have “A” in the email body.

Scary stuff. I hope they’ll fix this soon, but it’s going to make the app difficult to trust in future!

Update: I should mention, a probable workaround for this is to never, ever hit “Send” until you’ve saved the draft, and verified that the save operation has completed (perhaps even restart the app first).

So, I create two different views within the nib, one portrait, one landscape, each with the same view hierarchy, but with a different layout.

When the orientation changes, I set self.view to the appropriate view. I initialise both views on load, and keep both of them synced to properly reflect the app’s state — basically, I’m double-handling everything, which bloats my code and increases the chance I’ll make a mistake.

So, here’s an easier way: Rather than maintaining two separate view hierarchies and switching between them when the orientation changes, why not just change the layout of one single view hierarchy? The only changes between the portrait and landscape views are layout changes, so if we can extract just the layout information from each view, then we don’t have to worry about maintaining both view hierarchies.

Basically, we’re talking about using each view version as a layout template only.

That’s what TPMultiLayoutViewController class does. It’s a drop-in UIViewController subclass that automatically manages switching between different view layouts for portrait and landscape orientations, without the need to maintain view state across two different view hierarchies.

It works by defining portraitView and landscapeView outlets which it traverses upon loading the nib. It matches each subview element to its counterpart in the other layout (based on tag, target/action, title, etc.), and stores just the layout attributes of each element.

Then, when the orientation changes, the view hierarchy is traversed and these layouts are applied to each subview.

To use it,

1. Set the superclass for your view controller to TPMultiLayoutViewController.
2. In Interface Builder, create two different views: one for portrait orientation, and one for landscape orientation.
3. Attach your portrait orientation root view to the “portraitView” outlet, and the landscape orientation root view to the “landscapeView” outlet.
4. Attach one of the views (whichever you prefer) to the “view” outlet, and connect any actions and outlets from that view.

Grab it from the TPMultiLayoutViewController GitHub repository, and let me know what you think.

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.

A little utility I just put together does that for you: Post Grabber detects POST data and generates an equivalent “curl” command that can be used in shell or Automator scripts.

Post Grabber works with its own internal browser, so it can intercept POST submissions directly. That means it works with HTTPS, unlike the traditional web sniffer approach.

Download the app, or see the source on GitHub.

I thought I’d put together a relatively universal, drop-in solution: UIScrollView and UITableView subclasses that handle everything.

When the keyboard is about to appear, the subclass will find the subview that’s about to be edited, and adjust its frame and content offset to make sure that view is visible, with an animation to match the keyboard pop-up. When the keyboard disappears, it restores its prior size.

It should work with basically any setup, either a UITableView-based interface, or one consisting of views placed manually.

For non-UITableViewControllers, use it as-is by dropping the TPKeyboardAvoidingScrollView source files into your project, popping a UIScrollView into your view controller’s xib, setting the class to TPKeyboardAvoidingScrollView, and putting all your controls within that scroll view.

To use it with UITableViewController, pop the TPKeyboardAvoidingTableView source files in, and just make your UITableView a TPKeyboardAvoidingTableView in the xib — everything should be taken care of.

You can grab the source files, which includes a sample project, over on the GitHub project page