Runner’s Log uses a license file for registration, instead of a typical 20 digit serial number. With a license file, instead of sending users a code they type or paste into your application, you send them a file that contains the serial number along with any other registration information. Usually this is just a plain text file, although it doesn’t have to be.
Lately I’ve been thinking about the advantages and disadvantages of one method versus another. Here are the major points I came up with.
- When done correctly, license files can be easier than typing in a serial number. Just drag the file onto your app, or double click it. On the other hand, if you only require one field for your license key, and handle copy/paste correctly, serial numbers are not that much harder.
- You can include whatever information you want in you license files. You don’t want to force the user to type in their name, email address, transaction number, but there’s no reason not to include these when you generate the license. It’s good to make sure to associate a license with a real life name or email address, to discourage casual piracy.
- License files (should be) very secure. I’m not saying you can beat software piracy, don’t believe anyone who tells you you can. What you can do, is prevent someone from creating a serial number generator for your app. Unlike shared keys or cracked copies, which you can fight by releasing updates and blacklists, a serial number generator can be especially damaging. As far as I know, using OpenSSL it’s possible to create a licensing scheme that can not be beat by serial generators.
- License files don’t always fit with other company’s distribution models. Right now I’m talking with a company about localizing and selling Runner’s Log in Japan, both online and in a boxed software bundle with other applications. Although I’m sure I’ll work it out somehow, they assume applications use a serial number which can be sent via email or printed out. I would guess that some of the other promotional bundles, like MacZot or Mac Heist, work the same way.
- License files can go against the way users expect applications to work, or interfere with the way they store license codes for future use. I haven’t had any specific complaints, but it’s possible some people might be annoyed.
- It takes a little more work to implement license files. You need to associate the .applicense extension with your application, implement methods for loading external files, and make sure your online store can correctly send attachments in the registration email. In my case, I also ran into some unicode text encoding bugs I had to rush to fix. None of these require big investments in time; what I’m getting at is that the little things add up, and I don’t know any developers who wished they had more on their plate right before shipping 1.0.
No matter which method you use, there’s room to make your application stand out if you put in enough effort. I remember seeing a mock-up of a license file that was actually a generated .gif or .png image. The image looked like a key card, complete with the user’s information and the license key shown as a barcode (the actual license data could be stored in embedded metadata or headers for your application to read). If you use license codes, instead of random numbers and letters you could use a series of four or five letter english words.
For the most part, license files have worked well for Runner’s Log. However, there has been a small amount of overhead that I would have rather avoided. I’m going to keep this in mind for future projects; hopefully this will help new developers who might be in the same position I was.
I know it’s old, but last week I finally got around to watching Cabel Sasser’s C4 presentation.
Earlier this year I gave a talk (my first public presentation ever, actually!) at Johnny Rentzsch’s intimate and engaging C4 conference in Chicago. Despite nervousness, it was really great fun. We had just recently finished Coda, and with one hour to fill and a lot of Coda-related things still swirling around my mind, I pretty much just started talking. What followed was a whole lot of hyper-warp thoughts about all things Panic.
The presentation is great; lots of insight into the visual design process at Panic, and some of the challenges of developing Coda.
One of the more interesting parts was at the very end of the audience questions, where Cabel talks about the differences between developing a “big” application (Coda) and working on several tiny ones. Apparently the small applications each had enough feature requests and bugs that they took nearly as many resources and time as creating a larger application, only the smaller price tag meant only a fraction of the profits.
From David Heinemeier Hansson’s blog:
So given all that, I think the Git move is even more interesting. That camp is competing not only to convince people that a new paradigm is appropriate for many things, but also as that it, one-out-of-many, should be the one to embody it.
I think they’re going to get it. Killer apps makes or breaks any platform. With Github, I think the Git hub just scored one. Rails is going to be hosted there for the launch. Capistrano, Prototype, and Scriptaculous already moved there.
Besides lots of public projects moving to Git, I’ve noticed developers asking about it on message boards, wondering what the big deal with distributed source control is and how they can move their existing Subversion repositories. I started using Git last year, so I’m glad it’s gaining popularity. Based purely on rumors I’ve heard, Git’s big competitor Mecurial is slightly better, but lacks critical mass from the developer community (and the blog posts, tutorials and tips that come from it).
Cultured Code writes about designing the user interface for creating repeating items in their upcoming task management application, Things:
It seemed fine in theory. But after implementing and combining it with the underlying logic, it took us only minutes to discover that it didn’t work as expected. Not that anyone was able to tell exactly why. And that’s often the case when developing user interfaces. It just didn’t feel right.
Looking at the sheer number of rejected designs, it’s no wonder why Things is my favorite task management tool at the moment.
Great writeup from Daniel Jalkut on examining crash logs with the atos command line tool:
Many developers seem to think that gathering useful crash logs requires shipping a symbol-laden application, but aren’t willing to do so. The fact is, you can have the best of both worlds by shipping a symbol-stripped version of your application, but keeping a symbol-laden version on-hand for the developer’s convenience.
What am I getting at? Apple offers a tool called “atos”, which makes it relatively easy to map an address from a symbol-stripped application to a name in a symbol-laden version of that same application. As long as the two applications were built with the same sources and using the same build options, the addresses are bound to match up. It’s just the symbols that are “stripped” from the shipping application.
One of the changes I made to Runner’s Log recently is a small update to some drawing code to better match the new look and feel of Leopard. Since I’m still supporting OS X 10.4, I had to determine at run time what operating system I’m running under. There are a few ways to do this, but the best method I found was to use the Gestalt system call:
SInt32 version = 0;
Gestalt( gestaltSystemVersion, &version );
if ( version >= 0x1050 )
// New Leopard specific drawing code.
// Old drawing code.
Easy enough; see this Cocoadev page for more information, including checking for older versions of Mac OS X. If it’s just API calls in the operating system you’re worried about, you can just check the function pointer for a null value before calling it. See the Cross-Development Programming Guide for more information.
Mac OS X 10.5 Leopard: the Ars Technica review:
DTrace and Xray invite good questions. “How many files does my application open on launch?” “How many times is a particular function called?” “What does the memory usage of my application look like over time?” DTrace and Xray make the previously daunting task of answering these questions almost trivial and (dare I say it) fun. I can’t imagine any Mac developer seeing Xray and not instantly longing to sic it on his application.
A Quick Objective-C 2.0 Tutorial:
There’s a lot more ground to cover, but this should give you a good start. We can look at more advanced topics in future tutorials. The 64-bit runtime has some features that the 32-bit version does not, such as the ability to synthesize instance variables. All of the hardware Apple currently ships is 64-bit, but we’re a ways off from 64-bit being a majority of the installed base.
Remember that all of the new features in Objective-C 2.0 are optional. Aside from some lower-level runtime functions and hacks, anything that was valid code in Objective 1.x is valid in 2.0, as well.
Get rid of your code with Leopard:
I’ve been using Leopard for the last few months, and I thought I’d post a partial list of new and improved APIs which may be of interest to Cocoa application developers. I’m going to classify these in terms of what you can do with them, rather than by class-name or other such relatively obscure aspect, and I’ll include some screenshots where appropriate. Please feel free to add your own observations via the comments. I’ll stick roughly to the order used in the AppKit and Foundation release notes, which you should also read if you’re serious about getting the skinny on what’s new in Leopard.
From iBanjo, on the topic of distributed version control systems in small corporate development environments:
In 2007, Distributed Version Control Systems (DVCS) are all the range among the alpha-geeks. They’re thrilled with tools like git, mercurial, bazaar-ng, darcs, monotone… and they view Subversion as a dinosaur. Bleeding-edge open source projects are switching to DVCS. Many of these early adopters come off as either incredibly pretentious and self-righteous (like Linus Torvalds!), or are just obnoxious fanboys who love DVCS because it’s new and shiny.
And what’s not to love about DVCS? It is really cool. It liberates users, empowers them to work in disconnected situations, makes branching and merging into trivial operations.
Shocking statement #3: No matter how cool DVCS is, anyone who tells you that DVCS is perfect for everyone is completely out of touch with reality.
I’ve been using git, a popular distributed version control system, for a few months (and I’ll write about it soon).
Long-term, within the next two years, if not far sooner, I feel certain there will be various ways for developers to write iPhone software. (In fact, in Gizmodo’s transcript of the same Q&A session with Jobs from the D conference, they quote Jobs’s response to the question of third-party iPhone development as follows (emphasis added): “This is a very important trade-off between security and openness. We want both. We’ve got good ideas, and sometime later this year, we can open it up to third-party apps, and keep security.”)
I’m looking forward to seeing what sort of options start to spring up once the iPhone is officially released. I had a few neat ideas for possible applications back when it was first announced, and I’d still like to pursue those.