Episodes has been doing fairly well on the App Store and I’m currently working towards a v1.1 release that should introduce a few UI/UX improvements as well as social integration. In the meantime, I wanted to take some time out to introduce my second iOS project: Hardly Working.

Hardly Working was initial conceived to answer the age old question: how much am I being paid to poop? More over, how much is Jay-Z being paid to poop? Suffice to say, we took the idea and ran with it. Hardly Working is where we ended up.

It’s a cute little utilities application that takes your annual salary (or hourly rate), pairs it with the amount of time you spend at work, and tells you how much you’re being paid to perform various activities. It’s full of crude humour and it’s fairly goofy, but that’s kind of the point.

You’d be mistaken, however, for thinking that such a simple premise advocates a simple execution. From the very beginning of the apps development cycle we were intent on making Hardly Working as beautiful as possible. The result is an application that is chalk full of little visual flourishes. From the LCD timer, down to the animated paper receipt your earnings are printed on. Hardly Working isn’t your standard utilities application. We wouldn’t flush our reputations down the toilet for anything less.

Episodes hit the App Store a few days ago and thankfully users seem fairly pleased with the work we’ve been doing. Here are the release notes for the inevitable Episodes v1.0.1 release. The purpose of this release is to fix a few stability issues as reported by users and polish a few bits and pieces.

• Stability improvements.
• Increased feedback during network failure events. It’s now slightly more clear when requests fail.
• Increased feedback while searching (Episodes now lets you know about minimum search term length and when search terms turn up empty) as well as recommendations.
• A tool tip will now appear when you first open a show within your watchlist, making the process of rating shows explicitly clear.
• The Watchlist remove buttons visibility is now dependent upon whether or not your watchlist is empty.
• All animations have been ported to their iOS4 block equivalents, meaning animation should be much smoother.

The 1.0.1 release has been packaged and is now awaiting review by Apple. We thought it more important to get a stability/polish release out after initial user feedback than wait for a significant point release to patch up any stray issues. We’re hoping to introduce a few additional, exciting features in 1.1.

But for now, enjoy Episodes!

In a recent iOS project it was necessary for me to update the appearance of certain UITableViewCells based on their position within their parent UITableViews. Matt Gallagher wrote a wonderful piece for Cocoa with Love entitled Easy custom UITableView drawing which covers the basics of creating custom UITableViewCells.

As part of the exercise, Matt assigns separate backgroundViews to cells dependent upon whether they sit at the top, middle or bottom of their parent UITableView. By querying the UITableView for the cells indexPath it’s fairly easy to ascertain where things sit. Things only become slightly more complicated when your UITableView handles dynamic insertions/deletions.

Due to the nature of UITableViewCells, you’ll soon notice that existing cells are cached and recycled in such a way that cell backgroundViews quickly appear out of sync. Dependent upon how the user interacts with your UITableView, a UITableViewCell with a backgroundView intended for cells at the bottom of your table may shift up towards the middle, and so on and so forth.

I had a few ideas as to how I would go about solving the issue, but after spending a few hours consulting the iOS documentation, I decided to contact Matt directly with regards to ‘best practice’ in a situation such as this. I thought for sure there would be some delegate method or function I was otherwise missing that would allow me to dynamically adjust a UITableViewCells appearance. After receiving a helpful reply from Matt, the answer seems to be: there is and there isn’t.

The simple solution is to force the UITableView to reloadData after any insertion or deletion occurs. While this works, it has the unfortunate side effect of being fairly inefficient. It also tends to interrupt or stall the animations associated with the aforementioned actions.

Luckily, the nature of UITableViewCells means that scrolling the offending cells out of, and then back into, view will cause them to ‘course correct’, which means we’re only left with dealing with visibleCells. As luck would have it, getting a list of currently visible cells is fairly trivial. Matt’s solution is fairly simple in practice. First, we iterate through all visibleCells within the offending UITableView and then we force a reallocation of each of their backgroundViews via a custom method I’ve called: configureAppearanceOfCell:atIndexPath:

The configureAppearanceOfCell:atIndexPath: method itself is no different to Matt’s original approach. I’ve simply isolated it to ensure I can call it while iterating over visibleCells but also when my cell is first created as a result of calls to tableView:cellForRowAtIndexPath:. Here’s what it looks like:

