Post

Replies

Boosts

Views

Activity

Reply to MacOS Application as a daemon or in non-interaction mode
Thanks Quinn. This has been immensely helpful and insightful. I still did not have a view on how the user would be managing the service component, and your response has led to a good provocation. I have a few followup questions so that I can take an informed decision on which path I should take for my product(s). What about someone using MacOS as a ‘server machine’ and administering it using ‘ssh’ only (i.e. there is no GUI session to this machine right now) ? What kind of application build will allow that to work ? Our observation is that if a bundled application i.e. a GUI program is run on an ssh environment without having a GUI session, the application crashes. The reason of the crash as per my understanding has been that in a non-gui environment, if any 'UI Code' (in this case, if any AppKit API) gets invoked, it crashes. What about possible ‘headless systems’ where MacOS is the ‘preferred OS to act as a server machine’ ? While MacServer is a discontinued product line, are these no longer considered ‘possible environments’ ? In such environments, would we STILL use a ‘Bundled App’ ? Basically, the same 'server program' is expected to be used by the user in the above setups or may have a GUI macOS environment which is more common to have. Also, while Server Program embedded in the GUI Program is seeming a more recommended path by using SMAppService. However, SMAppService is supported from macOS 13+ as per documentation. For my product, we are targeting macOS 11 as our minimum supported version. So would the 'installer package' option be our only choice then (apart from the above questions which can also impact the choice). Thanks! Regards, Abhishek
Mar ’25