Isn’t not like I need a distraction from work, but I couldn’t resist this one. I saw a tweet about iDOS, a DOS emulator app just released for iPad and iPhone. For fear the app will be pulled from the App Store, I bought it right away. Besides, it’s only 99 cent.

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.

Yesterday Apple announced the Mac App Store, which will be available in 90 days. The Mac App Store is modeled after the iOS App Store. The store provides customers a trusted way to buy and download safe, quality software for the Mac OS X desktop. As with the iOS App Store, software developers must submit their apps to Apple for review, apps must adhere to a list of rules, and Apple gets 30% of the app price for each unit sold.

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.

Life has been crazy busy recently. Of course it seems my life is always crazy busy, and just when I think it can’t get any more crazy busy, it does. I’m behind on a number of things, and I can’t help but feel overwhelmed. Heck, feeling overwhelmed is probably an understatement for how I feel right now.

This year has been an amazing year for me, work-wise. I reinvented White Peak Software last year as company focused on iOS, and this year is shaping up to be my most exciting and enjoyable year in the company’s (almost) 7 year history. But a number of things are suffering as well. Progress on the book is suffering. Product updates are suffering. New product releases are suffering. Even client work is suffering because there’s simply no way for me to keep up with the demands. Despite of all this, I feel a bit better this evening after reading a posting from Jeff LaMarche.

I look up to Jeff, and I’m amazed at how much work he pumps out. I often wonder where he finds the time – not having a two year old in the house probably helps – and I’m convinced he never sleeps. In his posting Complaining About Success, Jeff mentions “time has become a scarce commodity.”

Ah, he is human. He does fall behind from time to time.

While I feel for Jeff, I admit reading his post makes me feel a bit relieved that I’m not alone.

And Jeff, if you are reading this, I plan to stick with the release then nil approach. It’s the approach I learned when first diving into Objective-C. Old habits are sometimes hard to break.

Fall is almost here and it’s going to be a busy on for me. Not only will I be heads down trying to finish my upcoming book, I will be speaking at two iOS developer conferences. The first conference is Voices That Matter in Philadelphia on October 16 and 17. This will be my first VTM, and I’m very excited to be apart of the event. There are a lot of great talks planned for the 2-day conference. My talk will be on the advantages of writing universal apps for iPad and iPhone. Early bird pricing ends today so register now to save money. Use the discount code PHASPKR to save even more money.

The second conference I’m speaking at this fall is 360iDev Austin. It’s no secret that 360iDev is one of my favorite developer conferences. I have made numerous friends since attending my first 360iDev last year, and the networking I’ve done at past 360iDev conferences has help land me paying gigs. My session at 360iDev will be on the fundamentals of iPad programming. This session is intended for anyone just starting out with iPad programming. Earlier bird pricing as already ended for 360iDev Austin but even at the full price of $599, it is money well spent if you are serious about iOS programming.

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.

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.

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.

At long last, a new theme is coming to Hey Peanut. Hey Peanut 1.3 was submitted to Apple today. This update includes a new safari theme for toddlers to enjoy. There is a hippo, giraffe, zebra, and a friendly lion. Also included in this update are all new animal sounds recorded from actual animal.

Previous releases of Hey Peanut used family-made sounds. What do I mean by “family-made” sounds? Well, the animal sounds were recordings of my wife and me attempting to mimic each of the farm animals. The sounds were silly but lacked a certain level of professionalism. Hey Peanut 1.3 will use all new sounds, and this time the animal sounds are the actual sounds from real animals, with one exception. A giraffe doesn’t really make a sound, so in Hey Peanut the giraffe sounds like a giggling kid. Of course, that kid giggling is my son, Rowan, so there is still a family touch in this new release.

Hey Peanut 1.3 should be available for download from the App Store very soon. Meanwhile, keep an eye on the White Peak Software Twitter account, @whitepeak, for promo codes to redeem a free copy of Hey Peanut (U.S. App Store only).