How to use the Mac OS X application optimizer.
Applimizer is the Mac OS X application optimizer. It optimizes applications by reducing their size using a number of different strategies, including the following:
The usage model is best explained by means of a brief tutorial.
In the Finder, double-click the Applimizer icon (NB. It might also go under the name Applimiser). Applimizer starts by presenting its main window. It is structured into two sections. At the top, space has been reserved for guidance tips which inform you about what you can do with Applimizer. Below that, you see statistical information on the applications that you have analyzed (none yet). There is both an summary and an individual view.
Before you can optimize an application, you must first analyze it. As suggested by the "Getting started" message, choose Open from the File menu to open - that is analyze - an application. A standard open window appears. Select the application that you wish to optimize.
Hint: You can shift-click several applications if you wish to open more than just one at the same time.
Note on Access Permissions
Remember that Applimizer does not modify applications for which you do not have sufficient access permissions. Unless you have an administrator account, you are only able to optimize those that you own.
You can check that in the Finder: open an application's Info window; in the Ownership & Permissions section, you require Read & Write access.
NB. You can still analyze all applications. Where applicable, Applimizer notifies you and allows you to preview the optimization results.
Once you have chosen your application and dismissed the open window, the analysis process begins. You can follow the progress of this step in the progress dialog that appears. Once the analysis step is done, the main window may look like this:

When you select the individual view tab, you can review the savings for each of the applications one by one. The Ignore or Optimize buttons act only on the shown application. Use the arrow buttons to view a different application.
At this point, it is a good idea to review which of the optimization algorithms are turned on. Press the Options button to open the optimization options window.

