Mac app issues
-
Thanks @pico. Good info.. My app is built with JavaScript and Electron, so I'll start by looking for a Node module to handle this.
-
I found this after a quick search: https://www.npmjs.com/package/auto-launch
Looks reasonable... has options to add a LaunchAgent or to use AppleScript to add an item to the Login Items (which I forgot you could do via AppleScript).
-
@pico, thank you. I'll probably use that unless it gives me trouble. I'll also need to figure out a way to get the app to install to /Applications because right now it just unzips to the folder where you download it to. I figure wouldn't be good to make an entry in Login Items that points to an app in your Downloads folder.
-
@russ It's not uncommon for apps to just unzip themselves into the Downloads folder. I feel that people should know to move it to the Applications folder but who really knows.
Some apps include code to alert the user if they launch the app outside of the Applications folder and the app offers to move itself. This can be clean and nice but is more complex code-wise.
One common solution that is simple for the user and doesn't require any code is to deploy the app in a Disk Image (.dmg). The Disk Image can be customized with a background image and a link to the Applications folder for the user to drag the app to the Application folder from within the Disk Image.
Users should be used to this because this is how apps like Chrome and Firefox are deployed but I have seen people screw it up. Since the App Store just takes care of all these things newer users may have trouble no matter what.
If you want to go the Disk Image route, I'd recommend DMG Canvas: https://www.araelium.com/dmgcanvas
It costs $15 but it makes the process super simple to do all the nice window customizations and makes it all work properly on retina or non-retina screens. The custom Disk Image can be done without an app but I think it can get pretty tedious, when I looked into it years ago I just went for using DMG Canvas since I liked the ability to design and customize it all within the app. -
Also, I've continued to notice that sometimes TRIGGERcmdAgent agent doesn't get launched on login even though it's in the Login Items.
This is not an issue that I'm used to seeing so I think it must be something with the app rather than an issue with macOS launching it on login.
Does the app have any logs that I can look through or send you? I search Console app but nothing came up. I'm assuming things are logged differently because its not native code.
-
@pico, thank you for the DMG Canvas tip. That definitely seems like the way to go.
The log is here: ~/.TRIGGERcmdData/debug.log
I'd be interested if you see something in there when it fails to start during login.
-
@Pico, I published a new version of the agent that uses a DMG installer. It works nice. I'm glad you encouraged me to do that.
I ended up using this because it's free and it does the job: https://www.npmjs.com/package/create-dmg
This is what it looks like:
-
@Pico, I published a new version just now that added a Login Item so it starts up automatically when you login.
-
@russ Awesome and awesome!
Great that you found a free DMG maker, I'll have to check that one out myself!
Sorry I've been busy and hadn't checked back on this thread sooner. I'll check out this new version tomorrow.
Earlier, I did quickly check the log you pointed me to and didn't see anything relevant. Only stuff about messages received etc. Nothing about any failures or crashes. But I wanted to dig deeper before getting back and just haven't had time yet.
-
@pico, about that, figured out how to reproduce the problem. If I download the agent from the Internet, then run it, the first time it runs, it hangs and I have to force-quit it.
I actually implemented the LSUIElement change you suggested (which worked great btw), but I had to undo it because you can't force-quit an application if it doesn't have a dock icon. I had to kill the pid from a terminal shell.
I'm still working on fixing that first launch after downloading from the internet issue.
EDIT: I fixed the first launch issue. Thanks for all your suggestions @pico!
-
Just a flyby 2c: I think Mac users are in general familiar enough with command shell, ps and kill (you kind of have to be if you have a mac), so as a tradeoff, fixing the two big bugs is worth the inconvenience, particularly since force-killing TC isn't something I've ever needed to do.
-
@dewi-morgan, these problems are fixed now in the latest version. Let me know if find out they're not fixed.
-
This is great! Sorry I didn't get back sooner, I didn't have email notifications turned on and I hadn't checked back on this post until today. But, I just turned on email notifications for new posts so I'll see this stuff sooner from now on
I just installed the latest version and it launched just fine on first run after download.
I wanted to be sure everything worked properly for new users so I deleted the app and all the trigger command config files to see a true first run with the token prompt and all... It worked perfectly!
I did find a new interesting bug though...
When I quit the app with the "GUI Command Editor" window open, the window is closed but the app doesn't quit. All attempts to quit the app after that don't work as well.
I had to Force Quit the app. As an aside, you can Force Quit headless apps through the GUI with the Activity Monitor app. In Activity Monitor you can select the app and then click the "Stop Sign with an X" icon in the toolbar and there is a button to Force Quit. Also, from the command line, you can use "killall TRIGGERcmdAgent" so that you don't have to fuss with finding the PID. But I find sometime I have to run "killall" multiple times to make it work.
With more testing, this seems to also happen if I open the "GUI Command Editor" and then close it manually and then try to quit... the app still doesn't quit.
I found that this doesn't appear to be an issue if the "Text Command Editor" window has been opened or if no windows have been opened. In those cases the app quits properly.
-
Just noticed that when I trashed the app and re-installed it, the app added itself to the Login Items multiple times.
-
@pico, is it possible you have two Login items because you added one, and the app added another one? I tried and I wasn't able to re-produce the problem.
-
@russ I was just able to reproduce it again doing the following steps...
-
Remove TRIGGERcmdAgent from Login Items
-
Launch TRIGGERcmdAgent (which adds itself to the login items).
-
Trash TRIGGERcmdAgent (but the references stays in Login Items).
-
Reinstall TRIGGERcmdAgent from .dmg and launch it.
In the end, I have two references to TRIGGERcmdAgent in my Login Items.
Shouldn't it not matter how TRIGGERcmdAgent was originally added to the Login Items though? The app should just check whether or not it is already in there no matter what.
Is there different code for adding itself to Login Items on first run vs other launches? Cuz the app doesn't keep adding itself to Login Items on every launch.
-
-
@pico, I was able to reproduce it this time. I'll fix it soon. Thank you for telling me.
EDIT:
I published a new version. I made it so it only adds a Login item the second time you run it. That should avoid the duplicate.The downside is now you don't get a Login item the first time you run it.
For some reason the first time you run it after downloading, it can't determine whether there's already a Login item, so added one anyway. All I could think of was to disable adding one if it's the first time running after downloading.
-
@russ I know it's been months, but I was recently working on an unrelated app and have realized a likely reason why TriggerCMD login item would get added on first run even if the app was already in the login items.
The first time a Mac app runs when its been downloaded from the internet, it is quarantined by the system.
An app can check if it's running in quarantine because its execution path will include a folder called "AppTranslocation".
A simple fix could be to detect if the app path is in this qaurantine folder and, if so, check if the app exists in /Applications. If it does, then use the /Applications path instead of the path the app returned for itself for the login item.
If for some reason a user didn't install it in /Applications then there's no loss in falling back to waiting until the second run.
-
@pico, that's interesting. I'll experiment with that. I hope it works. Thanks for the suggestion.
EDIT: I worked on it for a while and didn't get it working. I couldn't get it to add the Login item while it's quarantined. I think that's a mac security feature for apps downloaded outside of the app store.