Archive for the ‘iPad’ Category

My App Store Pricing Experiment: The Final Chapter

Wednesday, September 1st, 2010

Today is my final update on the pricing experiment I started back in May. You can read the previous posts here and here. The goal of the experiment was to see if the sales trend for Labor Mate would continue at the higher price of $1.99. After three full months, I can say the higher price has done more harm than good.

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.


iPad Stylus Review

Sunday, August 29th, 2010

I admit I don’t have a strong need for a stylus when using my iPad, but there have been occasions when I wish I had one. Using my finger to take notes in a drawing app is sometimes frustrating to me. My finger drawn text is usually too large, and on hot summer days, my finger doesn’t always glide smoothly over the surface of my iPad. So I decided to give an stylus a try. The problem was, which stylus to buy.

I narrowed my search down to two styluses, the Pogo Sketch from Ten One Design and the Boxwave Capacitive iPad Stylus. I spent more time than I should have reading reviews of both only to come to the conclusion: I don’t know which one to buy. So I bought both.

The Pogo Sketch gets points for price ($10.78 on Amazon at the time), which is much less than the Boxwave ($20.95 plus $4 shipping). Both work well on my iPad. The Pogo Sketch is longer and thinner, and felt cheaper than the Boxwave. The Boxwave stylus is heavier and thicker, much like a nice ball point pen, but it is short. I personally don’t mind the shortness since I’ve carried short pens in my pocket for most of my life, but others might not care for it.

The tip on the Pogo is shaped differently than on the Boxwave. With the Pogo tip, I can hold the stylus in different positions as I draw, sort of like a pencil. The Boxwave, on the other hand, is like using a pen. I find myself holding it in the same position as I would a pen.

The Pogo tip also looks like it could wear out quickly. With both styluses I must use more pressure to draw than I would with pencil and paper. I can’t help but feel I will flatten out the Pogo tip quickly with regular use. On the other hand, the Boxwave tip looks and feels solid, and I don’t have the same concern of it wearing out.

After spending time with both, I decided I prefer the Boxwave Capacitive iPad Stylus over the Pogo Sketch. I like the thickness and weight of the Boxwave, and it doesn’t have that cheap feel that the Pogo does. But $25 is a lot to spend. Given the amount of time I will use a stylus and having played with both, I know I would have been happy with the Pogo Sketch. But since I bought both, I will continue using the Boxwave stylus, and I will likely give away the Pogo Sketch at an NSHappyHour or similar event.

Speaking of NSHappyHour, I brought both styluses with me to the July NSHappyHour for others to try out. Jon Lee was kind enough to email me his own review, which I’ve included here. I love his final verdict.

Finger:

Pros: Always available when you need it. If you lose one, there is always another.

Cons: Pen tip is too squishy, and big. Writing by finger is an awkward user experience.

Pogo Sktech

Pros: Tip feels smaller, like you’re drawing with a thin Crayola marker. Using a stylus is familiar as a experience, as compared to finger painting.

Cons: The squishy sponge material makes me afraid that if I press too hard I will scratch the iPad surface with the edge of the ring that holds the sponge. Sponge feels very rippable after continued use.

Boxwave Capacitive iPad Stylus

Pros: Good weight, feels substantial. The tip, being rubber, feels like it could last longer than the Pogo.

Cons: The rubber end is like the bulb end of a turkey baster. And it feels like you’re writing with one. The thicker footprint does not make me feel like I have a high chance of being accurate when I draw. And $20? Really?

Verdict:
Make your own.


Don’t Rely on UIDevice orientation for Rotation

Monday, August 23rd, 2010

Last week I tweeted about having rotation issues with an iPad app I’m working on. This is the second time in recent weeks I’ve encountered rotation issues in an app. In both instances I was using a UIScrollView so I started thinking the UIScrollView was source of my problems. In the most recent instance the UIScrollView contains a UIView that uses a number of CALayer instances for content display.

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.


Some Useful Books for iOS Developers

Monday, July 26th, 2010

Last week I had the opportunity to teach a one-day class on learning iPad programming. One of the students asked what books I recommend. A friend asked the same question over the weekend, so I thought I might as well post the list of books on iOS and Objective-C programming I have found helpful.


A Really Simply Timer

Monday, July 19th, 2010

SimpleTimer.pngA friend asked if I would put together a sample iOS app that shows how to display a stopwatch timer like the one used in Labor Mate. It seemed like a fun exercise to break up the night, so I said, “Sure, why not.”

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.


Hiring iOS Developers in the Boston Area

Friday, July 9th, 2010

Jonathan Kardos has an excellent article on Boston Innovation explaining how to find a mobile app developer in Boston. NSHappyHour even gets a mention, which is great. But one thing left out of Jonathan’s article are national events such as 360idev.

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.


Sale Numbers are In: An Update on My App Store Pricing Experiment

Friday, July 2nd, 2010

Last month I mentioned my experiment with the pricing for Labor Mate to see what effects, if any, a price increase will have. The initial results were interesting. The number of units sold went down, but revenue had gone up. On the surface it seems the price increase was a success, but I needed more data.

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.”


Using UIPopoverController with iOS 4

Thursday, June 10th, 2010

I ran into an interesting bug today while testing Hey Peanut on iOS 4. For those who don’t know, Hey Peanut is a universal binary, which means it runs on both the iPhone and iPad. My iPhone has the GM version of iOS 4 installed on it, which I’m using to test my apps under iOS 4.

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]];
   }

Some Really Useful Xcode Plugins

Friday, May 28th, 2010

Xcode is a suite of developer tools for Mac and iPhone programming. Xcode is also the IDE included in the developer tools. As far as IDEs go, Xcode has become my favorite over the years. It’s simple yet powerful. But as good as it is, there’s always room for improvement, so yesterday I asked on Twitter, what plugins do other Xcode developers find useful? Turns out there are a number of really useful Xcode plugins. Here is the list of favorites based on responses to my tweet.

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.


It’s Official. I’m Nuts.

Friday, May 28th, 2010

Turns out I’m nuts, and I can prove it. Last week a signed a contract to publish a book with Addison Wesley. Justin Williams at SecondGear put it best when he asked, “ARE YOU NUTS!?” Yep, apparently I am. And signing the book contract is my proof.

Kidding aside, I’m very excited about this opportunity to contribute back to iPhone development community, a community that has been extremely helpful to me over the last couple of years. The book is on learning iPad programming. It will focus on the unique aspects of programming for the iPad and will hopefully serve as a launch pad for many new iPad programmer entering the space.

Writing on the book has just begun, and I have a very aggressive 6-month delivery schedule. My life is going to be busier than ever over the next 6 months, but it will be a good busy as this is something I have wanted to do for a long time. So if you don’t hear from me much between now and November, you know why.