Musings from The Software Underground

Macworld just reviewed MacGourmet as a "Mac Gem" giving it 4.5 mice out of 5!

According to the reviewer:

If you’re a recipe geek and need a place to store, organize, and categorize your current and potential meals, look no further than MacGourmet. From the program’s recipe box metaphor to its flexible visuals, plug-in architecture, auto import functions, and smart searching, this is one of the most versatile and extensible programs available for any cook.

The review is pretty extensive and hits on just about everything. It's a great read for even current users: you may find out about things in the product you didn't even know were there!

The reviewer sums up her review with:

If you work extensively at cooking or event planning, or you’re just intensely organized and interested in exploring the subject, MacGourmet should be in your shopping cart. Its functionality and extensibility add convenience and ease to tasks that can become mundane over time. Its automated features and flexible presentation are appealing, and the core program is priced attractively. If you want to add features like nutritional information, meal planning, and cookbook publishing, you can add on the items you’re interested in piecemeal or just purchase the Deluxe version.

You can read the entire review here: MacGourmet organizes and helps find new recipes

Ok, at first when I heard about BumpTop I thought, "great, yet another lame desktop replacement app" but this actually looks pretty cool. It includes some elements of what you see in Mac OS X, and some that were rumored (like piles).

Hands-on: BumpTop may be desktop revamp you've waited for

It's only available for Windows right now, but the site says it's coming for Mac OS X and Linux too.

Not as good as really being featured, but still kind of neat, I must say... MacGourmet "Featured" in Latest iPhone Ad "Office"

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.

I'm not sure how others have found the App Store approval to be, but I found it anything but smooth. In trying to get MacGourmet touch approved for the App Store, it was rejected three times:

• The first rejection, 3 days after submission, was because I didn't acknowledge that there might not be an active connection available. OK, I've noticed that other apps don't necessarily do this, but I found the reference, sort of, so fine, it's a logical request. Resubmit.


• The second rejection, 3 days after resubmission, was because I didn't provide "login information" for testing... which shows a lack of understanding about syncing that the average MacGourmet user wouldn't share. Syncing is with the app, not a web site that requires a username/password... Fine, I provided a download link for the prerelease of 2.4 and a link to the set up instructions. Resubmit.


• The third rejection, after another 3 days, was the result of the wrong build hastily getting placed on the server. A 30 second fix. Turn around time on that one? 4 days.

As a developer who is used to complete control over my release schedule, and when products are "ready for release", this whole exercise is an exercise in frustration. Not to mention, the whole process is time consuming. 3 days for each turnaround, which is probably decent, is just too long. Does everyone experience this kind of submission experience? I'll bet that once Apple decided to relax their standards and let iFart into the store, that it wasn't rejected even once...

There IS a flip side supposedly too though, as detailed here: Android app uproar sparks debate over open app store model. Apparently an app store can be a little TOO loose, at least according to the writer, who advocates needing submission standards similar to Apple's. Really, though, how is software downloaded from the Android app store different from software you can download and install now for your Mac or PC? These problems are all possible when you download a Mac application, but you hope that the developers are good citizens and do their best to "do no harm" and for the most part, that works.

As you can see, the problems with the App Store go beyond just what Craig Hockeberry refers to in his open letter to Steve Jobs, Ringtone apps. Anything more complicated than a fart "Ringtone app" is bound to also be a LOT more difficult to get approved, if for no other reason than the testers don't read or misunderstand requirements, and don't know how to use the companion apps the iPhone apps are made to work with.

Add to that, it's getting harder and harder to make a compelling business reason to even produce apps for the store, at least anything beyond what you can develop quickly and sell for a buck: The future of the crApp Store as detailed by the folks at Chilli X.

Now that MacGourmet touch is out, I do plan to add to it, but I'll have to balance that time with development on the main MacGourmet product and I have no choice but to base that time on what MacGourmet touch can generate for revenue. I love developing for the Mac, don't get me wrong, and that extends to the iPhone, but everything has a cost, and if the App Store doesn't have a significant enough return on time investment, then I'll have to spend a larger bulk of my time every day elsewhere.

MacGourmet 2.4, a free minor update, is now available.

This version adds support for syncing your information with your iPhone/iPod touch using MacGourmet touch, available very soon exclusively from the iPhone App Store. For a full list of changes, please see the release notes.

As always, MacGourmet can be downloaded from the MacGourmet download page or by using the built-in software update service.

MacGourmet Deluxe version 1.1, which includes MacGourmet 2.4, can be downloaded from the Mariner Software download page as soon as they make it available.

This new release is primarily targeted at the iPhone/iPod touch support so, what, you may be wondering, is coming next? I plan to have long overdue updates for Mealplan, Cookbook and Nutrition out before too long, changes are already underway, hopefully due out over the next month or so. They've seen a delay because of how much work developing MacGourmet touch took.

