First, let’s define “cookie cutter.” This refers to apps that follow the same template over and over. It also applies to apps that just pull in feeds that have no business being apps in the first place.

I’m not going to comment on specific competitors, but I believe as a result of the recent changes at Apple many of them will be out of business. The ones that are left are going to have to step it up, which is a good thing for the app store, for our business, and for consumers.

Mobile Roadie is not cookie cutter in any way. While we may provide a template, it’s a highly customizable template. Our customers can rename and reorder tabs any way they’d like. They can upload custom graphics and media, and of course content, to further differentiate their app. And they have the option of baking in custom features if they’d like from any outside developer they want.

I want to reassure our customers and partners that everything going on right now is a good thing for consumers and for Mobile Roadie. We are well positioned to adapt to ever changing standards, and this doesn’t hurt our business long term – it enhances it.

A frequently asked question we get is why get a native app when web “apps” are becoming so good? Why invest in Apple’s approval process and store (and soon Google’s and others) when you can hire a web developer to build you an HTML5 mobile friendly experience?

As good as web apps may be, they are still a far cry from their native app cousins. Here are a few specific examples that matter to you:

Push Notifications.

One of the great things Mobile Roadie customers do with their apps is reach their users – at times geo targeting them up to just one mile around any location – with a “push notification.” This message looks like a text message and appears regardless of whether the app is open or not. It’s an incredibly powerful way to reach users. Web apps simply can’t do this.

U/I.

As good as web apps have become, the overall user interface is still dependent on Safari. Things like scrolling, animation, transitions, forms, “cover flow,” and other native app-specific nuances aren’t possible or aren’t as pretty and seamless for users. Loading time is also greater in web apps than native apps. What this really means, quite simply, is that your users will have a better and faster visual experience with a native app – and be more likely to come back and frequent it.

Home screen icon.

Yes, you can create a “bookmark” which creates an icon on the iPhone’s home screen to a web “app.” But not everyone knows this. An App comes with a built in presence on the iPhone’s screen – making it easy to find and placing a constant reminder about you/your company/your brand/your group. Additionally, native apps show up in iTunes under Applications; web apps don’t.

Enhanced access.

Web apps can’t access your address book, iPod, or camera; native apps can. Native apps can tap into your iPod (to suggest to users what tracks they’re missing from your collection) and address book (to enable easy access to share with friends). Native apps can also access the camera that – in Mobile Roadie’s case – allows users to post photos from a particular event/show.

Your own world.

Native apps are all about you – your content, your users, your brand. But with a web app, while users may start off in your world, with one errant click Safari can take them to a completely unrelated website with no clear way back. This can’t happen in a native app.

While we applaud the efforts of developers around the world to improve HTML, Javascript, Flash (not on the iPhone), and other languages to make the web a more mobile-friendly place, there is still a very relevant place for native apps – and it is only going to grow as Apple (and others) add on features to the hardware that only native apps can take advantage of. While it’s a good strategy to have both a mobile-friendly website and a native app – if you wanted to go for the one with the best chances of making a big impact on your customer/fan base – native apps simply blow web apps away.

Since March 2009 we’ve tried to be good partners with Apple, making sure our Apps conformed to their standards, looked great, and added value for the end user and our customers. We also paid attention to blogs like TechCrunch and others that shined the spotlight on specific stories of rejections, and tried to proactively adapt.

Yet, despite our best efforts, in the six months since Mobile Roadie has launched, the toughest part of the business has been explaining to our customers the seemingly inexplicable delays and reasons for rejection. Adding insult to injury, Apple was very slow to respond, or just wouldn’t respond at all, when we tried to right wrongs.

In the last 30 days, however, I’ve noticed a change. I was cautiously optimistic after reading about how Phil Schiller was becoming more active in high profile rejections. Then I got a call from a guy named Neil. Neil explained that he was reviewing one of our Apps, one that happened to have quite a few YouTube videos. He told me that 3 minutes and 42 seconds into the sixth video (which was a cartoon), that there was a scene with nudity. He politely explained that this violates Apple’s TOS and the App couldn’t be approved unless we removed the video. I logged in to the CMS and removed the video in real time, he thanked me, and less than 30 minutes later we got an approval notice.

For Apple, a company of tens of thousands of employees that is reviewing a rumored 2,500 apps a week, to call one customer about that level of detail inside one App is truly amazing.

Even more amazing, Apple has approved nearly all of our v2 upgrades less than two weeks after we began submitting them, including approving 22 Apps in one day last week (a record for us). This is good for our customers and good for Apple to get our upgraded product in the store.

I’m glad Apple is waking up and being more responsive to developers, especially developers like Mobile Roadie that have many Apps in the store. Now, if we could just automate code base upgrades without having to resubmit each App individually…