I googled to see what others have done. I found some good approaches but no one solution that I liked. So I decided to write my own borrowing from the various ideas of others. The end result is KTTextView.

KTTextView derives from UITextView and enhances it with new features. At the moment the only new feature is the placeholder text. The placeholderText property works same as UITextField’s placeholder property. I also added the property placeholderColor in case an app has the need to use a color different then the default placeholder color.

KTTextView is hosted on github. The project includes a sample app showing how to use KTTextView. I plan to add more features as time allows. One feature I want to add is an option to display the text view in a rounded rectangle giving it a similar look to UITextField. In the meantime, I hope you find the KTTextView’s current implementation useful.

I read a story about someone installing Windows 3.0 inside of iDOS. Sounds cool but I’m not interested in Windows 3.0. Instead, I decided to install Turbo Pascal. Embarcadero recently posted Turbo Pascal v5.5 as a free download so the first thing I did was to grab a copy of it. Next, I grabbed an unzip program so I can unzip TP55.zip in iDOS. (Save time and go here to download unz552x3.exe.)

Here are the remaining steps I followed to get Turbo Pascal up and running on my iPad.

• Connect the iPad to iTunes.
• In iTunes, go to the Apps tab for the connected iPad and scroll down to the file sharing section.
• Drag and drop TP55.zip and unz552x3.exe to iDOS.
• Sync the device.
• Once sync is complete, launch iDOS on the iPad. You’ll find the two files in the root directory.
• Copy unz552x3.exe to a new directory, or just run it in the root directory. This will uncompress the unzip utility files. I prefer running it in a separate directory to keep the root clean.
• Unzip TP55.zip. This will create two directories, DISK1 and DISK2. Again, I copied TP55.zip to a temp directory before unzip.
• Run install.exe found in the DISK1 directory. If your experience is similar to mine, you will get a message saying to insert the oop/demos/bgi/doc diskette. I’m guessing the installer can’t find the directory DISK2.
• At this point, I aborted the install. Not to worry. Turbo Pascal’s IDE, compiler, etc have been installed.
• By default, the IDE can be found in c:\TP. The program file to run is turbo.exe.

That’s it. Happy coding!

Update: If those not lucky enough to grab a copy of iDOS from the App Store, you can download the source code for DOSPad and build your own version.

My first impression when reading about the announcement was 30% is too high. E-commerce providers such as Fastspring and eSellerate charge a much lower percentage. But the Mac App Store does do a few things that other e-commerce providers do not. The Mac App Store has the potential to reach many more users given that the app will be available on the desktop. Also, the Mac App Store will host the download file. But when I think about it, none of this is new. The only thing new is Apple.

Download sites have existed for years. The PAD specification, which has been available for years, provides a mechanism for software vendors to publish app metadata and be discovered by download sites, and ultimately by customers. And many download sites and e-commerce providers provide hosting of the app. Even Microsoft gave it a try with its web-based app store concept called Microsoft Marketplace, which after many years is no more. So it seems to me, the only thing new and different about the Mac App Store is the review process.

Downloading desktop software from download sites can be risky. You never know if the software you download contains a virus or malware. Attempts such as pre-scanning software for viruses by download sites have been made to instill trust but at the end of the day it’s hard to trust software downloaded from these sites. The Association of Software Professionals have attempted tackling the trust issue for years and has had some success. Still, at the end of the day, gaining customer trust with an online business is challenging.

Personally, I never download software from download sites but I buy a lot of software online. I only buy and download software from the vendor’s own web site, and I’ll only do it when I feel I can trust the vendor. The vendor earns my trust by having a professional online presence, provides contact information with bonus points for having a physical address and phone number, offers a money back guarantee, and most importantly digitally signing the software with a certificate from a trusted CA. If you browse the White Peak Software web site, you’ll see I follow these trust rules myself.

Trust is important when doing business in the online world, and the Mac App Store will help gain customer trust. This should, in turn, help encourage customers who have never bought desktop software online to final do so. The added level of trust and the potential reach to new customers makes the 30% cut to Apple worth while in my opinion. But I still have concerns, from a developer’s point of view, about the Mac App Store.

Many existing, and popular, apps sold today including some from Apple will be rejected from the store based on the list of review rules. But a bigger concern for me is that software vendors wishing to sell through the Mac App Store as well as through their own company web site will be required to maintain two different versions of the same app. Mac App Store apps cannot be self updating, cannot be trial version, and cannot use its own licensing scheme. These three things are key components to selling desktop software on the Internet today. This means a software vendor wishing to sell an app through the Mac App Store as well as through its own company store must have two separate builds of the app, one build without the self updating, trial version, and licensing scheme for the Mac App Store, and one build containing these features for sell through one’s own online store.

Another concern I have with the Mac App Store is the lack of pricing and licensing options. For example, Killink CSV is a business app bought by individuals and large companies alike. By selling directly to the customer, I can offer various pricing and licensing options. I offer a volume discount on purchases. The more single user licenses you buy, the lower the per unit cost. I offer a site license option too, which allows customers to pay a lower price while being able to install the software on a greater number of computers. Then there are coupons. I use coupons to offer discount pricing for a variety of reasons. It’s doubtful the Mac App Store will support coupons in the next 90 days. Then there are affiliates. While sells from affiliates represents only a small portion of my product revenue, affiliates do bring in additional customers. Come to think of it, in a way, one could think of the Mac App Store as an affiliate with review process.

