You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Shazron <sh...@gmail.com> on 2012/03/08 20:14:21 UTC
[iOS] Going ARC
Ref: https://issues.apache.org/jira/browse/CB-274
I say we go ARC.
What is ARC? (Automatic Reference Counting)
Automatic Reference Counting (ARC) for Objective-C makes memory
management the job of the compiler. By enabling ARC with the new Apple
LLVM compiler, you will never need to type retain or release again,
dramatically simplifying the development process, while reducing
crashes and memory leaks. The compiler has a complete understanding of
your objects, and releases each object the instant it is no longer
used, so apps run as fast as ever, with predictable, smooth
performance.
Re: [iOS] Going ARC
Posted by Shazron <sh...@gmail.com>.
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 <fi...@adobe.com> wrote:
> +1 going exclusively ARC
>
> On 3/8/12 12:39 PM, "Jesse" <pu...@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 <fi...@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" <pm...@gmail.com> wrote:
>>>
>>> >On Thu, Mar 8, 2012 at 14:14, Shazron <sh...@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
>>>
>>>
>
Re: [iOS] Going ARC
Posted by Filip Maj <fi...@adobe.com>.
+1 going exclusively ARC
On 3/8/12 12:39 PM, "Jesse" <pu...@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 <fi...@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" <pm...@gmail.com> wrote:
>>
>> >On Thu, Mar 8, 2012 at 14:14, Shazron <sh...@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
>>
>>
Re: [iOS] Going ARC
Posted by Jesse <pu...@gmail.com>.
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 <fi...@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" <pm...@gmail.com> wrote:
>
> >On Thu, Mar 8, 2012 at 14:14, Shazron <sh...@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
>
>
Re: [iOS] Going ARC
Posted by Shazron <sh...@gmail.com>.
That's where we are going. The reason we went with shipping a binary
.framework is because of Xcode 4 and it's limitations regarding
project template definitions (not supported nor documented) - there
was no way to link to a subproject. With cli tooling we have more
control.
On Thu, May 10, 2012 at 4:06 PM, Patrick Mueller <pm...@gmail.com> wrote:
> On Thu, May 10, 2012 at 5:32 PM, Shazron <sh...@gmail.com> wrote:
>
>> D'oh - we can't have dual support of course, since this is compile
>> time and we ship a built binary for the framework. We'll have to turn
>> it on, and require ARC. The problem is, all the plugins will need to
>> upgrade as well.
>>
>
> We should stop shipping a framework, and start shipping the source files in
> the framework, once we have the command line tooling working well. Goes
> along with not shipping an Xcode template, but creating the Xcode files
> with the command line tooling.
>
> --
> Patrick Mueller
> http://muellerware.org
Re: [iOS] Going ARC
Posted by Patrick Mueller <pm...@gmail.com>.
On Thu, May 10, 2012 at 5:32 PM, Shazron <sh...@gmail.com> wrote:
> D'oh - we can't have dual support of course, since this is compile
> time and we ship a built binary for the framework. We'll have to turn
> it on, and require ARC. The problem is, all the plugins will need to
> upgrade as well.
>
We should stop shipping a framework, and start shipping the source files in
the framework, once we have the command line tooling working well. Goes
along with not shipping an Xcode template, but creating the Xcode files
with the command line tooling.
--
Patrick Mueller
http://muellerware.org
Re: [iOS] Going ARC
Posted by Shazron <sh...@gmail.com>.
Resurrecting this. My latest comment (duped below):
https://issues.apache.org/jira/browse/CB-274?focusedCommentId=13272771&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13272771
-----------
D'oh - we can't have dual support of course, since this is compile
time and we ship a built binary for the framework. We'll have to turn
it on, and require ARC. The problem is, all the plugins will need to
upgrade as well.
This then becomes a communication issue that we will need to send to
devs ahead of time. We can push this to 2.0 but we must have an
extended RC period to iron out the bugs, but we can start blogging
about this change now.
If are to push it to now (1.8.0) my suggestion is to exclude ARC for
CDVPlugin, and instruct users how to exclude ARC for their plugin
files: http://stackoverflow.com/questions/6448874/disable-automatic-reference-counting-for-some-files
- this way there is a transition. We can also print out warnings in
the console.log about the migration to ARC.
-----------
Shaz
On Thu, Mar 8, 2012 at 2:58 PM, Shazron <sh...@gmail.com> wrote:
> I'd rather not do #ifdefs and go whole hog on ARC. If we go ARC we
> can't support iOS 3.x (see my previous email).
>
> The #ifdef you would use:
>
> #ifdef __has_feature(objc_arc)
> NSLog(@"ARC eh");
> #endif
>
> On Thu, Mar 8, 2012 at 12:16 PM, Patrick Mueller <pm...@gmail.com> wrote:
>> On Thu, Mar 8, 2012 at 14:14, Shazron <sh...@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
Re: [iOS] Going ARC
Posted by Shazron <sh...@gmail.com>.
I'd rather not do #ifdefs and go whole hog on ARC. If we go ARC we
can't support iOS 3.x (see my previous email).
The #ifdef you would use:
#ifdef __has_feature(objc_arc)
NSLog(@"ARC eh");
#endif
On Thu, Mar 8, 2012 at 12:16 PM, Patrick Mueller <pm...@gmail.com> wrote:
> On Thu, Mar 8, 2012 at 14:14, Shazron <sh...@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
Re: [iOS] Going ARC
Posted by Filip Maj <fi...@adobe.com>.
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" <pm...@gmail.com> wrote:
>On Thu, Mar 8, 2012 at 14:14, Shazron <sh...@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
Re: [iOS] Going ARC
Posted by Patrick Mueller <pm...@gmail.com>.
On Thu, Mar 8, 2012 at 14:14, Shazron <sh...@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