Dec 18

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:

Dec 08

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.

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

Nov 13

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:

Nov 02

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

Oct 19

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

Oct 16

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

Sep 18

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:

Sep 05

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

Aug 31

If you are considering attending the 360|iDev conference in Denver, September 27-30, and you have not yet purchased your tickets, then today would be a good time to do so. The conference organizers tell me that starting tomorrow, the price will going up every week.

Check out the great line-up of speakers here: 360|iDev

written by Nick \\ tags:

Aug 21

Apple posts their answers to the FCC’s questions.

One of the more interesting items posted was the statistic that “more than 40 full-time trained reviewers” review 8,500 new applications and updates per week, and at least two reviewers study each application. Some quick math reveals that each reviewer spends on average 5 minutes testing an application. That explains a lot.

People are questioning if the 40 full-time reviewers is the entire review staff, or if there is an additional group of front-line reviewers. (Would these people be part-time and/or untrained?) Also, how can 40 reviewers (or really 40 / 2) handle all the languages stemming from 77 country specific App Stores?

Now that I got my frustrations with the App Store out of my system, I promise that this will be the last post on this subject for a while. Now back to the regularly scheduled programming.

written by Nick \\ tags: