ARC in a nutshell is the compiler automatically adding retain/release code [2]. Also, weak references etc, @autoreleasepool built into the language.
Caveat: Cocoa only. CoreFoundation based frameworks cannot use ARC (so for example AddressBook stuff the memory still needs to be managed manually). However, there are concerns with toll-free bridged CoreFoundation objects (ie CFString to NSString) [1]. Files can be omitted from ARC (or added to use it) on a file by file basis using compiler flags that you can set in the Build Phase of your project (-fno-objc-arc or -fobjc-arc) [1]. ARC is only available on 10.7 (Lion) and iOS 5, but the binaries are compatible with 10.6 (Snowy) and iOS 4. This means however, that we will have to drop iOS 3 support, which we are already planning to do - so moving the project to ARC will accelerate that task. The WWDC 2011 Session 322 "Objective-C Advancements in Depth" video is a good overview on what's happening (as well as Session 300 - 'Developer Tools Kickoff' video). There is the ARC Migration Tool available in Xcode to help us with this migration. Devs will however need to use Lion going forward with ARC (to test with the iOS Simulator), See this FAQ item below: Can I develop applications for Mac OS X with ARC using Snow Leopard? No. The Snow Leopard version of Xcode 4.2 doesn’t support ARC at all on Mac OS X, because it doesn’t include the 10.7 SDK. Xcode 4.2 for Snow Leopard does support ARC for iOS though, and Xcode 4.2 for Lion supports both Mac OS X and iOS. This means you need a Lion system to build an ARC application that runs on Snow Leopard. [1] https://developer.apple.com/library/ios/#releasenotes/ObjectiveC/RN-TransitioningToARC/Introduction/Introduction.html [2] http://clang.llvm.org/docs/AutomaticReferenceCounting.html On Thu, Mar 8, 2012 at 12:44 PM, Filip Maj <[email protected]> wrote: > +1 going exclusively ARC > > On 3/8/12 12:39 PM, "Jesse" <[email protected]> wrote: > >>ARC benefits, less code, cleaner code, simpler code >>ARC downsides - anal memory management folk won't be able to use it ( >>non-ARC applications cannot load an ARC library, it is all or nothing. ) >> >>The only way to support both is to do both ... ie conditional code, #ifdef >>bs that I personally think will make BOTH paths suck. >> >>My vote is to go the ARC route (exclusively) >> >> >> >>On Thu, Mar 8, 2012 at 12:23 PM, Filip Maj <[email protected]> wrote: >> >>> What are the down-sides, if any, to moving to ARC? Potential for not >>>being >>> "as optimized"? Not sure how much that matters to the typical >>> lists-n-buttons app that most Cordova apps are. >>> >>> And up-sides? Less/cleaner/easier code? >>> >>> On 3/8/12 12:16 PM, "Patrick Mueller" <[email protected]> wrote: >>> >>> >On Thu, Mar 8, 2012 at 14:14, Shazron <[email protected]> wrote: >>> > >>> >> Ref: https://issues.apache.org/jira/browse/CB-274 >>> >> >>> >> I say we go ARC. >>> >> >>> > >>> >I think we need to support ARC. The question is do we need to support >>>NOT >>> >using ARC as well. >>> > >>> >Presumably there's some pattern of leaving your retain/release calls in >>> >the >>> >code, #ifdef'd, so they aren't used when your project is using ARC, and >>> >are >>> >used when your project isn't. Eventually, in theory, everyone is using >>> >ARC >>> >all the time (just like we were going to use GC all the time!!), and we >>> >can >>> >remove the #ifdef'y bits. >>> > >>> >-- >>> >Patrick Mueller >>> >http://muellerware.org >>> >>> >
