Extremely frustrated with Apple app update method

[Gametes]

So, as it stands, every time I update the system I end up with a folder called "Mail" in my Applications folder. Then, I open 2 windows: one showing the contents of the mail folder, and one showing the contents of the Mail app. Then I must carefully replace all the items in the latter with the newer items from the former, subdirectories first and out.
Repeat for however many apps have been updated.

LAME!

What is the deal, Apple?! Why can't you SEARCH for where I've put the app and update that!

What the heck are regular users supposed to do? They don't know about "Shawing package contents"!

[swiz]

Originally posted by Gametes:

What the heck are regular users supposed to do? They don't know about "Shawing package contents"!

Regular users dont worry about moving their apps into better organized directories.

[LightWaver-67]

Originally posted by Gametes:
So, as it stands, every time I update the system... (truncate)

Well... my "initial" thought was... "Well... just don't move the application...!"... but then I thought about it... you're right in a way. I also come from the early Mac-OS days (7.x and higher) and it was never an issue to move applications anywhere around the directories.

I guess it's a by-product of this being a "new" OS that has slightly different rules than the previous OS. Some things need (apparently) to be more windows-like in structure. i.e.; This "thingy" needs to be here for THIS "thingy" to find it.

Not sure if it really IS a limitation of the OS or if it's just too-strict of an installer.. or what... but, yeah... things sure have changed.

[godzookie2k]

Originally posted by swiz:


Regular users dont worry about moving their apps into better organized directories.

hehehehehhehehe

[Ibson]

Originally posted by LightWaver-67:
Not sure if it really IS a limitation of the OS or if it's just too-strict of an installer.. or what... but, yeah... things sure have changed.

It's a limitation of the installer. Rather than using hard-coded paths, the installer should take advantage of Launch Services. So, to update Mail, instead of looking for it at /Applications/Mail.app, it should call the LSFindApplicationForInfo() function, which searches the registry of applications in the order of bundle identifier (com.apple.Mail), then creator (emal), then name (Mail.app). This returns the URL of the application, wherever it is.

[lookmark]

Originally posted by swiz:


Regular users dont worry about moving their apps into better organized directories.

You could also phrase this as:

Regular users will learn not to move their apps into better organized directories because if they do, Apple's installer will punish them.

Sorry, this isn't just a problem for the geeky set. The installer issue affects ease-of-use.

[MacAttack]

The bottom line is that once users start loading up their Applications folder with LOTS of apps, some flexibility by Apple to allow users to create application subdirectories would be appreciated.

My Applications folder is subdivided as follows:

Apple
Audio
CD Burning
Emulation
Games
Graphics
Internet
Neat Stuff
Productivity
System Preferences
Utilities
Video

I've installed third party app stuff where the installer automatically finds the app and updates it, so it should be entirely possible for Apple to do this as well with their own apps.

I definitely like my current system of organization better than Apple's "throw everything into one folder" scheme...very un-Apple-like if you ask me!
:)

[Cipher13]

Yeah, it's a problem that should be addressed, even though it doesn't affect me directly... I like having all the apps in one folder.

I hit the applications button in the toolbar (or enter the path in 'go'), type the first couple of letters in the apps name, hit apple-down, and there we have it. Works beautifully.

[curmi]

Don't forget to send feedback to Apple telling them what you want. Otherwise they think that "regular users" are happy with this.

[plot twist]

why not just use alias' instead of actually moving the app? in fact, you can create a folder called apps, and orginize aliases of all your appliciations.

[itai195]

This is part of the price you pay for not having a registry built into the OS. Frankly, it's worth it.

[Ibson]

Originally posted by itai195:
This is part of the price you pay for not having a registry built into the OS. Frankly, it's worth it.
Actually, Mac OS X does have a sort of "registry" of applications and what data types they can handle built into it. It's called Launch Services. When you double click a file in the Finder, it looks up what application should open it using Launch Services.

Interestingly, in Mac OS 10.2, applications can now claim to open certain MIME types (used on the Internet, eg. text/plain), which points to a file system (hopefully) less reliant on file name extensions.

As I explained in a previous post, you can use LSFindApplicationForInfo() to locate the path to an application based on its signature ("Classic" Mac OS four-char codes), bundle identifier (Java-style string), and file system name. This is what Software Update should use.

[Ibson]

Originally posted by plot twist:
why not just use alias' instead of actually moving the app? in fact, you can create a folder called apps, and orginize aliases of all your appliciations.
That seems so Windows-ish. Start menu, anyone? That's just a folder full of shortcuts (the Windows equivalent of aliases).