- (void)configureAppearanceOfCell:(UITableViewCell *)cell atIndexPath:(NSIndexPath *)indexPath 
{
	NSInteger sectionRows = [self.tableView numberOfRowsInSection:[indexPath section]];
	NSInteger row = [indexPath row];
 
	// Set our rows background dependent upon its positions
	UIImage *rowBackground = nil;
	UIImage *selectionBackground = nil;
 
	/* Logic to assign your backgroundView and selectedBackgroundView here */
 
	((UIImageView *)cell.backgroundView).image = rowBackground;
	((UIImageView *)cell.selectedBackgroundView).image = selectionBackground;
}

Where you choose to iterate over your UITableView’s visibleCells is really a matter of implementation. If, like me, you’re making use of a NSFetchedResultsController, I’ve found the controllerDidChangeContent delegate method to be the most suitable place for it.

- (void)controllerDidChangeContent:(NSFetchedResultsController *)controller 
{
	[self.tableView endUpdates];
 
	for (UITableViewCell *cell in self.tableView.visibleCells) 
	{
		NSIndexPath *cellIndexPath = [self.tableView indexPathForCell:cell];
 
		[self configureAppearanceOfCell:cell atIndexPath:cellIndexPath];
	}
}

And that’s it! I’m interested to hear of other peoples solution to this issue.

Earlier this afternoon I submitted the first build of Episodes to the App Store. For all who don’t know, Episodes is a native iOS reimagining of my popular webapp Showtime. When Showtime was initially released it was amidst widespread debates over the future of the mobile platform and the significance of web-based solutions over native development. I thought it would be interesting, as a sort of retrospective, to look back at the development of both Showtime and Episodes. To try to decide whether there’s a clear cut ‘winner’ in terms of both the internal development cycle and the final product.

Development

I’ll start from the beginning. Development, for the most part, was fairly straightforward. I began by trying to summarise what I hoped the Episodes application would accomplish and then moved onto thinking about how it could accomplish those things. In terms of approach, nothing changed dramatically between either project. I compiled a feature list, created wireframes, discussed design and interface elements with my designer, and then I got to work.

Books have been written concerning the intricacies of both HTML5 and Objective-C. I don’t intend to go into any great depth regarding the difficulties I faced in developing either application. I would argue that, in terms of development time, Showtime came to fruition well before Episodes even became usable. There are a number of factors here. For one, I’m a web developer by trade. I’ve only recently branched into software development (starting first with an enterprise Mac application, and then using Episodes to get acquainted with the iOS platform). That said, I believe that were I to continue development of native iOS applications in the future, they would see a much shorter turnaround.

When approaching both the iOS platform and web-based development I relied heavily upon the MVC design pattern. Meaning, simply, that I kept logic and presentation separate where possible. In fact, I found the defining factor in terms of development time to not be based on business logic, but rather the creation of views. The simple fact of the matter is that HTML5 and CSS make it easier to style visual elements. I would say that the majority of my development time on the Episodes project was spent subclassing or otherwise manipulating standard UI classes.

In terms of business logic, I would say that the two platforms (or approaches, if you will) are pretty evenly matched. Episodes stores its internal data via CoreData, Showtime makes use of Local Storage. There’s really very little difference in anything logic related. XML is still a pain to parse and deal with. Error handling is still a drag.

Of course, where HTML5 wins in terms of presentation, Objective-C gains in terms of speed. You get more bang for your buck. But is this really something you can hold-up and celebrate? I’d speculate that in a few years client-side solutions such as Javascript will be almost impossible to distinguish from native applications in terms of speed and fluidity.

Testing

For me, developing a native iOS application became particularly interesting during the internal testing phase. This, in my opinion, is where the two approaches really start to diverge. With a web application, you upload it to a live environment and then make the link available to your testers. In order to control the environment you have a few options, ranging from managing user accounts to the extremes of restrictive firewall access.

With the iPhone, restricting your beta testing is certainly a lot easier. It’s just unfortunate that producing the beta build is a lot more involved. You’ll need to use the iPhone Member Center to configure and ultimately sign your binaries for AdHoc distribution. You do this by providing Apple with a list of your beta tester UDIDs. Each of which need to be collected in some form or another, which invariably means having a conversation about how a user can find their UDID ten or twenty times. (If someone tells me they can’t copy their UDID from within iTunes one more time, I’m likely to go thermonuclear).

With your beta builds distributed, it’s time to start collecting error reports. Much to my surprise, this proved to be far, far easier when it came to native application development. There are a few reasons for this:

