Every Good App Should…

If you had to describe the basic functions you would expect all MacOSX apps to provide, which would they be?     I’m not referring to the most basic, capabilities such as  the fact all apps should support (where appropriate) cut/copy/paste/unlimited-undo and the ability to work with multiple documents .. Think about something a little more …utilitarian…

Any Ideas?  Well, if we look at most popular Mac apps, the support a range of features that have noting to do with the purpose of the app itself but are designed to make using the app a better experience in terms of supporting the user as a developer.

Typically modern MacOSX apps can:

• Update themselves – they talk to the developer’s server periodically and let the user know if there an update available
• Notice if they are running of an installation medium (like as a disk image  a.k.a DMG file, or from a DVD) and offer to move themselves to the /Applications folder
• Support in-app purchase of the app itself or cleanly connect to your on-line purchasing system and support license key recovery
• Allow users to provide feedback or request support, and, with the users consent, report application crashes so you can find/fix bugs
• Support syncing of their data to external storage systems such as MobileMe’s iDisk or Amazon S3 to help the user backup/safeguard their data

In this article we’re going to discuss how each of these is possible with almost no work on your part and how a  collection of other Indie Mac developers have generously removed several hundred hours of programming from your plate and enabled you to provide a better experiences for your customers.

So let’s start with the basics…

Software updates:  There was a time not so long ago that if you wanted your users to know about an update to your app, you sent them email.  If you were very avant garde you wrote some custom code to talk to your servers out on the Internet and checked the version your user was running against your current version and prompted the user to go to your site and download an update.  All very low tech, error prone, and for most users a pain in the neck. Worse, for you, as an indie developer, more often than not users were missing critical software updates and you were left fielding support questions and the occasional irate user complaining to your support email — or worse — publicly cursing you out on the Internet.

As MacOSX started to mature several of the leading Mac indies, like OmniGroup created their own in-app update systems which had the ability to check software versions and download updated versions.  However, this is not exactly a trivial process if you think about it, there ’s a lot of moving parts in a software update, you have to (at least) make update/download decisions based on:

• Software version and hardware platform of MacOS your user is on
• Software of your app the user has
• Is the upgrade a freebie or a paid update?
• (Potentially) check serial numbers against whitelists or blacklists of pirates serials
• Ensure that software downloaded isn’t corrupted, incomplete or perhaps even a trojan.

This is just a short list of things to consider — then you have to be able to actually download the software and cleanly install it on behalf of the user.  Additionally, you want some mechanism to track who is downloading your software — hopefully anonymously without personally identifying info so you don’t freak out the user — so you can gather some statistics about upgrade patterns and kinds of machines your apps are being used on, etc.  Implementing such a facility is clearly not trivial, though a number of developers did roll their own versions of such code, its one of those utility functions that  takes dozens of hours of coding to do minimally, hundreds to do right. Eventualy someone would make

Enter Andy Matuschak.  In January of 2006 he released the first version of Sparkle, and introduced the concept of AppCasting (think “podcasting” but for application distribution) to MacOSX developers.  Sparkle is an Objective-C framework that normalizes and democratizes software updates for MacOSX. The concept is simple, the Sparkle framework “phones home” to an update server specified in your app’s info.plist and checks for software update packages.  Your update package can have release notes, digital signatures and other features to provide the user with information about  the update and to ensure that the update is valid and not malware in disguise.  Sparkle can be set to check for updates on a fixed schedule by the developer or it has hooks so you can let you users decide how often to check; it can also optionally send back system profile info to your servers so you can gather data about software versions and platforms using your apps.  Sparkle takes care of downloading and installing the update package for you.  Its very rare these days to encounter a MacOSX app that doesn’t use Sparkle  - so much so that users have come to expect that apps will notify the, automatically if there’s an update. Sparkle is also very versatile and can be used to update apps, preference panes and other kinds of OSX code.

Automatic installation:  We’ve all done it, right?  Run an app from the “Downloads” folder?  I’ll bet your mom or some relative tries to run applications from DVDs or off of DMG (disk image) files.  While the former is bad form, the latter can actually cause apps to fail, especially if they try to to create temp files or perform other actions that just aren’t possible when the application is run from read-only media. It used to be the case that all Mac apps used Apple’s or a custom package installer (such as app vise); but that has fallen out of favor for most Mac apps bcuase, well, unless you’re MS Office:Mac or XCode, most apps just don’t need the level of sophistication or the complications of a stand-alone installer .  Most apps really just need to be dragged into the /Applications folder.

