Broken apps after updating from Self Service

That sure sounds like permissions to me...

So, basically it only breaks the app if its already there and needs to overwrite it? Any errors at all in the install.log on the Mac after it runs the pkg version of the installation? I'm wondering if the install is being stopped or interrupted in some way and its not completely writing new files into place. Or some other issue perhaps that might get noted in the log.
I had originally thought the install isn't able to write new files/folders due to permissions on the existing app, but, as its running in a root context from a Casper policy, I can't see why it would have trouble overwriting files on disk. It really shouldn't, but who knows.

FWIW, I used to see this happen a lot a while ago with Firefox. We always needed to rm -Rfd the app bundle away before installing the new version in a Before script to get it to work. More recent versions don't seem to have this issue any more though. That said, it wouldn't happen to be Firefox as one of the apps causing this problem is it?

@AVmcclint I've seen similar behavior with certain apps as well. The one that I noticed it on was Google Chrome and prompted me to start a discussion on Slack about it. A Composer created installer would add an additional directory to Google Chrome.app/Contents/Versions leaving behind older versions. For instance if you have version 52.0.2743 installed and made an installer pkg with Composer for version 53.0.2785 when the newly created installer was ran on the computer you would have both the 52.0.2743 and 53.0.2785 directories. While it didn't cause Google Chrome to stop working it cause the app bundle to get large over time.

There was a long a spirited discussion on Slack but ultimately it came down to the way Composer deals with "installing" files. It will add things to the app bundle and may leave old stuff around. If you use the command line pkgbuild to create an installer of the Foo version 1.5 it likely will properly replace the Foo version 1.0 rather than the behavior you are seeing.

One app that I did have problems with the app launching was Skype. If a Composer built pkg was installed on top of an older version of Skype the application would crash. Ultimately I had to do what you did and delete the app before installing a Composer built version.

I explained the situation to my TAM and basically was told that the way Composer does it is as designed. They didn't see it as a bug needing fixed. I've not tried the Packages app to see if it deals with this differently. But that might be something you could look at.

@mm2270 There are no errors in the log. Everything indicates that it installed everything properly... except that it doesn't. I've tried running a policy with the -verbose switch and there's still no signs of problems. I've experimented with setting permissions on Foo 1.0 to a full 777 and owner set to local admin or root propagated all the way down and then upgrading to 1.5 also with full 777 permissions all the way down via policy and it still breaks.

As it just so happens, Firefox is one of the apps that does this. I discovered the ever expanding Versions folder within Google Chrome a few months back and am deleting Chrome before the upgrade to cut down on the bloat anyway.

This would be another reason for my Feature Request to get implemented.

I use AutoPkgr to build my Firefox and Google Chrome installer pkgs now and I don't have the problem with either the expanding issue in Chrome or corruption in Firefox. I doubt JAMF will change the behavior of Composer as they don't see it as a problem. But I like your feature request and voted it up anyway.