What is a common (acceptable) method to keep track of how many days a user has opened a “trial” version of an app.
This seems to be something a lot of other apps do. “This is day X of your Y day trial”
So somewhere it needs to either store an initial run date… or even better a count of unique date starts
I would like to do this in the same way everyone else does… the method isn’t the issue… it is where to put that data so the user doesn’t accidently trip over it
on first launch you create a preferences day.
You may want to store date there for first start.
than you can count from that and calculate difference.
To make it harder, you may want to store current date each time and just count how many different dates you have in preferences file. People may switch time zones or change computer time to trick you.
But if you have 30 days trial and you allow 30 dates in the hidden preferences file, that may work, even if people reset clock or make a6 week vacation break in-between.
As both a developer and a user I prefer feature-limited over timed trials. As a user, if I get sick or don’t have time to test something out, the trial can disappear without me having explored the app. As a developer, it’s just far easier to implement and rely on feature limitations than it is a timed trial.
I know AppWrapper’s timed trial hides at least one file. A commercial DRM engine I work with regularly also relies on hidden files to store that initial trial date. But even with hidden files and checksums, the user can still delete the trial information. There’s even command line and GUI tools for seeing what files were changed when on the whole system. One could sort by date to easily see what and where this hidden file is.
The common acceptable way is to store the trial start date in the preferences file. The user shouldn’t trip over it there. Hidden files are frowned upon, but are more reliable. Locations to store the hidden file are limited on macOS. You can verify the date online with a timestamp server if you feel that’s necessary. But if you’re getting into online verification, you could get into machine fingerprinting and verify / limit trials more reliably that way.
You could store the starting trial date on first run with some sort of encoding/scrambling and if somebody alters the encoded value the program could detect an invalid value and take an alternative action.
I have done encoding by converting things to HEX then add extra characters scattered in the string then scrambling the order and then altering individual characters in an way that made it seem random. If you use some sort of binary values it even makes it harder to edit.
Just some ideas.
There’s no perfect answer, but I’d sway towards @Tim Parnell 's answer, above. I have an app coming out soon, RVCare Logbook 3 - its trial mode consists of sensibly limiting access to features but not to the point of annoying the user. In the 90s, shareware used to nag and pester users in various ways to pay up. There was an app, I forget which now but I’m sure some Googling would reveal it, that famously played with a user if they didn’t pay up or were suspected of pirating the app, including deleting actual user data as a punishment. I’m not suggesting you were considering that, but stuff like that is from another era.
I’m staying away from time-limited trials because they’re so easily gotten around and they’re just not a great user-experience anyway.