How to write code which is ARC, non-ARC, iOS5.0 and iOS4.x compatible

I’ve been trying to use only ARC 3rd party libraries ever since iOS5 came out and I still stand by this decision. The new features are the future, not the old features – believe me. Couple of days after I was desperate to make AFNetworking working (non-ARC btw) at all and had this unpleasant taste in my mouth after the encounter with it I stumbled upon another library which totally amazed me.

Enter MBProgressHUD.

I want to say that this is a very carefully crafted API. I liked it instantly and loved the way they put it: no matter what’s your project just include the .h and .m and it’ll work – now, ain’t that just nice?

Being compatible with everything

So why would you like to write code which is compatible with both ARC and pre-ARC? If you work on a project of yours it’s highly unlikely you’ll need that. On the other hand if you’re writing a library for others to use – that might be a good choice.

Let’s just have a look at a short piece of code, to see how it all works for MBProgressHUD:

#if __has_feature(objc_arc_weak)
	id __weak delegate;
#elif __has_feature(objc_arc)
	id __unsafe_unretained delegate;
#else
	id delegate;
#endif

You can see that the author cared about the quality of his code just by these few lines. Now as you see the features are as follows: objc_arc_weak means you’re on ARC and iOS5, otherwise if you at least have objc_arc then you’re on ARC and iOS4.x and finally if non of the above – it’s good old (more old the good of course) non-ARC and doesn’t matter which iOS.

In your actual code you can check only for objc_arc – that’d be when you have retain/release etc.

Well, this covers how to make your code compatible if you care for the people using your stuff … and if you need a HUD class for your app’s loader/spinner do checkoutMBProgressHUD – it just works, no matter arc/pre-arc  ))