Solving the mystery of Snow Leopard's shrinking apps
In response to a report earlier this week pointing out that many of the applications in early builds of Mac OS X 10.6 Snow Leopard are dramatically smaller in size, a number of developers have weighed in to explain where all those missing megabytes went.
Bryce C noted that the extra heft in Leopard's apps does indeed come from localization files, which are used to distill all of the text strings and other variables that differ between languages. Depending on the language preference set by the user, the operating system accesses the desired language files and uses them in conjunction with the common application code to simplify developers' work to deploy their apps to worldwide markets.
Inside each application's bundle file in Mac OS X are NIB files, shorthand for the original name of the tool used to create them: NeXTSTEP Interface Builder. NIB files also contain any graphical resources used by the application.
During development, Interface Builder is used to visually arrange the program's interface controls -- from buttons to scroll lists -- which are then mapped to actions. The original XML files used during development are named "designable.nib," but these files are not supposed to ship with the finished application. The final NIB files that are included with the finalized application are much smaller, and can usually be compressed even further.
Running these NIB files through a simple file compression results in dramatic disk savings. Bryce noted that the XML and HTML files stored within the bundle of Leopard's Mail shrink from 289 MB to 96.6 MB with a simple file compression, resulting in a file size comparable to the new Mail delivered in the Snow Leopard beta release.
Apple earlier applied a similar technique to preference .plist files, converting them from plain human readable XML text files into compressed binaries to save space on disk. The added overhead required to compress and uncompress these files in the background as they are read from and written back to disk is insignificant.
While Apple may likely be expanding the use of background file compression to save space in Snow Leopard, today's Mac OS X Leopard is unnecessarily overweight due to an error Apple made when packaging the system, according to a developer who asked to remain anonymous. Leopard apps all contain superfluous designable.nib files that should have been removed in the Golden Master. "Mail alone has around 1400 of these files, taking up almost 200 MB of disk space," he noted.
Other suspected reasons for the dramatic weight reduction included lighter weight, resolution independent vector graphics and the removal of PowerPC code. However, the same developer explained that "most of the artwork in the applications is the same as it was in Leopard. Snow Leopard is, sadly, not much further along in resolution independence than Leopard, at least in the developer preview."
The move to vector graphics may make a small additional impact on tightening up the system, and even graphical interface elements stored as bitmapped art will benefit from the file compression noted above. As for the removal of PowerPC code, developers note that Snow Leopard's applications are still currently being delivered as Universal Binaries anyway, and that removal of that extra code has a very limited impact on file size when compared to the results of compressing large XML and graphics files related to interface localization and the complete removal of any unnecessary development NIB files.
Leopard users tight on disk space can safely delete all of the designable.nib files stored within their apps and use a tool such as Monolingual or Northern Softworks Leopard Cache Cleaner to remove unused foreign language files, resulting in a free weight reduction without the wait.
Bryce C noted that the extra heft in Leopard's apps does indeed come from localization files, which are used to distill all of the text strings and other variables that differ between languages. Depending on the language preference set by the user, the operating system accesses the desired language files and uses them in conjunction with the common application code to simplify developers' work to deploy their apps to worldwide markets.
Inside each application's bundle file in Mac OS X are NIB files, shorthand for the original name of the tool used to create them: NeXTSTEP Interface Builder. NIB files also contain any graphical resources used by the application.
During development, Interface Builder is used to visually arrange the program's interface controls -- from buttons to scroll lists -- which are then mapped to actions. The original XML files used during development are named "designable.nib," but these files are not supposed to ship with the finished application. The final NIB files that are included with the finalized application are much smaller, and can usually be compressed even further.
Running these NIB files through a simple file compression results in dramatic disk savings. Bryce noted that the XML and HTML files stored within the bundle of Leopard's Mail shrink from 289 MB to 96.6 MB with a simple file compression, resulting in a file size comparable to the new Mail delivered in the Snow Leopard beta release.
Apple earlier applied a similar technique to preference .plist files, converting them from plain human readable XML text files into compressed binaries to save space on disk. The added overhead required to compress and uncompress these files in the background as they are read from and written back to disk is insignificant.
While Apple may likely be expanding the use of background file compression to save space in Snow Leopard, today's Mac OS X Leopard is unnecessarily overweight due to an error Apple made when packaging the system, according to a developer who asked to remain anonymous. Leopard apps all contain superfluous designable.nib files that should have been removed in the Golden Master. "Mail alone has around 1400 of these files, taking up almost 200 MB of disk space," he noted.
Other suspected reasons for the dramatic weight reduction included lighter weight, resolution independent vector graphics and the removal of PowerPC code. However, the same developer explained that "most of the artwork in the applications is the same as it was in Leopard. Snow Leopard is, sadly, not much further along in resolution independence than Leopard, at least in the developer preview."
The move to vector graphics may make a small additional impact on tightening up the system, and even graphical interface elements stored as bitmapped art will benefit from the file compression noted above. As for the removal of PowerPC code, developers note that Snow Leopard's applications are still currently being delivered as Universal Binaries anyway, and that removal of that extra code has a very limited impact on file size when compared to the results of compressing large XML and graphics files related to interface localization and the complete removal of any unnecessary development NIB files.
Leopard users tight on disk space can safely delete all of the designable.nib files stored within their apps and use a tool such as Monolingual or Northern Softworks Leopard Cache Cleaner to remove unused foreign language files, resulting in a free weight reduction without the wait.
Comments
Although runtime compression/decompression is good idea. I wonder how it's efficiency compares to the compression option available in NTFS?
I presumably have saved few GBs on my application volume.
I just downloaded monolingual and it is tearing through my files! over 3 gigs freed already. Looks like adobe is a nasty culprit as well. Very cool.
You might wanna check out the read me file, it says to EXCLUDE adobe apps cos they might not work if you remove localisations!
You might wanna check out the read me file, it says to EXCLUDE adobe apps cos they might not work if you remove localisations!
Exactly.
A year ago I foolishly removed all the unused languages and was forced to do a complete re-install of my Adobe apps.
The new .xib files are much easier to use for development, but when it comes to actually shipping an application, for backwards compatibility, you still need a .nib package in your app bundle. Xcode 3 performs this conversion when building your app, and "compiles" a .nib package with a keyedobjects.nib file inside. The keyedobjects.nib file is the only file a shipping application needs to have to function properly.
The compilation step can optionally include a copy of the XML version of the file as well. The designable.nib file is basically a straight copy of the .xib file from your project. This file is necessary if you want to open up the nib and edit it with Interface Builder, but it's not necessary to just run the application. For shipping apps, you'll typically want to turn off the flag that copies the designable.nib file, since it just takes up space and is never used. You might want to include it in some scenarios, such as a debug build you're sending to a localizer, since they'll need to be able to edit the nib file.
The problem is that Xcode 3 is set up by default to copy the designable.nib file into your built app, even for release builds. The result is that many of Apple's apps (as well as third party apps) unknowingly include these files, even though they don't need them. So all that really needs to be done is to change this setting in Xcode so that the built apps don't include the designable.nib files, and that's how you get your hard drive savings, no fancy compression necessary.
I just downloaded monolingual and it is tearing through my files! over 3 gigs freed already. Looks like adobe is a nasty culprit as well. Very cool.
Not until you run an Adobe upgrade that targets those files you removed, then the installer quits half-way through and you're left with an application that doesn't launch. That's my story of using Monolingual and I never will again because of the massive headache it caused.
Well if there were tons of designable.nib files in Leopard that took up space, then Snow Leopard isn't so much revolutionarily lean as Leopard was unnecessarily bloated. Kind of disappointing really.
Kind of like Amazon claiming a retail price that's 50% higher than the manufacturer's own suggested retail price and then listing the Amazon price as saving you 35%, when really they are only saving you just 3%.
Not until you run an Adobe upgrade that targets those files you removed, then the installer quits half-way through and you're left with an application that doesn't launch. That's my story of using Monolingual and I never will again because of the massive headache it caused.
Typical... I have yet to run an Adobe installer that I didn't have to clean up after. How many years has OS X been around and they still haven't figure out how to perform a proper install?
NeXTSTEP didn't bundle their localization structures this way. We [having worked there] didn't bundle our applications via drag n' drop to install or trash an application.
The dynamically loaded nib files, by localization, is not surprising. The executables being twice as large, in some instances, should be a clue they have possibly not just optimized the run-time and executable binaries, but that there is a good chance the .nib file format and what it contains:
http://developer.apple.com/documenta...5344-CH11-SW13
What Goes in a Nib File?
Although the contents of a nib file can vary greatly in theory, in practice, there are usually a handful of standard configurations that developers include. The reason is that most developers use nib files for a very specific purpose: to load user interface items. This is particularly true for Carbon nib files, which can be used to store only user interface components, such as windows and menus. Cocoa nib files offer a little more variety in the types of resources they may contain. When you open a Cocoa nib file, you are likely to see any of the following items at the top level of the nib file:
Some of these objects must be at the top level of the nib file. For example, windows and menus must be at the top level of both Carbon and Cocoa nib files. In addition, controllers and nonvisual objects in Cocoa nib files are almost always at the top level. This is because non-visual objects cannot be embedded inside windows, views, or menus. (Cells and formatters are special because they work in conjunction with a view or control to implement its appearance.) Most other visual objects are situated inside a window or view and do not appear at the top level of the nib file.
I'd suspect that Core Data managed object contexts might have been redesigned, but as has been pointed out, bundle sizes of applications aren't the actual size of the application running.
Wait a second... your telling me all these apps are only smaller because a few nib files were removed
That 20 megapixel Firefox icon has to be rasterized at the color space spec and depth built-into the file attributes and your RAM of course goes through the roof so I doubt most people want to see it.
Typical... I have yet to run an Adobe installer that I didn't have to clean up after. How many years has OS X been around and they still haven't figure out how to perform a proper install?
Yeah, Adobe sucks big-time.
Ironically, Adobe *is* one of the biggest culprits in this kind of bloat. There are literally thousands and thousands of files in a CS3 installation that are completely unnecessary and loaded onto your HD in triplicate or more.
For instance every Adobe product has a "legal" folder with the licence agreements for the product in it. Why something that is never read by anyone needs to be copied to your HD I don't know, but making it worse, is that it's copied *hundreds* of times. The licence agreements are printed in 30 to 40 languages and an identical folder is every folder for every product in the applications folder.
So in order to convey a simple legal licence to the end user, we have hundreds of useless files and folders on the HD, most of which is unreadable by the user. And the support folders for Adobe in the libraries contain hundreds of thousands of files taking up gigabytes of space. All mostly for no reason at all.
Not to mention the four or five applications that they always install in the background that you haven't even agreed to and can't find out what they are even.
I know disk space is cheap these days...but still, why take up all that space unnecessarily?
While I agree that disk space is cheap I look at it this way 14MB will allow for a lot of iTunes media. If the space savings are accurate, which I believe is possible, then us guys trying to get by on a laptop will be very happy.
On another note I suspect that Apple has lots of room to improve the size of libraries and generated code. GCC is continually improving and Apple hasn't been reluctant to improve Objective C. There is big hope that all of Snow Leopards internal improvements lead to streamlined libraries.
This will likely be very good for applications moving forward. The question is just how backwards compatible will Apple be.
Dave
So as an experiment I deleted all of those files. My Applications folder went from 2.3 GB to 500 MB? then shot up to 5 GB. I have no idea what the hell is going on here, but I'll be restoring my backup when I get home.
Sorry but that made me chuckle.