• iOS devices are, quite famously, a very closed platform. This is frustrating for many users, but a godsend for developers. Because, ultimately, bug resolution is a three stage process: identify the issue (usually due to a user report), reproduce the issue, fix the issue. If a user told me they were experiencing an issue on their device, I could almost instantly reproduce it on my side. This is the antithesis to website development, where stage two of the bug resolution process – reproducing the issue – often involves some form of virtual machine or a specifically configured browsing environment. Which brings me to perhaps my biggest gripe with the pro-web app crowd: web application development may be open, but it’s almost impossible to create a standard build to run across all devices.

  You design for the space you’re given. Were I to design a web application to run on the HTC Desire HD, I would need to re-implement the majority of its user interface to work well on the Xperia X10 Mini. Of course, it would run from a technical perspective. But to the end user it may as well not.

• Bug reporting was made effortless on the iOS platform due to the Xcode tool suite. Crash reports sent by users were symbolicated automatically (usually giving me the offending line number) and timestamped by the Organizer in an easily browsable fashion. The majority of issues were resolved in a matter of minutes.

Release

Dun, dun, dun.. Enter the dreaded App Store distribution process. But is it really that terrible? Is it truly enough to turn developers away from native development altogether? After using iTunes Connect (Apple’s App Store distribution medium) for a month or so, I’d say probably.

This section should be a no brainer to the majority of the people reading this. Releasing web applications is just easier. Case closed. But that’s not to say that the App Store doesn’t have its advantages. Take, for example, the fact that Showtime is a free application. Episodes, on the other hand, will run you $0.99c (£0.59p for us Brits). I wouldn’t even dream of trying to monetize a mobile web application in the same way that the App Store allows me to. The bottom line is that for such a lowly one-time fee, it’s just not commercially viable to setup an entire proprietary payment process. Not to mention the time involved in handling refunds, complaints and general administration. With the App Store, that process is taken care of for me. I just have to jump through a few flaming hoops first.

What kind of hoops, you ask? Well, there’s the two months I was without access to iTunes Connect due to an internal error on Apple’s side. That required four phone calls and over twenty-five emails to fix. And then there’s the process of providing all of my tax and banking information (Negative. I am a meat popsicle). Which, I believe, comes down to the heart of the entire debate. It’s that edginess over putting your name, and in some cases your livelihood, in the hands of a company notorious for its secrecy. During my iTunes Connect issues I was left in the dark for days and weeks at a time. I often wondered, what if this wasn’t an evening and weekend project? What if I were relying on this application to put food on my table?

But there are some positives to the iTunes Connect process. For one, it terrifies you. But that’s a good thing. I read a number of unofficial release guides before I embarked on the process of submitting my application. I learnt that, for the majority of developers, applications see their largest sale spike when the application is visible in the ‘New Releases’ section of the App Store. Which, in basic terms, means you’ve got one shot to get everything about your release perfect. This lead me to go through my final testing with an added intensity which I can honestly credit for the fix of a potential crash bug.

Finally, it’s obvious from browsing Google that the iOS platform and the submission process has matured fairly swiftly in a short period of time. Approval turnarounds are significantly better, and the process of generating provisioning profiles, as well as archiving and submitting your application builds are all far more informed.

Conclusion

A number of journalists seem to have developed a ‘piss or get off the pot’ attitude when it comes to the native/web application debate. You are either for or you’re against. When I developed Showtime, I was fairly agnostic. I found the use of HTML5, CSS and Javascript to create an application that felt native to be fairly impressive. Yet, although I have received many subsequent requests to expand Showtime to other webkit enabled devices, it remains an iOS only web application. Why? Because I never approached the project with a ‘write once, run everywhere’ mindset. I don’t believe such a solution can or will ever exist. How can you write an application for a device you have never used? Logistically it’s a nightmare. Ethically it’s a sin.

Which surely means that the iOS platform has won me over? That I’m a proponent for the rise and rule of native applications? Not so much. I’m a tremendous fan of the iOS platform and I believe that, in terms of mobile hardware, you can’t get better than an iPhone. But Objective-C is a steep learning curve for outsiders, and the platform is still as closed as it has ever been. Perhaps the only solace I can find in that regard is that Apple still seem invested in HTML5, given the recent iAd announcements. While I believe Apple will remain fairly shady, fairly secretive, I have faith that their engineers will always seek the best solution to difficult problems.

And that’s all anyone can really hope or aspire to do. To use the best tool for the job at hand.

