Because of this, code written for the iPhone needs to be compiled twice, once for the simulator and once for the device. This makes working with static libraries a bit of a pain, because you need two of them, one for each architecture.

Luckily, it’s possible to build a “universal” binary that will work with both architectures. Apple did this during their switch from PowerPC to Intel.

I found the directions in this StackOverflow post.

• All you need to do is create a new static library target.
• Add a “Run Script” build phase.
• Copy and paste this script in.
• Your build output should be in a folder labeled Debug_universal or Release_universal

# Version 2.0 (updated for Xcode 4, with some fixes)
# Changes:
#    - Works with xcode 4, even when running xcode 3 projects (Workarounds for apple bugs)
#    - Faster / better: only runs lipo once, instead of once per recursion
#    - Added some debugging statemetns that can be switched on/off by changing the DEBUG_THIS_SCRIPT variable to "true"
#    - Fixed some typos
#
# Purpose:
#   Create a static library for iPhone from within XCode
#   Because Apple staff DELIBERATELY broke Xcode to make this impossible from the GUI (Xcode 3.2.3 specifically states this in the Release notes!)
#   ...no, I don't understand why they did this!
#
# Author: Adam Martin - http://twitter.com/redglassesapps
# Based on: original script from Eonil (main changes: Eonil's script WILL NOT WORK in Xcode GUI - it WILL CRASH YOUR COMPUTER)
#
# More info: see this Stack Overflow question: http://stackoverflow.com/questions/3520977/build-fat-static-library-device-simulator-using-xcode-and-sdk-4

#################[ Tests: helps workaround any future bugs in Xcode ]########
#
DEBUG_THIS_SCRIPT="false"

if [ $DEBUG_THIS_SCRIPT = "true" ]
then
echo "########### TESTS #############"
echo "Use the following variables when debugging this script; note that they may change on recursions"
echo "BUILD_DIR = $BUILD_DIR"
echo "BUILD_ROOT = $BUILD_ROOT"
echo "CONFIGURATION_BUILD_DIR = $CONFIGURATION_BUILD_DIR"
echo "BUILT_PRODUCTS_DIR = $BUILT_PRODUCTS_DIR"
echo "CONFIGURATION_TEMP_DIR = $CONFIGURATION_TEMP_DIR"
echo "TARGET_BUILD_DIR = $TARGET_BUILD_DIR"
fi

#####################[ part 1 ]##################
# First, work out the BASESDK version number (NB: Apple ought to report this, but they hide it)
#    (incidental: searching for substrings in sh is a nightmare! Sob)

SDK_VERSION=$(echo ${SDK_NAME} | grep -o '.\{3\}$')

# Next, work out if we're in SIM or DEVICE

if [ ${PLATFORM_NAME} = "iphonesimulator" ]
then
OTHER_SDK_TO_BUILD=iphoneos${SDK_VERSION}
else
OTHER_SDK_TO_BUILD=iphonesimulator${SDK_VERSION}
fi

echo "XCode has selected SDK: ${PLATFORM_NAME} with version: ${SDK_VERSION} (although back-targetting: ${IPHONEOS_DEPLOYMENT_TARGET})"
echo "...therefore, OTHER_SDK_TO_BUILD = ${OTHER_SDK_TO_BUILD}"
#
#####################[ end of part 1 ]##################

#####################[ part 2 ]##################
#
# IF this is the original invocation, invoke WHATEVER other builds are required
#
# Xcode is already building ONE target...
#
# ...but this is a LIBRARY, so Apple is wrong to set it to build just one.
# ...we need to build ALL targets
# ...we MUST NOT re-build the target that is ALREADY being built: Xcode WILL CRASH YOUR COMPUTER if you try this (infinite recursion!)
#
#
# So: build ONLY the missing platforms/configurations.

if [ "true" == ${ALREADYINVOKED:-false} ]
then
echo "RECURSION: I am NOT the root invocation, so I'm NOT going to recurse"
else
# CRITICAL:
# Prevent infinite recursion (Xcode sucks)
export ALREADYINVOKED="true"