I can’t help but wonder…giving the fact that I have more control over pricing, can offer discounts, and run sales using coupons…will customers become annoyed when they pay one price for my app in the Mac App Store only to find out they could have saved money by buying directly? And how will customer support change with the introduction of the Mac App Store? I’m assuming Apple will not provide any customer information after a purchase to the software vendor. What happens when a customer calls or emails me about re-installing the app on a new computer? I’ll have to first find out how they purchased the app, through the Mac App Store or through my web site. I can see it now, a customer responds with, “I don’t remember.” And what about refunds? Direct purchases can be refunded, Mac App Store purchases, well, “You’ll have to talk with Apple.”

Overall, I can see the Mac App Store leading to confusion and delay.

Oh, and then there is the concern of paid upgrades. Many, if not most, desktop software vendors count on revenue earned by paid upgrades. Paid upgrades are currently not supported in the iOS App Store, so I have to think the same will be true of the Mac App Store.

And let’s not forget the trial versions of the app. A customer can come to my web site and download a free 30-day trial of my software. This gives the user time to evaluate the app before making a purchasing decision. This is not going to happen, at least not initially, with the Mac App Store. Will this lead to users demanding lower prices and if so will software vendors given in starting a new race to the bottom. I certainly hope not. Software vendors need to stay their ground and price their products based on the value of the app.

Will my app be rejected from the Mac App Store if I include in the app description, “Come to my web site to download a free 30-day trial”? And what of cross-platform apps? Say I write a version of Killink CSV for the Mac. According to the list of review rules, I cannot mention the availability of the Windows version in the app’s metadata. If I do, it will be rejected even if this is a key selling point of the app.

I welcome the Mac App Store. It has great potential for tapping into a customer base that otherwise would be un-tappable. But I worry the Mac App Store is not the right place for many desktop app and by not being in the Mac App Store sells will suffer. Only time will tell if the Mac App Store will help software vendors, especially the indie shops like White Peak Software, to succeed.

Let’s take a look at the various ways to customize the navigation bar.

The UINavigationBar has a style property called barStyle. barStyle can be set to UIBarStyleDefault or UIBarStyleBlack. The default uses a blue gradient background. When using UIBarStyleBlack you can also set the translucent property to YES to give the navigation bar a partially opaque look. If you are using Interface Builder, then you will set the Style property in the Inspector window. Here you have the option to style the navigation bar as Default, Black Opaque, and Black Translucent.

What if you want a color other than blue and black? You can set the tintColor property (aka Tint in IB) to any color you like. This changes the navigation bar’s color. Best of all, setting the tintColor will also change the background color used by the bar button items displayed within the navigation bar.

Sometimes, however, just changing the tint of the UINavigationBar isn’t enough. Sometimes you want to have a fancier background. Maybe the background you want has a different gradient style or lighting effect, or maybe you want a title displayed in the center of the navigation bar to use a font not available in iOS. How would you change the look of the navigation bar for these scenarios? Simple. You use an image that is drawn on the navigation bar.

There are two approaches you can use to draw an image on the navigation bar. You can create a new class that inherits from UINavigationBar and override the drawRect method. For example:

@interface KTNavigationBar : UINavigationBar {

}
@end

@implementation KTNavigationBar

- (void) drawRect:(CGRect)rect
{
   [super drawRect:rect];

   UIImage *image = [UIImage imageNamed: @"navbar.png"];
   [image drawInRect:CGRectMake(0, 0, self.frame.size.width, self.frame.size.height)];
}

@end

In this example, the image navbar.png is used to customize, or skin, the UINavigationBar. This is a nice, clean, object orientated way to customize the look of your navigation bar. The only thing you must remember to do is to use your custom UINavigationBar class within your application. This means changing the class type for those of us using IB.

Another trick you can use that doesn’t require changing the class type is to use a category. For example:

@interface UINavigationBar (KTCustomLook)

- (void) drawRect:(CGRect)rect;

@end

@implementation UINavigationBar (KTCustomLook)

- (void) drawRect:(CGRect)rect
{
   UIImage *image = [UIImage imageNamed: @"navbar.png"];
   [image drawInRect:CGRectMake(0, 0, self.frame.size.width, self.frame.size.height)];
}

@end

I admit I have used this approach in more than one project, but doesn’t feel right to me. It feels more like using voodoo or black magic then following good OO design. But this approach does work and it does save you time by eliminating the need to change the class type for each instance of UINavigationBar within your app. [Update: This approach doesn't feel right because it overrides a method in a category. You should know this is a bad, bad thing, and I don't encourage others to do it. That said, it does work.]

One thing to note when using an image to customize the UINavigationBar, you still want to set the tintColor for the navigation bar. As I mentioned, setting this property will also change the background color used by the bar button items. So you want to set the tintColor to the appropriate color making the button color fit in with the navigation bar color style.

For those of you who want to see these concepts in action, I posted a sample project, called CustomNavBar, on github. Enjoy.

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.

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