[drmcnutt]

Originally posted by Ibson:

That seems so Windows-ish. Start menu, anyone? That's just a folder full of shortcuts (the Windows equivalent of aliases).

You could say Apple Menuish too, OS 9 that is.

DRM

[CharlesS]

I've long considered adding a feature to Pacifist (almost since its inception, actually) that would just check the LaunchServices database every time it encountered anything that ended in .app. If I ever implemented this feature, you could download OS updates and install them with Pacifist, and your apps would respect the locations you moved them to.

The trouble is, I've always had trouble trying to figure out how the interface should work. So far, the only thing I've been able to come up with has been to alert the user every time it was about to install some app that has been moved to an alternate location, and ask which location to put it in. Do you think that would be too annoying?

At any rate, I'm open to suggestions (support at charlessoft dot com).

Charles

[Ibson]

Originally posted by CharlesS:
I've long considered adding a feature to Pacifist (almost since its inception, actually) that would just check the LaunchServices database every time it encountered anything that ended in .app. If I ever implemented this feature, you could download OS updates and install them with Pacifist, and your apps would respect the locations you moved them to.

The trouble is, I've always had trouble trying to figure out how the interface should work. So far, the only thing I've been able to come up with has been to alert the user every time it was about to install some app that has been moved to an alternate location, and ask which location to put it in. Do you think that would be too annoying?

At any rate, I'm open to suggestions (support at charlessoft dot com).