echo "RECURSION: I am the root ... recursing all missing build targets NOW..."
echo "RECURSION: ...about to invoke: xcodebuild -configuration \"${CONFIGURATION}\" -target \"${TARGET_NAME}\" -sdk \"${OTHER_SDK_TO_BUILD}\" ${ACTION} RUN_CLANG_STATIC_ANALYZER=NO"
xcodebuild -configuration "${CONFIGURATION}" -target "${TARGET_NAME}" -sdk "${OTHER_SDK_TO_BUILD}" ${ACTION} RUN_CLANG_STATIC_ANALYZER=NO BUILD_DIR="${BUILD_DIR}" BUILD_ROOT="${BUILD_ROOT}"

ACTION="build"

#Merge all platform binaries as a fat binary for each configurations.

# Calculate where the (multiple) built files are coming from:
CURRENTCONFIG_DEVICE_DIR=${SYMROOT}/${CONFIGURATION}-iphoneos
CURRENTCONFIG_SIMULATOR_DIR=${SYMROOT}/${CONFIGURATION}-iphonesimulator

echo "Taking device build from: ${CURRENTCONFIG_DEVICE_DIR}"
echo "Taking simulator build from: ${CURRENTCONFIG_SIMULATOR_DIR}"

CREATING_UNIVERSAL_DIR=${SYMROOT}/${CONFIGURATION}-universal
echo "...I will output a universal build to: ${CREATING_UNIVERSAL_DIR}"

# ... remove the products of previous runs of this script
#      NB: this directory is ONLY created by this script - it should be safe to delete!

rm -rf "${CREATING_UNIVERSAL_DIR}"
mkdir "${CREATING_UNIVERSAL_DIR}"

#
echo "lipo: for current configuration (${CONFIGURATION}) creating output file: ${CREATING_UNIVERSAL_DIR}/${EXECUTABLE_NAME}"
lipo -create -output "${CREATING_UNIVERSAL_DIR}/${EXECUTABLE_NAME}" "${CURRENTCONFIG_DEVICE_DIR}/${EXECUTABLE_NAME}" "${CURRENTCONFIG_SIMULATOR_DIR}/${EXECUTABLE_NAME}"

#########
#
# Added: StackOverflow suggestion to also copy "include" files
#    (untested, but should work OK)
#
if [ -d "${CURRENTCONFIG_DEVICE_DIR}/usr/local/include" ]
then
mkdir -p "${CREATING_UNIVERSAL_DIR}/usr/local/include"
# * needs to be outside the double quotes?
cp "${CURRENTCONFIG_DEVICE_DIR}/usr/local/include/"* "${CREATING_UNIVERSAL_DIR}/usr/local/include"
fi
fi

Now that iOS 5 is out, I can talk about a better way to do it. Apple will now let you set the tintColor: property on the bar button item. That’s it. No more weird hacks with images or segmented controls.

There’s even a cool new appearance proxy that will let you change all controls from your app with a single line of code. (More about UIAppearance here)

So lets say you want every UIBarButtonItem in your application to be blue. That’s easy just call [UIBarButtonItem appearance] setTintColor:[UIColor blueColor]]

Remember, this is iOS 5 only. If you want your app to support iOS 4, you’ll have to do it the old way.

There are two ways to do it, one is with NSApplication and the other is with NSWindow.

To do it with NSApplication, you’ll make this simple call

   [[NSApplication sharedApplication]
           setPresentationOptions:NSFullScreenWindowMask];

To do it with NSWindow you’ll make this one

   [window setCollectionBehavior:
             NSWindowCollectionBehaviorFullScreenPrimary];

There is also an NSWindowCollectionBehaviorFullScreenAuxiliary that you can use to allow auxiliary windows to show up in the space with the main window.

Calling either of these methods will add the resize button to the upper right corner of the window. You can call them at any time also. If you want it to be in the app all the time, call it somewhere like applicationDidFinishLaunching.

