Für Apple Softwareentwickler

VonAntwort von sierra 19.09.07 23:12 Uhr19. September 2007 23:12 UhrMittwoch, 19. September 2007 um 23:12 Uhr19.09.07 um 23:12 UhrMittwoch, 19. September 2007 um 23:12 Uhr

Wie spart man mindestens 30 % der Filegrösse ein - mangels gutem Apple Support.

Der ehemalige NeXT Entwickler Rixstep hat sich auf die Socken gemacht und zeigt wies geht.

http://rixstep.com/2/20070306,00.shtml

http://dev.lipidity.com/tutorial/cleaning-apps-mac-os-x

About | Buy the Software | Forum | Industry Watch | Learning Curve | Newsletters | Products 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.

Get a decent file manager such as this or this. [Although if you choose the latter you’ll waste the first few hours cleaning that one instead of the bundle you originally planned on cleaning. Ed.] Get to a command line and stay there. Terminal (or the equivalent) will show you what you really have on disk and you need to see that. You might use a command line for other purposes anyway. Tell yourself ‘Finder’s spatial - and the best thing since sliced bread’ and get used to ctrl-clicking for ‘Show Package Contents’ all the time. The overview won’t be as good and you’ll have difficulties integrating with the command line but with a bit of perseverance (and perhaps several weeks arduous labour) you’ll make it. What You Don’t Need

There 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 is an eight byte file that consumes four kilobytes on disk because of the clustering of your file system. It contains but a creator code and a file type, each four bytes in length.

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 Why this file is ever created is a mystery but it’s not created on real ‘install’ builds. Unfortunately too few third party vendors seem to know how to create these install builds. If you find this file inside your application package, just remove it.

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 NIBs - NeXTSTEP Interface Builder files - are a chapter unto themselves. For starters they’re not files at all (but may appear to be - especially if the file manager you’re stuck with is Finder). They’re directories and in turn contain files that are used by your application at runtime.

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.

…