Consider this class:

#import <Foundation/Foundation.h>

@interface ClassA : NSObject

@property (nonatomic, strong) NSMutableArray *array;

@end

@implementation ClassA

@synthesize array;

- (id)popObject {
    id lastObject = [array lastObject];
    if (lastObject) {
        [array removeLastObject];
    }
    return lastObject;
}

@end

In non-ARC land, the call to removeLastObject would release the object that was in the array and then if that was the last reference to it, it would dealloc the object meaning that we return a dead object. So we would retain lastObject and then return it with an autorelease.

But this scared me not doing this, even though I knew full well that ARC should be doing its job. I think I thought this because naively I thought that ARC would parse the method line by line. If it did then I thought it might not necessarily add in a retain because when we get a reference to the last object, ARC doesn’t know it needs to add a retain because well, why would it necessarily have to?

That’s where I was wrong. Obviously what ARC does is it will add in a retain once we get a reference to that object and then when that variable goes out of scope it adds a release or in our case, because we are returning it and the method name does not start with new or copy, it autoreleases it.

Let’s see what that code compiled to:

        .thumb_func     "-[ClassA popObject]"
"-[ClassA popObject]":
        push    {r4, r5, r6, r7, lr}
        movw    r6, :lower16:(_OBJC_IVAR_$_ClassA.array-(LPC0_0+4))
        mov     r4, r0
        movt    r6, :upper16:(_OBJC_IVAR_$_ClassA.array-(LPC0_0+4))
        movw    r1, :lower16:(L_OBJC_SELECTOR_REFERENCES_-(LPC0_1+4))
LPC0_0:
        add     r6, pc
        movt    r1, :upper16:(L_OBJC_SELECTOR_REFERENCES_-(LPC0_1+4))
LPC0_1:
        add     r1, pc
        add     r7, sp, #12
        ldr     r0, [r6]
        ldr     r1, [r1]
        ldr     r0, [r4, r0]
        blx     _objc_msgSend
        @ InlineAsm Start
        mov     r7, r7          @ marker for objc_retainAutoreleaseReturnValue
        @ InlineAsm End
        blx     _objc_retainAutoreleasedReturnValue
        mov     r5, r0
        cbz     r5, LBB0_2
        movw    r1, :lower16:(L_OBJC_SELECTOR_REFERENCES_2-(LPC0_2+4))
        movt    r1, :upper16:(L_OBJC_SELECTOR_REFERENCES_2-(LPC0_2+4))
        ldr     r0, [r6]
LPC0_2:
        add     r1, pc
        ldr     r1, [r1]
        ldr     r0, [r4, r0]
        blx     _objc_msgSend
LBB0_2:
        mov     r0, r5
        blx     _objc_autoreleaseReturnValue
        pop     {r4, r5, r6, r7, pc}

Well, there we go. ARC has done a fine job for us. What it’s actually done is added a call to objc_retainAutoreleaseReturnValue which means it has noticed it needs to retain a value that was returned autoreleased which must be an ARC optimisation that will just pull the object once from the autorelease pool rather than actually performing a retain. Then at the end of the method it calls objc_autoreleaseReturnValue which must do the work of autoreleasing the value we’re returning.

This is just another example of how to look at what ARC is doing under the hood. The more I use ARC, the more I realise how useful it is. It makes code less prone to memory management errors and allows for optimisations such as the one shown here of retaining an autoreleased return value.

We shall start by defining a class like so:

#import <Foundation/Foundation.h>

@interface ClassA : NSObject 

@property (nonatomic, retain) NSNumber *foo;

@end

@implementation ClassA

@synthesize foo;

- (void)changeFooDirect:(NSNumber*)inFoo {
    foo = inFoo;
}

- (void)changeFooSetter:(NSNumber*)inFoo {
    self.foo = inFoo;
}

- (NSNumber*)newNumber {
    return [[NSNumber alloc] initWithInt:10];
}

- (NSNumber*)getNumber {
    return [[NSNumber alloc] initWithInt:10];
}

@end

This outlines a few important aspects of ARC including direct access to ivars versus using a setter and how ARC will add autorelease calls when returning an object from a method based on the name of the method.

