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!

Random Dice Roller, April’s 2nd app – or May’s first app, depending on how you look at it – is now out the door. As always, it’s time for another postmortem.

Development Time:

• ~16h

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

• 9 days

New technologies I learned and used:

• The main new technology here was networking. This was my first iOS app that touched the network in any way, shape, or form. Aside from the incredibly annoying extra-long default timeouts, it went quite smoothly, and resulted in my open-source class ReallyRandom.

Challenges:

• I ran into some performance issues when using setMasksToBounds: to round the corners of UIButtons. This will likely be the subject of a blog post in the near future.
• Taking good pictures of dice is hard!

Future plans: I have quite a few plans for Random Dice Roller. So many, in fact, that it was a difficult decision to actually release it, instead of spending more time adding new features. But in the spirit of release early, release often, I decided to let it go sooner rather than later.

There are two things that will likely be coming at some point in the future. The first one is the ability to roll multiple sets of dice at once; that is, instead of just being able to roll something like 3d6, you could roll 3d6 + 2d8 + 1d4 all at once. This would be quite handy for those games of D&D.

The second one is in-app purchases of different dice sets. I’m not sure what exactly the market would be for that, but I figure it’s worth a shot.

As always, please let me know if you have any feature requests or ideas!