Over a year after launching Showtime, an iPhone web application for keeping track of your favourite TV shows, I’m pleased to announce Episodes.app. A native approach to tracking the TV you know and love on your iPhone and iPod Touch.

We spent months pouring over the hundreds of support and feature requests we received for Showtime and feel that Episodes.app is, in every way, a worthy successor. We can’t wait to show you guys what we’ve been working on. To wet your whistle, here are just a few of the things we’re most proud of:

• An episode and series database over twice the size as that of Showtime’s
• Full, historic episode summaries and screen captures available in-app with a single tap
• A personalized recommendation engine and star rating system dedicated to helping you find your next favourite show
• Handy application badge counts for at-a-glance notifications of unwatched episodes
• A new powerful search feature

I’ll be giving Episodes.app a more detailed write-up (specifically, the decision to switch from web app to native) in a future article. But for now, signup to be notified at episodesapp.com.

Neven Mrgan recently posted an excerpt of an IRC conversation in which he confronts users over the supposed piracy of his iOS game, The Incident. During the course of the conversation many users congratulate Neven on The Incident (as they should), but ultimately tell him that it’s a “way of life”, that he’s just going to have to learn to “deal with it”.

For me, the most interesting aspect of this entire conversation was that Neven seemed almost surprised to find his videogame circulating amongst the pirate community. After all, isn’t this the same Neven who works for Panic, one of the Mac’s largest and most respected software houses? Surely Panic must deal with this calibre of theft on an almost daily basis?

But that’s exactly the point Neven is making here. Panic deals with piracy like a business. Because Panic is a business, right? The Incident, on the other hand, started as a passion project. A labour of love. The two are mutually exclusive. It’s a black and white distinction, surely?

Not so much.

As a long time Panic customer, and an avid fan of The Incident, I can tell you that the likes of Transmit and Unison are just as much passion projects as any iteration of The Incident. The same care and attention to detail went into both projects. The only differential here is that Panic works out of an office, and Big Bucket Software works out of their respective homes.

When I purchase software, be it an iOS application or something for the Mac, I look at it as an investment. Sure, I’m getting a fantastic piece of software, but I’m also letting its developer know that I support their efforts. That I’m glad they spent those two fateful days in front of a whiteboard. Because in the end, everyone benefits.

In many ways, I think the success of the App Store has caused a lot of problems for the indie developer. The press parade various rags to riches stories and, inevitably, people assume that the majority of developers are getting rich quick. The reality of the situation is that the majority of App Store developers are probably operating at a loss. Because the cold truth of it is that good application development is an expensive process.

But one that certainly deserves to be rewarded.

I’m tentatively pushing Rhombus out into the world today. It’s been a fairly simple evening and weekend project of mine for a while now. Rhombus’ objective is simple: archive and deliver price changes on the Steam digital content network. To make the data as accessible as possible, users also have access to an RSS feed and a Twitter account. Currently, Rhombus comes in two flavours: tracking both the US and UK versions of the Steam store.

The reason for Rhombus’ existence is simple: I love videogames and great deals. Rhombus combines the two.

I recently added HTML5 cache manifest support to Showtime in an attempt to decrease load times for users on older hardware and for those with spotty network connectivity. As Stoyan Stefanov mentions: the current iPhone will not cache individual components if they are larger than 15K and will wipe all caches when the device is powered down or restarted.

This represents an inherent issue with using the jQTouch library for iPhone-related web app development. Although jQTouch keeps itself fairly focused in terms of support (and thus lean), jQuery is bloated by its necessity to support all manner of rendering platforms and browser technologies. At the time of writing, a minified version of jQuery 1.4 will weigh in at about 72KB. As a result, jQuery must be remotely served each time your web application is accessed. While there has been talk of forking the jQuery codebase to shave away all non-essential (specifically, non-Webkit related implemenations and other pieces of fluff), those of us currently running web apps need a slightly more immediate solution.

That solution is the HTML5 cache manifest. As the Safari Dev Center explains:

The manifest file specifies the resources—such as HTML, JavaScript, CSS, and image files —to download and store in the application cache. After the first time a webpage is loaded, the resources specified in the manifest file are obtained from the application cache, not the web server.

Although I had read about the cache manifest around the Internet, it wasn’t until I read Jonathon Stark’s wonderful Building iPhone Apps with HTML, CSS, and JavaScript: Making App Store Apps Without Objective-C or Cocoa that I came across a cleverly dynamic means of generating a manifest and supplying it to the browser. There was only one problem: Stark’s implementation didn’t account for web apps that made use of dynamic content.