One thing to remember is that fullscreen functionality like this is LION ONLY. If you’re using this in an app that targets more than 10.7, make sure to do the appropriate checks around this code.

Unfortunately, I couldn’t get links to show up in my app. I tried sending it delegate messages and lots of other stuff. It just wouldn’t work when I set the text programatically. It would only work when I was actually typing in to the NSTextView and even then, it was a little flaky. I posted a question on StackOverflow and didn’t get any answers.

So to fix the problem, I did the link detection myself. I look through the text view for links and then add them myself as NSAttributedStrings. I did this using three different categories.

There is NSAttributedString+Hyperlink, NSString+FindURLs, and NSTextView+AutomaticLinkDetection. I use the FindURLs category to find the links and their locations, then I use the Hyperlink category to format the string like a link, and the AutomaticLinkDetection category to bring them together.

You use it like this

   [myTextView setString:@"http://google.com http://apple.com"];
   [myTextView detectAndAddLinks];

And here is the implementation

-(void)detectAndAddLinks
{
   NSArray *linkLocations = [[self string] locationsOfLinks];
   NSArray *links = [[self string] arrayOfLinks];

   int i=0;
   for( NSString *link in links )
   {
      NSAttributedString *linkString = [NSAttributedString hyperlinkFromString:link withURL:[NSURL URLWithString:link]];
      [[self textStorage] replaceCharactersInRange:[[linkLocations objectAtIndex:i] range] withAttributedString:linkString];
      i++;
   }

}

I put an example project on GitHub that you can look at and use.

Let me know if there was something I missed that would make it so I don’t have to use the category.

Clicking a link that says myTwitterApp://sendTweet?tweet=hello could send a tweet from your twitter app. It could also be used for configuring your app. Maybe you have an email app that needs some special server configurations. It could be set up so that you just have to visit a webpage on your server and click a link and have it automatically configure your email settings.

Facebook uses the URL scheme for authentication in their iPhone app. If I have an app that wants to authenticate with Facebook, it will try and talk to the Facebook app on the phone so I don’t have to authenticate again in my other app.

I think this is a pretty underused feature and I would bet there are TONS of clever things people can do with it. So how do you actually do it?

I’m going to show you how I’m adding it to the next versions of Thoughtback.

Your first step is adding a URL type to your app’s info.plist. You will add the same key if you’re making an iOS or Mac app. The raw key is CFBundleURLTypes.

Once the key is added links that start with thoughtback:// will launch the apps on both iOS and OS X.

Just launching from a URL is fine, but how do you get any information out of the URL that was clicked? That’s where the process differs between the two platforms.

iOS
Go into your applicationdelegate and override either of these two methods.

- (BOOL)application:(UIApplication *)application 
           handleOpenURL:(NSURL *)url

- (BOOL)application:(UIApplication *)application 
            openURL:(NSURL *)url 
  sourceApplication:(NSString*)sourceApplication 
         annotation:(id)annotation

I should mention that the first method is deprecated, but the second one is only available on iOS 4.2 or later.

Mac OS
This is slightly different on the mac, URL handling is not part of the NSApplicationDelegate protocol.

What you’ll need to do is tell the application to respond to an Apple Event.

-(void)applicationWillFinishLaunching:(NSNotification *)aNotification
{
    NSAppleEventManager *appleEventManager = [NSAppleEventManager sharedAppleEventManager];
    [appleEventManager setEventHandler:self
                           andSelector:@selector(handleGetURLEvent:withReplyEvent:)
                         forEventClass:kInternetEventClass andEventID:kAEGetURL];
}

- (void)handleGetURLEvent:(NSAppleEventDescriptor *)event withReplyEvent:(NSAppleEventDescriptor *)replyEvent
{
    NSURL *url = [NSURL URLWithString:[[event paramDescriptorForKeyword:keyDirectObject] stringValue]];
}

Parsing the URL
So now that you have the URL that launched your app, you’ll want to get the information out of the string. The most typical way to send information is with a query string. Here’s an example that Thoughtback will use.