Today, many apps that are downloaded via DMG often show the user using the DMG background screen how to install the app (Firefox and Adium for example show literally show you how to drag the app to an alias for /Applications), but even with this graphical hint, it’s surprising how many people don’t actually move their apps. It would be really nice if there was a way for apps to notice they weren’t actually installed correctly and offer to correct the problem for the user.  Fortunately two Indie Devs have created and Open Sourced such a utilities: LetsMove by PotionFactoy’s Andy Kim and M3InstallController by MCubed Software’s Martin Pilkington are both are small Objective-C utility classes that will perform this check an offer to move your app for the user.  Its a great idea and a convenience that adds a lot of polish an app.

InApp Purchase:

One of the hardest things in any seling situaion is geting the user to “pull the trigger” on the sale; the resistance go actually pushing the “chck out” button is known in marketing curcles as “friction.” If you talk to mareting experts they’ll al tell you that the easier you make for a user to buy something they’re interested in the more likely they are to do it.  So, how do you reduce purchase friction and get the user to make the purchase?  Well, on the iPhoneOS platform, Apple has provided a whole in-app-purchase API for allowing user to interact with add-on content or services your app might provide.  Given there is no one-stop point of contact for OSX application purchases somehting more general is needed.  One such solution is to setup a copy of the PotionStore an Open Source eCommerce web application by Andy Kim of Potion Factory and then install its companion application component the PotionStoreFront.  PotionStoreFront provides a clean and easy mechanism that will let your potential customers purchase a license to your app while using it.  All of the interactions happen inside the app all of the communications with your online store is hidden behind a nice facade and you can even install any license keys, if required,  which saves the user one more step once the transaction is complete.

If rolling your own online store isn’t something you’re comfortable with, Kagi and eSellerate, two of the large eCommerce fulfillment systems also offer in-app purchase systems.

Feedback and problem reporting:

The ability for users to connect with indie developers is very important.  If you have written any software you are probably already dealing with “over thr transom” kinds of email that flow into your support mailboxes.  Of course these are usually very unstructured and you have to send time to read through, categories qnd deal with each one.  With a feedback module such as   FeedbackReporter or JRFeedbackProvider you can integrate feedback and other kinds of reporting (like crash dump reporting) directly into your app and have the messages delivered over the Internet to your server.  The big benefit to this is that you can set up the feedback system so the user will (hopefully) give you a more structured report which you can then apply some processing to to help sort and categorize it, which will help you answer customer questions more efficiently.

And, lastly, we come to…

Saving Data to External Services

Everybody these days is talking about cloud computing.  What does that mean to you as an App developer?  Well, cheap storage up in the cloud (like MobileMe’s iDisk, or Amazon’s S3 service) is an opportunity to help your users help themselves.   One thing most users (and, let’s be honest,  most developers) are really bad at is acting in their own interest and ensuring their data is safe by making good off-site backups.

Really great MacApps in which users place their most valuable information (like VooDooPad, by Flying meat Software, which is wonderful personal Wiki) have built in mechanisms that allow their users to create backups, or even sync data between multiple copies of their application.   Beside the issue of backups, even using an app from you desktop machine and on the road from your MacBook should be easy if your apps support syncing.  So, how do you make backups or even finely grained sync services happen?  Well, one way is through the use of an Open Source package like ConnectionKit, which is an Open Source framework for managing file uploads/downloads to and from HTTP/ WebDav and FTP/SFTP servers. You could also roll your own uploading/downloading mechanism through the use of native classes such as Cocoa’s NSURL classes, but ConnectionKit will save you dozens of hours of work.

Another route to go, if you are just interested  in MobileMe, is using the Sync Services built into MacOSX.  This will allow your app to work just like Calendar, AddressBook and all the other apps that use MobileMe as a data repository.  Of course, the down side is that you are demanding your users sign up for MobileMe in order to use this feature which might not be in their plans.   Whichever route you choose, giving users the ability to back-up or sync their data does a lot to add to your app’s value proposition.

This has been a pretty long piece, but hopefully its been a useful exercise exploring how to add value and polish to your OSX apps!  Is there anything else that you think should be “out of the box” type features for Mac apps?  Let us know – we’d love to get your thoughts; drop a note to code (at) macindie.com; we’ll update with article with the best of suggestions we get.