To resolve the issue, I forked his manifest.php implementation to account for .php files:

header('Content-Type: text/cache-manifest');
echo "CACHE MANIFEST\n";
 
$hashes = "";
$lastFileWasDynamic = FALSE;
 
$dir = new RecursiveDirectoryIterator(".");
foreach(new RecursiveIteratorIterator($dir) as $file) 
{
	if ($file->IsFile() && $file != "./manifest.php" && substr($file->getFilename(), 0, 1) != ".") 
	{
		if(preg_match('/.php$/', $file)) {
			if(!$lastFileWasDynamic) 
			{
				echo "\n\nNETWORK:\n";
			}
			$lastFileWasDynamic = TRUE;
		} 
		else 
		{
			if($lastFileWasDynamic) 
			{
				echo "\n\nCACHE:\n";
				$lastFileWasDynamic = FALSE;
			}
		}
		echo $file . "\n";
		$hashes .= md5_file($file);
	}
}
 
echo "# Hash: " . md5($hashes) . "\n";

The above code should be fairly clear. Jonathon Stark’s original manifest.php made use of PHP5′s RecursiveDirectoryIterator class to generate a complete list of all the resources your web application relies upon (with the exception of the manifest.php file itself). I’ve simply altered it slightly to do a fairly primitive regex check to catch any files with a .php extension and preface those files within the manifest with a NETWORK flag (which forces the files to be requested from the web server, rather than the local cache).

Documentation on the application cache is fairly scarce at the moment, and I’m not professing to being any kind of expert. I just hope this code can help anyone else looking to use the cache manifest as a means of speeding up their dynamic mobile web applications.

It’s been just over three weeks since I released the first Showtime public beta. Since then the app’s undergone two major re-writes. The first involved a significant backend reshuffle, but ultimately meant that Showtime was able to track hundreds of additional programmes with greater accuracy, while the second, which hit devices earlier this week, centred exclusively on the front-end.

But development aside, I’ve noticed that Showtime has been involved in a number of recent debates over the future of the iPhone as a platform, and, perhaps more poignantly, questions over the relevancy and effectiveness of web-based applications as opposed to native solutions. Perhaps the major catalyst for Showtime’s involvement in said discussions was a tweet by the inimitable @gruber of Daring Fireball fame, which read:

Common answers so far for best iPhone web app: Gmail, Google Reader, Hahlo, Glyphboard, Showtime (http://showtime-app.com/) So: not much.

The tweet itself led to a flood of traffic (both directly and through subsequent retweets), as well as a direct response from Justin Williams, who stated:

The Web only Showtime allows you to see when your favorite TV shows air next. Both of these are great applications, but they miss the mark for a few reasons.

[...]

I believe that with the current crop of Web technologies available in MobileSafari, apps like Hahlo, PocketTweets and Showtime could thrive as an alternative to their native counterparts if Apple allowed developers to adjust the scrolling/drag coefficient of Mobile WebKit.

I’m not going to get into the web app vs. native discussion in any great detail here. It’s been covered far more extensively elsewhere. But I would like to take a moment to say that I agree with Williams on almost every level. Apple has created something special with Mobile WebKit, so let’s hope they support web app development in the future with a more extensive API.

The final point I’d like to make revolves around the fact that web app development has allowed me to avoid the App Store in its entirety. As a result, Showtime updates can be deployed in seconds, allowing me to accurately gauge user reactions. An experience which, rather paradoxically, native app developers (who pay for the privilege) sadly seem to miss out on:

Just when I start to get comfortable with the App Store again, shit like this happens. I understand Apple is completely inundated with updates and applications, but that’s not my problem. If you’re going to set up a system with this many requirements, you’d damned well better be able to handle it efficiently. 30 days to approve a simple update is not efficient.

And what does waiting mean? As I’ve said before, it means tons of email a day and tons of bad reviews. It means answering the same question (“My GA widgets all report zero… what gives??”) 20 times a day. It means watching negative reviews pour in. Here are some excerpts from lovely recent reviews:

via Garrett Murray (who develops the incredible Ego app.

Of course, the best part of Showtime development is meeting total strangers who use the application on a regular basis and find it useful:

Another app that shows webapps can be just as good as native ones: http://showtime-app.com

@DouweM

‘Showtime’ sets the standard for web apps on iPhone, absolutely incredible!

@petemwah

all #mobile #webapps should work like #showtime

@theadb

An interesting read on HTML powered iPhone application development.