Labor Mate continues to bring in over $1K per month despite the higher price, but the trend doesn’t look good. Over the last few weeks, the number of sales has decreased everywhere except in Japan. For some reason, sales are up in Japan and if not for Japanese sales in August, Labor Mate would have posted it’s worse sales month in 6 months.

Since it’s inception date, revenue for Labor Mate has been on a slow but steady rise. The higher price has reversed that trend. Labor Mate now appears to be on a slow but steady fall. Not only that, Labor Mate, which at one time was in the Health and Fitness Top 100 category in App Stores throughout the world, is not longer visible on any Top 100 chart, anywhere. This three month pricing experiment maybe the start of a slow death for Labor Mate, but it’s not done for yet.

I have big plans in the works, and a new update is just around the corner. I was planning a big release in a few weeks that would hopefully justify the $1.99 price tag in the eyes of consumers but I’m changing my strategy. Starting today, Labor Mate is back down to 99 cents, and instead of a big update in a few weeks, I’m going to release 3 or 4 updates over the next 1 to 2 months. My goal here is to get Labor Mate back on track and return to the trend I was seeing before the price increase.

Update: One thing I should point out is Labor Mate has a lot of competition. The other similar apps cost between free and 99 cents. This maybe a key reason why a $1.99 Labor Mate cannot sustain the slow but steady growth seen by the 99 cent Labor Mate.

For those who don’t know, in Mac OS X 10.5 and greater, CALayer has the autoresizingMask property. Unfortunately this property does not exists under iOS, so it’s up to my code to do the resizing CALayers as needed. This is where the rotation issue revealed itself.

As the device is rotated from portrait to landscape, or vice versa, my view must resize and adjust the layout of the CALayers. Because UIView does not receive the rotation notifications I decided to be smart and use the orientation property from UIDevice. So in my view I had code similar to this:

UIInterfaceOrientation interfaceOrientation = [[UIDevice currentDevice] orientation];
if (UIInterfaceOrientationIsLandscape(interfaceOrientation) == YES) {
  // Adjust for landscape.
} else {
  // Adjust for portrait.
}

What I failed to realize, however, is that the property orientation will always return 0 unless orientation notifications are enabled. Here is a quote directly from the Developer Documentation:

“The value of this property always returns 0 unless orientation notifications have been enabled by calling beginGeneratingDeviceOrientationNotifications.”

Doh! Guess I should have RTFM sooner.

Because the orientation property will return 0, sometimes the view in my app would not rotate. But I didn’t know this was the source of the problem at the time.

After banging my head over and over on the wall, I decided to investigate exactly what was happening. I never suspected [[UIDevice currentDevice] orientation] but eventually I noticed it was returning 0. This seemed odd so I checked the Developer Documentation. I wasn’t expecting to learn anything new. Boy, was I wrong. I was surprised when I read the property always returns 0 when orientation notifications are not enabled.

I now knew the source of my rotation problems, and a likely quick fix to the problem would have been to call beginGeneratingDeviceOrientationNotifications, get the device orientation, then call endGeneratingDeviceOrientationNotifications. But this just seemed wrong to me. The better fix, in my opinion, is to rely on the rotation notifications received by the view controller, so that’s exactly what I did.

Now in my particular situation, there are two times I want to resize and layout the CALayers in the UIView. One of those times is when the device is rotated, which is when the view controller receives the willRotateToInterfaceOrientation:duration: message. This was easy to solve. I added an adjustLayoutToInterfaceOrientation: method to my UIView and I call the method inside the UIViewController’s willRotateToInterfaceOrientation:duration: method. For example:

- (void)willRotateToInterfaceOrientation:(UIInterfaceOrientation)toInterfaceOrientation
                                duration:(NSTimeInterval)duration
{
   [view_ adjustLayoutToInterfaceOrientation:toInterfaceOrientation];
}

The other time my UIView needs to adjust the layout of the CALayers is when the UIScrollView scrolls. I’m using a modified version of Matt Gallagher’s virtual pages in a UIScrollView approach, so the contents of my view changes as the user scrolls. This is where, previously, I was trying to be smart and use the orientation property from UIDevice. But what I really need is the current orientation as received in the most recent call to willRotateToInterfaceOrientation:duration:.

My solution was to add the ivar currentOrientation to my view controller. My view already has a reference to the view controller. I exposed currentOrientation so my view can retrieve the property value. This allowed me to replace the [[UIDevice currentDevice] orientation] code with [controller currentOrientation]. Now the view always knows the current orientation and the app does not need to enable orientation notification in code.

As a result, the first code snippet in this posting changes to:

UIInterfaceOrientation interfaceOrientation = [controller_ currentOrientation];
if (UIInterfaceOrientationIsLandscape(interfaceOrientation) == YES) {
  // Adjust for landscape.
} else {
  // Adjust for portrait.
}

