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

A few weeks ago I was having some post-CocoaHeads beers with Jon Trainer and Daniel Jalkut. We were talking about the success I’ve had with Labor Mate. They both insisted I raise the price from $0.99 to something higher. Both had sound reasons why a price increase would work for Labor Mate. For instance, the price range for competing apps range is from free to $9.99. A higher price point will help Labor Mate stand out. Everything Jon and Daniel said made sense, but I was skeptical.

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.

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.

The video recording of my 360idev talk “Building Web Service Powered iPhone Apps” is now available from 360idev (free to attendees, for purchase for non-attendees). This was the first time a presentation I gave was recorded, and for the first time ever I get to see my own talk. I watched the video yesterday and overall I’m happy with the results. The best part for me, however, is using the video to learn from my mistakes.

A mistake I repeatedly made was not repeating questions asked by the audience. Repeating the question is an age old speaker tip, but the tip is easily forgotten during an actual presentation. Repeating the question is helpful to others in the audience who may not have heard the original question. Repeating the question also gives you a chance to make sure you understand the question, and it buys you a few more seconds while you think of an answer.

Repeating the question becomes more important when your session is being recorded. In the case of the 360idev recording of my session, you cannot hear questions from the audience. This sometimes makes it hard to understand the context of the answer. I could have avoided this by repeating each question before providing an answer. The lesson learned here, and one I must remember the each time I speak, is to repeat the question before answering.

The other lesson I learned by watching my session is to not do live coding. Live coding can be impressive, earning you some respect points with audience members. But live coding can also slow down the presentation. This is what happened in my session. There are lulls during my talk while I type code from memory. Also audience members will often see mistakes in your code as you type and shout out tips. This can break your thought process causing confusion and delay.

Having now watched my session video I have decided to no longer do live coding in these types of sessions. The extra time spent typing on the keyboard is better spent sharing additional knowledge with the audience.

Last month I had the fortunate opportunity to talk at 360idev. My talk was on using web services in iPhone apps. The talk got off to a bad start due to various technical issues, the biggest issue caused when my MacBook Pro and the projector would not talk with one another. This caused my talk to start late which meant I had to skip some of the details I wanted to cover.

Another issue came up with I tried to demo a RESTful web service call to Twitter using HTTP Client. Twitter reported the request limit had been reached for the IP address. This meant I had to skip over the Twitter related demos. Lucky for me, the rest of the presentation and demos ran smoothly.

For those who may have missed the presentation, the fine folks at 360idev have posted a video recording of the session available for purchase. You can also download the sample source code and the Keynote presentation file from my 360idev repository hosted on github.

I decided to do a little experiment earlier this week. I spent the day in Boston so instead of taking my laptop I decided to take only my iPad. I had no plans to write code that day but I had a number of other things I needed to do. Specifically write a new blog post, work on a book outline, and review and edits some documents. All the tasks can be accomplished on an iPad but what I wanted to know is how easy is it and how productive can I be.

Long story short, the experience was not good. I definitely wasn’t as productive as I am with a laptop. The problem isn’t with the device. The iPad is truly awesome and I believe it represents the future. The problem was inconsistencies with the various apps I used combined with the lack of features and or weird behaviors.

The experiment started on the commuter rail into Boston. The MBTA provides free wifi to riders, which was a plus for me. My iPad is wifi only, not the 3G model. With the free wifi access I was able to check my email, sync Instapaper, and post a tweet or two. The experiment was off to a great start.

The train ride into Boston was about 30 minutes so I decided to write a blog post about setting up a private centralized git server. If you follow this blog then you already know the posting isn’t here. This is when the problems started.

I used the WordPress app to write the blog post. The app does an okay job but it ain’t MarsEdit. For starters there is no easy way to create links. Making matters worse, I wasn’t able to paste in a URL from the clipboard. I ended up wasting a lot of time trying to get a link in the blog post but that was only the start of the problems.

