[Update:] I may be wrong on this one: the WWDC Keynote slide I’m talking about mentions ‘Automatic Reference Counting’, which technically is not the same as Garbage Collection, but nevertheless takes away the burden and responsibility of manual memory management from the developer. So the hooray is still valid, even if the technical implementation may not be Garbage Collection. For more details make sure you read the comments to this post[/Update]
Apple’s Keynote on the WWDC yesterday was again a huge media event, and they showed a lot of interesting new stuff that’s neither rocket science nor revolutionary on its own, but the level of integration into their product portfolio and their perspective on things that should simply work is great.
My personal highlight of the keynote was a very little but probably very influential tiny detail: iOS5 will have Garbage Collection.
Up to now, if you programmed in Objective-C for the Mac, and used Garbage Collection, you couldn’t use the same body of code for the iPhone or the iPad, because iOS required you to manage your memory by hand. Not that it was too hard, but it was a difference. So you either had to maintain two versions of your code, or you had to ignore Garbage Collection for your Mac version.
Now the only major difference between a Mac and an iPad application is the GUI framework (there are, of course, still others as well). This is easy to overcome, because you simply redraw your app in the IB for the other platform, and still maintain a single body of backend code.
And I guess even this difference will go away pretty soon, now that Mac OS X Lion adapts many principles from iOS.
It seems we’re on our path to the unified operating system and development environment for all platforms, from Desktop to Tablet PC and SmartPhone or Car Entertainment units. The gap between a MacBook Air and an iPad isn’t very broad anymore. Imagine a Netbook with a MultiTouch Screen and you have the unit for all purposes. Add to that the fact that there’s no real difference in APIs between platforms, we can imagine a lot of cool scenarios for our software.
So this is probably the answer to the question I posted a few weeks ago.
Joachims Small World 
11 responses to “My WWDC highlight: iOS5 will have Garbage Collection”
[…] decided to man up and actually just build garbage collection into iOS and supply a service to the device that they should have done a long time […]
LikeLike
@Thibault I was pretty happy with manual memory management too, but after reading David Chisnall’s post on automatic GC in Étoilé and GNUStep I’m now convinced that having the runtime take care of it is the way to go http://etoileos.com/news/archive/2011/05/26/1933/
LikeLike
Very interesting read, thank you 🙂
LikeLike
Steve,
Great article you refer to! o it seems GC is not evil 😉
LikeLike
(creating new comment as I cannot reply to yours)
I totally understand what you’re saying. I’m not saying I’m better than the machine either, I agree 90% of the time the machine will manage memory better than I would.
I’m just saying I prefer to do it myself, because I actually like to do it, and I also like to know what is going on. I dislike having to guess what the runtime/gc/whatever is doing behind your back that might not be compatible with what you’re trying to do.
Also, I find it easier to find leaks when you manage memory yourself rather than when you have a GC environment. Not that the GC will leak, it will just “not release” an object that could potentially be linked with another one — and those could be really hard to find.
All in all, I’m not saying manual memory management is better than GC, or the contrary. Both have their own up- and downsides.
However, even though ARC seems pretty classy, reading the documentation for it seems to reveal some edgy-stuff that might create weird bugs (if you have access to the doc, read “ARC Introduces New Lifetime Qualifiers” in the ARC release notes — the errors they show might occur seem hard to debug than a simple leak / over-release).
LikeLike
Mmmh, I have not heard of any Garbage Collector. All I’ve heard of is the ARC (Automatic Retain Count), which is a compiler feature which basically inserts -retain and -release calls where needed, without you having to worry about it.
In the end it’s almost the same (you don’t have to worry about memory), but it is very different in behavior et possibilities.
LikeLike
Well, you may be right. When I read “Automatic Reference Counting” I just assumed this means Garbage Collection. But it could mean “cheaper tricks” as well 😉
As long as it means I can share my “business code” between an OS X and an iOS projects, I probably just don’t care 😉
LikeLike
Well, in fact, it’s totally different :).
GC is a mechanism which, at runtimes, analyses all allocated objects and releases all thoses that are not used by any other.
ARC, on the other hand, is a compiler feature. It analyses your code and basically places -retain and -release calls wherever they should be placed. Once compiled, the code still uses the -retain / -release mechanism (no GC) — it’s just that the compiler did it for you.
Seeing the doc on ARC, it seems highly probable that ARC compiled code will be compatible with GC runtime.
LikeLike
it works completely different, but for the developer it just means “I don’t care”. Having a Smalltalk background, that’s exactly the way I like it 😉
LikeLike
It is true that, for the devs, it means “do not pay attention to memory”. It still think it’s a little “harder” to use than a GC (especially with blocks), but it still better than many things for those who dislike memory management.
I personally prefer to manage memory myself though, but at least I have the choice 🙂
LikeLike
well, the way you formulate it, it sounds a bit negative 😉
Not having to care about memory means that you have a complete set of potential problems you can ignore. This is what makes languages like Smalltalk so attractive: forget about technical stuff where it can be done by the machine. Assuming that you, the programmer, will do much better than the machine, is a big mistake in a majority of cases. It’s dangerous to believe that you can do better, especially if you work in bigger teams. When it comes to large projects, you can be sure that someone will have no idea what they are doing, and they will break the system in all kinds of ways.
I don’t know your background, so I am not saying *you* can’t do better, but knowing myself I have a lot of confidence in this argument 😉
As long as I am not handling extremely large objects, I really appreciate the fact that my Smalltalk VM will take care of memory and I can live with it releasing memory a bit later than I would or probably even letting a few instances linger around for too long, as long as it doesn’t kill objects I still need. The same is true for the Objective-C runtime. I like GC or any other automatism for memory management, because I can concentrate on more important stuff of my application.
LikeLike