Let’s first look at the direct access to ivars versus using a setter. If we compile that code and look at the assembly then we’ll get an insight into what’s going on. I decided to use ARMv7 because it’s easier to understand what’s going on than x86 (in my opinion anyway!). We can turn ARC on and off with the -fobjc-arc and -fno-objc-arc compiler options. In these examples I’ve used optimisation level 3 which will mean the compiler will also remove redundant code which we’re not really interested in and would clog up the understanding (an exercise for the reader is to try without any optimisations and see what it looks like).

So to compile without ARC I used the following command:

$ /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/clang -isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk -arch armv7 -fno-objc-arc -O3 -S -o - test-arc.m

So, let’s look at changeFooDirect: and changeFooSetter::

        .align  2
        .code   16
        .thumb_func     "-[ClassA changeFooDirect:]"
"-[ClassA changeFooDirect:]":
        movw    r1, :lower16:(_OBJC_IVAR_$_ClassA.foo-(LPC0_0+4))
        movt    r1, :upper16:(_OBJC_IVAR_$_ClassA.foo-(LPC0_0+4))
LPC0_0:
        add     r1, pc
        ldr     r1, [r1]
        str     r2, [r0, r1]
        bx      lr

        .align  2
        .code   16
        .thumb_func     "-[ClassA changeFooSetter:]"
"-[ClassA changeFooSetter:]":
        push    {r7, lr}
        movw    r1, :lower16:(L_OBJC_SELECTOR_REFERENCES_-(LPC1_0+4))
        mov     r7, sp
        movt    r1, :upper16:(L_OBJC_SELECTOR_REFERENCES_-(LPC1_0+4))
LPC1_0:
        add     r1, pc
        ldr     r1, [r1]
        blx     _objc_msgSend
        pop     {r7, pc}

And following straight on, let’s look at what it looks like with ARC enabled. To do this I used the following command:

$ /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/clang -isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk -arch armv7 -fobjc-arc -O3 -S -o - test-arc.m

Again, we’re interested at the moment in changeFooDirect: and changeFooSetter::

        .align  2
        .code   16
        .thumb_func     "-[ClassA changeFooDirect:]"
"-[ClassA changeFooDirect:]":
        push    {r7, lr}
        movw    r1, :lower16:(_OBJC_IVAR_$_ClassA.foo-(LPC0_0+4))
        mov     r7, sp
        movt    r1, :upper16:(_OBJC_IVAR_$_ClassA.foo-(LPC0_0+4))
LPC0_0:
        add     r1, pc
        ldr     r1, [r1]
        add     r0, r1
        mov     r1, r2
        blx     _objc_storeStrong
        pop     {r7, pc}

        .align  2
        .code   16
        .thumb_func     "-[ClassA changeFooSetter:]"
"-[ClassA changeFooSetter:]":
        push    {r7, lr}
        movw    r1, :lower16:(L_OBJC_SELECTOR_REFERENCES_-(LPC1_0+4))
        mov     r7, sp
        movt    r1, :upper16:(L_OBJC_SELECTOR_REFERENCES_-(LPC1_0+4))
LPC1_0:
        add     r1, pc
        ldr     r1, [r1]
        blx     _objc_msgSend
        pop     {r7, pc}

We can instantly see the difference here. The changeFooSetter: is exactly the same whereas changeFooDirect: has changed with a single call to objc_storeStrong. That’s the interesting bit. If we looks at the LLVM documentation for this then we see that it’s doing a standard swap of the variable by releasing the old value and retain the new value. Whereas in the non-ARC version the ivar is just swapped without any retain or release. That’s just what we’d expect! Thanks ARC!

Now for the more interesting bit, the newNumber versus getNumber. Those methods in non-ARC land are both returning NSNumber objects which have a retain count of 1, i.e. the caller owns them. That sounds right for newNumber but not for getNumber according to Cocoa’s naming conventions. We’d expect to see an autorelease call when returning from getNumber. So let’s see what the code looks like without ARC:

        .align  2
        .code   16
        .thumb_func     "-[ClassA newNumber]"
"-[ClassA newNumber]":
        push    {r7, lr}
        movw    r1, :lower16:(L_OBJC_SELECTOR_REFERENCES_2-(LPC2_0+4))
        mov     r7, sp
        movt    r1, :upper16:(L_OBJC_SELECTOR_REFERENCES_2-(LPC2_0+4))
        movw    r0, :lower16:(L_OBJC_CLASSLIST_REFERENCES_$_-(LPC2_1+4))
        movt    r0, :upper16:(L_OBJC_CLASSLIST_REFERENCES_$_-(LPC2_1+4))