I needed to switch to other apps as I wrote the post. Switching apps could be a bit easier on the iPad but I was multitasking, something some folks like to say is not supported. In switching between apps I discovered that the WordPress app doesn’t always save my data. In some cases the app could tell I had exited before saving and would tell me it had to recover the data next time I launched the app. The warning message is not necessary. Just return me to the edit screen, thank you very much.

In other cases something much worse happened. My data was lost…forever! The worse case happened after I had type three paragraphs only to have it lost. It was at this point I decided to give up on writing up the blog post and moved on to another task.

I decided to work on an outline using Pages. As far as an editor goes, Pages is great and it doesn’t have any of the short comings founding the WordPress app. But Pages is far from perfect too.

The document I needed to edit was stored on Dropbox. The Dropbox app is awesome. I was able to go to my document and open it in Pages. Here’s where I noticed the first problem. While I’m able to open a document stored on Dropbox in Pages there is no way to save the document back to Dropbox. Once the document was in Pages it stayed in Pages until I emailed it, posted it to iWork.com, or exported it for file sharing, which mind you requires a computer. So I was able to edit my document but I could not update Dropbox with the latest version. (Just to be clear, this is not a problem with Dropbox. The problem is with Pages.)

Another problem I encountered while working in Pages is access the toolbar for styling content in my document. My iPad is typically in landscape mode when I type but the toolbar is only accessible in portrait mode. This means I was continually rotating my iPad as I tried editing the document. This is a huge productivity killer for me and very annoying.

I also ran into another problem which is more behavioral than a problem with the device or apps. As I type my brain wants to Command+s to save as I go. Saving often has been hard wired into my head for most of my life. On the iPad in apps like Pages documents are autosaved. There is no need to Command+s but this doesn’t stop my brain, or fingers for the matter, from trying to type the key combination. So what happens? I end up with lots of / characters randomly scattered throughout my document.

This brings up another issue. Apps on the iPad behave differently. For example the WordPress app uses an edit screen with a Save button at the top. As I painfully learned the app does not autosave so I must touch the Save button, which I find myself doing often. Pages on the other hand autosaves. There is no explicit save action. This means my behaviors when using Pages must be different when compared to using the WordPress app. It becomes annoying that different behaviors at required for different apps and this can hurt productivity.

Overall the experiment was useful. It opened my eyes up to the challenges we third party developers have when trying to create really useful apps. I also learned that while I can do many tasks on my iPad I’m still not as productive as I am on my laptop. I don’t fault the device for this. It’s the apps that are to blame. Inconsistent app behavior and lack of sharing data between apps impact productivity. But the good news is, this is only the beginning. The experience is only going to get better. Apps are going to get better. And it is only a matter of time before my iPad replaces my laptop for most of my daily activities.

Apple has come under fire over its latest developer agreement for iPhone OS developers. The section causing concern is 3.3.1 which says applications must be originally written in Objective-C, C, and C++ (or JavaScript when using the WebKit engine). This restricts developers from using other cross-platform development tools such as Adobe’s Flash CS5 packager.

Steve Jobs has clearly explained his thoughts on Flash, but more importantly he talks about the impact felt from third party cross platform development tools. Those of us who have been in the software industry long enough will likely agree with Steve’s comments regarding the impact cross platform development tools have on software development.

An interesting fact: An abstraction layer separating the developer from the platform does not have to come from a third party to cause problems. When Microsoft first released Windows 7 the only way to take full advantage of the new features was to use a development tool that allowed the developer to talk directly with the platform, in this case the Windows API. This may come as a surprise to some but it meant you could not use .NET including C# to tap into the newest Windows 7 features. Microsoft’s own layer, the .NET Framework, prevented C# developers from tapping into the latest features in Windows 7. A developer’s only option at the time was to use Visual C++ or Delphi.

For years programmers have dreamed of some magical development tool that would allow them to write code once and run it anywhere. Sound familiar? That was the promise made by Java over a decade ago. Guess what. It never really happened. Most cross platform applications are subpar and do not feel or behave like applications written specifically for the platform.

