Solving the mystery of Snow Leopard's shrinking apps

[AppleInsider]

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.

[ View this article at AppleInsider.com ]

[syklee26]

so is smaller size mean faster running?

[ltcommander.data]

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.

Although runtime compression/decompression is good idea. I wonder how it's efficiency compares to the compression option available in NTFS?

[sausage&Onion]

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.

[guest]

I found 533 designable.nib files, all in all 47.8MB. Not really as much as advertised. You guys really sure I can just delete those?

[Chandana]

Well, this is not really revolutionery. In fact Xslimmer and few other applications already does this in Leopard. If you try that you'd be amazed by how much garbage you have dumped on your (paid) mac's hard drive space without ever knowing that,

I presumably have saved few GBs on my application volume.

[Kevinneal]

Originally Posted by sausage&Onion

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!

[davebarnes]

Originally Posted by Kevinneal

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.

[bewebste]

The designable.nib file isn't necessary at all in a shipping product. With Interface Builder 3, there is a new XML format for nib files, which are now stored as .xib files. These XML files are only used for development, and are a single file as opposed to the old .nib packages, which would often cause problems with source control systems such as Subversion (e.g. replace one nib package with another and you wipe out the .svn directory contained within).

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.

[crees!]

Originally Posted by sausage&Onion

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.

[Wiggin]

Originally Posted by ltcommander.data

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%.

[bobertoq]

Wait a second... your telling me all these apps are only smaller because a few nib files were removed that's it? I have always been saying they couldn't provide such a big update in a dot update, but... ehh I just hope there is more to come. Making apps monolingual (or bilingual for those who need it....) removing PPC code, and using vector graphics would be pretty exciting. I love vector graphics. Does anyone wanna see my 20 megapixel Firefox icon?

[Wiggin]

Originally Posted by crees!

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?

[TheCrow]

VERY interesting. From the Get Info dialog, I removed all of Mail's languages except English. Then I ran a terminal script to remove all of the designable.nib files from Mail.app. My Mail app is now 14.3 MB, and works great. Impressive space savings. If Snow Leopard does some file compression as well, the file sizes could be significantly improved. I know disk space is cheap these days...but still, why take up all that space unnecessarily?

[mdriftmeyer]

The point of the size of these application bundles is due to the design by application bundle.

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:

• Window resources
• Menu resources (both menu bars and individual menus)
• Views
• Formatter objects
• Cocoa controller objects (array controllers, object controllers, and so on)
• Core Data managed object contexts
• Program-specific custom objects
• The Cocoa proxy objects

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.

[mdriftmeyer]

Originally Posted by bobertoq

Wait a second... your telling me all these apps are only smaller because a few nib files were removed that's it? I have always been saying they couldn't provide such a big update in a dot update, but... ehh I just hope there is more to come. Making apps monolingual (or bilingual for those who need it....) removing PPC code, and using vector graphics would be pretty exciting. I love vector graphics. Does anyone wanna see my 20 megapixel Firefox icon?

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.

[Virgil-TB2]

Originally Posted by Wiggin

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.

[wizard69]

Originally Posted by TheCrow

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

[Ringo]

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.

[Ireland]

Originally Posted by Ringo

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.

[PG4G]

Make sure you dumped the files from your trash or they won't disappear and your restore may have been for nothing

[physguy]