In the options window you can turn the individual optimization algorithms on or off. As you change a setting, the statistical information in the main window is updated.
For more information on the algorithms see the section on optimization techniques.
Now you are ready to optimize an application. If you have analyzed more than one application, you have the choice to optimize all at once, or to optimize each application in turn. You simply press one of the corresponding buttons in one of the statistical views in the main window.
In case you wish not to optimize, you can press the one of the Ignore buttons, or you can simply quit from Applimizer.
Now that the optimization is finished, the main window reverts to its default state. You can repeat the above steps to optimize more applications, or you can quit from Applimizer.
In version 1.4 of Applimizer, it is possible to scan a folder hierarchy for all the applications that it contains and to analyze all of them in one simple step.
To do that, choose "Open All in Directory" from the File menu and navigate to the folder whose applications you wish to analyze. However, beware that this can take a little longer.
By default, Applimizer also optimizes any type of embedded bundles using the same options as for the application that contains it. The statistics that you see for an application already contains this information.
There is an option to make a backup copy of any application that is about to be optimized. You enable this option in the preferences window.
Applimizer makes use of the following optimization techniques:
A typical Mac OS X application comes with a collection of embedded language localization files. This makes it possible to run the same application under different languages. Depending on your settings in the International pane of the Systems Preferences, an application presents itself and all its windows in one of the languages listed there, provided of course that a corresponding language localization exists in the application.
Quite often, an applications contains a number of language localization files that you are never likely to use.
Safari (see figure above), for instance, comes by default with the following languages embedded: Danish, Dutch, English, Finish, French, German, Italian, Japanese, Korean, Norwegian, Spanish, Swedish, Traditional Chinese, and Simplified Chinese.
Knowing that you don't need most of these languages, you can safely remove all but those that you do need. In the example of the Safari, if you only ever use it in English, then you can safely remove 7.5 MB worth of files.
Applimizer uses the languages that you have defined in the International pane of your System Preferences as the basis for its optimization. You can modify the list of preferred languages in the options window.
NB. In the main window, the languages that Applimizer removes are listed in red color; the languages that remain untouched are those in black.
As an additional option, Applimizer offers the possibility to exclude the default development language of an application from this optimization, that is to keep it. NB. The development language is the one that is underlined in the list of languages in the main window.
A Mac OS X application that is not a Carbon application can still run with Mac OS 9 (or the Classic environment) if it contains Classic code. This Classic code is stored separately from the Mac OS X code.
If you know that you never run an application in the Classic environment, then you can safely remove the Classic code that it contains. The application remains fully functional with Mac OS X.
Files used by the Help Viewer are embedded in applications in form of Hypertext Markup Language (HTML) files. These files contain many empty constructs, or indeed internal comments that are never shown in the Help Viewer.
Based on the proven technology of htmlXPress, most of these "invisible" constructs can be safely removed from the HTML source code without changing the appearance of these files in Help Viewer.
As an example of this technology, feel free to view the source of this page in your browser, for example in Safari, choose View Source from the View menu. Compare this to any other page on the Internet (not a page from the tredje design as all of these are optimized).
NB. Since version 1.5, HTML optimization also handles CSS files.
Cascading style sheets (CSS) are used to separate the look and feel of an HTML page from its content. The style definitions in the CSS files can also be compressed by removing redundant white-space and developer comments.
NB. This technique is new since version 1.5 and is executed as part of the HTML optimization.
String files contain texts that an application uses, for instance warning message texts. However, the developers are encouraged to include also comments to explain the usage of each string, thus making it easier for translators to work on these files. However, the reader does not need these comments and will in fact never see them. They can therefore be safely removed.
Tests indicate that this is significantly more effective than HTML optimization because a typical string file can contain hundreds of comments.
NB. This technique is new since version 1.1 of Applimizer. From version 1.3 onwards, Applimizer also removes redundant string pairs.
Cocoa applications contain a number of NIB files. These files define all the windows and objects that an application uses in its graphical user interface. Similar to the HTML optimization, the model definitions in these files contain a large number of redundant white-space characters which Applimizer removes.
NB. This technique is new since version 1.3 of Applimizer.
When you browse folders in the Finder, it stores your view preferences in temporary files named ".DS_Store". As these files contain information on how to view a folder, they are not relevant to any application other than the Finder.
Normally, these Finder files are not part of an application bundle. However, if you browse an application in the Finder, the Finder adds these files just as it does for ordinary folders. The application itself has no use of these files and one can therefore safely remove them again. This is exactly what Applimizer can do for you.
NB. One can browse the contents of a Mac OS X application through control-clicking of the icon in the Finder. From the shortcut menu that appears, you choose Show Package Contents. This opens a new window where you can browse though the application bundle.
Attention!
This optimization technique may corrupt applications. Do not use this unless you are sure that the application contains the correct safeguards (see below).
Shareware applications may contain additional resources for the handling of online purchase transactions using the services a third party. eSellerate offers one such service. For it to work, the eSellerate system relies on the installation of a purchasing engine, the eSellerateEngine. On Mac OS X, this engine must be installed before the purchasing services can be used. It is installed in the folder /Library/Application Support/MindVision.
From the perspective of the shareware author, you cannot expect that this engine is already installed. Therefore, a compressed form of the engine is added to the application bundle and before the eSellerate services are used, the engine is first installed.
Once installed, the shareware application does no longer need to keep its internal compressed copy of the engine. There is thus a potential to free about 300 KB (kilobyte) of disk space. However, whether or not it can be removed depends on how the application is designed.
The problem is, if the function eSellerate_InstallEngine() is called in the absence of the engine copy, the application crashes. To prevent this, shareware authors are advised to implement the following installation example.
#define EngineInstallPath \
@"/Library/Application Support/MindVision/eSellerateEngine (Carbon)"
eSellerate_ErrorCode myInstallEngine()
{
eSellerate_ErrorCode errCode = eSellerate_NOENGINE;
FSRef fsRef;
NSString *path;
NSURL *urlRef;
ResFileRefNum refNum;
path = [[NSBundle mainBundle] pathForResource:@"eSellerateEngine_DataFork"
ofType:@"rsrc"];
urlRef = [[NSURL alloc] initFileURLWithPath:
path ? path : EngineInstallPath];
if ( CFURLGetFSRef( (CFURLRef) urlRef, &fsRef ) )
{
if ( FSOpenResourceFile( &fsRef, NULL, NULL, fsRdPerm, &refNum )
== noErr )
{
errCode = path ? eSellerate_InstallEngine() : eSellerate_SUCCESS;
CloseResFile( refNum );
}
}
[urlRef release];
return errCode;
}Most likely, you do not know whether a shareware application was implemented with this safeguard. This optimization step is therefore not turned on by default. If you still do wish to run this optimization, the following tips are advisable:
To my knowledge, the following applications can handle the removal of the internal copy of the eSellerateEngine and can therefore optimized (this is not a complete list):
If you knew of any other applications that qualify, feel free to contact me.
1 Introduction
2 Tutorial
2.1 Open Applimizer
2.2 Analyze an Application
2.3 View the Individual Statistics
2.4 Review the Optimization Settings
2.5 Run the Optimization
2.6 Repeat or Quit
3 Additional Commands
3.1 Open All Application in a Folder
3.2 Handling Embedded Plug-ins, Frameworks or Bundles
3.3 Making a Backup
4 Optimization Techniques
4.1 Language De-Localization
4.2 Removal of Classic Code
4.3 HTML Optimization
4.4 CSS Optimization
4.5 String File Optimization
4.6 User Interface File Optimization
4.7 Optimization of Finder Files
4.8 Removal of eSellerateEngine Resources
4.8.1 Known Applications for which the eSellerateEngine can be removed