LPC2_0:
        add     r1, pc
LPC2_1:
        add     r0, pc
        ldr     r1, [r1]
        ldr     r0, [r0]
        blx     _objc_msgSend
        movw    r1, :lower16:(L_OBJC_SELECTOR_REFERENCES_4-(LPC2_2+4))
        movs    r2, #10
        movt    r1, :upper16:(L_OBJC_SELECTOR_REFERENCES_4-(LPC2_2+4))
LPC2_2:
        add     r1, pc
        ldr     r1, [r1]
        blx     _objc_msgSend
        pop     {r7, pc}

        .align  2
        .code   16
        .thumb_func     "-[ClassA getNumber]"
"-[ClassA getNumber]":
        push    {r7, lr}
        movw    r1, :lower16:(L_OBJC_SELECTOR_REFERENCES_2-(LPC3_0+4))
        mov     r7, sp
        movt    r1, :upper16:(L_OBJC_SELECTOR_REFERENCES_2-(LPC3_0+4))
        movw    r0, :lower16:(L_OBJC_CLASSLIST_REFERENCES_$_-(LPC3_1+4))
        movt    r0, :upper16:(L_OBJC_CLASSLIST_REFERENCES_$_-(LPC3_1+4))
LPC3_0:
        add     r1, pc
LPC3_1:
        add     r0, pc
        ldr     r1, [r1]
        ldr     r0, [r0]
        blx     _objc_msgSend
        movw    r1, :lower16:(L_OBJC_SELECTOR_REFERENCES_4-(LPC3_2+4))
        movs    r2, #10
        movt    r1, :upper16:(L_OBJC_SELECTOR_REFERENCES_4-(LPC3_2+4))
LPC3_2:
        add     r1, pc
        ldr     r1, [r1]
        blx     _objc_msgSend
        pop     {r7, pc}

And now with ARC:

        .align  2
        .code   16
        .thumb_func     "-[ClassA newNumber]"
"-[ClassA newNumber]":
        push    {r7, lr}
        movw    r1, :lower16:(L_OBJC_SELECTOR_REFERENCES_2-(LPC2_0+4))
        mov     r7, sp
        movt    r1, :upper16:(L_OBJC_SELECTOR_REFERENCES_2-(LPC2_0+4))
        movw    r0, :lower16:(L_OBJC_CLASSLIST_REFERENCES_$_-(LPC2_1+4))
        movt    r0, :upper16:(L_OBJC_CLASSLIST_REFERENCES_$_-(LPC2_1+4))
LPC2_0:
        add     r1, pc
LPC2_1:
        add     r0, pc
        ldr     r1, [r1]
        ldr     r0, [r0]
        blx     _objc_msgSend
        movw    r1, :lower16:(L_OBJC_SELECTOR_REFERENCES_4-(LPC2_2+4))
        movs    r2, #10
        movt    r1, :upper16:(L_OBJC_SELECTOR_REFERENCES_4-(LPC2_2+4))
LPC2_2:
        add     r1, pc
        ldr     r1, [r1]
        blx     _objc_msgSend
        pop     {r7, pc}

        .align  2
        .code   16
        .thumb_func     "-[ClassA getNumber]"
"-[ClassA getNumber]":
        push    {r7, lr}
        movw    r1, :lower16:(L_OBJC_SELECTOR_REFERENCES_2-(LPC3_0+4))
        mov     r7, sp
        movt    r1, :upper16:(L_OBJC_SELECTOR_REFERENCES_2-(LPC3_0+4))
        movw    r0, :lower16:(L_OBJC_CLASSLIST_REFERENCES_$_-(LPC3_1+4))
        movt    r0, :upper16:(L_OBJC_CLASSLIST_REFERENCES_$_-(LPC3_1+4))
LPC3_0:
        add     r1, pc
LPC3_1:
        add     r0, pc
        ldr     r1, [r1]
        ldr     r0, [r0]
        blx     _objc_msgSend
        movw    r1, :lower16:(L_OBJC_SELECTOR_REFERENCES_4-(LPC3_2+4))
        movs    r2, #10
        movt    r1, :upper16:(L_OBJC_SELECTOR_REFERENCES_4-(LPC3_2+4))
LPC3_2:
        add     r1, pc
        ldr     r1, [r1]
        blx     _objc_msgSend
        blx     _objc_autorelease
        pop     {r7, pc}

