Objective C and iOS
I already have some experience on iOS as a platform from creating a game using Unity3D for iOS. This was a great way to learn how to use TestFlight for beta testing, doing some Twitter integration, and learning the iTunes App Store submission and acceptance process.
But Unity3D isn’t everything. For non-game apps, it’s almost always better to go native.
My first native app was a simple grocery list tool. I designed it around my own requirements. Namely: I needed it to be quick to enter things from the grocery store and also store pictures of foods so I’d not forget them. There are undoubtedly a thousand apps that already do this, but then I’d not learn anything, right?
I followed some of the excellent tutorials on RayWenderlch.com to learn the ropes of using CoreData, managing Views, and the like. One tricky part was having the "Add New Shopping List Item" button not only take you to a Detail View for a new item, but also have the cursor and keyboard showing so you can simply start typing to enter the name.
I integrated TestFlight and distributed it to my family as beta testers. They gave me a little feedback and I iterated a few versions. For example, you swipe right to "check off" an item in the list, but you can also swipe left to "un-check-off" an item to add it back to the list. Also, the items in the list are sorted by add check-off-ed-ness and then by date added.
All-in-all, its a solid app for what I need it to do. It reached a point where it has enough functionality that I use it now as my sole way of tracking groceries.
If I were to add anything to it, I’d add support for multiple stores. I’ve drawn up the changes in the interface; I’d use a tab bar, I think. Each item could belong to multiple stores: for example you can buy laundry detergent at Target or at a grocery store. So I could simply select which store I’m at and get a list of things to buy there. That would match my use-case perfectly.
Once multiple store support worked, I’d turn it into an In App Purchase feature and release it out onto the iTunes App Store.
My second native app is a 2D game using Cocos2D. It is designed to teach music students the lengths of different musical rhythms and how they fit into a single measure of different time signatures. In this game, you use sliders to solve a series of generated musical rhythm puzzles. Harder levels have more complex rhythms and more symbols to choose from.
It is based off a game designed by a piano teacher that she created out of paper. I made a quick prototype of my understanding of the game play and sent it to her. It became clear that there was some disconnect between my understanding and how she uses the paper version in the classroom/studio setting. Right now we’re working out the game play design.
I see this as the first of a series of educational games aimed at music teachers. Each would be sold at about $5 and marketed to encourage piano teachers to recommend them to the students (and parents of students) in their studios. $5 compares favorably to the typical price of a piece of sheet music, which is about $7. This series of apps would cross-promote amongst themselves since anyone interested in one educational music app would probably be interested in others. I also benefit by directly involving a music teacher in the development process as far as musical pedagogy is concerned.