It wouldn't be our only non-ARC framework. It might be interesting to benchmark an ARC version though.

It might even be faster under ARC since I think the compiler can optimize some retain/release calls. I think the ARC retain and release may be faster than -retain/-release, but I'm not sure about that.

Overall, yes, it's less smooth to include non-ARC code in an ARC project.

I was under the impression that ARC simply inserts the retain/releases into the code essentially write before the compile, so in theory would be equivalent.

ARC inserts the retain/release calls but once that is done there is an additional step where duplicate retain/release pairs are eliminated.

Why would you write it with manual retains? Who doesn't use ARC at this point?

If the rest of the project is non-ARC it's easier in my experience to write new additions that way as well. I've only been using ARC on newly-created projects because having to add -fobjc-arc or -fno-objc-arc to dozens of files in Xcode is very, very tedious.

You can do a search to filter files in Xcode as well as cmd-click to select multiple files, the double click and enter the flags once for all of them.

Actually you have my support for going manual. I still prefer to do all my projects without ARC (and I'm not old-school, unless 2009 is old-school). I just feel dirty everytime I use ARC, like I'm being sloppy haha. It also hides a lot about memory management that new people might never learn (and thus be in bigger trouble when something does go wrong). But I accept that it does have major advantages...

One trouble now is you never know if a library or whatnot will be ARC so it fragments things somewhat.

If you know how to use retain/release, then you shouldn't have any trouble dealing with ARC edge cases... go ARC!

well, [Something alloc] also hides some about memory management…