And look at the single difference – a blx (this is a method call) to objc_autorelease in getNumber:. That’s just what we’d expect from ARC because it’s noticed that the method name doesn’t start with new or copy and it knows that at the point of return the NSNumber has a retain count of 1 so it adds in an autorelease call. Excellent!

This has just shown a little insight into how ARC works in two circumstances and I hope it inspires the reader to go away and look for themselves into how ARC works rather than just taking it for granted. It’s important as a programmer to understand how your tools work.

I usually end up hand rolling a UITableViewCell subclass, or if I only ever want 1 of that type of cell in a given view (for instance a single username and single password cell) I might use Interface Builder to create the cell and put it in the XIB for the view controller. But when you end up with 10+ projects each with a handful of custom cells, you soon go quite mad trying to remember each detail about each cell.

So I was pleasantly surprised when I was recently given the opportunity to take a look at Sensible Cocoa‘s Sensible TableView (STV) project, which is a collection of Objective-C classes for easily creating custom UITableViewCells.

The Review

Having had a play with STV I have managed to get to grips with how it works and why you might want to use it. Hopefully by reading this you can get an insight into why you might want to use STV.

Features

STV at it’s core is a very simple way of creating custom cells (see the code samples below) but also there’s a lot of very impressive extra features such as binding to a data model so that you can create very complex interfaces to interact with your data. They also appear to be adding features all the time which is a good sign.

Examples

The best examples are on Sensible Cocoa’s website where there are videos showing how to use it.

Cost

STV is currently $99 for a license which includes full source code & limited time support. I think this is pretty decent value for money given what you can do with it.

Summary

If you’re someone who uses UITableView everyday, I can see that STV will definitely make your life a lot easier. I’d suggest that it might be suited more to contractors who are constantly churning out apps rather than developers working on long term projects where rolling your own cells is probably the right way to go still, given that you still get much more control over the cells if you do it yourself. For instance, in my Subnet Calc range of applications I have created a custom cell that is far too custom for STV to ever implement – it’s too specific to the application.

Overall, go and give STV a look. Watch the tutorial videos and see if it can do something for you.

In the coming weeks I aim to write a few more posts aimed at showing a few of the features of STV.

One that I came across today had stumped me for a long time and it has to do with the GCC atomic builtins. If you’re unfamiliar with them, then a good bit of introductory reading is a great blog post on the ARM blog. Now, these atomic builtins have not been defined within the iPhone’s libc implementation, until the 3.2 SDK came along – it appears that Apple have added them. This is a good thing, because it means that we can start using them in our applications. But, we can only use them for applications running on iPhone OS >=3.2 of course. That’s where the fun begins…

I have an application which I have been developing that needs to run on both the 3G and the 3GS, i.e. both armv6 and armv7. I found that after upgrading to the 3.2 SDK I started running into a rather strange problem when running the application on an iPhone 3G (running iPhone OS 3.1.3). The error I was getting was this:

dyld: lazy symbol binding failed: Symbol not found: ___sync_fetch_and_add_4
  Referenced from: /var/mobile/Applications/xxx/MyApp.app/MyApp
  Expected in: /usr/lib/libSystem.B.dylib

dyld: Symbol not found: ___sync_fetch_and_add_4
  Referenced from: /var/mobile/Applications/xxx/MyApp.app/MyApp
  Expected in: /usr/lib/libSystem.B.dylib

Now that’s really odd because __sync_fetch_and_add_4 is one of those GCC atomics which shouldn’t be being linked in as I am building for an iPhone OS deployment target of 3.1. It’s worth at this stage having a quick look at – http://developer.apple.com/iphone/library/documentation/Xcode/Conceptual/iphone_development/120-Running_Applications/running_applications.html – which says:

You specify the earliest iPhone OS release on which you want your application to run with the iPhone OS Deployment Target build setting. By default, this build setting is set to the iPhone OS release that corresponds to the Base SDK build-setting value. For example, when you set Base SDK to iPhone Device 2.2.1 or iPhone Simulator 2.2.1, the value of the iPhone Deployment Target build setting is iPhone OS 2.2.1, as shown in Figure 3-3.

So that means that if I set the base SDK to 3.2 and the iPhone OS deployment target to 3.1, then I should get code that will definitely run on 3.1, right? Running my app on 3.1.3 however causes a crash simply because __sync_fetch_and_add_4 isn’t available in its libc.

After a bit of inspection I found that even this simple program caused the crash:

