The App Business Blog

After watching the highly anticipated presentation of Apple’s latest creation, here are my initial impressions from a developer’s point of view. Apologies in advance for the very long post and the somewhat random order of information. My mind is in hyperdrive thinking about all the new possibilities.

The iPad and the iPhone are very different

The iPad is not portable in the same way that the iPhone and iPod Touch is. You will not pull out the iPad from your back pocket and interact with a 2-minute app while you’re waiting in line at Starbucks. When thinking about apps for the iPad you have to think about how this device will be used.

The iPad is the new home computer. I see it being shared among members of a family to surf the web, consume media or look up information while watching a show. Or even interacting with the show in real-time. You don’t walk to another room to “use the computer”; it’s always laying around in your house, ready to be picked up and used where you are. Of course much of this applies to the iPhone as well. But one big difference is that the iPhone is very personal in that the screen is too small to share. The iPad screen seems big enough that you can have shared experiences around it. How about sitting around an iPad and playing a board game, where the computer takes care of the boring parts like keeping score and enforcing the rules?

I can also see a big role for the iPad in schools and educational settings. Schools that today have a computer in the classroom often have it shoved off in a corner or a special computer area, where students go to do “computer tasks”. An iPad can be integrated into the classroom and with the teacher-student interactions in a much more natural way. Given Apple’s long history in the educational market, I’m a bit surprised there was no mention of this. Maybe they’ll do a special school related event later with iTextbook and some other features targeted directly at the educational market.

As an app developer you need to realize that the iPad is not an iPhone. The same apps, user scenarios and UI designs that make sense on the iPhone, probably don’t translate well to the iPad. While there is sure to be an initial flood of iPhone apps “adapted” for the iPad, I think that in the long run the really successful iPad apps will be those that really take advantage of the unique characteristics of this device.

App development

Apple is really encouraging developers to create universal binaries that will run on all devices and that adapt to the current run-time environment. This has some interesting consequences. On the positive side for developers is that you only have to maintain one build. For customers this approach is also a good thing because they don’t have to manage different versions of the same app for their array of devices. (You know people will want an iPad in addition to their iPhone.) The economic drawback of this for us developers is that customers who have already purchased your iPhone app will get the iPad upgrade for free.

The bar for apps is going to be much higher on the iPad than the iPhone/iPod Touch. A silly app that just does one simple thing might be a fun gag on a device that you can pull out of your pocket and show your friends. But it’s going to fall flat on the larger capabilities of the iPad. I think people will expect more. However that doesn’t mean that app developers won’t try.

Relying on pixel doubling is not going to cut it. You need to adapt your apps to make use of the larger screen and the new SDK features. This may lead to a natural segregation of apps in the App Store: those apps where the developers actively invest in upgrades, and those that are more or less abandoned. Personally I think that would be a good thing.

Also, the bar for app developers is going to be much higher on the iPad. The learning curve for getting into iPhone development is not that steep. And if you don’t want to learn Objective-C and Cocoa Touch, then you can outsource development for a reasonable cost. Creating an app that works well on both the iPad and the iPhone is a whole new level. This requires that you have given separation of concerns some serious thought, you have a solid model-view-controller design, etc. Of course you can ignore this advice and forge ahead anyway. But given the conditional coding required to adapt to the two device classes, you are very likely to end up with a big pile of spaghetti code.

The new SDK 3.2 comes with a new NDA, so I can’t talk about any new features. But at a first glance there is a lot of new stuff to learn. It’s going to be an intense 60 days to master this new SDK.

Hardware

The iPad screen resolution is 1024 x 768. This is a 4:3 aspect ratio, instead of the 3:2 ratio of the iPhone and 16:9 for HDTV sets. So when you play HD content in landscape mode you’ll get black bars above and below the video. This is something to keep in mind when you create full screen video content for the iPad. The new SDK seems to support video playback that does not take over the entire screen, (finally!), so another option could be to play videos in portrait mode at 768 x 432 (=16:9) and leave the bottom half of the screen for other content. I’m guessing that the reason for the iPad screen size is that a more elongated device would feel awkward in your hands.

