incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <shaz...@gmail.com>
Subject Re: [iOS] Going ARC
Date Thu, 08 Mar 2012 22:52:22 GMT
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 <fil@adobe.com> wrote:
> +1 going exclusively ARC
>
> On 3/8/12 12:39 PM, "Jesse" <purplecabbage@gmail.com> 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 <fil@adobe.com> 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" <pmuellr@gmail.com> wrote:
>>>
>>> >On Thu, Mar 8, 2012 at 14:14, Shazron <shazron@gmail.com> 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
>>>
>>>
>

Mime
View raw message