Author Archives: Lou Franco

Start Habits not Resolutions

I saw this list of New Year’s Resolutions on the Did I Get Things Done blog (originally from Amazon)

  • Lose Weight
  • Get Your Finances in Order
  • Go Greener
  • Curb Your Vices
  • Get in Shape
  • Relax More
  • Pursue a New Career
  • Upgrade Your Technology
  • Organize and Optimize
  • Start a New Hobby


The main reason that I have had a problem with a resolution is that I don’t really think about them much a week or so after New Year’s. A few years ago, I created a small web app for myself to log how well I was doing at keeping to resolutions I was making. A few months ago, I ported it to the iPhone as Habits.

Instead of making resolutions this year, I created a few habits instead. I want to lose some weight this year (the #1 resolution), so I added a habit to run every 2-3 days, to do bicep/chest and shoulder/tricep weight training once a week. I want to keep my house in better order, so I added a habit to clean up and to process my mail pile more regularly.

A lot of these resolutions should just be a recurring task that you try to do as often as possible.

Habits on Sale for $0.99 until the end of January

Habits is the perfect application to make sure that you stick to your New Year’s resolutions, so from now until the end of January, I am putting Habits on sale for $0.99.

I am working on version 1.1, and I will post it at the end of January and return it to its old price. Until then, here’s hoping that you’re able to turn your resolutions into habits.

(The AppStore takes time to fully update — please make sure it says that the price is $0.99 before you buy)

Buy Habits on the App Store

O’Reilly’s iPhone AppStore Answers

iPhone AppStore Answers from O’Reilly’s Inside iPhone Blog. There are frustrations with the AppStore, but as O’Reilly acknowledges, Apple appears to be listening:

Changes have been relatively slow to come to the App Store. However, with the addition of review copies, as well as limiting ratings to those who’ve purchased applications, Apple has made changes that have been welcomed by developers. I’m hopeful that the App Store will continue to improve over time and address additional issues.

The other major improvement is dropping the NDA for released SDK’s, thus opening up the possibility of books, online tutorials and blogging about iPhone development.

More interesting iPhone pricing articles

From Chris Anderson’s The Long Tail blog, I got this link to some interesting iPhone pricing and sales data.

Having more than doubled over the last two months, Gaming remains the largest category accounting for a quarter of all apps. The fastest growing categories were Education and Lifestyle. Medical is the newest app category and as of the end of November there were over 80 medical apps, the 10 most popular of which were free. Among Game apps, Racing, Music, and Sports were the fastest growing Game sub categories.

And, here’s another iPhone app pricing article I got from John Gruber’s DaringFireball. In the article, Peter Cooper uses popularity as a stand-in for units sold and and tries to figure out which apps have the most revenue. Put this one in your RSS feed if you are interested in hearing more as this installment covers mostly the Games category.

Seth Godin’s iPhone App Ideas

Today, Seth Godin is giving away iPhone App ideas, the first one helps you avoid traffic:

Have the iPhone use the gps data… upload where I was a minute ago and where I am now. Figure out my speed and route. Use the data to tell other RadaR users which route is best. It’s worth $20 a month if you live in a place with traffic jams. It’s a natural monopoly–once someone figures it out, why wouldn’t everyone want to use the market leader?

The Google Maps app on the iPhone has traffic data already–what’s missing is that I don’t think it takes that into account when selecting a route, or updates it if conditions change. If the traffic data is available with an API (like most google data), then this might be easier than even Seth thinks (no server side) — of course, no lock-in either.

The second idea needs some kind of server-side dialier because Apple doesn’t let apps run in the background:

Here’s an easier one that you could probably sell as well. I type in a phone number and enter a time. Record a message and press go. I can cue up a bunch of messages that are based on time. I can have groups get the message I record, at the time I want them to get it.

Interesting iPhone App Pricing Articles

When I was trying to figure out a price for Habits, I found a few articles that were interesting. This one from Andy Finnell made the rounds on Reddit and advocates for busting through the $0.99 mentality and pricing applications in the $9.99 range.

The fix for pricing too low is really simple: raise your prices. Most $0.99 apps should become $9.99, $4.99 apps should become $14.99, and so on. With a $9.99 app, you’d make $7 per copy and at 16 copies per day, you’d make about $40,000/year. That’s not a great income, but that could potentially support one iPhone product being developed in some Iowan’s wheat field.

This other article from Andy is also good.

John Gruber made an interesting point when he linked to Andy (software with higher prices needs demos and refunds)

Tap, Tap, Tap has had a couple of AppStore hits, so what they have to say is also very interesting.

iPhone apps are typically much smaller and more focused than desktop apps and as such, should be priced accordingly. In addition, you need to take into account the much larger market that you’re dealing with here… Apple is selling well over 10,000 iPhones per day and these are all potential new customers, plus all the existing iPhone owners and iPod touch sales.

Unit testing on the iPhone

Thanks to Google, there’s a unit-testing framework for the iPhone. There’s not much more to say about it — the instructions are crystal clear and it worked exactly as described. It’s compatible with OCUnit (the Objective-C unit test framework in XCode), so once you set it up, you can just create test cases the way you would for any ObjC project.

One quirk — it instructs you to add a build step that runs the unit-tests during build time and shows the failures as compiler errors that you can then use XCode to track down. That’s nice, but I have found that you don’t really have enough of an environment to successfully run every kind of test — they run fine if you run them in the simulator. The main problem I have is with setting up my database in my Documents folder — I get errors at build-time that work just fine at run-time.

How I use Habits

Habits was released last week, but before that, I had something like it on a private area of my website for me to use. This is what my Habits looks like right now (edited for brevity and to remove personal data):

Generally, I use Habits to help with Sharpen the Saw type of tasks — things I want to make sure I do every once in a while, but not necessarily at a specific time. Also, unlike a recurring event in a calendar, I can record how well I do with them (if I do them late, early, or skip them).

Debugging memory based crashes on iPhone

On my Atalasoft blog, I wrote some tips for debugging unmanaged crashes in .NET. The idea is the same for iPhone — namely:

The corollary to this tip is to get it to crash as early as possible. It’s no fun to figure out a crash bug once the culprit function has already returned. You really want the root cause somewhere on the call stack when it’s detected.

In XCode, it’s actually really easy to get information about how you might be managing memory incorrectly.

If you think you are having an issue where you go out of bounds of a heap allocated memory block, then in the Run menu, you can check “Enable Guard Malloc”. This will tell you if you overrun your bounds. It’s not going to be as handy as a Page Heap style check (where each heap allocation gets its own page and therefore crashes at the point of the mistake), but it’s better than nothing.

Go to Project->Edit Active Executable, go to the Arguments tab and in the environment variables section, add

NSAutoreleaseFreedObjectCheckEnabled
NSZombieEnabled
NSDebugEnabled

And set each to YES. You can leave them there unchecked, but if you check them, then your application will now do some extra checking on autorelease and release and give you a good stack trace when you have done it wrong. A common problem is to think you need to call release when the object is already set to autorelease (see yesterday’s post on what the rules are for that).

Also, I haven’t needed it yet for the iPhone, but MallocDebug is supposedly available for use when you debug through the device. I have used it for regular applications and it’s quite good at finding heap corruption problems.