The lack of a camera is disappointing. The focus of the iPad seems to be on media consumption. And there’s plenty of new territory to explore here to keep us busy for quite some time. I wouldn’t be surprised if Apple included a camera in a future model. That would make the iPad a real communication and collaboration device. But then again, maybe they’re reserving that for the iPhone. Remember the fuss around the “missing” camera in the latest generation iPod Touch.

The Apple A4 processor is a big deal. Reports from people who got to test the iPad after the presentation say that the iPad is blazing fast. How could you even consider writing a suite of productivity apps for the device if it didn’t have the necessary horsepower. This bodes really well for app developers. How many times have you been hamstrung by the lack of CPU power in the iPhone? Now whole new horizons open up. And for the 4th generation iPhone coming later in the year, would you be surprised if it was powered by the A4 processor (or a close sibling)?

And since Apple designed the A4, they own it. How many other mobile device manufacturers have their own chip design company in-house? How are they going to compete? The iPhone showed that it’s all about the software. After almost 3 years competitors have yet to achieve the same usability and supreme user experience as the iPhone. Now add in a super-blazing-fast CPU (that nobody else can get their hands on) and the type of applications you can create on Apple’s devices just took another huge leap forward.

Content

By not including Flash on the iPad (no surprise in that) Apple has put another nail in the coffin of proprietary web technologies. If the iPad is the new home entertainment complement that sits on a kitchen or coffee table, people will avoid web sites that rely on Flash when they search the web for entertainment or information related to the show they’re watching. Before, you could maybe get away with a web site that did not support mobile devices. But with iPad media consumption devices that number in the millions that is no longer an option.

I’ve spent a lot of time building ebook and comic book readers for clients. So I can speak with some authority when I say that Apple has spent a lot of time and money building iBook. It is by far the best presentation of traditional books on an electronic device that I’ve seen. Kindle and Nook look very pale (literally) in comparison. I consider this to be state of the art for Book 1.5. The next step is to take books to another level: Book 2.0. Now that we have the hardware device, it is time to really innovate.

There was no mention of DRM for ebooks, but I assume that Apple will add an additional layer of Fairplay in the EPUB files that you purchase from the iBookstore (as allowed by the EPUB specification). DRM is a huge concern for people who buy a lot of books. Traditional books are compatible with almost all readers (=humans). But when you buy DRM locked ebooks for your Kindle, Nook or Sony device, you are tied to that vendor forever for reading your ebooks. Apple actually has a leg up in this race because there is a Kindle app for the iPhone. So if you have purchased Kindle ebooks in the past you can read them on your iPad. It will be interesting to see if Amazon will create an iPad version of their reader. My guess is that they will. In the long run it has to be more attractive for Amazon to deliver digital content vs. being in the hardware business competing with Apple and Sony.

I’m a little bit surprised that Apple just focused on traditional books. No mention of magazines, newspapers or textbooks. If the NY Times demo was any indication, then Apple will leave this area to individual publishers. That’s good for us developers since we get to build apps for each one.

The new gold rush

The work Apple has done with creating iWork for the iPad is nothing short of amazing. It’s hard to tell how useful productivity apps will be on a tablet until you get your hands on a device for a longer period of time. But I’m disappointed in the price level and the expectations Apple sets by “giving away” the iWork apps for $9.99 each. That means we remain stuck in dollar-app mode. (I’m convinced that Apple really likes dollar-app pricing. More on that in a future blog post.)

At $499 this is a mass market device. Apple will sell a lot of these devices. Dedicated ebook readers like the Kindle and the Nook will have a tough time to justify their existence. Kindle recently announced a SDK for their device, and Nook is built on Android so there’s a theoretical possibility that they’ll come out with and SDK too. Meanwhile Apple has over 100k developers with current skills and who are just itching to dig in and build new apps for this device.

I fully agree with Scott Forstall: This is going to be another app developer gold rush. It’s going to be fun!

