Apple says Mac app makers must transition to ARC memory management by May

Posted:
in Mac Software edited February 2015
In an announcement posted to Apple's developer portal on Friday, the notified app makers that all Mac App Store submissions will soon be restricted from using garbage collection in favor of the Automatic Reference Counting (ARC) compiler feature.


Source: Apple


The announcement calls for developers to migrate upcoming and existing Mac apps away from garbage collection memory management, which was deprecated with the release of OS X 10.8 Mountain Lion, to the more efficient ARC scheme by early May.

ARC is a compiler feature that provides automatic memory management of objects when using the Objective-C programming language, allowing developers an alternative to traditional retain and release code.

Developers are urged to use Xcode's migration assistant when transitioning, as the tool includes an automated conversion feature that, among other operations, removes retain and release calls from an app's code.

Apple notes that apps distributed through the Mac App Store may continue to use retain and release operations for manual memory management.

The new stipulation takes effect on May 1 and applies to both new Mac apps and update submissions.
«134

Comments

  • Reply 1 of 76

    How does this translate into an improvement for the app user? More efficient use of code, meaning a smoother experience for apps? Potentially fewer crashes?

  • Reply 2 of 76
    If my understanding is correct, ARC works by inserting retain and release calls, so there is no way for Apple to tell from a compiled app whether you are using ARC or manually retaining/releasing. So developers do not have to use ARC at all, they just have to move away from garbage collection.
  • Reply 3 of 76
    asciiascii Posts: 5,936member
    Quote:
    Originally Posted by SpamSandwich View Post

     

    How does this translate into an improvement for the app user? More efficient use of code, meaning a smoother experience for apps? Potentially fewer crashes?




    It means apps will use less maximum memory (lower "high water mark"). Garbage collection lets unused memory build up for a while and then cleans it all up in one go, whereas ARC cleans up as it goes. 

     

    I wonder if this means the garbage collector will be removed (as opposed to deprecated but still there) in OS X 10.11?

  • Reply 4 of 76
    ARC?

    Guess we're gonna have a wet May.
  • Reply 5 of 76
    I'm kind of amazed they didn't make this a requirement a year ago.
  • Reply 6 of 76
    Quote:

    Originally Posted by SolipsismY View Post



    I'm kind of amazed they didn't make this a requirement a year ago.



    Same. A friend and I were talking last night about how Apple needs to do some housecleaning in OS X, get rid of a lot of the legacy cruft again. This is a move in the right direction.

  • Reply 7 of 76
    ascii wrote: »

    It means apps will use less maximum memory (lower "high water mark"). Garbage collection lets unused memory build up for a while and then cleans it all up in one go, whereas ARC cleans up as it goes. 

    I wonder if this means the garbage collector will be removed (as opposed to deprecated but still there) in OS X 10.11?

    Retain/Release is a well-founded feature of ObjC/Cocoa going back to NS 3.3. It isn't garbage collection. ARC just automates it and with blocks does a lot more.
  • Reply 8 of 76

    Cocoa GC was at best half-baked. It was introduced in 10.5, and ARC showed up in 10.6.

  • Reply 9 of 76
    asciiascii Posts: 5,936member
    Quote:

    Originally Posted by mdriftmeyer View Post





    Retain/Release is a well-founded feature of ObjC/Cocoa going back to NS 3.3. It isn't garbage collection. ARC just automates it and with blocks does a lot more.



    Yep, I also used to write ObjC apps using retain/release before GC or ARC were available. In fact manual retain/release is probably a little bit more efficient than ARC as it doesn't have to go searching up the stack to see if it should release a var at the end of a method or not.

  • Reply 10 of 76

    It's about the same as telling someone they have to stop jabbing themselves with a fork.  Having coded an iOS app prior to ARC, I remember how painful it was and how careful you had to be.  

  • Reply 11 of 76
    Quote:

    Originally Posted by ascii View Post

     
    Quote:
    Originally Posted by SpamSandwich View Post

     

    How does this translate into an improvement for the app user? More efficient use of code, meaning a smoother experience for apps? Potentially fewer crashes?




    It means apps will use less maximum memory (lower "high water mark"). Garbage collection lets unused memory build up for a while and then cleans it all up in one go, whereas ARC cleans up as it goes. 

     

    I wonder if this means the garbage collector will be removed (as opposed to deprecated but still there) in OS X 10.11?


     

    If Apple removed garbage collector in the next OS, wouldn't that crash old apps that relied on it?

  • Reply 12 of 76
    It's about the same as telling someone they have to stop jabbing themselves with a fork.  Having coded an iOS app prior to ARC, I remember how painful it was and how careful you had to be.  
    Using simple reference counting was only "painful" to someone with a low enough intelligence not to realize that the thing being banned here is the awful, buggy as hell garbage collector that Apple briefly toyed with about seven or eight years ago, not manual reference counting, which would be hard to distinguish from ARC by looking at a binary anyway, since ARC just compiles down to refcounting code.
  • Reply 13 of 76
    If Apple removed garbage collector in the next OS, wouldn't that crash old apps that relied on it?
    It sure would. However:

    1) Supporting GC apps doesn't just require that the garbage collector be present. It also means that everything an app might link against, including all the libraries and frameworks as well as any plug-ins, all need to be GC-aware. That's got to be a pain in the ass. Also:

    2) This is Apple we're talking about. They haven't cared about backward compatibility for the last decade or so.
  • Reply 14 of 76
    Apple copying again.

    First Android gets ART now Apple copies by introducing ARC. ;)
  • Reply 15 of 76
    ajmasajmas Posts: 597member
    If Apple removed garbage collector in the next OS, wouldn't that crash old apps that relied on it?

    I don't think they can afford to remove it, since people would be up in arms for existing stuff. Hopefully the move will only impact new and maintained stuff.
  • Reply 16 of 76
    dugbugdugbug Posts: 283member
    It's about the same as telling someone they have to stop jabbing themselves with a fork.  Having coded an iOS app prior to ARC, I remember how painful it was and how careful you had to be.  

    This is just them removing gc. ithey could still do it manually aka pre-arc as I understand
  • Reply 17 of 76
    If Apple removed garbage collector in the next OS, wouldn't that crash old apps that relied on it?

    OS X officially supports every public SDK since 10.4.9 (the first Intel SDK) and that's not likely to change anytime soon. As long as that's still the case then your old garbage-collected apps will continue to run.
  • Reply 18 of 76
    nasseraenasserae Posts: 3,167member
    Quote:

    Originally Posted by EricTheHalfBee View Post



    Apple copying again.



    First Android gets ART now Apple copies by introducing ARC. image



    ARC was completed and implemented in 2011.

  • Reply 19 of 76
    Quote:
    Originally Posted by Durandal1707 View Post



    1) Supporting GC apps doesn't just require that the garbage collector be present. It also means that everything an app might link against, including all the libraries and frameworks as well as any plug-ins, all need to be GC-aware. That's got to be a pain in the ass. Also:



    2) This is Apple we're talking about. They haven't cared about backward compatibility for the last decade or so.



    1) That's correct, it's a significant maintenance pain for framework authors.

     

    2) Baloney, Apple works hard to not break existing Mac apps; I have apps from over a decade ago that still work. Much of the time when apps break, the app is doing something wrong. Backward compatibility for hardware and software are not the same. Apple waited a long time after deprecating GC to add this requirement. Weaning app store developers off of GC helps cap the number of apps that can break in the future.

  • Reply 20 of 76
    Quote:



    Originally Posted by ascii View Post

     



    Yep, I also used to write ObjC apps using retain/release before GC or ARC were available. In fact manual retain/release is probably a little bit more efficient than ARC as it doesn't have to go searching up the stack to see if it should release a var at the end of a method or not.


     

    ARC inserts retain/release calls at compile time, so there is no searching the stack at runtime. ARC is generally more efficient than MRR code, because it can discard objects as soon as they are unused. Really tight MRR code can be as fast, but it's hard to get it optimal by hand, whereas with ARC the compiler can handle memory management and optimize the heck out of it.

Sign In or Register to comment.