This brings me to a comment I read this morning in an article speculating Apple may change the iPhone developer agreement to avoid an antitrust case.

“Mobile advertiser Greystripe’s CEO Michael Chang has explained that writing an app using Flash CS5 for the iPhone could cost $75,000 initially but would cost just a few thousand dollars more to port to Android. Without Adobe’s tool, however, developers could be forced to rewrite from scratch and spend as much as they did before. The sheer expense could be considered anti-competitive as it would make writing for more than one platform cost-prohibitive for smaller studios.”

First of all, writing a top quality cross platform application is hard and costly. It doesn’t matter what development tools you are using. Second and more important, when did Flash CS5 become the only cross platform development option? Last time I checked C and C++ were considered cross platform programming languages with C being one of the more popular options for cross platform development. The iPhone developer agreement doesn’t restrict the use of these cross platform programming languages.

Yes, it would be great if cross platform development were cheaper but to say the expense associated with cross platform development should be considered anti-competitive is just down right stupid. The developer agreement is not preventing cross platform development. It is preventing the use of third party cross platform abstraction layers that separate the developer from the platform.

Why stop with Flash? Let’s start a petition against Apple because I can’t use my favorite programming language, Pascal. I think I should be able to use Pascal as my programming language of choice and not just for iPhone OS development. I want to use Pascal for any device and platform. Pascal should be a first class programming language for the Kindle, PSP and DSi, and Amazon, Sony and Nintendo should be responsible for making this happen otherwise face accusations of being anti-competitive.

This grumbling about section 3.3.1 in the iPhone developer agreement boils down to two things:

1) Businesses want to reduce development cost.

2) There are lots of lazy programmers out there.

Let’s discuss these 2 points a bit further. Building a cross platform application using a tool like Flash CS5 might help businesses reduce development cost. Will it help a business be successful? Maybe and maybe not. Success depends on whether or not customers like the apps produced by the business. Personally I dislike non-native apps because most are subpar and behave differently. If the apps are subpar then a business will likely not succeed despite using third party cross platform development tools and saving a few dollars in development cost.

Now on to lazy programmers. Actually saying “lazy” is probably the wrong word to use. I often say I’m a good programmer because I’m lazy. I don’t like to repeat the same task over and over, so I write a program to do the task for me. This makes me lazy because I find ways to reduce the amount of work I need to do. So being a lazy programmer can actually be a good thing. The DRY principle is another example of being a good type of lazy programmer.

In my second point I’m referring to a different type of lazy programmer, a bad lazy programmer. This is typically a programmer who does programming as a job and programming is just that, a job. This type of programmer doesn’t have the same love for programming that someone like me has. This type of programmer isn’t interested in learning new programming languages and this type of programmer definitely is not the type who would be programming even if he or she didn’t get paid to do it.

The bad lazy programmer wants everything to be easy. He wants to write an app once and have it run everywhere. He’s main goal is to move up the corporate ladder in hopes of making more money. And what better way to move up the ranks than showing your company how it can reduce development cost by using a third party abstraction layer and tool.

These are the types of programmers complaining about section 3.3.1. Programmers too lazy to learn a new programming language such as Objective-C, C or C++. Yes, these languages are harder to learn than many of the newer programming languages including those fun scripting languages used by many today. And yes, I might be a little basis because I first learned C over 25 years ago and I have no problems using it today. But instead of bitching about terms in the developer agreement why not accept the fact that cross platform development is hard and costly. After all you can still use the same C and C++ code in both iPhone and Android apps. Yes, that’s right. The Android NDK (Native Development Kit) does exists and allows C and C++ code to be used to implement parts of your application. It’s not easy but it’s possible.

Adding more fuel to my fire is this comment in NY Post article from yesterday:

“Regulators, this person said, are days away from making a decision about which agency will launch the inquiry. It will focus on whether the policy, which took effect last month, kills competition by forcing programmers to choose between developing apps that can run only on Apple gizmos or come up with apps that are platform neutral, and can be used on a variety of operating systems, such as those from rivals Google, Microsoft and Research In Motion.”