written by Nick \\ tags: iPad

All so called analysts should be required to follow up on their predictions and show to the world how accurate they were. Since I don’t make a living as an analyst, I’m happy to give you my scorecard for my 2009 predictions.

Push API

The Push API was indeed introduced in 2009. This was an easy prediction.

MobileMe API

I still think it would make sense for Apple to lock in users closer to the iPhone/Apple/MobileMe world by providing a MobileMe API for the iPhone. But nothing close to this was revealed in 2009. A clearly missed prediction.

More APIs

We definitely saw new APIs for the iPhone in 2009, including video recording and iTunes music access. We would all have liked to see more, specifically more access to the phone part of the iPhone, but I’m still going to claim this as a win.

No Major Hardware Releases

The new iPhone and iPod Touch releases were exactly as I described them: incremental improvements.

Better App Store

Apple did introduce keywords for the App Store as well as one new top list that isn’t “completely tilted towards $0.99 apps”. But I wouldn’t call the organization of the App Store “vastly improved”. I’ll claim half a point for this one.

More App Store Commerce

“Apple will introduce more commerce options for the App Store, e.g. subscriptions and separate billing for content.” I think I hit the bulls-eye on this one! Keep in mind that I made this prediction before In App Purchase was announced even to developers under NDA.

No Trials

Time limited trials were not introduced in 2009. With In App Purchase for free apps I think we got a bit closer to trials, but that also came with other headaches. I think most developers would agree that we don’t yet have a good system for creating trials for iPhone apps.

Summary

A total score of 5.5 out of 7. Not too bad. Maybe I should make a living as an analyst. 🙂
Stay tuned for my 2010 predictions coming next week. In the meantime, have a safe and Happy New Year!

written by Nick \\ tags: predictions

Google Analytics is a powerful web analytics solution used by thousands of web sites. Like most Google products it’s free for most users.

Earlier I had toyed with the idea of adding a small UIWebView to each screen in an iPhone app to make use of Google Analytics. Since that would have been a kludge, I was happy to see that Google has introduced a native iPhone library that interfaces with Google Analytics.

Why would you choose Google Analytics over the many existing analytics solutions for the iPhone, Pinch Media, Medialets, Mobclix, et. al?

• Google Analytics tracks user behavior, whereas most other services just track number of users with a particular attribute or who have done a particular action.
• Google Analytics lets you slice and dice data in a seemingly infinite number of ways.
• If you’re not using Location Services in your app to report the location of the user, then the analytics tool has to rely on IP address lookup for the location. Google has a much better database for this. (Note that determining a location by IP address is reasonably accurate when users are on WiFi, but all bets are off when users are on a mobile network.)

There are some drawbacks with the current version of Google Analytics:

• The current version is 0.7 which means that there are some rough edges and bugs.
• The simulator is identified as an iPhone device is the stats. This is not a big deal since the number of users on the simulator (i.e. you) should be dwarfed by the number of actual customers.
• Another minor issue is that all devices are reported as supporting Java. 🙂
• The OS version is not reported anywhere.
• It’s not possible to tell Google Analytics the exact location of the user, should you know that from Location Services.
• It’s not possible to create custom segmentations. This is a really powerful feature of GA, and it would be nice if that was exposed through the iPhone library.
• If you’re not familiar with Google Analytics, it can be a daunting experience to explore and understand all the stats reported.

So which solution should you choose? My recommendation is both. I use both Google Analytics and Pinch Media, and I find that they complement each other well.

Adding Google Analytics to your iPhone app is easy.

1. Download the library here. See the very bottom of the page for the download link. (There used to be a regular Google Code project for this library, but that mysteriously disappeared.)
2. Add the libGoogleAnalytics.a static library and the GANTracker.h header file to your project.
3. Add the framworks required by Google Analytics. If you already have another analytics library installed, then you probably already have the necessary frameworks added.
4. Add a few lines of code to initialize the tracking and then a few lines where you want to track a page view or an event. See the included sample project for examples.

