Musings from The Software Underground

Unlike many apps developed for the iPhone, MacGourmet touch is more of a "port" of MacGourmet to the iPhone. It's meant to work tightly with the desktop version of MacGourmet, and comes with a certain set of built-in expectations. In some cases, this makes things easier, in others more difficult. Existing users have a certain set of expectations, created by the desktop version, that will carry over into the iPhone version. Because of that, It takes some thought and planning, and a tight focus, to meet the key expectations, without building something that just doesn't work on the iPhone. That said, I have a number of things learned during the process of designing and building MacGourmet touch:

1. Remember, the iPhone is not a Mac, not even close. Don't try and include every feature from the desktop app, and every option. In a lot of cases, it won't even be possible. Simplify, Simplify Simplify.


2. Concentrate on the core feature set. Yes, a desktop app can be about every feature from A-Z (not that you SHOULD do this even for a desktop app, but it IS possible). Design for focused functionality. MacGourmet touch focuses on taking your recipes, notes and shopping lists with you. This means that quick and simple display of information is more important than say, advanced Find, advanced organization, publishing, web site import, etc. or even editing (though I do plan on allowing editing more than just shopping lists in the future).


3. Some of your desktop code will come over to the phone just fine. Some won't. Test, test, test. You'd be surprised by what does work on the Mac, but doesn't work at all on the iPhone, especially if your desktop app has been around for a while.


4. Build for the device as early as possible. As I write this, the simulator will let you include and build with libraries and APIs that aren't available in the iPhone OS. A good example bit me in the butt: I built the original sync code using NSArchiver, got everything done and working in the simulator, only to later find out that NSArchiver isn't supported, only NSKeyedArchiver is. This meant taking a huge step back and changing a lot of working code. Ouch!


5. Port your code with an eye towards improving both the desktop and iPhone versions of your application. I've found that the iPhone code I've been writing has actually been improving some of the code that the desktop version uses. This cross-pollination is a very useful and beneficial thing, if done right.

MacGourmet touch will continue to evolve in the future. There are some things, like editing recipes and notes, in addition to editing shopping lists, that definitely make sense. Something like simple meal planning would also make sense as a future feature. How the product evolves though, will be influenced and largely dictated by the points I've listed above.

For another great take on building a companion iPhone app, Cultured Code's post on how they developed their companion app for Things is a good read.