thoughtback://send?thought=Interesting Thought&redirect=http://fredandrandall.com

We want to pull out a few different things from that. First we want to grab “send” because that’s the action thoughtback will take. Then we want to get the thought that will be sent and the url that Thoughtback will redirect to when it’s done sending the thought.

To parse out “send” we can use NSURL’s host method.

To get the query string, we can use NSURL’s query method.

Parsing the query string is a little more difficult but this block of code, that I found on StackOverflow, will put it into an NSDictionary for you.

NSString *query = [url query];
NSArray *queryPairs = [query componentsSeparatedByString:@"&"];
NSMutableDictionary *pairs = [NSMutableDictionary dictionary];
for (NSString *queryPair in queryPairs) {
  NSArray *bits = [queryPair componentsSeparatedByString:@"="];
  if ([bits count] != 2) { continue; }

  NSString *key = [[bits objectAtIndex:0] stringByReplacingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
  NSString *value = [[bits objectAtIndex:1] stringByReplacingPercentEscapesUsingEncoding:NSUTF8StringEncoding];

  [pairs setObject:value forKey:key];
}

EDIT: There is a new way to do this in iOS 5 that is much easier and nicer. If you want to support iOS 4, keep reading.

A UIBarButtonItem is an item that goes on a UIToolbar or a UINavigationBar. It’s typically a button but it can be a bunch of different things. I’m going to talk about the button. A UIBarButtonItem button takes on the color of the bar that it is on. You can set the tint of a UIToolbar, but you can’t change the colors of the buttons on it.

I found lots of different solutions for this online, most involving adding a UIButton as the customView of the UIBarButtonItem and having some sort of image for the color you need. That works fine, until you need a color that you don’t have an image for.

I found a better solution here. Basically what they figured out was that a UISegmentedControl with a style of UISegmentedControlStyleBar looks just like a UIBarButtonItem. A key difference is that UISegmentedControl has a nice tintColor property that you can use to change the colors.

So what I did was take CharlyBr‘s code and put it into a UIBarButtonItem category.

+(UIBarButtonItem*)barButtonItemWithTint:(UIColor*)color andTitle:(NSString*)itemTitle andTarget:(id)theTarget andSelector:(SEL)selector
{
	UISegmentedControl *button = [[[UISegmentedControl alloc] initWithItems:[NSArray arrayWithObjects:itemTitle, nil]] autorelease];
	button.momentary = YES;
	button.segmentedControlStyle = UISegmentedControlStyleBar;
	button.tintColor = color;
	[button addTarget:theTarget action:selector forControlEvents:UIControlEventValueChanged];

	UIBarButtonItem *removeButton = [[[UIBarButtonItem alloc] initWithCustomView:button] autorelease];

	return removeButton;
}

You can check out my example project on GitHub.

To get started imgur has some good examples of how to upload in a variety of programming languages. I grabbed the iPhone example and copy and pasted it in thinking, “Well that was easy”. It turns out there was a little bit more to do.

Here is the iOS example from their website (with a few typos corrected)

-(NSData *)uploadPhoto:(UIImage *) image {
       NSData   *imageData  = UIImageJPEGRepresentation(image,1);
       NSString *imageB64   = [self escapeString:[imageData base64Encoding]];  //Custom implementations, no built in base64 or HTTP escaping for iPhone
       NSString *uploadCall = [NSStringstringWithFormat:@"key=%@ℑ=%@",imgurKey,imageB64];

       NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:@"http://api.imgur.com/2/upload"]];
       [request setHTTPMethod:@"POST"];
       [request setValue:[NSString stringWithFormat:@"%d",[uploadCalllength]] forHTTPHeaderField:@"Content-length"];
       [request setHTTPBody:[uploadCall dataUsingEncoding:NSUTF8StringEncoding]];

       NSURLResponse *response;
       NSError *error = nil;

       NSData *XMLResponse= [NSURLConnection sendSynchronousRequest:requestreturningResponse:&response error:&error];

       return XMLResponse;
}