If you’re going to use more than one analytics service, you should consolidate the calls to each service in one place. Below are two methods that I use for Google Analytics and Pinch Media. Note that since Pinch Media doesn’t have any concept of page views, that method only calls Google Analytics, whereas both services track events.

- (void)trackPageview:(NSString *)pageName {
  // Google Analytics
  NSError *gaError;
  if (![[GANTracker sharedTracker] trackPageview:pageName withError:&gaError]) {
    NSLog(@"GA trackPageView Error: %@", [gaError localizedDescription]);
  }	
}

- (void)trackEvent:(NSString *)category
            action:(NSString *)action
             label:(NSString *)label
             value:(NSInteger)value {
	
  // Google Analytics
  NSError *gaError;
  if (![[GANTracker sharedTracker] trackEvent:category
                                       action:action
                                        label:label
                                        value:value
                                    withError:&gaError]) {
    NSLog(@"GA trackEvent Error: %@", [gaError localizedDescription]);
  }
	
  // PinchMedia
  NSString *subBeaconName = [NSString stringWithFormat:@"%@ - %@ - %@", category, action, (label ? label : @"")];
  @try {
    [[Beacon shared] startSubBeaconWithName:subBeaconName timeSession:NO];
  } @catch (NSException * e) {
    NSLog(@"Error starting SubBeacon %@ : %@", subBeaconName, [e description]);
  }
}

written by Nick \\ tags: Analytics

Unfortunately I was not able to attend any of Apple’s iPhone Tech Talk World Tour presentations this year. Fortunately several developers have posted their notes from the events.

• Stephen Ryner Jr.: iPhone Tech Talk Toronto, Notes on App Style, Notes on Layout and Icons, Notes on High Fidelity UI
• Daniel Jalkut
• Several developers, via The iPhone Blog
• Ronnie Schwartz
• Manish Gupta
• Jeff LaMarche

On this blog I talk a lot about UIWebView. It turns out that Apple is pretty bullish on using web views in your app as well (from the iPhone Blog):

• One dev who was new to Apple technologies found WebKit and their specific CSS (-webkit-gradient, -webkit-mask, webkit-box-reflect) to be “astoundingly powerful”. If you run WebKit or Safari, check out the westciv.tools.gradients demo.
• Apple stressed the advantages of using WebKit and embedded WebView. The AppStore app is an example of a native app with a WebKit UI made by Apple.
• A button made in CSS is much lighter than an image file and also scales elegantly (resolution independent).
• Even a JPG that’s only 50k in size will take up 10 times more memory when it’s decompressed and rendered in a UI.
• WebKit interfaces can be updated outside of the App Store approval process, so no resubmission just to change UI elements.
• Client-side database storage API in HTML 5 saves state locally and reloads the next time you view the page. See the webkit.org/demos/sticky-notes demo.

written by Nick

This week has seen the departure of two high profile iPhone developers: Joe Hewitt and Rouge Amoeba. This is a big loss to the iPhone development community.

Rouge Amoeba details the story of the rejection of their Airfoil Speakers Touch app and presumably that was the straw that broke the camels back. I think this case has some interesting aspects that are worth discussing. I will not take sides, since I don’t know all the details of what has transpired between Apple and Rouge Amoeba.

There has been an interesting exchange between Jeff LaMarche and John Gruber about this case, which to me highlights the difficult position that Apple’s App Store reviewers are in. The iPhone is a computer that is constantly connected to a network, but it happens to be disguised as a phone. The complexity of the applications that you can write for the iPhone is astounding. The Airfoil Speakers Touch app is a great example of a complex application that involves streaming audio over a network from another computer. When a very experienced iPhone developer like Jeff LaMarche is not clear on the details of where images that show up in the UI are coming from, how is an App Store reviewer (presumably without a developer background) supposed to understand how an application like this is architected?

Since Apple is unlikely to completely do away with the App Store review process, what can be done to make it better?