Charles
Just make it a preference: "Install applications at my locations" or something similar (mmm...that's a really bad example :)). As you say, I'd find everything ending in .app, extract the signature (if any)and bundle ID from the Info.plist file, then automatically install it at the location returned by LS.

[Mithras]

It is absolute horsecrap that the old Mac OS did better updates than Mac OS X

Try it with classic Mac OS sometime: install, say, Mac OS 8.1. Move things around, out of the "Apple Extras" folder, or taking the Calculator or Key Caps out of "Apple Menu Items". Then update to Mac OS 8.5.

You will have duplicates of everything you moved.

I think the only difference is that updates come much more often in OS X, so people notice it more.

It was true in classic Mac OS, as it is in Mac OS X, that you can move an app and it will at least work, unlike many apps in Windows. But updating has always been problematic.


To me, the solution is simple:
* Let "/Applications" be the Apple-Application folder. Leave it alone.
* Make a different folder, either within /Applications or at the HD root, for all your 3rd-party applications.

This makes for cleaner backups anyway.

But Charles, your idea sounds great.

[lookmark]

Originally posted by Mithras:
It is absolute horsecrap that the old Mac OS did better updates than Mac OS X

Try it with classic Mac OS sometime: install, say, Mac OS 8.1. Move things around, out of the "Apple Extras" folder, or taking the Calculator or Key Caps out of "Apple Menu Items". Then update to Mac OS 8.5.

You will have duplicates of everything you moved.


Well, we're not saying the classic Mac OS was a paragon of virtue in this area.

But this is something in which is OS X is noticably far less user-friendly. The big difference is that OS X doesn't leave duplicate apps, but, (a) the original (unupdated) application, (b) a (confusingly) generic folder with the app's name that contains a bunch of strange names, and (c) a receipt that makes it tricky to reinstall the update. This just leads to fear and confusion:

- what just happened?
- did the update really update my apps?
- what's updated and what's not?
- how do I re-apply the update, or fix the apps that weren't updated?
- why is this so complicated, all I did was press "Install Software Update"?

All of these questions are answerable and can be fixed, of course. Except the last.

But it takes work, and creates much unnecessary panic and consternation -- especially for the much-bandied "regular user" who dares tidy their Applications folder.

It also makes people afraid to move their own files around, an enmpowerment the Mac has always stood for.

BTW, all who care about this, send Apple feedback all, please. I'm sure Apple has this on their list to fix but it's apparently low-priority.
(I wonder if they're waiting for 10.3, and its new rumored FS/metadata architecture...? Hmmpf. Who knows.) Let's try to bump it up.

[CharlesS]

Originally posted by Ibson:

Just make it a preference: "Install applications at my locations" or something similar (mmm...that's a really bad example :)).

I think you've just noticed one of my biggest problems. :)

As you say, I'd find everything ending in .app, extract the signature (if any)and bundle ID from the Info.plist file, then automatically install it at the location returned by LS.
The trouble with that is that updates don't always include the Info.plist file. But that's not too much of a biggie since I can look up apps by their name in LS.

[Millennium]

Yeah. This is, by far, one of the worst problem with the Installer; it can't handle apps that have been moved. And considering how bad it is as shipped, that's quite a feat.

CharlesS' Pacifist is excellent, and solves many of the Apple Installer's problems. But in the end, there's really only so much even it can do. Case in point: some updates are unlikely to ever be made available for download, except through the Software Update mechanism.

What would be really neat would be if there were a way for Pacifist to completely replace SU (it could probably do that job better too). But there are huge problems with that, among them the fact that SU uses encrypted network connections for at least part of the transaction, and although the client-side key has to be stored on disk somewhere, Apple's not going to take kindly to its being found.

[lookmark]

How about a checkbox:

[ ] Protect customized Applications folder

with a subtitle (or hint tag):

Checks to find location of Apple-created applications before installation

---

I do think that asking the user whether to install an app if it's moved for every app would be annoying. It would have to be invisible and do its magic in the background to be a clear improvement.

Easier said than done, I'm sure. ;)

[LightWaver-67]

how about (as others have suggested) simply having the installer LOOK for it's damned-self to SEE where the original app. is...?

I know updaters and other installers do this.... if you tell it to install, and it "finds" a version or MULTIPLE versions... it asks which one you want to update.

It seems 'simple' enough to me.... then again, I've never programmed anything.

:)

[CharlesS]

Well, the thing with just doing it automatically is that I don't want to overwrite users' apps without their permission or their knowledge. It could be that a user has moved an app to another location as a backup, or wanted to keep the old version around, or something. Also, it might be misleading to say that the app will be installed in a certain location and then put it somewhere else. So by default, as I see it, I need to either ask the user (with a "Apply to all"-style checkbox, of course), or have the feature turned off by default. I suppose an option in the preferences to either always use the default location, always use the found location, or ask the user first, with the default setting being to ask the user, could work. It just kind of seems like there has to be a better way, but I can't think of one.

Also, I'm trying to think of decent message text. So far, this is what I've been able to come up with:

"A previous installation of the application bundle %@ has been found in the following location:\n\n%@\n\nWould you like to update this previous installation with the files you are installing or install the files in the location defined by the package?"

and the buttons:

"Replace Existing Installation"
"Install in Default Location"

As you can see, this text is not ideal - it is too verbose, not clear enough, and doesn't roll off the tongue well.

I don't think this would really be that difficult of a feature to implement - I've actually got some sample code I wrote a month or so ago - but the interface questions of the thing just make it one of those times where you wish you had a HI team working for you...

[dfiler]

Originally posted by CharlesS:
...
I don't think this would really be that difficult of a feature to implement - I've actually got some sample code I wrote a month or so ago - but the interface questions of the thing just make it one of those times where you wish you had a HI team working for you...

I've never used pacifist but am quite familiar with how it operates and have kept up on related discussions. As a developer with an education in human-computer interaction, I'd love to lend my skills to this endevour. If pacifist is a cocoa app, I can easily supply some demo nibs.


Off the top of my head, here is how I think the interface should operate:

If an updated app has been moved from its intended/default location, or multiple installations exist, the installation should pause and prompt the user for what to do next.

-------------------------------------------------------------------
Installing AppName.App

Would you like to replace your current version of AppName.app? It is currently stored in /full/path/here but its default location is /another/full path/here.

__Quit__ __Save As...__ __Replace__
-------------------------------------------------------------------


or if multiple copies of the app are found...


-------------------------------------------------------------------
Installing AppName.App

You have 3 copies of AppName.app.
Would you like to replace one of these with the current version of AppName.app?

[ ] AppName.app (v#.#) (/full/path/here/Appname.app)
[+] AppName.app (v#.##) (/another/full/path/here/appname.app)
[ ] modifiedName.app (v#.#) (/another/full/path/here/appname.app)


__Quit__ __Save As...__ __Replace__
-------------------------------------------------------------------


Choice of button names was quite a dilema:
- Quit could have been cancel but then the title of the window should reflect the name of the whole installation process rather than just the app in question.
- Save As... had numerous alternatives: Select Folder, Select Location, Choose Locaiton, New location, Install New, New copy, etc. I chose 'Save As...' because users are already used to the phrase when dealing with duplicate/existing files during normal document save tasks. Clicking this button should open a file save sheet to the default save location.
- Replace had at least two alternatives as well, Overwrite and Upgrade. Overwrite and Replace seemed 100% synonymous so I chose the more common and shorter word. Upgrade is more descriptive but only to people familiar with computer jargon. Replace makes it absolutely clear that the user will no longer have their old version.

[shadybirdstan]

Originally posted by Ibson:

That seems so Windows-ish. Start menu, anyone? That's just a folder full of shortcuts (the Windows equivalent of aliases).

I don't see the problem with that solution is, its not like every last thing on a Windows machine is awful. This seems like an easy solution for a problem that may be more complicated then it seems.

I'll be doing this right now plot twist, thanks for the tip :D.

[dfiler]

Looking back over my post, I'm still not satisfied with the interface. In general, quit buttons are fairly un-Mac although this rule has been bent by quite a few apple installers. Also, it seems like the ability to skip a portion of an installation would be useful as well. Rather than ammending the previous post, here's some addendums:

- The window's title should reflect that of the complete installation name, not an individual sub-component. Installation wizards or scripts shouldn't open and close a billion different windows. This is especially true when each new window is used for the same task even if its dealing with different data.

- The component in question should be given a sub-title status in the window's content area.

- The close widget and File Menu's Quit item should both bring up an 'Abort Installation' confirmation sheet.

- The Quit button should be relabeled as 'Skip'

[CharlesS]

dfiler, thanks for your input.

For consistency with the rest of my dialogs, the "quit" button would be labeled "Stop Installation" as this is what I currently use for other dialogs that pop up during installation. I feel that it is quite clear as to what it will do.

The Replace and Save As... buttons are also problematic. The Save As... is unnecessary, because by the time the user reaches this point he/she has already had the option of extracting to either the default location or a custom location, and has chosen the default location. Hence the buttons need to choose between the default location, and the alternate location of the pre-existing app that we have found. "Replace" has problems, because it conflicts with terminology I'm already using - I already ask whether to Replace or Update an app bundle when installing over it. Clicking Update simply copies the new files inside the old app bundle - the obvious choice when installing software updates, and the default - while Replace deletes the old app bundle and installs the new one clean, which you may want to do if you are downgrading to an earlier version of an app, or simply want to remove corruption.

We will have to think of a new name for the buttons.

Also, AFAIK, it is not possible to get more than one path to a given application from LaunchServices, so I will not be able to implement the "choose version to update" feature without doing a full search of the hard drive, which is a time-consuming process that I am not willing to do at present.

Thanks for your help,
Charles

[dfiler]

Originally posted by CharlesS:
dfiler, thanks for your input.
...
Charles

All very good points. Sorry for the irrelavent suggestions... perhaps I should have studied your current interface more prior to giving that input ;) Now that I'm not stuck behind my work XP machine , I'll do more research.

[CharlesS]

Originally posted by dfiler:


All very good points. Sorry for the irrelavent suggestions... perhaps I should have studied your current interface more prior to giving that input ;) Now that I'm not stuck behind my work XP machine , I'll do more research.
No, there were some good and interesting points in there... they may just need to be adapted somewhat.

At any rate, I have to finish some other half-implemented features before I can go on to this one, so we do have time to discuss this and think it through before I go and implement something...

[dr.george]

Originally posted by MacAttack:
The bottom line is that once users start loading up their Applications folder with LOTS of apps, some flexibility by Apple to allow users to create application subdirectories would be appreciated.

My Applications folder is subdivided as follows:

Apple
Audio
CD Burning
Emulation
Games
Graphics
Internet
Neat Stuff
Productivity
System Preferences
Utilities
Video

:)


I bet that "Neat Stuff" is porn ... :D

[K++]

Originally posted by Ibson:


It's a limitation of the installer. Rather than using hard-coded paths, the installer should take advantage of Launch Services. So, to update Mail, instead of looking for it at /Applications/Mail.app, it should call the LSFindApplicationForInfo() function, which searches the registry of applications in the order of bundle identifier (com.apple.Mail), then creator (emal), then name (Mail.app). This returns the URL of the application, wherever it is.
I would think apple knows about these seeing as how they wrote them and all. But then again thats just me, I only read Apple's documentation on Apple's API and sytem frameworks, so youll have to excuse me. :rolleyes:

[MacAttack]

Originally posted by dr.george:



I bet that "Neat Stuff" is porn ... :D

Nope, just stuff like Britannica 2002, WorldBook, Marine Aquarium, Blobber, etc. (pretty much apps that I can't put into the other categories).

Besides...I keep my porn in my Pictures folder. ;)

[CharlesS]

Originally posted by K++:

I would think apple knows about these seeing as how they wrote them and all. But then again thats just me, I only read Apple's documentation on Apple's API and sytem frameworks, so youll have to excuse me. :rolleyes:
They know full well about LaunchServices, and could easily update their install packages to use it. For some reason, they seem to have made a conscious decision not to.

[Rickster]

Actually, the 10.2 version of Installer's package format supports a pretty interesting mechanism for handling relocated apps. Package builders can provide plists that specify all sorts of things about where to look for a possibly-moved app, what version(s) to look for, what identifying features to use (CFBundleIdentifier versus four-char signature), etc.

But go figure, they don't actually use this nifty feature themselves.

[winterlandia]

Originally posted by LightWaver-67:
how about (as others have suggested) simply having the installer LOOK for it's damned-self to SEE where the original app. is...?

I know updaters and other installers do this.... if you tell it to install, and it "finds" a version or MULTIPLE versions... it asks which one you want to update.

It seems 'simple' enough to me.... then again, I've never programmed anything.

:)


I totally agree. Apple seems to think users don't move things. They do move things. Get over it, Apple. Look for the damn application. Replace it in place. What could be difficult about that?

[CharlesS]

Originally posted by Rickster:
Actually, the 10.2 version of Installer's package format supports a pretty interesting mechanism for handling relocated apps. Package builders can provide plists that specify all sorts of things about where to look for a possibly-moved app, what version(s) to look for, what identifying features to use (CFBundleIdentifier versus four-char signature), etc.

But go figure, they don't actually use this nifty feature themselves.
That's why I said they could easily update their packages, not the Installer.

Yes, folks, the Installer actually includes a Find File feature that looks up things in the LaunchServices database, and installs them in the appropriate locations. I noticed that a while ago but was hoping to keep quiet about it in order to make mine look neater (thanks, Rickster :p) but mine will still be better, because the Apple feature has a fatal flaw: it relies on the developers to actually use it, and indeed, even Apple doesn't. My feature will install things in the correct places regardless of whether the developer saw fit to support it or not.

Charles

[Brass]

Originally posted by winterlandia:



I totally agree. Apple seems to think users don't move things. They do move things. Get over it, Apple. Look for the damn application. Replace it in place. What could be difficult about that?

yes, Apple seem to have taken a half hearted approach which does nobody any good. Really, they should either:

1. Leave the installer as it is, and Make it impossible for users to move Apple applications.

2. leave the Applications as they are (moveable) and make the installer look for them.

It's absurd to have the two incompatible parts of these two together as we have now.

[ShotgunEd]

Actually Apple's installers have been doing this very thing for as long as I can remember. In 7.5.1 onwards. Apple Video Player and Apple CD Audio Player would be loosely sitting in the Applications folder by default along with their respective readmes. I moved these apps into aptly named folders - Apple Video Player (f) and Apple CD Audio Player (f) - where (f) means that cool folder symbol you got by pressing option-f. When Apple updaters realised that I had moved the apps they up came an error forcing me to stop the update, find the Apps and move them back to where they were supposed to be. Either that or use TomeViewer to manually install the items. I filed this with Apple Feedback back then, and we are still getting similar problems now. It gets increasingly more irritating to see bugs like this remaining 15+ OS updates later especially when at least a third of these have been paid. But then again, I guess its a feature not a bug.

[khufuu]

Assuming a muti-user system and that each user has an icon on their dock for 'standard' apps like Mail and AppleWorks, if you move the apps, your dock icon turns into a big question mark because it isn't where it thinks it is.

You haven't yet launched the application so LS hasn't been called and you're not just opening a document which would call LS to find the app for you.

Would think make sense then that Apple would insist on 'standard' locations for standard apps?

[CharlesS]

Originally posted by khufuu:
Assuming a muti-user system and that each user has an icon on their dock for 'standard' apps like Mail and AppleWorks, if you move the apps, your dock icon turns into a big question mark because it isn't where it thinks it is.

You haven't yet launched the application so LS hasn't been called and you're not just opening a document which would call LS to find the app for you.

Would think make sense then that Apple would insist on 'standard' locations for standard apps?
Not in my experience. The Dock entries store alias data, so you can move things and they should still point where they should. LS has nothing to do with this.

[Sven G]

... Still no dependency checking (and uninstalling) � la Fink in Apple's Installer, sofar, AFAIK; even the OSXGNU "OSXPM" package manager hasn't delivered (despite the promises), sofar. :(

There really should be some new and more powerful Fink-like solution, IMHO...