An iPhone app developer’s diary, and some thoughts on Android

The reaction to our new free iPhone app has been tremendously positive — if you’ve got an iPhone and haven’t downloaded it yet, I suggest you hop to. On my post announcing the app, there were a few comments I wanted to respond to. First, this one from Robin Sloan, who wants a little background on how the digital sausage got made:

I’d love to read a little mini “developer diary” about the behind-the-scenes process here — tools/frameworks you used, surprises along the way, etc. Bet it would be useful to a lot of folks working on iPhone apps at news organizations, too!

So, for those interested, here’s my tale of how the Lab iPhone app came into being — a tale I hope lots more news organizations can tell. Because if I can do it for a total cost of $624, there’s no reason more newspapers shouldn’t be on the platform.

Building with frameworks

I’m nerdier than your average journalist, and I’ve done some small, basic projects in Xcode — Apple’s development environment for Macs and iPhones/iPads — before. But there’s no way I could have built this app without the help of a framework. Frameworks are tools to abstract away layers of complication — they take a variety of common tasks and handle them for you, leaving you more time to deal with tasks specific to your app. (You may have heard of Django and Ruby on Rails, popular web frameworks for building web applications.)

The framework I used is TapLynx, which is aimed at building apps from one or more RSS feeds. It’s built by Brent Simmons, best known in the tech world as developer of the first great RSS reader for the Mac, NetNewsWire. Much of the guts of TapLynx uses the feed reading and parsing code from the iPhone version of NetNewsWire.

With RSS feeds as a base, the decisions around content are both more restricted and a little easier. We produce one major RSS feed — our posts. Another one comes from our Twitter feed. So those were obvious choices as the first two tabs. In TapLynx, creating tabs is largely a matter of editing a .plist file in Xcode with some simple customizations and editing an HTML template for the display of the individual story pages. If you don’t know any HTML or CSS, you’d find the latter a challenge, but the templating language is simple enough.

Beyond that, I knew I wanted to embed some of the best publicly available feeds related to journalism, so that the app could be a concentrated shot of news-about-news. And I also wanted it to be a tool that would also promote some of our friends here around Harvard. So I added a tab that would pull in some of those feeds called Friends of the Lab. That created some new challenges, since some of the feeds were malformed in a variety of ways. One didn’t present post dates correctly, so I ended up removing dates from the presentation of all feeds in the tab. (TapLynx, unfortunately, won’t let you customize presentation for different feeds in the same tab.) I also had to build in a few template-file CSS hacks for feeds that presented images incorrectly.

Shoehorning Hourly Press in

The most challenging tab (and the one that still needs some work) is the Hot Links tab. (The name is a slight nod to my Cajun heritage.) It uses Hourly Press, the great web service built by Steve Farrell and Lyn Headley, to pull in the most linked-to links in the future-of-news Twitterverse. For THP we define a set of “authorities” (see ours here) on Twitter; the people they follow end up having more weight in the system than people they don’t. Once an hour, everyone’s tweets are scanned for links, weighted according to how much authority the system gives them, and then output in a top-10 list. It’s perfect for those moments where you want a quick jolt of the biggest news of the moment, but curated within our particular field of interest.

Because TapLynx is optimized for RSS feeds, it’s a challenge to deal with HTML, which is THP’s output. I asked the THP guys to build an iPhone version of the rankings, formatted for the smaller screen and big fingers. But TapLynx works better with static HTML than with live web pages. So I ended up having to use a plugin called OOZWebView, built by Roberto Brega and expanded by Walter Tyree. It allows for some very basic web access in a tab. I even made a few changes to the code to allow user resizing of text in webpages — the only real Objective-C I wrote. It’s not perfect — refresh behavior is unreliable, particularly in iOS4 with state saving, and the UX looks as hacky as it is. But it was the best way available. (Any Objective-C coders want to help make it better? Lemme know.)

Lagniappe

Beyond that, the search tab just uses WordPress’ little-known search RSS feed to dive into our archives on command. There was a fair amount of Photoshop work to create transparent PNGs at precisely the right size (and again at twice that size, to look good on the better Retina Display of the iPhone 4). I built a few of the tab icons myself as greyscale PNGs with transparent alpha channels; others I took from the Glyphish collection of icons, including the Retina icons just released via Kickstarter. For the static About page and the Twitter template, I ended up using data URIs to embed our icon into the HTML itself — that prevented a weird resizing when the image was loaded after the rest of the page. And I, like many app developers, had to navigate the new waters of Twitter’s xAuth system (newly mandatory as of a few weeks ago) to allow tweeting from within the app.

All this is to say that the process was more complicated and self-directed than most people would be able to manage — but easy enough that any shop that has a Mac and a few nerds could pull it off. There’s nothing impossibly hard here. From my viewpoint, I don’t understand why more news organizations don’t use frameworks to build out apps quickly and easily. Even if the ad revenue from a mobile app isn’t astounding, it’s still better than nothing — and it’s a foot in the door for increasingly mobile news consumers.

One constant throughout the process was that there were factors outside my control. Our app would have launched sooner if Apple hadn’t made the move to iOS 4, which necessitated waiting for a new TapLynx library to work with it. It would have launched sooner if the impending Twitter xAuth switchover hadn’t made me wait. It would have launched sooner if I wasn’t relying on the generous work of guys like Roberto and Walter to made one of my tabs function. And, frankly, it would have launched sooner if I wasn’t doing all this work on evenings and weekends around my other duties — or if I’d been happy with something closer to the TapLynx defaults in a number of cases.

Now comes the challenge of keeping the thing up-to-date and functional. They say a band has a lifetime to write its first album and six months to write its second; I feel the same thing is true for version 1.0 and version 1.01. I’ve already got a list of improvements and fixes ready to move on. I’d love to hear any suggestions on how to make it better.

On Android, BlackBerry, WebOS, Windows Phone, Symbian, et al.

Back to my original post. Another thread of comments — on the post and on Twitter — were from people upset there’s only an iPhone app. “Nothing for Android, huh?” one commenter wrote. “Seems shortsighted.” Others on Twitter called out for a BlackBerry app, or an iPad-specific app. (I didn’t see any calls for Windows Mobile/Phone, Symbian, or WebOS.) There are a few reasons why we’re just on the iPhone right now.

We’re tiny. The Nieman Journalism Lab is currently three people in a basement. (Two iPhones and one BlackBerry, if you’re counting.) Along with being director, I’m also house nerd. Our budget doesn’t allow for big investments in technology, which is why I ended up building the iPhone app as a personal side project. I’ve been a Mac guy since the early 1990s and an iPhone guy since 2007, so my own personal interests and knowledge base are going to play a role in what I develop in my spare time.

If, as some predict, Android sweeps aside the iPhone and becomes the dominant platform on mobile, then maybe we’ll build an Android app. But for now, we’re just putting our limited resources where we think they can have the most impact.

We need the tools. As I said above, if there wasn’t a framework like TapLynx to make the process easier, we wouldn’t even have an iPhone app. Google’s new App Inventor would seem to be a move in that direction, but the initial reviews I’ve read don’t make it seem particularly user-friendly. (And this TechCrunch piece indicates “there isn’t any RSS functionality baked in” App Inventor, which would limit its usefulness for our purposes.)

That said, I don’t pretend to be up to date on the latest state of Android development frameworks — or their equivalents on other platforms. If someone out there is interested in volunteering to help build an Android (or WebOS, or BlackBerry, or Windows Phone, or Symbian) version, I’d love to hear from you. We’ve got no animus against other platforms; we just don’t yet see an audience big enough to justify our scant resources.