Apple has announced on its developer site that apps submitted to the Mac App Store starting on May 1st will no longer be allowed to incorporate garbage collection, which was deprecated in OS X 10.8. Instead, developers will be required to switch to ARC, Automatic Reference Counting, which was introduced in 10.7.
This change affects both new apps and updates to existing ones. Developers who need to make the switch to ARC can do so using the migration utility in Xcode. Apple also has a reference document to help make the transition.
FTC: We use income earning auto affiliate links. More.
You’re reading 9to5Mac — experts who break news about Apple and its surrounding ecosystem, day after day. Be sure to check out our homepage for all the latest news, and follow 9to5Mac on Twitter, Facebook, and LinkedIn to stay in the loop. Don’t know where to start? Check out our exclusive stories, reviews, how-tos, and subscribe to our YouTube channel
Does this mean no more 10.6 apps?
No. But it does mean that Mac app store apps need to use modern, efficient techniques if they are to be sold.
Can someone please explain me what this means? Sorry, this might perhaps be a dumb question, but I’m not a developer ;) Still, I find it quite interesting how Apple pushes the developer community into the future. I like that about the Mac App Store model, Apple defines the track of the platform and the pace of development.
I’ll give this a shot. While a computer program runs, sometimes it will need to dynamically allocate memory to store a newly created object. Imagine you have an email client that is constantly running and you decide to start composing a draft of a new email. The email client would need to dynamically allocate memory for this newly created draft you’re working on. Say you then change your mind and decide to discard the draft. Traditionally the programmer would need to write code to ensure the program always deallocates that memory since it’s then no longer needed. That would free the memory to be used elsewhere in the system. If the programmer fails to ensure this, that memory will typically remain tied up and unable to be used by the rest of the system until the program terminates. Imagine this process being repeated several times while the email client is running, it’ll continue to effectively gobble up and waste more and more memory, leaving less and less memory available for the rest of the system and gradually bogging it down.
Garbage collection is a form of automatic memory management. A process that runs in the background known as a “garbage collector” periodically looks for such tied up memory that isn’t being used (“garbage”) and frees it so that it can be used again. This relieves the programmer from having to ensure the program manually does this and keeps programs from accumulating a bunch of wasted memory (“garbage”). Apple added such a feature to version 2.0 of the Objective-C language.
Automatic Reference Counting is another form of automatic memory management but works differently from garbage collection. When memory is dynamically allocated for an object, the program is able to keep a handle or a “reference” to that object in memory. In fact it can have multiple such references to it from various areas of the program. Automatic Reference Counting (ARC) automatically keeps track of the number of references to an object. As areas of the program no longer need to reference an object, they effectively remove their references to it. When the number of references to an object reaches 0, the object is automatically destroyed and the memory is freed up for use in other parts of the system. Apple introduced this feature to Objective-C in 2011 and also built it into Swift.
Hope that makes sense.
I used to develop back when we had to manage memory ourselves. What a hassle that was when you missed something and had to debug the gradually diminishing memory.
Wow! You are awesome! I couldn’t have asked for a better way to describe the difference between garbage collection and ARC. Now even I understand what’s happening after May 1st.
thanks for the clean and simple explanation. i have a doubt here. can you please explain me the advantage of ARC over garbage collector.
Karthik, the process of garbage collection runs periodically. When it does, it freezes up the program for a tiny bit of time so that it can work on its memory. As you can imagine, this can become a problem. ARC deallocates the memory the instant it’s not needed anymore. It’s a more deterministic process that doesn’t freeze up the application in unexpected moments.
The advantage of ARC over garbage collection – ARC memory management is handled at compile time, so that when the app runs, the objects are deallocated exactly when their retain count reaches 0, with the retain/release statements added in automatically by the compiler. Garbage collection on the other hand uses up CPU to figure out what can be released, so it’s not as memory efficient (dead objects hang out longer) and CPU intensive.
here is a detailed (though outdated – before ARC was unveiled write up about it)
http://cocoasamurai.blogspot.co.il/2010/12/objective-c-memory-management-garbage.html
good riddance garbage collection hello arc
Should be a pretty easy transition given that I know very few developers who actually ended up using the garbage collection when it was provided since garbage collection was never available on iOS which meant if it was used then you’d have a code base incompatible with iOS. It’ll be interesting to see how much of the OS X code base is now making use of ARC.
I think Apple must do something to bring more developers to OS X App Store. The one on iOS is full of cool apps and games, but on OS X it’s so miserable. Many developers don’t publish their apps there because of very strict rules and obligatory use of Sandboxing which limits majority of desktop apps. Even Windows Store has more apps…
Such as 50 fake copies of VLC.
Apple is being more strict with app developers but the main memory problem of my soon-to-be-replaced 4Gb Ram MacBook Pro is… Safari itself.
Safari manages memory pretty poorly, IMHO.