#include <string>

int main(int argc, char *argv[]) {
    std::string strA = "yes";
    return 0;
}

That really is a very simple program! Why would that crash! Well, with a bit of inspection using ‘nm‘ we can work out what’s going on. ‘nm’ shows us a list of the symbols that a given object file, or binary references. Below are outputs of ‘nm’ on the resulting binary from 2 different combinations of base SDK and iPhone OS deployment target.

Base SDK = 3.1.3, iPhone OS Deployment Target = 3.1:

nm build/Debug-iphoneos/AtomicsBug.app/AtomicsBug

build/Debug-iphoneos/AtomicsBug.app/AtomicsBug (for architecture armv6):
00002f64 s  stub helpers
00002fdc s GCC_except_table0
00003048 D _NXArgc
0000304c D _NXArgv
         U __Unwind_SjLj_Register
         U __Unwind_SjLj_Resume
         U __Unwind_SjLj_Unregister
         U __ZN9__gnu_cxx18__exchange_and_addEPVii
         U __ZNSs4_Rep10_M_destroyERKSaIcE
         U __ZNSs4_Rep20_S_empty_rep_storageE
         U __ZNSsC1EPKcRKSaIcE
         U ___gxx_personality_sj0
00003054 D ___progname
00002f58 t ___restore_vfp_d8_d15_regs
00002f50 t ___save_vfp_d8_d15_regs
00001000 A __mh_execute_header
00003050 D _environ
         U _exit
00002e9c t _main
0000301c s _pvars
         U dyld_stub_binder
00002e70 T start

build/Debug-iphoneos/AtomicsBug.app/AtomicsBug (for architecture armv7):
00002f64 s  stub helpers
00002fdc s GCC_except_table0
00003048 D _NXArgc
0000304c D _NXArgv
         U __Unwind_SjLj_Register
         U __Unwind_SjLj_Resume
         U __Unwind_SjLj_Unregister
         U __ZN9__gnu_cxx18__exchange_and_addEPVii
         U __ZNSs4_Rep10_M_destroyERKSaIcE
         U __ZNSs4_Rep20_S_empty_rep_storageE
         U __ZNSsC1EPKcRKSaIcE
         U ___gxx_personality_sj0
00003054 D ___progname
00001000 A __mh_execute_header
00003050 D _environ
         U _exit
00002eb0 t _main
0000301c s _pvars
         U dyld_stub_binder
00002e84 T start

Base SDK = 3.2, iPhone OS Deployment Target = 3.1:

nm build/Debug-iphoneos/AtomicsBug.app/AtomicsBug 

build/Debug-iphoneos/AtomicsBug.app/AtomicsBug (for architecture armv6):
00002f64 s  stub helpers
00002fdc s GCC_except_table0
00003048 D _NXArgc
0000304c D _NXArgv
         U __Unwind_SjLj_Register
         U __Unwind_SjLj_Resume
         U __Unwind_SjLj_Unregister
         U __ZNSs4_Rep10_M_destroyERKSaIcE
         U __ZNSs4_Rep20_S_empty_rep_storageE
         U __ZNSsC1EPKcRKSaIcE
         U ___gxx_personality_sj0
00003054 D ___progname
00002f58 t ___restore_vfp_d8_d15_regs
00002f50 t ___save_vfp_d8_d15_regs
         U ___sync_fetch_and_add_4
00001000 A __mh_execute_header
00003050 D _environ
         U _exit
00002ea4 t _main
0000301c s _pvars
         U dyld_stub_binder
00002e78 T start

build/Debug-iphoneos/AtomicsBug.app/AtomicsBug (for architecture armv7):
00002f74 s  stub helpers
00002fe0 s GCC_except_table0
00003044 D _NXArgc
00003048 D _NXArgv
         U __Unwind_SjLj_Register
         U __Unwind_SjLj_Resume
         U __Unwind_SjLj_Unregister
         U __ZNSs4_Rep10_M_destroyERKSaIcE
         U __ZNSs4_Rep20_S_empty_rep_storageE
         U __ZNSsC1EPKcRKSaIcE
         U ___gxx_personality_sj0
00003050 D ___progname
00001000 A __mh_execute_header
0000304c D _environ
         U _exit
00002ea8 t _main
00003018 s _pvars
         U dyld_stub_binder
00002e7c T start