And the willRotateToInterfaceOrientation:duration: implementation changes to:

- (void)willRotateToInterfaceOrientation:(UIInterfaceOrientation)toInterfaceOrientation
                                duration:(NSTimeInterval)duration
{
   currentOrientation_ = toInterfaceOrientation;
   [view_ adjustLayoutToInterfaceOrientation:toInterfaceOrientation];
}

This has been an eye opener for me, and I now have a new rule of thumb. Never use UIDevice orientation in code that is responsible for the resizing and layouts of subviews and CALayers.

• Beginning iPhone 3 Development, Dave Mark and Jeff LaMarche
• More iPhone 3 Development, Dave Mark and Jeff LaMarche
• iPhone App Development, the missing manual, Craig Hockenberry
• Core Data, Marcus Zarra
• iPhone SDK Development, Bill Dudney and Chris Adamson
• iPad Programming, Daniel Steinberg and Eric Freeman
• The iPhone Developer’s Cookbook, Erica Sadun
• Programming in Objective-C, Stephen Kochan
• Tapworthy, Designing Great iPhone Apps, Josh Clark

I decided others might find the sample source code useful so I posted the project to github for all to enjoy. The piece devs might find interesting is the KTStopwatch class. This is a simplified version of the class I use in Labor Mate. It supports wall clock and elapsed time.

The source code is licensed using The MIT License, so do with it what you like. Enjoy.

Speaking from personal experience, attending events like 360idev is a great way to not only meet and network with developers but for developers to find work, whether they are looking for a permanent position or contract work. This is one of the many reasons I return to 360idev event after event, and why I will be at the next one in Austin TX on November 7th through the 10th.

I increased the price of Labor Mate by $1 on May 15, going from $0.99 to $1.99. By increasing the price on May 15, I was able to compare the first half of the month with the second half. And as I mentioned in the previous post revenue had indeed gone up. But I was curious to see if this would continue and what might be the long term effects, so I left Labor Mate at $1.99. After all, I made more money in May as a result of the price increase.

June is over and the sales numbers are in. I’m now able to compare a full month of sales (for June) at the higher $1.99 price to a full month of sales (for April) at the lower $0.99 price. And I can compare these numbers to May’s numbers. The results might be surprising to some, but are inline with what I secretly thought would happen.

In June, Labor Mate earned a whooping $31.94 more money than in April, and it earned $30.90 less compared to May. In April, Labor Mate averaged $35 per day. The average was $37 per day in May, and only $36 per day in June.

Revenue from Labor Mate has been on a slow but steady increase since it was first released back in 2008. Though I cannot prove it, based on past trends, my gut tells me Labor Mate would have likely hit June’s revenue number in May without the price increase. And my gut, again based on the trend, says June would have probably hit May’s number without the price increase. In other words, while the price increase did improve Labor Mate’s revenue, the amount of additional revenue resulting from the price increase is actually no different from the slow and steady increase in revenue I was already seeing at the lower, 99 cent price point. As a matter of fact, I saw a bigger jump in revenue between March and April, with April bringing in a whooping $175.71 more than March.

I’m now convinced the price increase did little to improve revenue, and actually the price increase likely did more harm than good. Prior to the price increase Labor Mate was ranked in the Top 100 in the Health and Fitness category for a number of different countries including the U.S. Today Labor Mate is no were near ranking in the Top 100 in most stores.

Another negative effect caused by the price increase is that fewer people are now using Labor Mate. As I noted in the previous post, the number of daily downloads dropped. This means fewer people are buying Labor Mate, which in turns means fewer people are using it. I believe Labor Mate’s slow but steady raise was due in part to word of mouth advertising. Now that there are fewer new moms and dads buying and using Labor Mate, there are fewer people recommending Labor Mate to other new moms and dads. And I admit, ignoring price for a moment, I’m a little disappointed that fewer people are using the app. A part of me prefers selling at a lower price point so more mom and pops to be will use it. (Hmm, maybe I should release a free, iAd supported version.)

So what’s next? I’ve thought about dropping the price back down to 99 cents, but this could lead to a backlash from the folks who purchased Labor Mate over the last 6 weeks. Plus, $1.99 is still cheaper than a large cup of Starbucks coffee. The better idea, and the one I have been planning all along, is to continue improving Labor Mate and make it stand out above the other 99 cent copy cats. This includes leaving the price at $1.99 for now. After all, as one recent new user said to me in email, “it is a very practical and intuitive app and certainly justified at $1.99.”