The problem with their example was that it wasn’t quite finished.
That Database64Encoding method is not a part of the iOS sdk. You need to do that yourself. So what does it mean exactly?

It means that you need to convert the image data to Base64. That basically means turning your image data into a string so it can be sent up via a POST request. So I did a little bit of Googling and found some code that converts NSData to a Base64 NSString. I got the code from the MGTwitterEngine, but it can be found in a few places.

So after that I thought I should be done. I ran the code and got an error back from imgur. Then I noticed the weird ℑ character in the request. I’m not sure what it’s for, but it didn’t work. I replaced it with “image” and I got a success back from imgur.

Hooray, everything seemed like it was working, but it still wasn’t. When I went to the URL in the response, there was no image. Nothing loaded. What was wrong?

I had a suspicion that there was some funny stuff going on with the encoding so I wrote the base64 encoded string out to a file (it was waaaay too long for NSLog to handle) to see what was actually in it. There were a bunch of /’s and +’s. These are valid URL characters that can definitely mess up query string parsing if you want them to be in one of your arguments.

I pulled out an NSString category I had written to escape valid URL characters and called my stringByEscapingValidURLCharacters method on the base64 string. After trying again I was getting valid stuff back and my image URLs were loading correctly.

So, to prevent others from going through the headaches to make a simple imgur uploader, I decided to open source some example code code.

This code is very simplistic. It is a simple iPhone app that lets you choose an image from the camera or your phone’s library and send it to imgur. The ImgurUploader class calls out to imgur and returns the URL of the original sized image by calling a delegate method. It doesn’t handle any errors right now either. You will also need to get an API key from imgur, which only takes a second. This comes with the “works on my machine” seal of approval.

Check it out on GitHub

I started off by just using the default Cocoa Framework project that XCode makes for you. It all seemed to work just fine, but when I tried actually using the framework in a different project, it wouldn’t load. I kept getting this error

Library not loaded: path/to/framework
 Referenced from: path/to/app/
 Reason: image not found

After lots of looking around I finally figured out the problem. Frameworks can be referenced at the System level (requires admin rights to install), the User level (could be useful to share a framework between apps), and at the application level. Bundling your framework inside the application is the most common way to do that. The “image not found” error has to do with some pathing in the framework. To fix it, you’ll need to change the “Installation Directory” in the build settings of your framework. Right click on your framework’s target to bring up the info panel. Search for “Installation Directory” and set it to be @executable_path/../Frameworks.

Now the framework should load just fine in any project you want to use it in. I still had a problem though. If you’re familiar with cocoa frameworks, you’ll know its just a bundle with a library and some header files in a certain directory structure. I looked at my framework and couldn’t find the “Headers” folder with my header files so I couldn’t use anything that was in my framework. I googled around for a little while and found nothing. Thats when I noticed the “Role” column when I clicked on my framework target. That let me set the header files to public, private, or project, depending on how I wanted them to show up in my framework.

So now that I have the library path right and the header files right, there is just one thing I needed to do to get it working in my test app. You’ll need to add another build step to your application target that copies the framework to your application bundle.

1. Right click on your application target.
2. Click “New Build Phase”
3. Click “New Copy Files Build Phase”
4. Change the destination to “Frameworks”
5. Close the window.
6. Drag and drop your framework into the build phase.

Hopefully you found this useful. I couldn’t find all of the resources I needed in one place and what I did find wasn’t detailed enough to solve my problem immediately. This post from Cocoa Is My Girlfriend got me most of the way there and has some more good information on the subject.

I’ve been hearing about how great Grand Central Dispatch is for awhile so when I heard about a practical application of it, I decided to learn about it myself. A little bit of googling led me to a post at Cocoa Samurai. It seems to be a pretty good overview of GCD and blocks.

Based on some stuff I learned from there, I built a little demo app that uses GCD and blocks to make synchronous web calls asynchronous.

