I am a Windows developer (with some iOS Objective-C experience) and I am trying very carefully to choose the correct language to make a fairly simple daemon for the MacOS.
The app will download and upload files, communicating with our .NET web services that are already in place.
The installation will be done by non-technical everyday users, so asking them to do a lot of configuration/scripting on their end is not an option. A sleak package is a requirement.
I see my choices as:
- Objective-C
- Java
- Mono
- Scripting
Objective-C has the advantage that it is native, but I’m not the strongest with this language yet.
Java is very easy, but do all users have it? Is it going to be a problem asking people to install it?
Mono will let me leverage my .NET skills, but will it install elegantly as a daemon?
Scripting may be an option as it is very simple what the app has to do, but is this the norm, to deliver a product like this?
—
EDIT
There will be no GUI. I’m okay with not hiding the code, although a UID/PWD will be necessary in order to access the webservices (different for each client). It will always be running, for all clients.
Objective-C/Cocoa or C (esp. using Core Foundation) would certainly give you the most native implementation with performance and OS integration benefits.
Java is reasonable and will be built-in. You’ll need some basic scripts to bootstrap it, but not much.
Mono is also reasonable and can be relatively easily installed by the user. You’ll need to point them at the download page and specify that they only need the runtime, but it’s do-able. Depending on licensing, you may be able to include the Mono runtime installer package within your own installer package so it’s installed at the same time as your daemon.
Naturally, scripting languages will most likely leave your code exposed and modifiable, so you may want to avoid that route if that’s of concern.
Regardless of the language used to develop the daemon, you’ll want to consider installation & management.
For installation, Mac users are used to two installation methods: installing via an Installer
.pkgfile that the user double-clicks and then is brought through the installation process or by dragging an application into their Applications folder and double-clicking to launch. As a developer, the former gives you a lot of control over including README/license text, running pre- & post-flight scripts, building meta packages to install one or more packages (as mentioned above re:possibly including Mono runtimes right in your own installer), and also gives the OS & user the ability to see what files will be installed, where, and when (post-installation) if they so wish. Alternatively, many daemons will be actual Mac OS X applications which will then install themselves as background processes upon the first launch. The former would be independent of your language selection, but the latter would lean towards a Objective-C/Cocoa implementation.This brings me to management. Most daemons will want to be run through
launchedas either a LaunchDaemon (for all users, typically launched at boot) or a LaunchAgent (for particular users, typically launched at login). If you integrate well withlaunchedeveryone will be happier and should be do-able in any of your language options.The question then becomes will the user need to manage the daemon at all? If so, this is most frequently implemented as either a MenuExtra or a Preference Pane. In either case, the daemon could be developed in any language and controlled (esp. via
launched) by the MenuExtra/Preference Pane, but in some cases the MenuExtra could actually function as the daemon and so you’d want to develop in Objective-C/Cocoa.See also: Apple’s Designing Daemons & Services documentation.