The Vikings left their trash on the ground - Mac developers are stuffing theirs into their apps.
We’ve heard the excuses and listened to the complaints; the amount of junk shipped in third-party applications just doesn’t seem to change. If anything, it’s getting worse. Just because users may not realise how much bloat they’re getting along with the app, doesn’t change the fact that it’s bloat. Unnecessary junk.
Finder info, .DS_Store files, resource forks, debug symbols… They do nothing for the user short of wasting disk space. For the developer, extra bandwidth costs. Do people not realise this is a problem, or are they just too lazy to act? Either way, the solution is simple.
You can clean apps (sometimes to less than half their original size) with some basic commands in the Terminal. But this takes time, and what’s more, Mac users in general have an aversion to the command line. Enter Trimmit.
![[Trimmit]](http://lipidity.com/wordpress/wp-content/uploads/2007/11/flow2.jpg "Trimming Flow.app")
Trimmit is a svelte utility which takes the pain out of keeping your applications as tight as possible. I use it on Flow each time I seed a build, and I seriously doubt the process could any easier.
Brian Amerige
Trimmit uses superfast UNIX APIs, Apple’s own developer tools, and the rock-solid Cocoa framework to automate your cleaning process. Just drop your built app onto it, maybe configure a few settings, and you’re away. It doesn’t get any easier - or faster.
Other applications claim to save disk space by stripping universal binaries, or removing languages. Trimmit does all of that - and more. But it works. Look at this screenshot from Xslimmer regarding Xcode:
Xslimmer naively believes that only two architectures can exist in any application, but the truth is revealed by Trimmit:
Because Trimmit interacts with the shell (zsh, in fact), no similar application can even come close to it’s level of power, accuracy and performance.
The results speak for themselves.
Use Trimmit to recover disk space that third-party applications so rudely waste.
28 Comments so far
Leave a commentThis will break some applications and it will most assuredly break Apple software updates if you try it on Apple disks. Don’t do this, fergoshsake. Instead, go spend $50 and get 500 more GB of storage. And complain to Apple: they need to make it easier in Xcode to slim down apps for distribution.
voiced by Zhak on November 3, 2007 1:06 pm | Permalink
Right. But only if a) the application is written in some legacy format that doesn’t support anything or b) the application itself is written in such a way that changing something will cause it to stop working. But in terms of “breaking” applications irretrievably - maybe in version 0.9, but the next version, which we’re about to release uses an even more highly sophisticated backup mechanism that is guaranteed to work if the trimming fails - or your money back. [But Trimmit’s free!]
Breaking software updates? I’ve tested Trimmit on almost all the applications that I have - some fail to run, so I restore the backup - but for most there are huge savings. I don’t know what software update has to do with it.
I don’t think you’re getting it. What Trimmit does can and *should* be done using Xcode and the Terminal already. Trimmit’s just a faster, easier way. Apple do this themselves for their apps. It’s not just wasteful - it’s downright discourteous to waste your users’ disk space with junk.
But IT’S THERE!!! That’s the point of all this rambling - developers are given all the right tools: Xcode, Terminal, and now Trimmit but they just keep shipping junk.
composed by Ankur on November 3, 2007 1:22 pm | Permalink
I always had a hard time wrapping my mind around the paradox that Xslimmer was ostensibly trying to do such a good thing but doing such a bad job of it. I guess it’s possible for the Xslimmer people to know bits and pieces of a technology without having the depth necessary to carry something like this off. I’ve seen the changelog for the next version and there’s no other way to say it: ‘I be blown away’.
voiced by Rick on November 3, 2007 1:45 pm | Permalink
‘This will break some applications and it will most assuredly break Apple software updates if you try it on Apple disks.’
Nonsense. How long you been around? A couple of weeks? People have been doing this manually for years. Besides: Apple aren’t the culprit - Apple are usually better, not worse, than the rest. It’s these lame third party people who really don’t have a clue what they’re doing.
First clue: if you find a .DS_Store in a bundle you download you can scratch that developer off your list right away. Any developer using (depending on) Finder doesn’t know enough to release software.
spoken by Rick on November 3, 2007 1:48 pm | Permalink
“That’s the point of all this rambling - developers are given all the right tools: Xcode, Terminal, and now Trimmit but they just keep shipping junk.”
Most developers don’t even know how to make an ‘install’ build. I bet over half of them out there calling themselves ‘developers’ (and taking your money for their blubber) really don’t grasp what that combo box with ‘Debug/Release’ means either.
stated by Rick on November 3, 2007 1:52 pm | Permalink
Hang on a moment… did I read that quote from Brian Amerige right?
“…and I seriously doubt the process could be less painless.”
So, using this application must be a complete pain in the arse then.
expressed by Phil on November 3, 2007 7:14 pm | Permalink
Phil, not sure if you’re being sarcastic, but “it couldn’t be less painless” means “it is painless, and nothing could be more painless”. But that’s impertinent.
recorded by Ankur on November 3, 2007 7:28 pm | Permalink
I was being sarcastic about the original quote as I’m sure your app is easy to use but that’s a very bad double negative. “It couldn’t be more painless” is what Brian meant. “It couldn’t be less painless” can be equated to “It could be more painless” or (far worse, as I’m sure your app doesn’t do this) “It could be less painful”.
voiced by Phil on November 3, 2007 7:33 pm | Permalink
I do believe you’re right!
But “it couldn’t be more painless” would sound the opposite… No matter.
determined by Ankur on November 3, 2007 7:38 pm | Permalink
Using Trimmit on a CARBON app can render it non-operational (just tested it). So my plea to the developers: please make TRIMMIT check for carbon apps and request confirmation before tampering with them.
revealed by Norbert Müller on November 4, 2007 6:33 pm | Permalink
Backup works?
disclosed by Ankur on November 4, 2007 6:57 pm | Permalink
Yes, backup works, as expected. But still, why use trial and error, when you can do it right in the first place. Also some resources can still be trimmed in carbon apps, one just needs to keep the essential ones.
uttered by Norbert Müller on November 4, 2007 8:39 pm | Permalink
Yes, I want to eliminate all the bloatware on my mac, but Trimmit 1.0 does not work correctly.
It does not remove languages and does not remove PPC code from the apps.
Other people have problems, too. Have a look at the versiontracker comments:
http://www.versiontracker.com/dyn/moreinfo/macosx/33361
How about making Trimmit open source ?
That would be great !
published by Michael on November 5, 2007 12:52 pm | Permalink
Maybe in the future. But you can just uncheck the options for the debug symbols and lipo.
It has been reported that Trimmit fails to lipo correctly on some systems. This is being investigated.
uttered by Ankur on November 5, 2007 2:57 pm | Permalink
It’s working 100% on my machine, but on some others it’s not. If people could please inform me whether this is actually working that would be great. Thanks.
declared by Ankur on November 5, 2007 8:47 pm | Permalink
I just want to clarify if Trimmit is for the general user or, primarily, for developers. Namely, is this more for the developer to use before they ship an app, or can I run it on an app after it’s been installed on my system?
I saw other third-party apps mentioned in comments, but just wanted to clarify.
Thanks in advance.
voiced by John on November 6, 2007 3:35 am | Permalink
It doesn’t decompress for me! Did you trim that one too?
recorded by Stereo on November 7, 2007 4:42 pm | Permalink
Both.
Sorry. It’s fixed.
stated by Ankur on November 8, 2007 9:23 pm | Permalink
It works for me. Thanks for the info.
composed by Autumn on November 9, 2007 8:49 am | Permalink
Agreed. Too much software has become too big the last couple of years. Just because HDD space has become cheap then RAM and CPU power is used needlessly. This is especially a problem for notebooks and other small portable devices.
professed by Jaime on November 10, 2007 7:58 am | Permalink
“Clear foreign languages” assumes that everyone uses only one language. I use at least two.
Would it be too hard to offer the means to choose which languages to keep?
recorded by Tut on November 18, 2007 1:31 am | Permalink
Tut, we’ll have a look at this.
voiced by Ankur on November 23, 2007 8:50 am | Permalink
Trimming resource forks seems like a dangerous idea to me. Unlike the rest of the things in the list, you can’t easily predict which applications actually use resources.
Neat idea, though.
spoken by Steven Fisher on December 7, 2007 4:31 am | Permalink
Finder ‘get info’ shows increase in app sizes for both Camino and Comic Life after running Trimmit. This must reflect the backup file, but there is no info on where the backup is kept, when it is safe to delete it, or how much space was reclaimed.
Is there a FAQ page? A ‘help’ file?
This is on MacBook Pro, Tiger 10.4.11.
Thanks
posted by robert on December 26, 2007 2:56 am | Permalink
“Clear foreign languages” currently (0.95b - I don’t see 1.0 despite the comments) assumes you wish to keep only your “first choice” language and either deletes all others or, if that language isn’t available, deletes none of them. This doesn’t work for me - I want to keep my first language choice and English/English-GB if both are available, otherwise I want to keep English/English-GB and delete the rest. It seems Trimmit picks up language preferences but only considers the first language. It is pretty easy to adapt it to behave as you need, but it would be nice if users wary of this sort of “fiddling” could access the same functionality.
My main issue with Trimmit isn’t really with Trimmit, I think. All the large applications I test this on fail to work once trimmed whereas many of the smaller ones do just fine but obviously it then saves me much less space!
composed by cfr on May 2, 2008 1:25 am | Permalink
Robert - Camino is working fine for me; Comic Life should work too. After running, you’ll get two apps - one has ‘ backup’ appended to its name.
CFR - a lot of the functionality can be modified (eg, keeping two languages) in Resources/trimmit (it’s a shell script).
What do you mean by “large applications”? Those I’ve tested (including Pages, Keynote, Numbers, Safari and iTunes) all show very drastic reductions in size. Some apps (like most old Carbon apps) have an aversion to being modified (but you can still run Trimmit on them; just turn off “Keep architecture” and “Strip debug symbols”).
stated by Ankur on May 2, 2008 4:15 pm | Permalink
It worked great until Snow Leopard; on 10.6 applications, I’m getting problems reported that I suspect are to do with permissions of some parts of the package.
It’s not the end of the world because I am running 10.6 on a newish iMac with a big fat disc - and have most need for Trimmit on old iMacs that run 10.4 but have smaller discs.
revealed by StephenB on January 12, 2010 3:39 am | Permalink
Leave a comment