Workout Tip Jar is now available on the app store.

Overview:

A workout tip jar is a jar that you deposit money into every time you work out. Once you reach your goal ($50, $100, etc.), you take the money out and treat yourself to something The Workout Tip Jar app is that jar, in app form!

Workout Tip Jar was a collaboration between myself and my wife. You can read about her thoughts on the app creation process over at fitnessprogrammer.com. Working with someone was a nice change from my other, primarily solo apps.

Development Time:

Probably around 8 hours. Half of that was spent writing the app, and the other half was spend creating launch images, screenshots, and icons….

Review Time (time spent in the iOS app submission queue):

8 days. To be fair, this was over the New Year’s Eve and New Year’s Day.

New technologies I learned and used:

This was my first app that involved audio. Fortunately, playing a small sound is an incredibly easy process.

What went right:

The best thing about Workout Tip Jar is that it was an untapped market (albeit a small one). It’s only been a few days since it was released, but it’s already #1 in a Google search for ‘workout tip jar’.

From a development perspective, it’s hard to pinpoint anything that went surprisingly ‘right’ because the application was so small and straightforward.

What went wrong:

We decided to release Workout Tip Jar as an iPhone-only application. In retrospect, I wish we would’ve taken the extra time to add an iPad version too. It probably wouldn’t have been that big of a deal.

Future plans:

Conceptually, Workout Tip Jar is pretty small in scope, so there’s not too much else to be done here in terms of new features. There are a couple of things that we still have to do though: adding an iPad version is #1 on the list, and improving the graphics and UI design is #2. We might also explore some ‘social’ features like a ‘Share on Facebook’ button when you reach your goal.

If there’s something you’d like to see in Workout Tip Jar, let me know!

Bug Tracker is now available on the app store.

Overview:

As the name implies, Bug Tracker is a bug and issue tracking tool targeted at software developers. It is a standalone application, requiring no external server software. The app store is full of iOS clients for tools like Bugzilla, Jira, mantis, and FogBugz, but contains virtually no iOS-only issue trackers.

Development Time:

Around 44 hours or so, plus a chunk of time spent working on ios-queryable.

Review Time (time spent in the iOS app submission queue):

6 days. Thanks for the relatively speedy review, Apple! I think that was my fastest one so far.

New technologies I learned and used:

Aside from a heavy dose of Core Data, there wasn’t really anything particularly new here.

What went right:

• With Bug Tracker, I took a data-first approach – creating virtually the entire Core Data model before writing a line of code. I think that this helped narrow down the focus of the app and get straight to the point of what it really needed to do. Sometimes I find that starting with a UI (my usual approach) can lead down a never-ending road of ‘hey, I could add this feature here…’. Starting with the data and building the UI on top of it seemed work quite nicely.
• Normally, after developing an app primarily using the simulator, and the switching over to my iPod for testing, I find a number of issues or things that don’t quite work right. With Bug Tracker, everything was surprisingly usable from the start on the device, and I didn’t have to go back and rethink designs or change the UI.

What went wrong:

• Well, the fact that Core Data annoyed me so much that I had to write a library to make it suck less can’t be a good sign. But it did turn out to be a fairly useful tool.
• In terms of design – always a challenge – I found myself struggling with the limitations of UITabBarControllers.and UINavigationControllers. Although these form the backbone of navigation in most of my apps, I am starting to have second thoughts about their usability and the patterns of interaction that they demand.
• Finally, although the title of this blog is ‘App Per Month’, Bug Tracker’s development put a bit of a stop to the idea of monthly releases. For various reasons, including starting a challenging new job, I simply haven’t had as much time as I would’ve liked for iOS development. The result is that Bug Tracker’s 44 hours or so of development was spread out over a period of nearly 3 months.

Future plans:

The ‘stuff I want to do’ list is pretty long here, but a lot of it depends on what users want. I think iCloud support would be quite nice, for both backup purposes and cross-device usage. Saving of searches would be a great way to enhance the dashboard and the search capabilities. Icons for things like issue types and priorities, and UI enhancements in general, would also be nice. Oh, and a proper iPad version would be handy, too.

But really, it all depends on you, so if there’s something you would like to see in Bug Tracker, let me know!