I found all designer.nib file on my disk (sudo find /* -name designer.nib) and added up the sizes - Just over 600MB.

[g.money]

Originally Posted by TheCrow

VERY interesting. From the Get Info dialog, I removed all of Mail's languages except English. Then I ran a terminal script to remove all of the designable.nib files from Mail.app. My Mail app is now 14.3 MB, and works great. Impressive space savings. If Snow Leopard does some file compression as well, the file sizes could be significantly improved. I know disk space is cheap these days...but still, why take up all that space unnecessarily?

wow. i just did the same strategy for deleting localizations and cleared 1.3GB of space! amazing. i felt much more comfortable doing it via get info than monolingual.

[Stormchild]

How is this a mystery? It's been obvious all along that the apps in 10.6 are smaller due to getting rid of non-essential localization files (something many of us have already been doing for years). The fact that Snow Leopard is going to be Intel-only will also allow removal of PPC code. From what I've heard that hasn't been done yet in the developer preview, but no doubt it will shrink things down further.

[Kickaha]

Originally Posted by Stormchild

How is this a mystery? It's been obvious all along that the apps in 10.6 are smaller due to getting rid of non-essential localization files (something many of us have already been doing for years). The fact that Snow Leopard is going to be Intel-only will also allow removal of PPC code. From what I've heard that hasn't been done yet in the developer preview, but no doubt it will shrink things down further.

Snow Leopard *may* be Intel only. May.

And, as discussed above, the actual binary executables are generally a small fraction of the total disk space used by an app.

Further yes, but only a % point or few.

[gastroboy]

It would seem that the credit for any improvements in Snow Leopard are more to Apple stopping bad practices than inventing new good ones.

Now if only they'd do the same to the GUI. Starting with Finder, the Dock and Spotlight.

[dvh]

Just deleting the superfluous language files in Leopard Safari 3.1.1 drops the package size from 60+ meg to 9.2 meg.

Also, same problem with Adobe apps. Don't use Monolingual. Adobe updaters stop mid-update if the original installation is modified. Only option is to reinstall from scratch.

[emulator]

Originally Posted by syklee26

so is smaller size mean faster running?

exactly. this may be useful to save space on the iphone, but on computers? people use 500 GB HDs or much more. HD prices fall almost as fast as memory does. so if the apps are not faster that I doubt, this 'feature' does not make much difference.

[TheMadMilkman]

Originally Posted by emulator

exactly. this may be useful to save space on the iphone, but on computers? people use 500 GB HDs or much more. HD prices fall almost as fast as memory does. so if the apps are not faster that I doubt, this 'feature' does not make much difference.

It does when you move to solid state drives. Even if the drives were the same size, more open space = more space for rotating writes = longer drive life.

[ouragan]

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.

Great article! Thanks for the reference to Monolingual or Leopard Cache Cleaner.

It's great to have an article which describes a problem, but goes the additional step of including the solution. Great work! Thanks to the author.

[sapporobaby]

Originally Posted by g.money

wow. i just did the same strategy for deleting localizations and cleared 1.3GB of space! amazing. i felt much more comfortable doing it via get info than monolingual.

Hi g.money. I have heard of get info ( I think), what is it exactly and does it remove all the localization files.

[eAi]

You suggest binary plists have to be decompressed. I'd say you're wrong, and that binary plists are probably faster than xml plists as they can be read straight in without going through a full XML parser.

[gastroboy]

Originally Posted by TheMadMilkman

It does when you move to solid state drives. Even if the drives were the same size, more open space = more space for rotating writes = longer drive life.

Is there any information on the life of flash memory. This is going to become very cogent in the near future. I am already holding a lot of pre-backup material on large capacity USB flash drives.

You seem to be saying it is only good for a certain number of wipes and rewrites. Exactly what sort of practical storage life do these thing have?

[Ringo]

Originally Posted by PG4G

Make sure you dumped the files from your trash or they won't disappear and your restore may have been for nothing

They were deleted by the rm command, so I'm quite certain they're gone.

[hypoluxa]

Originally Posted by Chandana

Well, this is not really revolutionery. In fact Xslimmer and few other applications already does this in Leopard. If you try that you'd be amazed by how much garbage you have dumped on your (paid) mac's hard drive space without ever knowing that,

I presumably have saved few GBs on my application volume.

Same here! XSlimmer rocks!

[eAi]

Originally Posted by gastroboy

Is there any information on the life of flash memory. This is going to become very cogent in the near future. I am already holding a lot of pre-backup material on large capacity USB flash drives.

You seem to be saying it is only good for a certain number of wipes and rewrites. Exactly what sort of practical storage life do these thing have?

With most flash memory it's said that each block can be written 100,000+ times. The memory uses wear levelling so that blocks are all 'worn down' at roughly the same speed. How that actually works in real life depends very much on the application. If you were to write backups to flash every day and fill up the card, in theory you'd be able to do that 100,000+ times. You may have issues if you write a lot of small files very often - flash has to blank an entire block each time it writes, so small files are inefficient in this sense as many unused bytes are 'worn down' even though they contained no data before.

See http://en.wikipedia.org/wiki/Flash_memory#Limitations

[djdj]

To those of you deleting files randomly from your computer:

When you start to do things like remove .NIB files, extraneous language files, Power PC code, etc., you are likely breaking the ability for Apple Software Update to detect and install product updates.

After deleting these files, the applications that they are attached to are not longer recognizable, and can't be patched by ASU.

I'd say don't do it, unless you're prepared to manually check for and download the full installation packages for any OS updates from Apple.

[Keyz316]

I haven't tried myself, but I'd recommend caution in using Monolingual. Having read this topic I looked it up and came across a variety of warnings to use it only with caution or not at all (e.g. can totally break your system). You may want to update this post with a warning.

Info:
http://osx.iusethis.com/app/monolingual
http://www.versiontracker.com/dyn/moreinfo/macosx/13031

[Slewis]

Null.

[Slewis]

Null.