Question for indie Mac developers out there:
How do I implement a 30-day time trial in a non-evil fashion? Putting a counter in the prefs is not an option, since wiping prefs once a month is not a problem for an average user. Putting the counter in a hidden file somewhere sounds a bit dodgy - as a user I hate when apps sprinkle my hard drive with random files. Any ideas?
The least evil way is to just ask the user to delete the program after one month or pay for it ;)
Read an UUID from some hardware component and make a check against your web service to see if your software has already been installed for 30-days upon program launch?
We did it for one of our client application. Granted it was done in .NET for Windows, but the same principles can be applied in MAC.
Like eckesickle mentioned, if your user have access to the internet (or should), then you can have a web service that will register some unique id from the host computer with the starting date trial (MAC adress is a good one). With this, the user cannot really cheat the program unless he chances his network card every month.
Now, if the user doesn't have access to the Internet for some reason, you can either shut down the program until he connect to it or use a grace period. This file records the last time the app is opened. When the Internet is not accessible, we stop writing the time (we still write something in it so the user doesn't notice the file is not updated).
Should a user notice that this file contains the information and delete it (or change it using a copy he has), then you need a way to counter that. You can have some other value in another config file (encrypted always) and check for consistency. What you do if you discover that the user is trying to cheat is up to you, but we force the user to connect to the internet for it to work.
It might be overkill for a program, but it definitly works.
At the time of download, provide them with a trial serial number. When they enter the serial number, have it connect to your server and gets expiration information (stored and encrypted locally to prevent any additional "phone home" calls).
By doing it this way, you make it fairly hard for them to get around your 30-day window, as the expiration date is permanently stored on the server. You could set it up so deleting the key and re-entering it would cause your application to connect to your server again and download the same expiration date as before.
Or you can do it like WinZip does (or used to do it?): Provide a 30-day trial and just pop-up a screen at every load that shows how long you've been using it and links to purchase.
I would suggest to implement few of things which are less intrusive and may avoid a normal user to either uninstall or buy at one month period.
Additionally implement these things in the config file.
By doing the logging of timestamp you can avoid these workarounds:
Ensure that your app doesn’t run without the config file. So essentially you send the encrypted serial number in a file or maybe upon entering the serial number you can create file. Since the serial number already has the expiry date user can’t reuse the serial number also.
I would not suggest the internet way because people get pissed off when app tries to connect to server every time. Plus, one may get suspicious that you trying to send some personal data of users to your servers.
One thing I would like to say: No matter how strong the anti-piracy technique you use, someone is bound to break it. You are not making your app for those guys. You are making your app for people who would like your software and will buy it happily. So have the anti-piracy in limits without losing the genuine customers by making your application too intrusive during the trial period. One thought also says, if your software is getting cracked that means it’s getting popular also. Again opinions may differ and would not like to digress on these issues.
Consider this. How many potential users of your software are out there, just itching to use it solidly for the next 30 days?
I suspect the far more normal case is: Users encounter a new software package that solves a problem they've had on a site like lifehacker.com. the software gets downloaded, played with briefly, then put aside. Perhaps its mp3 ripping software and they don't have any cd's to rip at that time. Or they're just busy that day, but they'll get round to reviewing that software 'soon'.
30 days pass. Probably more. Only Then do they buy a CD, encounter some sort of 'problem' and remember, 'aha, theres that trial version I downloaded! Where did I put it again?' It doesn't matter. Without ever being used, the 'trial' has timed out.
I can't count the number of software tools that have fallen into that bucket for me. The day a piece of software is recommended to me, the day I see a positive review on lifehacker, is NEVER the day I actually have a need - or even the time - to use / analyse the program I've downloaded and intalled.
This issue comes up repeatedly on the cocoa-dev mailing list and the consensus answer is always do the simplest thing possible. Determined hackers will break all but the most over-engineered solution. And they're unlikely to pay for the software anyways. Go for the 80/20 solution: the easy solution that gets 80% effect for 20% effort. In this case, putting something in ~/Library/Application Support/your.app.com/. You might name the file something innocent if you want to obfuscate things just a bit. Using the user defaults is easy too.
Whatever you do, don't use the MAC address or an other hardware ID. Users with a network home directory (e.g. in a shared lab setting) will hate you. Using hardware IDs is just evil.
If someone is in love with your program so much that they're willing to break your trial limits, let them. The free software costs you nothing and their good will (and maybe recommendation to others) is worth a lot.
Finally, write software that people want to use and price it for its value. If your price is a good value and people want to use it, most people will pay for it.
Having the software expire after 30 calendar days is bad because what if someone downloads it, runs it once, and then decides they'll evaluate it a month later? Next time they launch it, a month later, it'll say it's expired.
I'd go with having it limited to 14 launches, or something like 120 minutes of use.
As for implementation, a file (hidden or not) in the user's Preferences folder, with an obfuscated name, seems like the best way to go. The file isn't randomly placed on the hard drive, but the user can't easily figure out which file to delete.