Gym Calculator is now available on the app store.

This will be a rather short postmortem as it’s such a small application. But don’t worry, I have some things in the pipeline that will warrant much longer ones…

Overview:

Gym Calculator is an app that does the math for you when you are at the gym. It lets you quickly add up your plates to figure out how much weight you are doing. You can also give it a target weight, and it will tell you exactly what plates to put on the bar to achieve it.

Development Time:

~7 hours.

Review Time (time spent in the iOS app submission queue):

9 days.

New technologies I learned and used:

There wasn’t anything particularly new here. I guess the most notable new ‘technology’ was that Gym Calculator was the first app I created from the ground up with the 4″ iPhone in mind.

Challenges:

The main challenges were not implementation issues, but small-scale design decisions. For example, the app supports conversion between pounds and kilograms, but metric and imperial olympic weight sets are different. Should a 45lb bar convert to a 20.4 kg bar (the mathematical equivalent), or to a 20 kg bar (the real-world equivalent)? I chose the latter.

Future plans:

Aside from bug fixes,  I don’t see too much development happening on Gym Calculator in the future. It’s such a small app that there’s not really too many other things I could do with it.

20 Rep Squats is now available on the app store.

I am particularly proud of it as I believe it is my most well-designed, aesthetically pleasing application yet.

Development Time:

~18h, the bulk of which was spent trying to get Core Plot to display my charts properly.

Review Time (time spent in the iOS app submission queue):

12 days; my longest wait yet.

New technologies I learned and used:

As mentioned above, I used the Core Plot framework for generating the charts.

Challenges:

The biggest challenge – by far – was trying to get Core Plot to display the charts the way I wanted it to. This may be the subject of a blog post in the future, but suffice it to say, it should have much better defaults. I don’t think what I want to do is really that unusual; I just want to display all of my data, in only the postitive X/Y quadrant, with custom labels for points on each axis. But [graph.defaultPlotSpace scaleToFitPlots:[graph allPlots]] didn’t do the trick, and getting the right orthogonalCoordinateDecimals and plotRangeWithLocations was a painstaking process.

Future plans:

This will probably depend primarily on user requests. It does pretty much everything that I want it to do, and there’s only so much a ’20 Rep Squats’ app can do without turning it into something else (such as a full workout tracking app). So as always, please let me know if there’s anything you would like to see in it!

Drink Menu is now available on the app store. Like always, that means it’s postmortem time!

Development Time:

• ~3h. Drink Menu was essentially a total conversion of BBQ Menu, so I wasn’t starting from scratch.

Review Time (time spent in the iOS app submission queue):

• 11 days

New technologies I learned and used:

• There wasn’t really anything new here

Challenges:

• Fully renaming an Xcode project is surprisingly difficult. There are a lot of hidden strings and plist entries to watch out for. Other than that, it was smooth sailing.

Future plans:

Drink Menu, along with BBQ Menu, do pretty much everything I want them to do. Unless there are specific requests from users, they likely won’t get too many more features. So as always, please let me know if there’s anything you would like to see in it!

Which Episode? is now available on the app store, and that means it’s time for another postmortem.

Development Time:

• ~8h

Review Time (time spent in the iOS app submission queue):

• 9 days

New technologies I learned and used:

• The only real new thing here was iOS 5’s handy NSJSONSerialization class, which is used to look up your TV shows and download posters form them.

Challenges:

• The biggest problem here was figuring out where to get posters of TV shows. After initially settling on http://www.imdbapi.com/, I became unhappy with the (movie-centric) quality of the results, and the inability to retrieve more than one image in case of multiple shows with the same name.
  So after looking around for quite some time, and being continuously disappointed in either the licensing or the technology of each particular solution, I stumbled across http://trakt.tv and their ridiculously awesome API. Problem solved!

Future plans: The main change that will likely be coming in the future is the ability to browse between different images for your shows, just in case the default image is for the wrong show. For an example of where this would be handy, try searching for ‘Angel’. You won’t get a show about vampires.

Aside from that, the application does everything I want it do do, and aside from user requests, it likely won’t get too many more features. So as always, please let me know if there’s anything you would like to see in it!