One is it just builds the binary, runs it through SHA1 (or whatever), and stores that digest somewhere in the installation directory. But what's stopping attackers from just changing the digest? They have access to the application, so they can know exactly how to generate the digest; all they have to do is run the bundled digest function in gdb, copy the output, and then search for it in the installation. Even if the author tried some sort of obfustication (xor, deflate, reverse, etc), such attempts would show up in the binary and could be trivially duplicated.
A second is that the digest is somehow pre-computed for a binary before it's built, then included in the binary itself. But I don't see how this is possible with secure digests. And if the method is simple enough that it's worth using for typical iOS applications, what prevents an attacker from pre-computing a digest for the cracked version?
Traditionally, the way of doing this is by making that 'can know' step very difficult. Techniques to accomplish that include refusing to run under a debugger, multiple layers of protection, self-modifying code, loading the digest code from disk block checksums, from between tracks on a floppy disk or from blocks marked bad (back in the day when there weren't that many layers between application code and hardware), etc.
A lock does not have to be unbreakable; it just has to make breaking it costly enough to discourage even attempting breaking it.
With hackers, though, that does not quite work. They see even attempting to break the lock as enough of a reward in itself.
Skype (which has notoriously complex obfuscation) had this problem for a short time when Mac OS X 10.5 was released:
You can work around this by validating only the important subset of the Mach-O contents, but it's probably not worth it. Cracked applications (rather than, say, reverse engineered serial number generators) are an annoying thing to use -- you'll have to refrain from applying updates until you get a new crack, trust the person distributing the crack, etc.
It's not something I (or, afaik, most other small Mac developers) really worry about.
The first rule of software engineering is you never let the shareware stuff do it all. Test version should not save? Rip it out. Shouldn't print? Remove printing. Chop it out wholesale.
If you do an unlocking scheme, then make it subtle. Take a hint from Unix development: dont tell the user that the code worked or not. Just take the code or whatever. Tomorrow, then tell the user if it's a bad code.
And if it's in the blacklist, don't tell the user at all, and instead start introducing subtle errors everywhere. "What, you saved it yesterday and now it doesn't open? Whoops (snicker)." Or, misalign printing so anything looks good for a draft but not 'professional' use. Or you could go the obvious route of slapping a banner on it, but that is usually easily removable.
The idea here is to be subtly annoying up to the point of just doing nasty shit to the data worked with in your program. And of course, give error codes in a form of a md5sum that tells the company if you're a pirate or not.
But as I said earlier, put the time you would protect the program instead as improvement to make your program do its task better and easier. Crackers find these to be challenges. They just crack to keep their chops up.
"Gee, I'm sure glad I decided to pirate [program], it's buggy as hell. Better warn my friends..."
I'm not sure if this is true or not, but it kept us all on the straight and narrow. :)
There were of course ways to work around it (load then save with the same version under the free license, or export the entire design as text using a ULP and then import in the new version). But on the whole, it struck me as frustrating the process just enough to encourage users who would possibly pay, to pay. (I wonder if Cadsoft made even more from unlocking design files. "You are having trouble opening that design because your fly-by-night consultant used a pirated version of Eagle. We'll happily unlock it for the cost of a deluxe license.")