3 Replies
      Latest reply on Dec 12, 2019 1:15 AM by eskimo
      Rulovic Level 1 Level 1 (0 points)

        have MacOS application with no UI which is intended to be running all the time. Right now it is an .app which is controlled by script to start it again in case it gets killed.

        My question is, should I implement daemon instead?

        Also the application needs to take screenshots. In MacOS Catalina I need to give special permissions to allow that. Since it does not have UI I don't see any popup asking for permission. How can I display the popup? Should I force the display programatically?

        Thanks in advance

        • Re: MacOS application continuously running. Should I create daemon?
          eskimo Apple Staff Apple Staff (13,075 points)

          If the program needs to take screen shots, it must not be a daemon.  A daemon should not connect to the window server (because the window server might quit and relaunch while the daemon keeps running, and that causes havoc for the daemon’s window server connections).

          What you want is an GUI agent, that is, a background process that runs in a GUI login context.  Do you plan to deploy this via the Mac App Store?  Or independently, using Developer ID?

          Share and Enjoy

          Quinn “The Eskimo!”
          Apple Developer Relations, Developer Technical Support, Core OS/Hardware
          let myEmail = "eskimo" + "1" + "@apple.com"

            • Re: MacOS application continuously running. Should I create daemon?
              Rulovic Level 1 Level 1 (0 points)

              Hello eskimo,

              Thanks for your answer. My idea is to deploy not via Apple Store but independently, using Developer ID.

              Why does it matter?

              Thanks

                • Re: MacOS application continuously running. Should I create daemon?
                  eskimo Apple Staff Apple Staff (13,075 points)

                  Why does it matter?

                  Mac App Store apps must be self contained, which means they can only use one agent mechanism, a sandboxed login item, as illustrated by the AppSandboxLoginItemXPCDemo sample code.

                  A Developer ID program can do this, but it can also use a launchd agent or a traditional login item (using LSSharedFileListRef with the kLSSharedFileListSessionLoginItems list).

                  Still, even with those other options available, a sandboxed login item is probably the best choice IMO.  Given that it’s embedded within your app, it should inherit the app’s Screen Recording user data protection (although I must admit that I haven’t actually tested that particular configuration).

                  Share and Enjoy

                  Quinn “The Eskimo!”
                  Apple Developer Relations, Developer Technical Support, Core OS/Hardware
                  let myEmail = "eskimo" + "1" + "@apple.com"