In Rouge Amoeba’s case maybe getting an engineer at Apple involved earlier could quickly have resolved any technical questions Apple might have, and then they can make an informed decision on merits instead of possible misunderstandings. To not overburden an already bogged down process, there should be a limit to how often you can call in engineers to review your case. Maybe you have to use one of your golden support tickets. (And they could borrow the process from American football where a team who challenges the ruling on the field does not get charged a timeout if the ruling is overturned.)

I think the bigger issue is transparency. (Regular readers know that I’ve been on this soap box several times in the past.) In the beginning Apple could be excused from being overwhelmed and making up rules as they go. But now, 15+ months later, it’s time to publish the rules. All the rules.

It’s the uncertainty and apparent randomness that is making life hazardous for iPhone developers and companies who depend on the App Store for a living.

Maybe Apple still doesn’t know all the rules and all the details. That’s ok. The American legal system works in a similar way with case law. There is a limited number of laws that have been legislated and then courts interpret those laws and apply them to real-world cases. The key here is that courts’ decisions are published for all to see and learn from. I know this is a gross simplification and a system that is not without controversy, and bad decisions. But I think there’s enough similarity for Apple to adopt a similar system.

If every App Store rejection was published by Apple, including a detailed explanation of the reasons, all developers could learn and avoid mistakes made by others. Developers would win in such a system. I think Apple would win even more with a less clogged review system and much happier developers.

written by Nick \\ tags: App Store

Thank you oDesk!

To all new visitors from oDesk: Welcome! If you like what you see here, click on the orange button in the top right corner of each page to subscribe to the RSS feed.

You should also check out the other blogs on the list. They’re all on my daily reading list.

written by Nick

I just received my session survey feedback from 360|iDev Denver 2009:

• Agree that the Session was Informative? 100%
• Agree that the Speaker was Authoritative? 100%
• Agree that the Session was What you Expected? 100%
• Overall rating (1-5, 5 being best) Avg : 5

Wow! I could literally not have asked for anything more. Thank you to all of you who attended my talk. If you have not checked out the presentation, it’s available here: UIWebView – The Most Versatile Class in UIKit.

While on the topic of feedback, feel free to suggest topics you would like to see covered here on the iPhone Development Blog in the future. Is there anything you would like to see more of? Less? Comments are open.

written by Nick

Back in the old days while the NDA was still in effect, us old-time developers had to walk miles through snow without shoes to find any information about iPhone development and the iPhone SDK. These days, there’s too much information available and it’s hard to know where to start.

It’s great if you have a veteran iPhone developer at your side to guide you through the jungle. To make sure that you understand the Cocoa Touch principles, get a good application architecture in place from the start, etc, etc.

Luckily you can have one of the best teachers in the business by your side for two days to get you started the right way. Dan Grigsby of Mobile Orchard fame is teaching his Two Day Beginning iPhone Programming Training Class in Portland, Nov 12-13 and in Los Angeles, Nov 19-20. You don’t need any iPhone or Mac programming experience before the class, but you should have some prior development experience, e.g. being a web developer.

More information here. If you enter the coupon code “nick”, you’ll get a nice discount if you sign up during early registration. (And no, I’m not getting any kickbacks on this.)

If you’re already past the beginner level, then you should definitely subscribe to the Mobile Orchard Podcast. It has great interviews with iPhone developers and gets into wonderfully gory details about iPhone programming and other development issues.

written by Nick

Today Apple launched the new App Store Resource Center. Calling it “new” is actually a bit of a stretch, since it seems to be mostly a collection of information that was previously scattered in several places. But we should still give Apple credit for the effort. The are moving in the right direction.

I still think my own App Store Rejection Reasons page is a good complement to Apple’s official documents. And I just updated the page with a few new items that I painfully encountered.

written by Nick \\ tags: App Store

After a brief outage due to upgrading to the latest version of WordPress, we’re back.

If you are running a WordPress blog, now would be a good time to upgrade to version 2.8.4. There is a nasty worm that’s going around attacking all older versions of WordPress. Ominous security advisories abound.

written by Nick