Make your Mac application work with IT

Some things you can do so that your Mac application fits in with Mac IT needs

One of the more frustrating things I run into are applications that would be a wonderful fit for the hundreds of people on my network, but are designed in a way to make it as hard as possible to deploy, configure, and manage. Developers would be surprised at how many times an application that isn't as good as theirs is chosen, simply because it needs to be installed, configured and deployed on a few hundred desktops, and the lesser application makes easier to do than the better one. Here are some simple tips to help Mac developers ensure their applications fit in well with the widest range of Mac IT tools.

  • Use Apple's installer. This is the easiest step, the one that really separates the wheat from the chaff. Don't use a proprietary installer, and don't assume that "drag and drop" are all you need. While 'just copying a file' is indeed the simplest way to do things, using a 'proper' installer package lets us take advantage of smarter installation tools, like Apple Remote Desktop's Task Server functionality, the command line "installer" utility, and others. Using a good installer makes it easier to include your application in our system images, and makes your application work better with various imaging tools. When you think about IT, keep in mind that quite often, we'll never use your application, but we will install it. Hundreds, or even thousands of times. We care about installationa lot. A poor installer experience that is resolutely manual, such as Adobe's Air, is a great way to encourage us to find other applications that will accomplish the same task.
  • Make your update mechanism remotely configurable, manageable and runnable. In general, IT is rather happy with update mechanisms that don't require us to download the update, push it out to machines, then run said update. However, if you're going to use Sparkle, or one of the other update mechanisms, then think about a few things. First, set up an announce-only mailing list that lets customers know when a new version is available outside of the in-app mechanism. This way, IT folk can grab the update and make sure it doesn't accidentally do strange things to our workflow. Secondly, give us a way to remotely turn off notifications of updates. There's a variety of reasons for this, but a big one is that when you're running a network, you don't tend to give users administrator rights on their machines. In that situation, notifying the user of an update just means they have to ask someone in IT to actually run it. Giving us the ability to turn notifications off means we can apply the update in a more rational manner for our network's needs. Finally, include a command-line component for your updates. You may not see the reason for this, but as I can batch out command-line operations via Apple Remote Desktop to hundreds of machines at once. If we can do silent/background updates, it makes it more likely that we will update your application faster, which is assumedly what you want.
  • As a corollary to number 2, if you have allowed yourself be talked into completely silent background updates, ensure the default setting for this is "off". Yes, I know, Google, and lately, Adobe love this, because it ensures that their stuff is always up to date. Well, it's also extra network connections to remote servers from hundreds, or thousands of machines, and it's a quick path to having to reinstall the application because an update is causing you problems the developer never thought about. I know quite a few sysadmins in high-security environments, such as weapons labs, and that kind of thing can get your application banned with no recourse until you change that functionaltiy. Making it an option is great, making it the default? Not so much. Also, when I update your application as an administrator, that is the last of it. Do not, under any circumstances, require an additional administrator authorization just to run the newly updated application as a non-admin user. This is the kind of thing that makes users and sysadmins alike say unkind things about and to you. Sysadmins are highly skilled at saying unkind things.
  • Make your application setup automatable, especially serialization. AppleScript is de riguer on the Mac, but make sure you can do this from the Unix shell. As with installers, having to manually set up applications, type in serial numbers, etc., makes us really dislike your application. Especially if your serial number is a string of 28 random characters. Allowing this to happen via scripting is probably better for both sides than relying on editing preference files/plists, because if you have your application setup/serialization be scriptable, you don't have to store your serial numbers in plain-text format. Once again, this can be the difference between getting hundred-plus license sales and not. (Just so you don't think I only beat on Adobe about such things, Apple is one of the worst offenders here. Trying to automate setups for iCal, Address book, iChat and Mail is far harder than it should be.)
  • Respect your preference settings. If you asked a hundred Mac sysadmins what one of the most annoying application behaviors is, a majority, if not all of them would mention Adobe Acrobat's bad habit of ignoring its own preferences. No matter how you set that application to not install the Safari plugin, when you try to update it, or half the time, just start the application, it insists on fussing at you about "repairing" the Safari plugin. Yes, you can set this in the application preferences, but if the application, or the updater ignores this, then there's not much point, is there. You Do Not Always Know Better. If a preference is manually set or changed, then your application needs to respect that. Period.
  • Include preference manifests with your application. For the uninitiated, a preference manifest is a XML file that contains information about the preference keys that can be managed for an application by Workgroup Manager and other Mac management tools. They are used in Managed Client for Mac OS X, (MCX) environments, which is closely analogous to Active Directory and Active Directory's Group Policies. With a good preference manifest, your application can be properly managed from a single directory, (usually Apple's Open Directory) by user, machine, user group, or machine group. This takes number four one step further. Instead of pushing out preference settings and serial numbers to each machine manually, we can set those preferences in one place, and then every machine or user pulls those settings off of the directory. Centralized management makes sysadmins love you, and love your application. It can also be of real benefit to you. For example, if you license per-machine and per user licenses differently, a properly done manifest can ensure that licensing is implemented properly. Per user licenses can be tied to that user, and will follow them regardless of what machine they log into, and per-machine licenses will stay with that machine. If you're talking about email/calendaring/groupware applications, then a good preference manifest allows for server information, account information, even signatures to be set up in one location, and applied to every user or machine without anyone having to do any work. If a user logs into a new machine for the first time, their account information is already there. This is the kind of thing that makes using your application across large networks a no-brainer, because it pretty much reduces the setup work from hundreds/thousands of machines and servers to one. That is the kind of thing that makes us encourage the writing of large checks to you.

I'm not going to say implementing these suggestions are trivial or even easy, I know they aren't. But these are the things that turn your application from an application that grudgingly works on a managed network to an application that is an enlightened citizen of that same network. Sysadmins, especially Mac sysadmins talk to each other a lot, and when we find an application and developer that took the time to make our lives easier while creating a great application for our users, we are going to make sure we talk that application up, and recommend it highly.

That's got to be worth some extra work, right?

Insider: How the basic tech behind the Internet works
Join the discussion
Be the first to comment on this article. Our Commenting Policies