Then, after that, it's head down and into development for version 3. I've got a very long list of requests and new features planned, so stay tuned for that, as well as updates to MacGourmet touch in the coming year!

Honestly, I don't know why it didn't happen sooner. Macworld has always required that Apple build their products and announce them around a date outside of their making. I'm sure this never set well with Jobs and Co. who can really do things as they darn well please, thank you very much.

This writing has been on the wall for some time now. Apple has stores everywhere. They have also started doing their own "mini keynotes" whenever THEY see fit. Development based on a date, rather than a date based on when development was actually finished has never set well with me, as an engineer. I can see now that it never really set well with Apple either, and they've finally decided to do something about it. And in this down economy, why NOT do it now?

Oh and can we PLEASE STOP making everything about the health of Jobs?

The App Store has been open for some time now, and it's become clear that we're at the dawn of a new market. Right now, it definitely has a "Wild West" feel to it. I mean there are tons of questions, and not nearly as many answers, not yet any way. People have started blogging about their experiences though, and it's useful to read these, as they cast some light onto the current state of the things.

One of the main concerns right now, is pricing vs. exposure and subsequent sales. Some personal experiences are starting to fill in the details, but the picture is still mixed.

The App Store seems to be really "hit driven" at least at first blush. Being featured, and very aggressive pricing, seem to be the paths that lead to ongoing success, by some accounts anyway.

In Craig Hockenberry's recent post, Ringtone Apps, (he created the really nice Twitterific app, both on the desktop and the iPhone at IconFactory, among other things), he talks about how it seems that the only successful App Store apps are "ringtone apps": those that are sold for 99 cents; and how it's nearly impossible to really fund iPhone app development at this pricing level.

"As an iPhone developer who’s been in the App Store since its launch, I’m starting to see a trend that concerns me: developers are lowering prices to the lowest possible level in order to get favorable placement in iTunes. This proliferation of 99¢ “ringtone apps” is affecting our product development."

