Subscribe to
Posts
Comments
NSLog(); Header Image

Demo Options for Mac OS X Software

In a few weeks, Analyzr will ship. It will come in two versions, eventually priced at $49.95 (Home) and $495 (Pro).

As I see it, there are roughly four options for handling "demo" versions of an application like this. I hope to get some insight from some other Cocoa/Mac developers and even users as far as what's feasible, reasonable, etc.

This is not a post about registration codes, but about enforcing the "demo mode." We're happy with our registration code and aren't looking to tweak that.

If you'd like to talk to me confidentially, send me an email or an IM. If you can say something publicly, please feel free to use the comments.

  1. Time-Limited per Version - The application runs fully unlocked for x days (5, 7, 15, 30, whatever), x launches, or a combination of both. If a new version is released, the time period starts over, allowing users to check back with the app to see if it meets their needs down the road.
  2. Time-Limited per Launch - The application runs for a set length of time, often measured in minutes, before quitting and/or becoming severely crippled.
  3. Feature Limited - Not every feature works or is fully functioning. These features "unlock" when you register.
  4. Trial Code Registration - A trial license gives the user x days to try the software. The software thus has two registration states: registered with a trial license or registered with a purchased license.

There are others (like making a separate downloadable file that's only capable of being a demo), but they're too silly to discuss here1.

Additionally, Analyzr employs a watermark for un-registered copies, so any sort of demo limitations we'd add would be in addition to the "hey, there's a watermark on the screen."

Let's explore each of these options in more detail…

Time-Limited per Version
We like this idea, but definitely not the "x days" version because if you launch an app and then forget about it for two weeks, you might not get to launch the app again until an update is released. "X launches" might not work because you could just leave the application running, particularly if you're a golf professional and the machine on which Analyzr is installed isn't used for much else. Conceivably, software updates that require a reboot might be the only reason to quit the app!

But the biggest fail point I see with this is that you have to store the date (or launch count) somewhere, it's relatively easy to bypass. I'm not a fan of spending a lot of time trying to thwart piracy, but if the solution to getting $500 software for free is "delete your Finder preferences" then you've probably got a problem on your hands.

Time-Limited per Launch
This can take a few forms, from an app that quits after 10 minutes (often it will show you a modal dialog first) to an app that cripples itself after 10 minutes (10 is just used as an example).

For example, Analyzr could run fully featured for 10 minutes, at which time it could display a modal dialog box prompting you to buy. After five more minutes, you might get the dialog again. After the second dialog box, they might begin appearing every two minutes - long enough between them to let you use the app but often enough to "annoy"2 users mildly.

One other downside here… I believe it would be relatively simple to find a method call or some point of failure, hack the binary to return "NO" or "YES" as appropriate here, and the dialog would never appear.

A final variation is a startup wait counter. GraphicConverter does this, and you must wait progressively longer with each launch. The problem here is similar to the problem with the first solution: where do you store the file so that users can't just "reset" it easily3.

Feature Limited
Most of the time, this works really well. It's not the easiest method to crack if you do some basic obfuscation and other things, and users can use the demo forever until they finally decide to buy.

The downside is that you can't show off your application's to its fullest. What features do you disable to make the software "usable enough" and not so unusable that people aren't really sure what they'd be getting by paying?

Trial Code Registration
This one can go a few ways. You can grant users an x-day license whenever they request them so long as their email address has not requested a license within the past y days. That's overkill for a $50 app for sure, and still awfully close to overkill for a $500 app. I haven't seen many consumer or pro-sumer apps doing this.

It does open a conversation with the customers, but at the expense of confusing a good percentage of them. How many "conversations" in terms of "people downloading and being able to try your app" are you giving up on and since it's probably automated, does it really count as a "conversation" anyway?

Where Am I Currently?
I think the best option right now combines the feature limited option with the trial code registration option for the Pro version.

Second place? Time limited (5 or 10 minutes for Home, 10 or 15 for Pro perhaps) with the Trial Code registration for Pro.

In the first instance, we have to be careful on choosing which features we limit, but we have a bit of an out - if a Pro user sends us an email, we can manually4 create a license which contains an expiration date. If the current date is past the expiration date5, the app would fall back to the un-registered state. A purchased license wouldn't contain an expiration date.

The second instance would work similarly, but would simply remove the time limit while the app was "registered" with either an expiring or a purchased license.

I think those two options present the best possibilities. We can be a little gentler with Analyzr Home and just do one, with the fallback for Analyzr Pro to offer a time-limited demo. Since the date is encoded fairly securely in an encrypted file, it's reasonably secure, and still "keeps honest people honest" in ways that some of the other apps could fail6.

Your Input
User or developer, what's your take? Share it with me in the comments if you can say something publicly, or privately via email or IM.

Thanks!

Footnotes

  1. Assuming I've thought of all of them.
  2. I don't want to annoy potential customers, but the word probably fits and there are degrees of annoyance…
  3. The first launch should probably always be without delay, so the answer is definitely not "just set a long launch time by default."
  4. If this became too big a burden to do it manually, either we're making mad bank or we made the demo way too limited.
  5. We'd have to do a basic check to make sure the user didn't set their clock back.
  6. Honest users are more honest with apps that cost $19.95 than $495!

12 Responses to "Demo Options for Mac OS X Software"

  1. I didn't see it listed there, and I'm not familiar with what Analyzr does, but there's also the option that apps like 1Password employ that limit how much you can create before you need to buy a full license. Being able to try that app out, un-restricted for as long as I wanted (so long as I didn't create more than 15 entries), really helped in my purchase decision.

  2. Like 1Password, Analyzr uses a centralized database (it's not document based), but I'd consider that a subtle variation of "feature limited demo." 1Password allows "unlimited" passwords, and so that feature is limited to 15 or so in demo mode.

    Analyzr (basically) plays back movies and lets you draw on them. There's an image here: http://iacas.org/f/analyzr.png. On the left, you'll see a library that is unlimited in the Pro version and is limited to 25 videos (and just the "OTHER" section) in the Home version. So it'll be trickier still to get the right number if we limit the number of videos. If we did this, we'd probably let the user import as many videos as they wanted, but only load a small number into the players. We'd "disable" the rest. (That way we'd maintain compatibility with databases created by registered and unregistered copies of the app. If I have a registered copy and send you my database full of 50 videos, we wouldn't want the app to show the user only a few videos).

    The other problem is this: since Home limits the user to 25 videos, if we set the limit too high (like 1Password's 15) then Home users might just use the Pro demo and not sweat the loss of 10 videos!

    We could bump the Home limit from 25 to something higher (Home is also limited to just having "OTHER"), with a demo mode of something "reasonable" like 10, but I don't know…

    More food for thought, but I think it's on the path I'm looking at already - feature limited + possibly an expiring license for Pro users who want to test it out for a week or two.

  3. For the "Home" version, I could see something like import max 2 videos for x minutes. After X minutes, you can't import new videos but you can still "play" with what you already have displayed in the two panes.
    For the "Pro" version, also limit the imports (per categories, too) and have a time limit, with the option of a trial code.
    Not to forget that having a "home" version is already in a way a trial for the "pro" version...

  4. Christopher said on January 11, 2011:

    Not to forget that having a "home" version is already in a way a trial for the "pro" version...

    It is, but there are of course several things you simply won't be able to do in the Home version (registered or not) that you can do in Pro, so it's not the best "demo" particularly since you'd have to register Home to get all of the features it has to offer. 🙂

    1. Agreed. But then perhaps the Pro version should only be offered with a trial code that limits use to x minutes?

      As for import and load, I apologise for the confusion. I mean that you can import any two videos -once-. After that the database is locked and the time limit kicks in. You can quit/relaunch, but you won't be able to import any other files. However, you can load over and over the two videos you imported initially, but you'll have the time limit every time you launch the application.
      If you only import one file, you cannot delete it from the database but you can import one more.

  5. Use a trial license locked on (hash of) mac address and date. When the app starts afresh, reach out to a web server to acquire a license based on the version/mac(hash) and then use that to do x days.

    If the user starts fresh, they will make a request which you can deny based on prior request data, or simply give back their old trial license.

    This will require network the first time only but since they have likely just downloaded it they probably have a connection in any case.

  6. You don't have to worry about the hacked binary if you use codesigning.

    Have you considered automatic trial serial generation ala Jolly's Fast VNC?

    From what you've written, I'd suggest limiting demos to x minutes of drawing per video. Or maybe a percentage. Or allow only one video at a time to have 100% usage. Anyone who'd go hunt for a file to delete everytime they want to use a new video probably wouldn't pay for your software anyway.

  7. What if you go with a combination of time-limited per launch and time limited per version... i.e. limit the demo to 30 days (or launches; whatever you want) with a 10 hr. limit per launch; this way you give the user plenty of time to do work but you don't have to worry about somebody just leaving the demo open because they only get 30 days anyways. I know the other issue was somebody potentially launching it and then forgetting about it until the time is up (if you went with time over launches) but really those people that neglect it for that amount of time probably weren't interested in it anyways really.

  8. Thanks for the feedback. I have some emails too but naturally those will not be commented upon here and will be kept private.

    A few responses here...

    Alex Blewitt said on January 12, 2011:

    Use a trial license locked on (hash of) mac address and date. When the app starts afresh, reach out to a web server to acquire a license based on the version/mac(hash) and then use that to do x days.

    I'm generally pretty leary of "required network access." I think people are largely over the "phoning home" behavior but I don't like to assume that someone can access the Internet.

    Additionally, these are pretty easy to fake. And though most golf professionals aren't hackers, if I were just a golfer I certainly have the skills to do it, so piracy of the Pro version by potential Home customers would be a bit more of a problem than I think we'd like.

    Mark said on January 12, 2011:

    You don't have to worry about the hacked binary if you use codesigning.

    We're going to look into that, yeah... If we do a timer or something then that will be quite relevant.

    Mark said on January 12, 2011:

    Have you considered automatic trial serial generation ala Jolly's Fast VNC?

    I don't know how that works. Hadn't heard of it. Can you describe, generally, what that app does?

    Tristan said on January 12, 2011:

    What if you go with a combination of time-limited per launch and time limited per version... i.e. limit the demo to 30 days (or launches; whatever you want) with a 10 hr. limit per launch; this way you give the user plenty of time to do work but you don't have to worry about somebody just leaving the demo open because they only get 30 days anyways. I know the other issue was somebody potentially launching it and then forgetting about it until the time is up (if you went with time over launches) but really those people that neglect it for that amount of time probably weren't interested in it anyways really.

    I think that's easy to overcome, though. And I'm not saying that the "Golf Pros" who will use "Pro" are 1337 h@x0rs or anything, but there will be Home users who will figure out how to hack Pro if the answer is as simple as "it stores a date in an external file." We'll be out $50, but they'll feel like they've "stolen" $500 in software.

    Currently, I have two solutions in mind…

    Both solutions include a tiled watermark rather than the rather unintrusive watermark we have on the software now. We think that for most pros the watermark will be enough to prompt them to buy because it will look really bad to their customers, but we can't be sure and we don't want potential Home customers thinking "I don't mind the watermark."

    Solution 1:
    Demo limited to 10 minutes, after which time you can't draw anything.

    Solution 2:
    You can only load two (or three, or four, or whatever) videos into the players, by any method. Otherwise, you can do whatever you want for as long as you want. But after two videos are loaded, you can't load any more.

    These limits would be the same in both versions of the software because we think the watermarking and the second layer is enough to get a potential home customer to fork out the $40 to $50 for a Home version and not just use the Pro version.

  9. I think solution 1 would work out fine... It gives the user just long enough to do something but then cuts them off... I assume with this solution it would reset when the program relaunches, would there be a limit on the number of launches?

  10. Tristan said on January 12, 2011:

    I assume with this solution it would reset when the program relaunches, would there be a limit on the number of launches?

    Probably. We could include a counter somewhere in the database file itself and if the user exceeded that number, we could limit them to five minutes or something, but that seems like too much effort. If someone doesn't make up their mind after 20 uses (to make up a number) then they probably aren't buying it anyway.

  11. [...] this post - the comments on which were tremendously helpful, both public and private, so thank you to those [...]


Trackback URI | Comments RSS

Leave a Reply

Please abide by the comment policy. Valid HTML includes: <blockquote><p>, <em>, <strong>, <ul>, <ol>, and <a href>. Please use the "Quote Me" functionality to quote comments.