PKG doesnt always install into Applications

I keep getting complaints that having installed a new app, the customer cannot find it/still has the demo.
Using PKG to install apps on OSX is a bit of a game of chance.
If the app it is replacing has been deleted (but the Trash not emptied), OSX will ‘helpfully’ install the new version into the Trash!!

I’ve been wondering is there is any way around this, and the following snippet I found online suggests that there might be, but the trail has gone cold.

My bold…

[quote]Using terminal to install a pkgs contents

for f in *.pkg ;
do sudo installer -verbose -pkg “$f” -target /
done
As an alternative you can install the packages to your home folder with -target ~. They will end up in /Users/<your_account>/Applications unless a specific path is predefined in the installer.
[/quote]

Does anyone know how to predefine this specific path?

If the install destination is fix, then you should set ‘relocatable’ to false. Might also be ‘allow relocate’. Can’t check on the phone…
Otherwise the installation will look up where the user has moved the app (bundle id), and you get that described (in most orher cases expected…) behavior.
I hope Packages has that ‘relocatable’ support/option and that you’ll find it. It might be what you’re looking for.

This Article explains the effects of the ‘relocatable’ setting for a .pkg

[quote=481194:@Jeff Tullin] keep getting complaints that having installed a new app, the customer cannot find it/still has the demo.
Using PKG to install apps on OSX is a bit of a game of chance.
If the app it is replacing has been deleted (but the Trash not emptied), OSX will ‘helpfully’ install the new version into the Trash!![/quote]

The Apple pkg replaces the app, wherever it is. If the demo has the same ID, then it replaces the demo.

Also note that if you’ve run your app from your Builds folder or moved the original to the Trash, installer will happy install your new version into the Builds folder or Trash, so make sure to only run your app from /Applications and empty your trash.

Jürg Otter has pointed to a good article about this, and the relocate option.
Simple packages (like the ones currently produced by AppWrapper) don’t have that option, and it doesnt seem to be possible to amend the plist file contained within ,after it has been created.

I may have to pivot back to DMGs again (im getting dizzy) , or switch to another way to generate the PKG files for a while

A disk image would not resolve a pkg issue. For applications that need an installer to perform elevated tasks or install daemons simply moving to a disk image is not a solution.

I took a look at the demo installer for MacStitch, and I don’t see anything in the manifest that requires an installer. This software could be distributed using the ZIP option in AppWrapper.

Ah, I somehow thought you are using Packages (probably because there has been another thread mentioning that product). And Packages has that relocatable-option :wink:
And in the mentioned Article there is a link on the bottom to quickpkg. That seems to simplify creating own custom/simple pkg’s, too - and has the relocatable-option built-in.

I’d look at that linked quickpg…

True.
Nothing fancy.
Just irritating that I cant rely on the app ending up in Applications.

Sadly, a ZIP file doesnt really fit.
My users are not typically the sort who would unzip then drag an app to Applications.

DMG with a ‘drag and drop’ thing used to work reasonably well, (even though some people would run the app from inside the DMG, then wonder where it had gone when the DMG was unmounted.)

A PKG is nicest since App Wrapper generates it easily, and when all goes well, the app can’t be used until installed.

I used to build installers way back when installing fonts on Mac was a pain the you know what.

The only time I kneed a pkg today is to do my auto update, and App Wrapper"s pkgs are basically enough.

To distribute my apps outside of the MAS, I sign with App Wrapper, and build and notarize the DMG with DMGCanvas. Much simpler for me, and for the user. I hate those apps that cannot be uninstalled by simple dragging to the trash.

Judging from the picture at http://s.sudre.free.fr/Software/Packages/about.html, though, showing an install under Snow Leopard, is Stphane Sudre aware that we are now 9 system versions away ?

Don’t judge this book by it’s cover. The software is regularly updated, a recent update added dark mode.

Packages appears to have solved the (admittedly minor) problem nicely, at the cost of a little extra prep time on my part.
As a bonus, the package also has the ability to make the user quit a running app before allowing the install.
(This was another cause of issues: if the app was running while the installer for an upgrade was used, it didnt overwrite)

So , although I know Sam has some good stuff cooking,
my interim process is:

Build.
Use App Wrapper to code sign but not pack
Use Packages to create a nifty package and codesign it at the same time.
Use App Wrapper to Notarise the result.
Works a treat.