I would tend to agree. I mean if you think of what your time is worth as a developer, now many hours it takes to create an iPhone app of any substance (as I've found out, this is far from trivial), and the price at which you must sell an application, the numbers have a hard time adding up in favor of the developer. This leads to a situation where developers don't spend "real" time on apps, but instead do "drive by" apps (or ringtone apps as Craig calls them) that take far less time and effort to produce.

What happens, if the pricing levels are set so low, to those who want to invest a great deal of time into their apps, and need to charge more for them to make up for the development cost? Can they succeed?

Well according to the source listed in this TUAW post, Stats: 99 cent apps aren't selling any better, pricing your app at 99 cents DOESN'T increase sales. The data in the post they refer to is interesting. But I agree with Gruber, when he says:

"grouping all apps that cost more than 99 cents together spoils the whole thing."

It's interesting, but far less enlightening than it could have been. It fails to show how different prices ABOVE 99 cents effect sales. What's the "sweet spot" for app pricing, if it's not 99 cents? Is there one? Is it largely dependent on the app?

The current problem with the store, as I see it anyway, is that it is the ONLY real source for apps right now. It's the only way to distribute, buy and sell iPhone apps. It's also for the most part, the only way to get real exposure for apps. There are a few complementary ways I suppose, Daring Fireball ads for one, which seem to have helped apps like Classics and "Where To?". John Casasanta blogged about what tap tap tap did to get exposure for their apps at the beginning. Remember though, that when he posted this, there were far fewer apps and far less competition. Still, it's interesting to see what worked and didn't.

But for most people, it's the App Store or nothing, and honestly, it currently doesn't do a great job of giving non-featured apps exposure yet.

This is backed up by the experiences of David Barnard (he doesn't say in his post, but I think it's David) at AppCubby who says:

"If I can find a cost effective way to market my apps, I would be willing to borrow money for marketing, but so far the strategy that has made the most fiscal sense is to spend money on development and hope for good placement with Apple and the press."

in his Financial Realities of the App Store post.

Honestly though, I've been doing indie Mac development for a long time now, and the Mac market isn't much different in this regard, success can be based on who blogs about and who features your product. Still, the Mac market has so many more avenues for exposure, "good placement with Apple and the press" isn't quite as key for your typical Mac app to be a success, but it really helps. I actually like Gruber's idea:

"What Apple could do is weight the best-seller list by revenue rather than unit sales. That way a $10 app with 1,000 sales could get ahead of a $1 app that sells 5,000."

At least I think it's his, at any rate, it'd go some distance towards fixing the race to the bottom we seem to be seeing now. But, being devil's advocate, is a $10 app more "valuable" than a $1 app, just because the developer wants 9 more dollars for it? Is this any more useful? I'd say that at the very least, it puts the brakes on the drive to the bottom in pricing at least.

So, what's a developer to do? I face this exact question myself. MacGourmet Touch, a MacGourmet companion app for the iPhone (and iPod touch), is currently in beta. Now, it remains to be seen how things work out for it when released. For one thing, it won't be going into the store without an existing audience. There are already lots of MacGourmet users clamoring for a companion application that will let them take their recipes with them. But, as detailed in the previous posts, iPhone app development isn't cheap. Will MacGourmet Touch pay for itself? If it does, how long will it take, and at what price point? In the current incarnation of the App Store, which seems to be largely "hit driven" it remains to be seen. One thing I might try is making it more attractive to the non-MacGourmet users, maybe by including more sample recipes, etc. At any rate, it has to pay for itself and the effort required (though honestly, it's possible that it's release will also work in reverse, and sell copies of MacGourmet...).

I plan to blog about approaching the app store from this angle, adding another perspective, once MacGourmet Touch is out, so stay tuned...

Just a bit over a year ago Apple released a revolutionary device, the iPhone, to great fanfare. At the time, there was no way to develop applications for it. Apple's answer to developers' demands that they be able to create new products or the iPhone? Make iPhone-optimized web sites, that should be all you need...

Well of course that WASN'T all we wanted, or needed. We wanted to be able to create first-class iPhone apps, with all of the "bells and whistles" of the built-in iPhone apps. After much developer gnashing of teeth, Apple recanted (or maybe it was always their plan), and announced an SDK for the iPhone. There was much rejoicing. Yes! Mac developers WOULD be able to create products or the iPhone and iPod touch!

As has been covered more and more on the Mac web though, Apple is a harsh mistress. Months after the release of the iPhone SDK, all developers are still bound by an NDA that prevents them from mentioning anything iPhone development related. Having problems with your code? You can't ask other developers for help. Don't understand something? Again, there is no sharing of information allowed. The only samples you get are what Apple provides. And, ridiculously enough, even if your app is rejected from the App Store... you aren't allowed to talk about it. I can't tell you how much this is stifling development, at least from my perspective.

I've been working on a mobile version of MacGourmet for way longer than I expected I'd be. Why? Because what I am trying to do either isn't possible, because of bugs in the SDK, or isn't because I'm doing things incorrectly. Do I have any sources to try and find out WHY things aren't working? Just one: Apple's already overworked, over-stressed, overburdened developers.

More than anything else, the NDA is holding up the development of MacGourmet: To Go. I've had to spend WAY too much time trying to figure out why my application just seems to crash randomly when trying certain things. I've already cut back the feature set, so that I can try and get SOMETHING shipped, but I'm still running into problems. It seems every time I step outside of the "box of simple" I get slapped back down by random crashes in the SDK code.

If we were allowed to discuss development freely, this wouldn't be a show-stopper. All it would usually take is a post to one of the developer lists, where someone could spot any SDK misunderstandings or problems in no time. Chances are, someone reading would have tried to do what you are doing, and figured out how it works. It's this collective, that serves the Mac community so well, that makes all Mac developers so productive. The wealth of sharing is amazing. You can always seem to find the answers to any development questions, or at least find information that helps lead you to your own solution. The least they could do is provide registered NDA developers a place where we can talk and exchange information freely, but they don't even give us that, all they do is keep us from talking.

Right now, Apple is preventing the free exchange of information regarding iPhone development from happening. And it's hurting the whole development community. I mean just look at my own app. It's not just a simple viewer of static information, a simple to do or shopping list app. It's an iPhone application that I ultimately want to be a handheld version of MacGourmet, not with all of the same bells and whistles, but with the basics still largely intact: recipes, wine notes, cooking notes and shopping lists. I'm currently having trouble producing this though. The NDA is largely responsible.

I realize that the SDK is new, and is still evolving. I've submitted potential bugs to Apple, in the hopes that they are fixed, or that I get information on what I'm doing wrong. This is a really slow way to develop though. Granted, for personal reasons, where I for years spent the bulk of my time working at the expense of personal life, I've now switched things around and am spending less time on work at the moment (an 8 hour day instead of working all the time), I've still been trying my damnedest to ship an iPhone product, while keeping up with MacGourmet support and development. A lot of time I just seem to be spinning my wheels, and scaling features back and finding less-optimal workaround ways of doing things, because the way I should be able to do things doesn't seem to work. Not having access to the Mac developer "collective" is what I see as one of the major causes (at least for me personally).

Apple really needs to lighten up, and drop the NDA. It's not serving anyone well, and it's stifling the platform.

[UPDATE: No sooner do I post this, then do we get word that APPLE IS DROPPING THE NDA for released versions! Yea! This makes perfect sense. I don't mind being bound by NDA for say, iPhone 2.2, which isn't out yet. But now we can discuss iPhone 2.1 as needed. Thank you Apple!]

Labels: Development

Check out this month's Mac|Life magazine for a 4 star review of MacGourmet Deluxe! They have this to say: "...the app cooks up some nice features, including menus, meal planners, shopping lists, nutrition guidelines, and, of course, your favorite recipes available at the click of a button." You can read the full review online here.