carpeaqua

As I mentioned in a previous post, I have been spending the past few weeks working on a new iOS application called Elements. Elements shipped this week and its success has far exceeded my meager expectations.

Elements was built to scratch a small itch I had. For the past four years I have been writing a column in the Evansville Courier & Press. It doesn’t pay much, but it gives me a soapbox to talk to a large, local audience and it helps my grandparents understand what I’m doing¹. A few weeks ago I went back home to attend a family wedding and had the itch to give the ‘iPad only’ experiment a whirl. Unfortunately, the dreams were quickly crushed when I realized I needed to write my column while down in Evansville.

On my Mac I write exclusively in plain text using BBEdit. I like BBEdit because its just plain text, which is guaranteed to work on any platform no matter if they pay the Microsoft tax or sell their souls to Google Docs. I scoured the AppStore for a few writing apps, but nothing really stuck out to me. Moreover, not many of them shared data how I wanted. I used those needs and desires to craft Elements 1.0 to be just enough to write my weekly column.

When I created the initial Elements project in Xcode, I had it scoped out to be an iPad only application. Only as I was nearing the beta did I realize that it wouldn’t be much more effort to build an iPhone version as well. In fact, the iPhone port took approximately a day of development work. The iPhone version exposed another use for Elements: it’s a great notes platform. Having access to your notes on your iOS devices as well as access via the Finder is, as Fraser Speirs put it, comprised of win.

Doing the iPhone port also exposed some things I didn’t like about the iPad version. Namely, I ditched the UISplitViewController that I had initially designed with in favor of a grid-based layout a la iBooks and Reeder.app. I didn’t like how when in landscape mode the master view controller was always visible. This is a writing application, so the less distractions in front of you, the better. I’m still not 100% satisfied with the grid layout, but it’s a good start.

For syncing, I chose the Dropbox API for syncing Elements because it’s becoming ubiquitous. Unlike iDisk, it doesn’t require a $99/year subscription. Anyone can sign up and have more than enough storage for their Elements files. Their API is pretty good overall, though their Objective-C wrappers aren’t perfectly tailored to what I’m trying to do. Eventually I am probably going to have to bite the bullet and spend a week or two writing my own version based around operation queues. Having said that, there’s no way I could have built Elements as fast as I did without having that ready-made Objective-C SDK available. Kudos to the Dropbox guys for that.

The one downside to the Dropbox decision is that their API doesn’t really have the concept of merging or file locking. If you end up with a double dirty situations, the last one to sync will win out. It’s not exactly ideal in some cases, but I opted to move forward with it because using Dropbox as the platform was more than worth it despite the issue. I’m looking into ways I can detect conflicts and at least allow the user to choose one file or the other.

Elements was a five week project from the time I did my initial Mercurial import to submitting the 1.0 to the AppStore. I couldn’t imagine shipping a Mac app in such a short period of time. The iOS SDK has really matured since my last foray into app development. The SDK’s power coupled with the restrictions imposed by the small form factor devices make building narrowly focused applications relatively quick and fun. The fact that almost 3000 people have already downloaded the application is just gravy.