Joachim Mårtensson: The changes between the 32-bit and 64-bit Objective-C runtime are documented in http://developer.apple.com/leopard/devcenter/docs/releasenotes/Cocoa/RN-ObjectiveC/index.html (ADC free account login required).
Basically, 32-bit Objective-C classes store instance variables (ivars) in something close to a struct somewhere in its own class layout (which is also a struct - `id` is the name for a struct whose first field is an isa of type Class). You can use the deprecated @defs keyword to recreate the ivars inline in another struct if you's like (and you probably don't). This means that the size of the direct object varies depending on how many ivars you have.
With the 64-bit Objective-C runtime they're doing changes they've liked to do for all these years on the 32-bit runtime but can't do because it would break binary compatibility. One of those changes are "non-fragile ivars" which means that they're instead stored in another opaque container, and that means that the size of the object is instead constant, leading to better binary compatibility.
For example, if you make a framework with a class that has one ivar, and compile a 64-bit version of it, and an application uses that framework, and you then put out a new version with identical API but two new ivars inside that class, and you swap the old framework with the new framework, Everything Will Just Work.
by Jesper — Oct 28
Basically, 32-bit Objective-C classes store instance variables (ivars) in something close to a struct somewhere in its own class layout (which is also a struct - `id` is the name for a struct whose first field is an isa of type Class). You can use the deprecated @defs keyword to recreate the ivars inline in another struct if you's like (and you probably don't). This means that the size of the direct object varies depending on how many ivars you have.
With the 64-bit Objective-C runtime they're doing changes they've liked to do for all these years on the 32-bit runtime but can't do because it would break binary compatibility. One of those changes are "non-fragile ivars" which means that they're instead stored in another opaque container, and that means that the size of the object is instead constant, leading to better binary compatibility.
For example, if you make a framework with a class that has one ivar, and compile a 64-bit version of it, and an application uses that framework, and you then put out a new version with identical API but two new ivars inside that class, and you swap the old framework with the new framework, Everything Will Just Work.