Flurry is still allowed by Apple in iOS apps. We used Flurry to see how many beta users actually used the app. They were not personally identifiable, of course but we got a rough sense of how many betas were installed (via the 0.1 version tag) and a really good sense how they were using (or not using) the app. For example, only about 15% of the users ever clicked on More in the tab bar. As a bonus, Flurry will log your uncaught exceptions for you if you implement an uncaught exception handler. This is invaluable for finding those bugs you can't find easily. Always email beta testers personally when you get any feedback - you might get some improvement suggestions that aren't that hard to implement.
He glosses over beta, but that's a crucial stage for non-developers to understand. Testing your application with real, live users is hugely important. If you don't beat the hell out of it, the public will, and you don't want to end up waiting around for Apple to approve a fix for a glaring bug that pisses people off.
(Sidenote: This is the pain of experience. I once pulled one of my apps just as it got popular because of a data destroying bug that my sloppy QA process didn't catch. Just one line of code, part of final performance optimization. Harmless, right?)
I wrote up a lengthy post on doing iPhone betas last year. Maybe it'll be useful to others here, dev or not:
Actually, I specifically bring up beta testing and testing with real world customers/conditions instead of addressing Andrew's question about what's involved in submitting an app. It was that important for me to mention it. Of course, we could spend an entire interview discussing that aspect, so perhaps that is why you perceived me glossing over it. :)