The app is a url shortener, if you want to try it out, first you’ll have to get an API key from bit.ly. (It’s super easy, just go to http://bit.ly/a/your_api_key/ and log in or sign up). Alright, lets get started.

First I made a simple UI with a button and a couple of text fields. One is for the URL you’re going to shorten and the other is for the short URL. Then I hooked up the button to an IBAction called shortenURL:

shortenURL: gets the URL from the first text field and passes it into some blocks that call a synchronous method for shortening the URL and then when that is done, another block updates the UI with the shortened URL. Here’s the function:

-(IBAction)shortenURL:(id)sender
{
   [spinner startAnimation:nil];

   dispatch_queue_t queue = dispatch_queue_create("com.Blocks.task",NULL);
   dispatch_queue_t main = dispatch_get_main_queue();

   dispatch_async(queue,^{
      NSString* shortURL = [self shortenSynchronous:[urlField stringValue]];

      dispatch_async(main,^{
         [self updateUIWithShortURL:shortURL];
      });
   });
}

To explain the dispatch_queue_ts you’ll need to understand a little bit better how GCD works. When you get a new thread from GCD it grabs it from a pool of available threads. When you’re done with the thread, GCD takes it back so it can be used again. So when you create a thread, you have a little bit of control over where it comes from. This is what the queues are. You create different queues so you can have a little bit of control over what queues your thread dispatches from. At least that is my understanding of this stuff. I could be way wrong.

dispatch_queue_create(“com.Blocks.task”, NULL) creates a private queue that is just for my app. dispatch_get_main_queue() gets the main thread for your application.

Next up is dispatching the threads onto the different queues. The first dispatch_async() takes a block that calls the URL shortening function. Then, it dispatches a new block on the main UI thread to update the UI with the result of the url shortening function. It uses what Apple calls recursive decomposition to call it in the right order. I don’t fully understand how it works yet but the Cocoa Samurai post I talked about earlier goes into more detail.

Other than the UI updating code and the URL shortening code (which is only 3 lines) that is all I needed to do. With an NSURLConnection I’m stuck implementing delegate methods and appending data as it arrives and some other confusing things. This is much cleaner and shorter. The only problem with it is that I don’t fully understand how it works… yet.

You can download the demo and play with it too. Feel free to use and modify the code.

The result of my weekend? Thoughtback.

Thoughtback is a personal idea saving/reminding service. Basically, we built an app around the idea that lots of people try to keep track of their thoughts and ideas, but very few ever get to revisit them. So what thoughtback will do is take your thoughts, then at some later time, send you an email with one of those thoughts so you can revisit the idea.

The service is a webapp, iPhone app, and Mac OSX app. How did we do it in just one weekend?

We had a pretty skilled team of developers. A few people on the team built the website, and I built the iPhone and Mac apps.

The website backend was written in PHP using CodeIgniter. The email stuff is done using Python and Cron. That stuff is sorta outside my realm of expertise so I’m glad I got on a team with people that knew what they were doing.

I wrote the iPhone and Mac apps. At first, it might seem like an awful lot to get done in 48 hours, but I was able to do a pretty good job of sharing code between the two apps. For example, all the network communication is done using a cross platform class. Luckily NSURLConnection was one of the things that Apple decided to keep on both platforms. For Keychain access I used a class I found that was actually designed to be used just for iPhone. Unfortunately (although fortunate in my case) the iPhone simulator doesn’t use the iPhone keychain, it bizarrely uses the Mac keychain. So I was able to use some code (SFHFKeychainUtils written by Buzz Anderson) and slightly modify it so it would work on both the iPhone and Mac. Basically I just changed the ifdef from the iPhone simulator to my mac. This let me basically just switch out my view classes and I was good to go.

Anyway, it was an AWESOME weekend and we’re gonna keep working on it. We even won $1000 bucks to put back into the “company” so hopefully we can get some cool stuff into it. We’ve even been getting some press on local radio stations and in the newspaper. The Mac app is available for download RIGHT NOW and the iPhone app is ready to be submitted to the app store. Check it out www.thoughtback.com.