Steven Frank, of Panic co-founder fame, is taking a stand against the iPhone.
When the app store first opened, there were some questionable decisions, and like most everyone, I was willing to forgive Apple a few transgressions as they were navigating new, exciting (and rocky) territory. Historically, Apple has made bad decisions, but they’ve generally corrected them. (The $100 refunds for original launch-day iPhone purchasers after the price dropped come to mind.) The boat may turn slowly, but nothing before has ever suggested to me that Apple are actively malicious.
But after an entire year of continuous bad decisions that are hostile to developers and consumers alike, we’ve moved on from “working out the kinks” to good old-fashioned getting fucked.
Every week it seems like there’s more and more developer backlash about App Store policies and the viability of making a living as an independent iPhone developer. I don’t blame them; right now the App Store is not a platform I would want to commit to. At the same time though, I’m not about to give up my own plans for the iPhone. Most of the apps I have in mind are companion apps to desktop Macintosh applications I’ve been working on over the past year or two. While I might make money on the iPhone apps alone, I don’t see them as a way to make rent as much as I see them as a way to augment and improve the work I’m already doing on the Mac. And I think most Cocoa developers will agree with me when I say that OS X is still a pretty sweet platform to write software for.
Jeff Atwood recently wrote about copy and paste coding, and those small, frequently reused code snippets that pop up at every programming blog or website.
To me, the most troubling limitation of copypasta programming is the complete disconnect between the code you’ve pasted and all the other viral copies of it on the web. It’s impossible to locate new versions of the snippet, or fold your features and bugfixes back into the original snippet. Nor can you possibly hope to find all the other nooks and crannies of code all over the world this snippet has crept into.
Attach a one line comment convention with a new GUID to any code snippet you publish on the web. This ties the snippet of code to its author and any subsequent clones.
I’ve been idly thinking about the same thing lately, especially since I’ve started using services like gist.github to share and view small code snippets. A good example is a category on NSBezierPath to add rounded rectangles, which I remember copying from someone 5 or 6 years ago when I first started with Cocoa. If I was using this in a project today there’s no way I would remember who it originally came from, or be able to tell (except accidentally) that Leopard added the same thing when it was released and now I don’t need to use the snippet at all.
I really don’t know if GUIDs are the best (or even a workable) solution. I don’t have anything against the idea, but how can you enforce it on every blog, code sharing website, programming forum, and so on? Still, when I think about a programmer’s dream world I imagine my IDE tagging these snippets with contextual information, popping up a window with text from a blog post just like it does with autocompletion.
One thing I’ve noticed more and more of lately is news of trojans appearing for Mac OS X. Take this, or this for example. These stories aren’t the result of a security issue, but of users trusting applications they shouldn’t, and explicitly authorizing them to do whatever they want to the system.
The reason I’m bringing this up is because there’s a rule every OS X developer should follow, one that I think is more important now than ever: never, ever use an installer unless you absolutely need to. I’ve seen a lot of applications use an installer when they don’t need it (especially cross platform applications), and if trojans like these become well known to the public conscious, you’re going to have a lot of potential customers trashing your app before even trying it.
So when do you need to use an installer? Obviously there are exceptions, but it doesn’t seem to me like there are many cases where you do. Preference panes can be installed with a simple double-click, and users can drag application bundles wherever they want (frequently I run an app from the disk image before I decide if I want to keep it). Even if you have good reason to put support files or background applications elsewhere on the hard drive, you can check and do this the first time the user opens your application.
From Mark Grimes, this ruby script for Xcode automatically copies the first seven characters of the latest git commit ID to your project’s CFBundleVersion Info.plist key. I’ve been waiting for something like this for a while, it works great and it’s very easy to set up.
I love it, indie iPhone developers bake cake representations of their applications. The iPhone development community is largely new and doesn’t seem to have the same sense of community as in the Mac OS X development world, so it’s great to see things like this pop up.
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.
Advantages
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.
Disadvantages
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.
Earlier this year I gave a talk (my first public presentation ever, actually!) at Johnny Rentzsch’s intimate and engaging C4[1] 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.
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).
Recently, Quentin Carnicelli of Rogue Amoeba asked if there were NSResponder methods that you could hook your “OK” and “Cancel” buttons to to dismiss a modal panel (or sheet). As far as I knew there wasn’t but, gosh darnit, that would be a useful thing to have.
To clarify what I’m talking about here, when you run your own modal window or sheet with “OK” and “Cancel” buttons (or some equivalents), you end up hooking those up to methods that dismiss the window/sheet, stop the modal session and return some code (either one for confirmation or cancellation). Most of the time, you end up writing the exact same code. It’s glue code that shouldn’t have to be written.
With STABS, you could build the release version of your app with debugging symbols, make a copy of the executable MyApp.app/Contents/MacOS/MyApp to keep, strip the executable for shipping, and then use the unstripped executable for symbolizing crash reports by giving a space-separated list of stack trace addresses to the command-line tool atos. Unfortunately, atos cannot currently serve this purpose with DWARF. Unlike STABS, DWARF does not include the debugging symbols in the executable itself but merely includes references to the intermediate object files, which do contain debugging symbols. You can usually find these .o files in a sub-directory of the build/MyApp.build directory. If you delete the object files after building with dwarf, you won’t be able to step through your app’s code. (With stabs, the object files are refuse.) You also won’t be able to step through the code if you strip debugging symbols from your app, even if you keep the object files, because the references to the object files will be gone from the executable.
Ultimately I think the trend is bad. Code signing itself is a neutral technology, but it gives incredible power to the system vendor, and that power is just waiting to be exercised and abused. I believe that the iPhone is serving as a testbed to see how users and developers will react to an environment with ubiquitous code signing and control. If it goes well I think we can expect to see our desktop Macs gradually move in this direction as well. Judging by how badly Apple’s developer servers were flattened during the SDK release it seems like there’s no way it won’t go well.