Drawbacks of building a background-only COCOA app as a launch daemon?

Question

Are there any drawbacks of building a background-only COCOA app without any GUI and run it as a launch daemon. This would use:

import <Foundation/Foundation.h>
import <AppKit/AppKit.h>
import <CoreData/CoreData.h>

The primary advantage of using this and not building a objective-C command line tool is that It offers an implicit run-loop with benefits including well defined callbacks when application finishes launch or during termination. This would need to be explicitly implemented in a command line app.

Are there any disadvantages such as functionality break? Will the launch of the daemon be deferred?

Answer 1

For a daemon, there are serious drawbacks to using any non-daemon-safe framework. From Technical Note TN2083: Daemons and Agents – Layered Frameworks :

Layered Frameworks

Most Mac OS X functionality is implemented by large system frameworks. Many of these frameworks use Mach-based services that they look up using the bootstrap service. This can cause all sorts of problems if you call them from a program which references the wrong bootstrap namespace.

Apple's solution to this problem is layering: we divide our frameworks into layers, and decide, for each layer, whether that layer supports operations in the global bootstrap namespace. The basic rule is that everything in CoreServices and below (including System, IOKit, System Configuration, Foundation) should work in any bootstrap namespace (these are daemon-safe frameworks ), whereas everything above CoreServices (including ApplicationServices, Carbon, and AppKit) requires a GUI per-session bootstrap namespace. …

In summary, the concrete recommendations are:

• When writing a daemon, only link to daemon-safe frameworks (see Framework Cross Reference ).

• When writing a GUI agent, you can link with any framework.

• If you're writing a daemon and you must link with a framework that's not daemon-safe, consider splitting your code into a daemon component and an agent component. If that's not possible, be aware of the potential issues associated with linking a daemon to unsafe frameworks (as described in the next section).

Living Dangerously

If your daemon uses frameworks that aren't daemon-safe, you can run into a variety of problems.

• Some frameworks fail at load time. That is, the framework has an initialization routine that assumes it's running in a per-session context and fails if it's not.

  This problem is rare on current systems because most frameworks are initialized lazily.

• If the framework doesn't fail at load time, you may still encounter problems as you call various routines from that framework.

  • A routine might fail benignly. For example, the routine might fail silently, or print a message to stderr, or perhaps return a meaningful error code.

  • A routine might fail hostilely. For example, it's quite common for the GUI frameworks to call abort if they're run by a daemon!

  • A routine might work even though its framework is not officially daemon-safe.

  • A routine might behave differently depending on its input parameters. For example, an image decompression routine might work for some types of images and fail for others.

• The behavior of any given framework, and the routines within that framework, can change from release-to-release.

The upshot of this is that, if your daemon links with a framework that's not daemon-safe, you can't predict how it will behave in general. It might work on your machine, but fail on some other user's machine, or fail on a future system release, or fail for different input data. You are living dangerously!

Read the whole technote for the full details.