| About | ACP | Buy | Industry Watch | Learning Curve | News | Search | Test | |
Home » Learning Curve
Every Bundle Counts!Deploy your software. Recently there's been more discussion about cleaning universal builds to reclaim disk space. As has already been pointed out this can often be but the tip of the iceberg. Here follow some general tips on how you can successfully deploy your own software and save (sometimes) copious amounts of disk space as well as a real life example of the dramatic results that can be expected. Why Don't Apple Do It?The quick answer to the above is 'but Apple do do it'. Stripping binaries is not what they want or can do: their OS must run on all platforms and in addition support software written for all platforms - sometimes for the wrong platforms. But that's only about the 'universal' aspect of Apple builds anyway - in all other respects Apple engineering represents a yardstick third party vendors should hold themselves to. Why Don't Third Party Do It?Good question, next question. It's perhaps understandable Apple do the best job as they're most intimately acquainted with how the system works, but it's not beyond a third party vendor understanding the methods and the exigencies involved. And it's what they don't do you have to do - if you want to reclaim the disk space they're so graciously wasting on your behalf. Drilling Down!To get at all of the flotsam and jetsam in your applications you have to be able to 'drill down' inside the application bundles - and recursively into further embedded bundles if need be. You can do this in one of several ways.
What You Don't NeedThere are any number of typical elements of an OS X application package that represent 'flotsam and jetsam' - that have nothing to do with the running of the application you just downloaded. PkgInfo This information is also found in the essential file 'Info.plist' and therefore is basically redundant - but for authentically native Cocoa applications only. If you are not sure if you're looking at a real Cocoa application then don't touch it. If you still do about the worst that can happen is you lose your dock icon but don't touch it anyway. If however you know you're looking at a really native OS X application then by all means get rid of it. You just reclaimed 4 KB disk space. pbdevelopment.plist You might be curious as to what it contains, and if you feel the urge then by all means take a peek. It's a straightforward property list file with one key value pair only that archives the disk location of the development project that was used to create your application. As this pertains to the developer computers and not yours you see how irrelevant it is for you. Remove it and you reclaim another 4 KB. NIBs Unfortunately there's only one file in a NIB that's ever used by the running application: objects.nib (or keyedobjects.nib). All the other files can and should be removed - in fact Apple themselves make quite a point of doing this for all their products. It's just that third party vendors either #1) don't know; or #2) don't bother. See for yourself: search /System/Library for any of the other files such as classes.nib, info.nib, or data.dependency. The first two are plain text files used by Interface Builder and the third is a clue to Interface Builder what other so called 'palettes' it needs to load to manage your interface (at edit time only). And yes, if you have the ADC developer tools installed, you will find quite a few of the above - and you should not remove them. [You should not ever muck about in /System/Library at all.] But these files are used for development: they interface developer tools where they're needed - they're not used in third party apps such as the ones you're looking at right now. The classes.nib, info.nib, and data.dependency files each take at least one cluster each on disk. That means every time you remove one of them you reclaim at least another 4 KB of your disk space. As they can be found in every NIB your application has and as the first two are almost always found there, you reclaim at least 8 KB for every NIB in your application. And remember: you need objects.nib (keyedobjects.nib) as that's the code that's run by your application. [Note: NIBs can also contain image files. These files are essential and should not be removed.] lproj If English is your preferred language and the NIBs your application needs are not found directly in Resources, the system will look first for English.lproj or en.lproj. If these are not found the system will then check for your second preference. If it's French the app will now search for French.lproj or fr.lproj. And so forth. The point being that unless you plan to flip your language preferences all the time you're probably going to run your application in a single language. And if you know where those files are located in your application package you can safely move them to Resources and thereafter remove all extraneous lproj files. Check Safari as an example: Apple's web browser has numerous NIBs directly in Resources. It can have others in language specific directories but the point is the system itself will never go down below Resources if it doesn't have to. If you have all your resources directly in Resources you not only save disk space but you help your application load and run marginally faster. Most applications will have at least two NIBs and one localisation directory. Removing classes.nib and info.nib from both and moving the NIBs up to Resources (and removing your now empty localisation directory) saves you 20 KB just like that. [That's because no matter what your trusty Finder tells you those directories do consume disk space like any other file in your system - and again the minimum they can take is 4 KB. Ed.] Image Files Stripping Binaries IYou should always clean your app as well as you can according to the above guidelines before attempting any work on the binaries themselves. When you've got the application bundles whittled down you should archive (zip) the application up and set it away for safekeeping. What you've done up to this point works for any hardware platform - what you do now is hardware specific. [And you should always test your application before proceeding: make sure it still performs according to spec - you might have made a blooper and you want to catch it now instead of later. If the app is functioning correctly, then yes - save your new archive and dispense of the old one.] There are two steps in stripping binaries.
They must be performed in the above order. There are several tools available for step 1, perhaps most notably Monolingual. Be careful when you use the program as you don't want to remove the wrong images. You can also do this manually but with a great number of targets all at once it becomes tedious. You might want to first check and see if your target is in fact a universal ('fat') binary. Drill down to its directory and use the following. /usr/bin/file <target> If you're looking at a fat binary, file will tell you so. The next step (no pun intended) is to strip out the unused binary. There are several methods to do this but one does it the way you really want and the others don't. In all cases you use the program /usr/bin/lipo. lipo <target> -thin <arch> -output <target>.lipo; mv <target>.lipo <target> The 'lipo' extension is arbitrary; you can use any extension you want. The idea is to avoid possible renaming conflicts. You can of course reduce all this to a script as well. lipo $2 -thin $1 -output $2.lipo; mv $2.lipo $2 Where $1 is the architecture you want to use and $2 is your target. [The architecture you want to use will mostly be either 'ppc' or 'i386'.] So if your script were called 'unilipo' a typical invocation would look like one of the following. unilipo ppc <target> Where '<target>' again is the binary you want to perform the lipo on. Where is this binary located? Your application bundle may have several - you need to keep 'heads up' and 'eyes open' for this phase. The primary binary will be in a 'MacOS' directory under 'Contents' but there can be other binaries as well embedded in frameworks and plugins and whatnot inside your application bundle in the Resources directory. And any file marked with the eXecutable bits (aside from legacy which often have all bits set as they didn't use the present POSIX paradigm) may be a binary you'd want to strip. Run file on each of the suspects and proceed accordingly. A universal binary will normally be about twice the size of a single architecture binary. So if your universal binary is 500 KB you'll reclaim about 250 KB. And so forth. Stripping Binaries IIBut that's only phase one; phase two can often have more dramatic results. For a reason unknown to most platform observers an alarming number of third party vendors ship so called 'debug binaries' - these binaries, several times the size they need to be, are chock full of - for you - totally useless information. This information is to be used (sparingly) during software development to track down bugs and other unforeseen occurrences prior to declaring a program fit to ship and creating a good 'install' build. Apple's development environments of course see the developer can set things as needed both for the development stage and finally the deployment stage. If your third party vendor ships you a debug image there will be vestiges of junk left inside the binary no matter what you do but stripping away the most of it will still save you incredible amounts of disk space. To do this you need the ADC developer tools - in particular pbxcp found at /Developer/Tools. This program works a funky way - and here's a script that will make it work. /Developer/Tools/pbxcp -resolve-src-symlinks -strip-debug-symbols <target> ..; mv ../<target> . Where again '<target>' is the binary you want to strip. pbxcp assumes you're moving a non-stripped binary to another directory; as it copies the binary it strips it. To get your binary back where it belongs you simply move it back. You can synthesize all the above into a script you can invoke from your command line. /Developer/Tools/pbxcp -resolve-src-symlinks -strip-debug-symbols $1 ..; mv ../$1 . Calling this script 'adcstrip' your command line might look like the following. adcstrip <target> That's all you'd need. The results from stripping debug info are often far greater than from merely removing an unused binary image. To see how much - read on. A Real Life ExampleTaking a generic Cocoa document based application and seeing what's there to be weeded out before the 'universal strip' can be instructive.
Which is pretty incriminating. The original bundle took 136321 bytes/336 blocks; after your work on it all you have left is 26993 bytes/80 blocks. The results are nothing less than dramatic - from an original 168 KB you're down to 40 KB. You just reclaimed 128 KB - which is over three times what remains. Nearly 80% of the bundle was pure junk. And were this only a question of stripping a universal binary (with all else already taken care of) the difference would have been in the 20 KB range rather than the above figure of 128 KB, over six times that. And of course the issues compound when application bundles have further bundles within - frameworks and plugins each with their own binaries and resources that in turn might contain further bundles in need of similar cleaning and each with their own NIBs in need of trimming. The above example is only the merest of examples of how dramatic the differences can be - between what you need and what you get. A relevant question is: are there any tools that automate this process? And the answer has to be 'not up to now there aren't'. Until something comes along to save users from these issues it's still all up to that developer you trust. See Also |
| About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack |
| Copyright © Rixstep. All rights reserved. |