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.
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 checkout MBProgressHUD – it just works, no matter arc/pre-arc ))The post was originally published on the following URL: http://www.touch-code-magazine.com/how-to-write-code-which-is-arc-non-arc-ios5-0-and-ios4-x-compatible/