How to find old Apps ?

Hi all !

I want to write a good, intelligent installer script for my application. This script must be able to find any old versions of my App no matter where they might have been moved to by the end user. Getting the file path should be adequate I think. Is this possible? I have been experimenting with "path to " but I’m not sure if this is the best implementation. Is there a way to use Spotlight for this, or is there a better way?

Ultimately the goal will be to completely remove the old App so there are no conflicts with the new App.

Many thanks

PS. (Micky San - Hope this is a well formulated question. Thanks for the link on How to ask better questions.)

set tAppName to "UI Actions"
set F to do shell script "mdfind -onlyin / " & quoted form of tAppName

We deal with this at Freeverse with our updater applications that are designed to locate pre-existing installations of our software. (Typically, we’d just use

Looking for software by NAME isn’t really how you need to do this, because users can and do change the names of applications on disk. (Sometimes accidentally, sometimes not.) You also shouldn’t only look at /Applications. Users often store programs in their home folders or in other areas of the machine. What you really want is to search for the application via, in order:

  1. LaunchServices bundle identifier.
  2. A quick two or three-level deep search in /Applications, /Shared, and the active user’s home directory. Don’t search for the application’s NAME, however, search for its MacOS executable, which doesn’t get changed by users.
  3. Finally, just prompt the user to locate the previous installation, if you can’t find one programmatically.

Don’t use what you expect the application name to be as a qualifier, basically. The LaunchServices search will find the software in 99.9% of cases, if the user has the ability to see the software at all, but you should have backup plans.

Another concern is that you need to deal with permissions roadblocks. If the user running the update does not have permission to delete the existing software and write the new software, or overwrite it, your installer must not misbehave. You don’t HAVE to go the full mile prompt for authentication, etc., to make it seamless, but your installer must at least not screw up.

If there’s a way you can do this with a standard installer package, DO IT. Don’t roll your own unless you know exactly what you’re doing. I’m pretty sure you can’t do the LaunchServices trick with in Panther and Tiger, but you should be able to formulate a decent search for the application’s MacOS executable that will work well on the command-line level.

Good installers are hard. Really hard. Good luck.

I took the liberty of writing a command-line tool that uses LaunchServices to locate an application via its bundle identifier (, for example). You can invoke this in your installer script, if you go that way, or if you roll your own solution.

Be sure to look at the readme.

Note: This doesn’t do step #2 from above. That’s your job.

One more piece of advice:

Validate your target before taking action. Maybe even go so far as to tell the user what you’re about to replace, as well. (That’s what we do.) Programmatically, you want to make sure you’re not overwriting the wrong application or files. Verifying the md5 checksum on the MacOS executable of an application package is a good start with this.

Hi Mikey,

isn’t your shell script almost the same as this AppleScript routine.
However, it returns either the alias of the app or boolean false :wink:

set S to check_App("")

on check_App(A)
		tell application "Finder" to return application file id A as alias
	on error
		return false
	end try
end check_App

OK. Thanks for the replies. There is a lot which I don’t fully understand.


  1. I’m not sure how to do this.
  2. I did find some info on verifying the checksum though
  3. I like the idea of not searching for a file name but rather matching the checksums. Upon reading about checksums I think this will be the route I’m taking.
  4. My problem remains however.

How do I search for the app?

I’ll explain. When using applescript there is a command which gives a list of Apps on the computer. Regardless off their names.

“Choose application” - However this list is for user interaction.

Is there a way to get this list or something similar so I can look for the checksums using a repeat loop?


While trying your suggestion I’m getting paths to incorrect locations when replacing :

with my App

even when trying the code exactly I get “”.

Is there something I’m missing because surely my machine must have “UI Actions”

Trying other apps I also get nothing ie. “” as the return value

Many thanks

It’s not a shell script; it’s a Foundation tool. It also doesn’t use the Finder at all, it uses the underlying Application Services function, which makes it instantly better than any Finder-based solution. It’s more portable, faster, and less prone to Finder problems (like the Finder being busy or insert_reason_here).


Did you download the tool and read the documentation? It will give you the same information as the Finder, you realize. 0 and the application path on success, 1 if unable to locate an application, and 2 if no argument was provided at all.

Thanks for the tool and the explanation

Sure. The question comes up once in a while, so maybe I’ll put it up for permanent download on my site and just post a link to it when I see posts asking similar things.

No one said to search for a checksum. You should locate the application via other means and when you have what you think is a valid target, verify its executable with a checksum.

Did you try lslocate?

  1. Use lslocate.
  2. If lslocate does not return useful data, use find (or mdfind, whatever) to look in /Applications for a potential target.

To be honest I don’t know how. I understand applescript and I am slowly learning how to use shell scripts.

so if

what do I need to do to use it ?


Thanks for than StefanK. It works perfectly. It isn’t slow on my machine, but I do hear alot about Finder being ,well less that a perfect solution. For now it is probably adequate in my requirement but I am intrigued by Mikey-San’s solution.

Many thanks for the reply !


Have you considered using Sparkle for updating? Then your installer would not have to look for the app because it will be the first time installing, and sparkle would handle the updates.

  1. Shell scripts and command-line tools can be invoked with “do shell script”. See:

  1. If you aren’t familiar with using shell scripts/command-line tools in general, and think the Finder is an adequate solution for your task, you are not ready to ship your own custom installer. I really don’t intend to be mean here, but that would be my opinion at this point.

Sparkle is pretty good. We use a customized version of it for a couple of our applications, and it’s worked well for us. I’m not sure how well it’ll integrate into a Studio project, but it might be a viable solution for him going forward.

it works perfectly fine in an AS-Studio app. Already tested it:D

Voting for this, then. Implementing Sparkle is trivial in Cocoa, shouldn’t be much more work in Studio.

Did you have any hiccups while implementing it in Studio?

nope, not at all. I just followed the instructions and no bumps along the road:D

Two things – it should be as Unicode text, and you may not have that setup unless you downloaded it. Go with Sparkle if you can and pay attention to Mikey’s warnings.

Thank you All for the advise. This all helps a lot.

Mickey-San , you are not being mean. I take it you are a full time programmer and as such work with the best your world has to offer. I am not a full time programmer and as such I rely on applescript to merely simplify my workflow. I do however see and understand your remarks. I accept that I am not ready to roll out my own installer using shell scripts just yet, as I mentioned I am still learning.

That won’t stop me from developing , applescript (and Finder) are merely a means to an end at the moment.

Thanks for the link to the technical docs on shell scripting.

There is so much to learn and so little time.

Thanks once again to all.