Yes, exactly what world needs. Apps that are platform neutral. But wait! Don’t we already have that today in the form of web-based apps? And doesn’t the iPhone and iPad come with Mobile Safari capable of running web-based applications “that are platform neutral and can be used on a variety of operating systems”?

Ah, but you say you want native built apps that take advantage of the platform. That’s cool. You can have that too. But this notation that you can have a native built app that is also platform neutral is just crazy talk. It’s not going to happen anytime soon and it shouldn’t be Apple sole responsibility to make it happen.

I wonder, if Objective-C were more popular would the torch carrying mob go after Google, Research in Motion, and Microsoft for not supporting it on their mobile devices?

A few weeks ago I renamed the iPhone developer meet-up from NSiPhoneDevs to NSHappyHour. When I announced the name change I said I would follow up with the reasons behind the name change but I totally spaced and forgot. Thanks to @jlbruno for reminding me to explain the reasons behind the change.

I came up with the name NSiPhoneDevs back at the beginning of the year. I like the name because it’s a good play on words, or rather a good play on prefixes. “NS” is the class name prefix in the foundation framework used by iPhone and Mac developers, but “NS” also stands for North Shore. For those who don’t know, Salem MA is located in Boston’s North Shore area. So NSiPhoneDevs is short for North Shore iPhone Developers.

While I like the name it is not without it’s problems. First, NSiPhoneDevs doesn’t exactly roll off the tongue. I for one am guilty of saying “NSiDevs” on more than one occasion. Another issue with the name is some may believe it excludes iPad developers. This is a stretch I know but I’m sure with the release of the iPad there will be more new developers entering the space who consider themselves iPad developers.

The third, and most important reason for the name change, is the name NSiPhoneDevs excludes a major developer group, the Mac developer. I talked with many Mac developers who said they are not interested in the group because it’s iPhone only, and this includes Mac developers who also do iPhone development. My intentions were never to exclude Mac developers. On the contrary, I want more Mac developers to come especially given that I’m doing more Mac desktop development these days.

The iPhone has attracted a large number of developers who come from other platforms including Windows, .NET, and Java. The reasons for moving from another platform to the iPhone varies by developer. Some are interested in mobile development. Some are interested in joining in on the gold rush. For others, including me, the reason is out of love for Cocoa, Objective-C, Xcode, and OS X.

I switched from Windows and web development to work in the world of Apple because, in my opinion, it provides the best developer experience. Programming on my Mac, whether for the desktop or for the devices, is way more fun for me then in Windows, and I find the developer tools to be far better than anything else I have used in recent years.

So back to the NSHappyHour name change. As someone who is also doing Mac development I did not want others in the Mac developer community to feel excluded. After all, we all use a Mac for programming, we use Xcode as our developer IDE, and we work with many of the same core frameworks.

This point hit home for me at NSConference 2010 where I met a lot of people who share the same passion and love for the developer experience provided by the fruit company. It was at this time I realized NSiPhoneDevs is the wrong name.

The NSiPhoneDevs name is good because it builds off the hype that is the iPhone, but at the same time the name is bad because it does not recognized the development community as a whole. At the end of the day we all work with pretty much the same tools and we can learn a lot from one another whether you are writing iPhone/iPad only apps, desktop only apps, or doing all of the above.

So the group is now called NSHappyHour. After all, that’s what the group is really about. Getting together with fellow Cocoa developers to talk shop over a few beers. So if you are writing code and producing apps for the iPhone, iPad and or Mac then NSHappyHour is the perfect gathering for you to socialize, learn, and network while enjoying tasty adult beverages.

For more information about NSHappyHour, visit http://nshappyhour.org.

Today was the last day for 360idev and what a great 4 days it has been. Catching up with friends, making new friends, listening to great talks, and yes, having a beer or four. This 360idev was extra exciting me for because I got a chance to talk.