Notice how it’s referencing __sync_fetch_and_add_4 in the armv6 version of the binary created with base SDK 3.2? That’s bad! After a bit of digging into the header files supplied with the SDKs we find where the problem stems from – it’s in the c++config.h header file. Here is the difference between the file supplied with 3.1.3 SDK to the file supplied with 3.2 SDK:

$ diff -u /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.1.3.sdk/usr/include/c++/4.2.1/armv6-apple-darwin9/bits/c++config.h /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.2.sdk/usr/include/c++/4.2.1/armv6-apple-darwin10/bits/c++config.h

--- /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.1.3.sdk/usr/include/c++/4.2.1/armv6-apple-darwin9/bits/c++config.h  2009-12-18 09:19:17.000000000 +0000
+++ /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.2.sdk/usr/include/c++/4.2.1/armv6-apple-darwin10/bits/c++config.h   2010-03-16 05:39:05.000000000 +0000
@@ -879,7 +879,7 @@
 /* #undef _GLIBCXX_VERSION */

 /* Define if builtin atomic operations are supported on this host. */
-/* #undef _GLIBCXX_ATOMIC_BUILTINS */
+#define _GLIBCXX_ATOMIC_BUILTINS 1

 /* Define to use concept checking code from the boost libraries. */
 /* #undef _GLIBCXX_CONCEPT_CHECKS */

This means that for any file compiled with the 3.2 SDK, GCC is told that it has the atomic builtins and so it creates code that links against them. So, there’s the problem!

Apple are trying to get everyone to use base SDK and iPhone OS deployment target settings rather than just building for an old SDK, but they need to make sure 100% that their SDKs are sane enough to cope with the asymmetry.

I have uploaded a sample project that shows the problem: AtomicsBug Project.

EDIT: I’ve found that if you use gcc-4.0 rather than gcc-4.2 then the problem doesn’t appear. This is because gcc-4.0 doesn’t use __sync_fetch_and_add for its atomic functions. (Note: this isn’t a fix but is a quick workaround for anyone experiencing the problem).

Update [17/05/2010]: It appears that Apple are aware of the bug. Fingers crossed that it’ll be fixed in future SDKs.

Eventually I managed to find a fix which uses the libresolv to find the DNS servers. This seems to work just fine and I have shown the patch to ares_init.c below for reference.

#if TARGET_OS_IPHONE
#include <resolv.h>
#endif

...

#if TARGET_OS_IPHONE
// XXX: On the iPhone we need to get the DNS servers using resolv.h magic
if ((_res.options & RES_INIT) == 0) res_init();
channel->nservers = _res.nscount;
channel->servers = malloc(channel->nservers * sizeof(struct server_state));
memset(channel->servers, '\0', channel->nservers * sizeof(struct server_state));

int i;
for (i = 0; i < channel->nservers; i++)
{
    memcpy(&channel->servers[i].addr, &_res.nsaddr_list[i].sin_addr, sizeof(struct in_addr));
}
#endif

