How to find old Apps ?

Why?

From Apple’s Software Delivery Guide:

His posts indicates he wants a mechanism to locate previous installations of existing software. This seems to be his driving reason. I don’t see anything wrong with this; such a requirement goes beyond the scope of the recommendation you posted. There’s a reason people are nuts for Sparkle, after all–it’s really slick, easy to implement, and makes for effortless version checking and upgrading on the user’s end. Yes, it’s okay to have a drag-and-drop “upgrade”, but there’s nothing particularly wrong with an automated updating system.

Sparkle is definitely the way to go, here, if drag-and-drop updating is not acceptable to him. He will learn new concepts and not have to risk shipping a substandard customer experience because he’s new to installers.

Edit:

But yeah, in general, that’s the paragraph to point to. Don’t roll installers unless you have some special reason.

Yeah, that’s the point I was going for. (I know I’m a little late here. :P)

In my mind, that’s one of the things I was really questioning. (FWIW, I almost removed the actual “Why?” from my post because it was too short.)

If drag-and-drop is acceptable for the initial install, then it should also be acceptable for later updates, and then the above question should be moot. (If drag-and-drop is acceptable, then Sparkle-based updates for existing users would be a great idea. Edit: In the future, Sparkle 2.0 may work for more “complex” projects as well.)

Finally, that lslocate tool works nicely.

I can’t speak for him, but I can tell you why some of our products have special installers that locate previous installations:

Some of our users just aren’t savvy enough to do it on their own. It’s intimidating. They feel better when they’re guided through the process. But even more than that, before we did it, we had support problems where people would have two or more copies of the software installed, and either didn’t realize it, or didn’t communicate it well. When they had a support issue–and they would, because they wouldn’t necessarily be running the current version, but an older one on their drive–we would have to deal with it. Made support harder, because you can’t just ask, “Do you have a previous version installed?” as they might not realize they do.

When we started shipping installers that would locate previous versions and update or replace them, for the products where we found customers weren’t keen to do it on their own, we found that we had fewer support issues where versioning was involved.

I prefer drag-and-drop installs, as do most of my peers. Overall, it’s the best installation procedure, I’d say. But there are times when it’s not. :slight_smile:

Word up.

Hi Bruce,

I do agree with the drag & drop concept. However, Mickey-San is right on the money. I have started testing my app on a few different machines, and some of the users need a helping hand when it comes to installing. The first few testing versions were installed by simply doing the drag and drop thing, but some users decided NOT to remove the older versions. Needless to say, conflicts everywhere, software misbehaving , and so on and so forth. Anyway the idea here is simply to help my less “savvy” users find all the previous versions which they renamed and installed all over the place and remove it.(They are not keen on using spotlight & deleting stuff) Then to also install the new version. All in 1 slick move.

Alas it would appear that it’s not that simple. I am working on a partial solution which will look for the software in the obvious places. However if the app file was renamed or placed in a strange location it becomes more difficult. After a few tests using the code posted by StefanK , I am able to find the renamed app files quickly. Thats why it appears to be an adequate, but not nessasarily the most ellegant or robust solution.

Honestly I would love it if drag & drop was the only way to do an install, but in reality people with various degrees of skill use our apps and if we want them to continue doing so, we need to make it easy for them. My app is very specific and does not have a broad client base and as such should be fairly easy to support.

Thanks for the suggestion,

Much appreciated :wink:

EM

  1. It’s Mikey. :wink:

  2. I stand by what I said about the Finder. If you can’t do it without the Finder, you are not prepared to provide the solution to your users.

This thread has already given you the knowledge you need to deal with this problem. Adequate is not good enough when it comes to software installation.

Well … Drag & Drop here we come ! :smiley:

How can I find applescript-created applications like this?

Applescript-created applications don’t seem to be locatable using either the bundle identifier or the file creator. I opened the info.plist from inside of an app bundle and added a bundle identifier. Neither Mikey-San’s shell script or using the Finder would locate it. I then tried with the file creator code in the PkgInfo file… also no good.

Any suggestions for getting applescript-created applications working with these techniques? Here’s my script for locating the apps.

set bundleIdentifier to "com.HAMS.appBundle"
set fileCreator to "HAMS"

tell application "Finder"
	try
		set appPath to application file id bundleIdentifier as Unicode text
	on error
		set appPath to application file id fileCreator as Unicode text
	end try
end tell
appPath