My presentation “Building Web Service Powered Apps” didn’t start off great. There was a technical issue with my laptop and the projector that cause the talk to start late. Then as I tried to show an example of a web service call using the Twitter API I got a request limit reached error.

Despite the bumpy start and the shorten time frame, I think the talk was okay. Not great but okay. I wasn’t able to talk through some of the points I had hoped to cover and I had to skip a couple of the demos. My plan is to record the skipped demos as a screen cast and post them here soon.

Thanks to all who came to my talk, and big thanks to the 360idev team, other speakers and the attendees who made the last few days in San Jose great.

The iPad release day is less than 2 weeks away and like many iPhone developers I’m scurrying along to get my first iPad app submitted before the deadline. The introduction of the iPad as a new target platform means developers can choose to target the iPhone only, target just the iPad, or target both within a single application. The last option is called a universal binary and is recommended by Apple.

The user benefits with the universal option in that the same application can run on each iPhone OS device. In other words, the same app will run on a user’s iPhone, iPod touch, and iPad. Best of all the user only pays for the app once even if the app is used on multiple devices.

I’m a fan of universal. It makes the buying decision easier for the user. Buy the app and it will run on all your iPhone OS devices, the ones you own today and the ones you might buy tomorrow. The user doesn’t have to think, “I have an iPhone but I might buy an iPad soon. Should I buy the iPhone only version or the version that will run on both?”

The universal also makes it easier for the developer with regards to app naming and marketing. With a universal app the developer has only one app, which means only one app name and one app icon. The alternative is to release multiple editions for the app, each with its own unique name such as “App XYZ”, “App XYZ for iPad”, “App XYZ Universal”, and so on.

Marketing with a universal app is easier too because the developer is marketing a single edition of the application. The developer doesn’t need multiple app descriptions or web pages for each app edition. But the universal option is not without its problems.

First, what happens if the developer already has an iPhone app in the App Store. Can a new build of a universal binary be submitted as an app update? Can it be submitted as an update before the deadline for launch day? If not then that means a new app must be created which means having different app names. And of course existing ratings and iTunes comments will not appear for the newly created app.

Another issue comes to mind. To the developer, a universal app might feel like writing two separate apps wrapped into a single binary. The user experience, the views, navigation, artwork, etc will likely be different for the app when run on the iPad versus the iPhone. This complicates the code base for the developer, which increases the chances for bugs. The developer can overcome this by separating logic in the code and performing additional testing, but this increases the development cost for the application, which leads me to pricing. Higher development cost can lead to higher pricing.

Pricing is a big issue for me. Will users pay more for an app on the iPad, especially if the iPad version has more features, features not feasible on the iPhone? I think so. But will the user who only owns an iPhone with no plans to buy an iPad pay more? I think it’s less likely.

A desktop app typically costs more than an iPhone app, and since the iPad is closer to the desktop than the iPhone in terms of its ability, especially for productivity apps, it makes sense to me that an iPad app will cost more than it’s iPhone equivalent. Will the higher price for a universal app mean the developer will likely loss out on app sales from iPhone and iPod touch users? Or will there be another race to the bottom (i.e., 99 cents) in terms of pricing for universal iPad apps? I certainly hope not.

A developer can get around this by releasing 2 editions of the same app, one for the iPhone only at lower price point and a second universal app at a higher price point. But now we’re back to complicating the buying decision for the user with different editions of the same app. The user is back to thinking, “Which edition do I need? Which one should I buy?”

I already asked will iPad app pricing race to the bottom like we saw with iPhone apps, and again, I certainly hope not. Developers will be able to do much more on the iPad which will justify the higher price. But should developers expect iPhone and iPod touch only users to pay $9.99 for an app not as feature rich as the iPad equivalent? Or should iPad apps limit functionality to only what is feasible on both devices for the sake of a lower price point?

I wish I had answers to these questions. I’m sure the answers will become clear once the iPad has been released and developers see and understand more, but for know I’m left scratching my head as I ponder these questions.