[As per most of my posts these days, this is just a brain dump. I'll try to pad it out as soon as possible]

# Defines to set up environment
export DEVROOT=${ROOTDIR}/Platforms/${PLATFORM}.platform/Developer
export SDKROOT=${DEVROOT}/SDKs/${PLATFORM}${MAX_VERSION}.sdk
export CC=$DEVROOT/usr/bin/gcc
export LD=$DEVROOT/usr/bin/ld
export CPP=$DEVROOT/usr/bin/cpp
export CXX=$DEVROOT/usr/bin/g++
export AR=$DEVROOT/usr/bin/ar
export LIBTOOL=$DEVROOT/usr/bin/libtool
export AS=$DEVROOT/usr/bin/as
export NM=$DEVROOT/usr/bin/nm
export CXXCPP=$DEVROOT/usr/bin/cpp
export RANLIB=$DEVROOT/usr/bin/ranlib
export OPTFLAG="-O${OPT}"
export COMMONFLAGS="${ARCH} -pipe $OPTFLAG -gdwarf-2 -no-cpp-precomp -mthumb -isysroot ${SDKROOT} -miphoneos-version-min=${MIN_VERSION}"
export LDFLAGS="${COMMONFLAGS} -L${HOME}${SDKROOT}/usr/lib"
export CFLAGS="${COMMONFLAGS} -fvisibility=hidden"
export CXXFLAGS="${COMMONFLAGS} -fvisibility=hidden -fvisibility-inlines-hidden"

This uses a few defines which need to be different for the device vs. simulator. Below are what you might want to use for each one. Note that MIN_VERSION, MAX_VERSION and OPT can all be set to control what SDK versions and the level of optimisation is used.

Device:

# Variables
export ROOTDIR="/Developer"
export PLATFORM="iPhoneOS"
export ARCH="-arch armv6 -arch armv7"
export MIN_VERSION="3.1"
export MAX_VERSION="4.0"
export OPT="3"

Simulator:

# Variables
export ROOTDIR="/Developer"
export PLATFORM="iPhoneSimulator"
export ARCH="-arch i386"
export MIN_VERSION="3.1"
export MAX_VERSION="4.0"
export OPT="3"

Once you have set the environment, you just need to use ‘make’ to build the library. If the library is using autoconf, then you will need to use the following ‘./configure’ options:

Device:

./configure --host=arm-apple-darwin9 --prefix=${HOME}/${SDKROOT} --enable-shared=no --disable-dependency-tracking

[Note: --disable-dependency-tracking is required because gcc can't use dependency tracking when building for 2 architectures at the same time (i.e. armv6 and armv7).]

Simulator:

./configure --host=i386-apple-darwin --prefix=${HOME}/${SDKROOT} --enable-shared=no

Then just use ‘make’ and ‘make install’ to build the library! It really is as easy as that .

[Other libraries may require other configure options, but I can't cover them all here as they are often different]

EDIT: I’ve edited the defines above to be a bit clearer and factor out the common bits from the device/simulator.

For a recent project I’ve had to compile the Boost C++ library for the iPhone. Much of the Boost library is header files so they are fine as nothing needs to be done, they just get copied into place, but the bits which do need compiling are a bit trickier. So I thought I’d share my experiences here.

First you need to download Boost (I went for version 1.40) from http://www.boost.org. Then you need to edit some of the Boost.Jam configuration. This involves creating a user-config.jam file in your home directory like so:

~/user-config.jam:
using darwin : 4.2.1~iphone
   : /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc-4.2 -arch armv6
   : <striper>
   : <architecture>arm <target-os>iphone <macosx-version>iphone-3.0
   ;

using darwin : 4.2.1~iphonesim
   : /Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/gcc-4.2 -arch i386
   : <striper>
   : <architecture>x86 <target-os>iphone <macosx-version>iphonesim-3.0
   ;

Then edit tools/build/v2/tools/darwin.jam and add in the following under the macosx-versions variable:

.macosx-versions =
    10.6 10.5 10.4 10.3 10.2 10.1
    iphone-3.1 iphonesim-3.1
    iphone-3.0 iphonesim-3.0
    iphone-2.3 iphonesim-2.3
    iphone-2.2 iphonesim-2.2
    iphone-2.1 iphonesim-2.1
    iphone-2.0 iphonesim-2.0
    iphone-1.x
    ;

Then, you need to use the following lines to build Boost for iPhoneOS and iPhoneSimulator respectively:

./bjam --prefix=~/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.0.sdk/usr toolset=darwin architecture=arm target-os=iphone macosx-version=iphone-3.0 define=_LITTLE_ENDIAN link=static include=/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.0.sdk/usr/include/c++/4.2.1/armv6-apple-darwin9 install

./bjam --prefix=~/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator3.0.sdk/usr toolset=darwin architecture=x86 target-os=iphone macosx-version=iphonesim-3.0 link=static include=/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator3.0.sdk/usr/include/c++/4.2.1/i686-apple-darwin9 install

It’s worth noting that at this stage everything will compile for the simulator but not for the device. This is because the device is missing two header files – ‘bzlib.h’ and ‘crt_externs.h’. To make it compile for the device simply copy these files from ‘/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator3.0.sdk/usr/include/’ into your Boost folder and then everything should compile fine. I have no idea why Apple have omitted these header files from the device. The libraries are there, just the header files missing. I’ve created a bug on Radar for this, so please also do the same if you encounter this problem such that Apple will listen and include them.

That installs the files in ‘~/Developer/Platforms/iPhone(OS|Simulator).platform/Developer/SDKs/iPhone(OS|Simulator)3.0.sdk/usr’ which was where I wanted mine to go, but feel free to change that to wherever you want the libraries to end up. I did it this way because I created a custom SDK and then include that from iPhone projects within XCode.

boost-1.42:
Since Boost has been updated, I thought I’d extend this article to explain how to compile boost-1.42 for the iPhone. Boost themselves have gone a long way to do everything for you now, so there’s much less that needs to be done. You now need to do this:

~/user-config.jam
using darwin : 4.2.1~iphone
   : /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc-4.2 -arch armv7 -mthumb -fvisibility=hidden -fvisibility-inlines-hidden
   : <striper>
   : <architecture>arm <target-os>iphone <macosx-version>iphone-3.1.3
   ;

using darwin : 4.2.1~iphonesim
   : /Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/gcc-4.2 -arch i386 -fvisibility=hidden -fvisibility-inlines-hidden
   : <striper>
   : <architecture>x86 <target-os>iphone <macosx-version>iphonesim-3.1.3
   ;

Then edit tools/build/v2/tools/darwin.jam and add in the following under the macosx-versions variable:

tools/build/v2/tools/darwin.jam
## The MacOSX versions we can target.
.macosx-versions =
    10.6 10.5 10.4 10.3 10.2 10.1
    iphone-3.2 iphonesim-3.2
    iphone-3.1.3 iphonesim-3.1.3
    iphone-3.1.2 iphonesim-3.1.2
    iphone-3.1 iphonesim-3.1
    iphone-3.0 iphonesim-3.0
    iphone-2.2.1 iphonesim-2.2.1
    iphone-2.2 iphonesim-2.2
    iphone-2.1 iphonesim-2.1
    iphone-2.0 iphonesim-2.0
    iphone-1.x
    ;

# <grab source from boost.org>
tar xzf boost_1_42_0.tar.gz
cd boost_1_42_0
./bootstrap.sh

# Install for device:
./bjam --prefix=${HOME}/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.1.3.sdk/usr toolset=darwin architecture=arm target-os=iphone macosx-version=iphone-3.1.3 define=_LITTLE_ENDIAN link=static install

# Install for simulator
./bjam –-prefix=${HOME}/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator3.1.3.sdk/usr toolset=darwin architecture=x86 target-os=iphone macosx-version=iphonesim-3.1.3 link=static install

* Google backs Android, a major pipeline for its cloud services.
Yes, true, but Apple backs the iPhone and clearly has cloudy things in the pipeline with it’s building of a new billion dollar data centre.

* Android is improving rapidly. The Cupcake 1.5 release was well-received, and Donut 1.6 has already been sent over the air to handset owners.
iPhone OS is improving all the time as well. Granted Android is faster, but for developers I think it’s great how Apple release iPhone OS. It means you have time to get ready for each release to make sure all apps work properly on each version.

* Android is open, making it easier to quickly gain developers’ support.
The iPhone SDK is free to download and only £59 to become a member of the full developer program. It’s really not that much of a barrier.

* Android will run on phones from several manufacturers, which will help it quickly spread through the marketplace. HTC, Motorola and Samsung are already supporting handsets.
This is a bad thing in my opinion. I absolutely love the fact that with the iPhone you know exactly what devices the app will run on, and you know every exact specification. Only if the hardware manufacturer is the SDK provider, can this happen 100%.

* Android combines the best of what’s out there. It’s open, but it offers iPhone-like menus and apps, with Windows Mobile-esque icons, with Palm Pre-like multitasking. There’s another arms race afoot — the battle among Android handset makers as to which company can squeeze the most out of the OS.
Is that a good thing to mix-and-match? I prefer having a rock solid, stable OS, built by one of the best software companies in the world. Furthermore, they build the hardware as well so they know how to eek every last bit of power out of the hardware to provide software developers with one of the best platforms to develop for.

UITableViewCellStyleValue2
textLabel: 10.000000 : 14.000000 : 68.000000 : 16.000000
detailTextLabel: 83.000000 : 12.000000 : 207.000000 : 0.000000

The problem comes that during code-sign, it searches for certificates by the name, which leads to “iPhone Developer: Matthew Galloway” matching both certificates you have installed (one for each developer account). But Apple have at some point changed their certificate signing process and they add a number of the end of the common name on the certificate. This means that each certificate is unique even if it’s for the same physical developer.

One thing to note is that I used the same private key to generate the CSR for both certificates. I’m not sure what the implications would be for using separate private keys, but I can’t imagine it would make a difference.

I guess Apple had to do this really because lots of companies would have ended up with problems I’m sure.

So for anyone wondering if they can use multiple developer certificates, then just go for it, it should work!