Because Hey Peanut can run on both the iPhone and iPad, my code must include certain checks to avoid crashes. One check the code makes is to determine if the class UIPopoverController is available or not. Prior to iOS 4, this class was only available in iOS 3.2. The current release of iOS on the iPhone is version 3.1.3, and it does not include this class. To make use of the popover I use code such as the following:

   Class popoverControllerClass = NSClassFromString(@"UIPopoverController");
   if (popoverControllerClass) {
      popoverController_ = [[UIPopoverController alloc] initWithContentViewController:[self imagePicker]];
   }

Turns out there is a big problem with this code under iOS 4 causing Hey Peanut to crash each time. It wasn’t obvious to me at first why this code was failing but as I thought it more, and as I talked through the issue with an Apple engineer, I realized, “Duh! iOS 4 is running on the iPhone, not the iPad.” Simply checking for the existence of the class isn’t good enough any more. Instead, I need to also check the device type. So with a quick change to the code, shown below, I was able to fix the crash in Hey Peanut. The code now checks that the class is available and is running on a iPad.

   Class popoverControllerClass = NSClassFromString(@"UIPopoverController");
   if (popoverControllerClass && UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad) {
      popoverController_ = [[UIPopoverController alloc] initWithContentViewController:[self imagePicker]];
   }

For those who don’t know, Labor Mate is a niche app for the iPhone. It has been in the Top 100 in the Health and Fitness category for multiple App Stores including the U.S. for more than a year. Back in November Labor Mate’s status in the Health and Fitness category started to drop due to two competitors being mentioned in the What’s Hot lists. Despite the drop in rankings Labor Mate continues to sale well, slowly and steadily earning more money per month. A big part of this success comes from international sales, which have steadily improved since translating Labor Mate into 8 other languages. Another part of the success comes from the fact that the app is rock solid. It doesn’t crash, and as one of the reviewers recently said about Labor Mate, “Maybe not the slickest looking app for counting contractions, but we didn’t want to risk crashing or accidentally losing data – we just wanted a reliable app that would work under pressure.”

Even though I was not confident of a positive outcome, I decided to follow the advice from Jon and Daniel. I raised the price of Labor Mate from $0.99 to $1.99. My plan was to leave it at the higher price for a minimum of one week. As expected the first full day at the new price saw spike in revenue. However, sales dropped. This trend continued for the first week. As a result, Labor Mate lost most of its visibility in the App Store’s Top 100 for Health and Fitness. I figured it was only a matter of time before sales and revenue hit an all time low.

Despite what appeared to be a downward trend, I decided to continue the pricing experiment for a second week. To my surprise sales started to return to its normal pattern, a spiky, Bart Simpson-like hair cut. What I noticed was exactly what Jon and Daniel said would happen. I started making more money. Jon and Daniel were right! Sure, daily unit sales were lower than before the price increase, but revenue was higher for those two weeks. So while Labor Mate dropped from the rankings of the Top 100 in the Health and Fitness category and the number of units sold per day dropped, in the end I made more money.

The next big question now is, will Labor Mate revenue continue its slow but steady climb at this higher price point, or will the overall trend start heading downwards? I’ve decided to keep Labor Mate at the $1.99 price for another week to see what happens.

Meanwhile, for those of you who prefer looking at charts, I’ve included the sales and revenue charts for Labor Mate covering the time period between April 1, 2010, and May 31, 2010. There was a spike in mid-April but sales started dropping afterwards. The red-dash line is the first full day at the new, higher price. The spike on that day was almost as high as the spike in April.

Code Pilot is by far the favorite based on the number of responses I received. Code Pilot provides easy navigation through your Xcode project. If you are a keyboard junkie like me than you owe it to yourself to try out Code Pilot.

Accessorizer is the second most popular plugin. Accessorizer saves you time by generating boiler plate code for you. For instance, you can use Accessorizer to generate the @property declarations based on a set of ivars. Give the Accessorizer Quick Start Guide (PDF) a read to get a sense of what Accessorizer can do for you.

Mogenerator tied for second most popular plugin. It generates Objective-C code for Core Data models. It works differently than Xcode in that Mogenerator manages two classes per entity, one intended for the machine and the other intended for humans. The Mogenerator sites says, “The machine class can always be overwritten to match the data model, with humans’ work effortlessly preserved.” Perfect for Core Data projects. FYI, Mogenerator is an open source project created and maintained by the most-excellent Jonathan ‘Wolf’ Rentzsch.

Completion Dictionary is a free plugin that enhances Xcode’s own code completion. It allows you to define your own expansion macros. You type a few letters and press the completion shortcut. You instantly have new code added to the file. This plugin reminds me of Delphi Live Templates, which I used religiously back when I did lots of Delphi programming. Oh, and did I mention Completion Dictionary is free?

What other Xcode plugins are out there? Which ones do you find useful? Post a comment if you have a favorite plugin not listed here.