Tobias Dengel is CEO of WillowTree Apps Inc., a mobile applications developer. He is also a BIA/Kelsey blog contributor, and will be posting regularly on mobile-related topics. The views he expresses are his own and do not necessarily reflect those of BIA/Kelsey.

At this point, the Apple Maps fiasco is well documented. Apple has issued an apology, and is making it easier for consumers to get Google maps on their iPhone. But there’s a much bigger problem under the surface that won’t be so easy to fix: almost every iPhone app that contains maps relies on the mapping framework provided by the iOS Software Development Kit (SDK), which Apple switched from Google to Apple maps without informing any developers of the implications.

Take a look at the two map screenshots below from the University of Virginia iPhone app — the one on the left is the map in iOS5 and on the right is in iOS6. In iOS5, the iconic landmarks on UVA’s “Grounds” are clear; in iOS6, the building locators look like a bunch of dots on an open field. As developers, we relied on the data present in the mapping framework when we designed what the experience would be – so we created simple dots hovering over the Google-provided building outlines for users to tap. If the map we were working with had been a picture of an open field, as it is today, we would certainly have developed a different approach.

The change has significant implications for the local search industry — the mapping function of every existing app is going to perform differently vs. 2 weeks ago. Apple does seem to be making adjustments rapidly — last week a search for a 3rd Street address while standing in Manhattan directed me to Brooklyn; today it is showing me an interstitial (“Do you mean Manhattan or Brooklyn?”). And in fairness it took Google years to get its maps to their present state. But I don’t know that consumers and app developers will give Apple years to fix this….

So what can directories and local search apps do now? Testing of course is the key — under a variety of scenarios and geographies. If the mapping results are not as desired, a redesign may be in order. For example, in the UVA app, if Apple doesn’t make progress soon, we may look at adding a layer with all the building outlines, etc. In other apps (e.g. for franchises), developers may have to plot buildings, local landmarks or other important data themselves. These types of things previously were part of the SDK so inexpensive and easy to do — now they will have to be custom programmed.

As of last week, Apple is requiring that any new updates to iPhone apps include a larger version that is optimized for the iPhone 5 screen. And many map-based apps will require expensive updates to ensure their usability in the new iOS 6 mapping environment. Looks like app development budgets that as of two weeks ago were targeting feature enhancements for Q4 are now likely going to be burned on just maintaining the status quo. That’s the unfortunate ripple effect of Apple’s iOS6/iPhone 5 launch.

_____

Tobias Dengel is CEO of WillowTree Apps Inc., a mobile applications developer. He is also BIA/Kelsey’s new technical editor and will be posting regularly on mobile-related topics.

The post Apple Maps’ Ripple Effect on Local Search appeared first on BIA/Kelsey - Local Media Watch.

While Apple iOS and Google Android have attracted hundreds of thousands of apps, BlackBerry remains stuck at some single-digit percentage of that number.

Is it that BlackBerry users don’t have the same appetite for apps that other smartphone users have? That would seem highly unlikely. It seems much more plausible that BlackBerry users have not been habituated to apps because there are so few of them, and frankly many BlackBerry apps aren’t that great.

The primary reason is that software developers shy away from building native BlackBerry apps. The platform is simply much more difficult to develop for than Apple iOS and Android. Some real examples:

1. Multiple Versions/Devices: It’s hard to make one BlackBerry app that will work well for all BlackBerry devices — there’s little standardization among RIMM devices. The “smartphone” BlackBerrys are touchscreen, whereas the other ones use a scroll-ball to move a cursor and make selections. There’s not even a standardization of screen sizes, which makes layout difficult and time consuming. To understand the issue in about one second, take look at the BlackBerry Operating System version chart on Wikipedia.

2. Testing: You can test your code on a simulator in the computer — but each simulator download is 150 MB (!) per device — multiply that times the devices on the above OS chart.

3. Internet Connectivity: Getting a connection to the Internet from your app is not at all straightforward. BlackBerry is designed for security, which means that all of your Internet could be running through a central proxy somewhere. This becomes problematic for development as the app code must probe and prod in order to figure out the best means of connecting to the Internet to fetch data from any sort of Internet-hosted datastore.

4. Debugging: In iOS, the development cycle is:
– change code
– click button
– watch the app load on the device and verify your code change

Now here’s the comparative debugging process for BlackBerry:

Change code, click button, watch your app get sliced in to 64kb pieces, a window prompts for your encryption password, each 64kb is signed by TWO signing servers (meaning that you need to wait for about 40 requests/responses for even a meagerly-sized app — making a build at the end of the day? forget it — the signing servers are too busy to handle all those requests; watch your e-mail box as RIMM e-mails you for every single piece that was signed (hundreds of e-mails); wait for the device to completely reboot; wait for the debugger to attach; then dig through the menus to find the “Downloads” icon to actually launch the app; then, as standard operating procedure, the debugger throws two or three error windows for which you are recommended to “ignore” per the RIM documentation; then you may check your code changes.

Bottom line: Development for BlackBerry is complex for UI, complicated for developers, resource intensive for computers, and time-consuming to test versus the Apple and Android environments.

Not surprisingly, BlackBerry has begun taking the position that native apps are a fad (see the article RIMM co-CEO interview with Barron’s this week), much like the AOL proprietary service was.

RIM’s position is that Web-based apps will dominate in the future. But only time will tell if it is right. At least for now, consumers continue to embrace the use of proprietary apps.

_____

Tobias Dengel is CEO of WillowTree Apps Inc., a mobile applications developer. He is also BIA/Kelsey’s new technical editor and will be posting regularly on mobile-related topics. The views he expresses are his own and do not necessarily reflect those of BIA/Kelsey.

The post BlackBerry Bets Against Native Apps (Again) appeared first on BIA/Kelsey - Local Media Watch.

Sometimes you see something so compelling you just know it’s the start of something big. The 7-iCollection iPhone app recently launched by Green Tomato for 7-Eleven Hong Kong fits that bill.

Simply put, it uses the phones “augmented reality” feature (if you haven’t seen this, the easiest way to understand it is look at “Monocle” within the Yelp app) to collect items hidden in 7-Eleven stores. So the user walks into a store, holds up his/her phone until a “collectible” (in this case teddy bear) shows up, and then captures it by jiggling the phone. You can then exchange items with your friends, and once you get a complete collection, receive a prize.

This is the modern-day version of the Pepsi bottle cap promo of my youth, where each had an NFL team helmet and you got some huge prize if you collected all 28 (the NFL of the late 1970s). We all bought Pepsi whenever we could and traded with our friends in a mad pursuit.  Pretty soon it turned out all of us had 27 teams and none could get his hands on that elusive Baltimore Colts (before Peyton Manning) cap — rumor was that only five of those were made in the entire country.   Some Pepsi marketer should get a gold star — this campaign is still remembered by at least one kid 30 years later.

The power of campaigns like this 7-Eleven Hong Kong implementation may be similar:

— Most important, it’s fun and addictive, and so will drive downloads and usage. This isn’t another “store locator” app; instead it gives the user a real payoff for downloading it.

— It drives traffic to multiple locations.

— The Collectibles/Prizes can be tied into whatever a retailer is trying to push.

— Collaboration among friends builds brand awareness.

— Users download the marketer’s app (e.g. 7-Eleven), not a third-party app like Foursquare or Gowalla.

— And unlike the Pepsi version of the 1970s, the retailer has the option to promote additional products/coupons through the app.

Certainly there will be many iterations/improvements on this concept — but for marketers interested in location-based campaigns, this is surely an approach worth considering. This app might just be a little glimpse into the future.

_____

Tobias Dengel is CEO of WillowTree Apps Inc., a mobile applications developer. He is also BIA/Kelsey’s new technical editor and will be posting regularly on mobile-related topics. The views he expresses are his own and do not necessarily reflect those of BIA/Kelsey.

The post A Glimpse Into Next-Gen Retail Apps appeared first on BIA/Kelsey - Local Media Watch.

Yesterday Apple updated various pieces of its developer rules/requirements. The change that got the most press was that Apple was “opening up its popular App Store to products made using Adobe Systems Inc.’s (ADBE) Flash program,” according to The Wall Street Journal. That description is somewhat misleading — there is clarification later in the article, but the casual reader might assume that iPhones/iPads now support Flash. They don’t. All that happened is that Apple is now allowing apps to be compiled from non-Apple software.

The most common will likely be Flash CS5, where developers can export programs as iPhone apps. The theoretical advantage is that programmers can work in CS5 and build apps for a variety of platforms. That said, there is a long way to go yet in proving this model, especially for high-functioning apps. What’s interesting is that while Apple is relaxing these constraints on one end, on the other it released its first ever “Store Review” guidelines. Historically, when we submitted apps to be approved, we didn’t have much to go on except Apple’s Human Interface Guidelines, which are typically very focused on UI and certain technical/design attributes. Now for the first time, we are getting much broader guidelines.

Apple’s guidelines, available at TechCrunch, start off with a bang — the second bullet says “We have over 250,000 apps in the App Store. We don’t need any more Fart apps.” Further down in the intro, “if you’re trying to get … into the store to impress your friends, please brace yourself for rejection. We have lots of serious developers who don’t want their quality Apps to be surrounded by amateur hour.” Cheeky stuff. But as developers, we agree with Apple — the more “trash” gets into the App Store, the worse for everyone. One of the things consumers love about the App Store is that most of the stuff there is good, unlike surfing on the Web or the blogosphere, where the opposite is often true.

Apple then gets serious with seven pages of small print rules. There are a few highlights that matter to any business considering an app:

— Lots of duplicate apps will be rejected — this confirms the day of every SMB having its own app is probably never going to happen — not that it would have made sense anyway.

— Apps that enable additional features/functionality outside of the App Store will be rejected — so you cannot send someone to a Web site to pay for new levels of a game, for example, thereby circumventing Apple’s system (and 30 percent revenue share).

— You MUST use the In App Purchasing API to purchase content, functionality, or services within the app — so you cannot use a credit card to sell anything that is part of the app.

–You CANNOT use the In App Purchasing API to purchase goods or services that exist outside the app — so you cannot sell your old record collection using in-app purchasing (presumably because Apple has no interest in getting into the messy chargeback world, among other reasons).

— Subscription sales must last at least 30 days and be available on all iOS devices.

— Apps need to inform users before collecting location information (this is not new) and obtain user consent for push notifications.

— And finally, “We will reject Apps for any content or behavior we believe is over the line.” And yes, that’s defined as “I’ll know it when I see it.”

At the end of the day, on the content side, Apple is giving itself lots of wiggle room to reject virtually any app it doesn’t like. What’s really interesting is how e-commerce is evolving in the apps — the divide between what MUST and what CANNOT be done through Apple’s In App Purchase is becoming clearly drawn. That’s where the money is.

_____

Tobias Dengel is CEO of WillowTree Apps Inc., a mobile applications developer. He is also BIA/Kelsey’s new technical editor and will be posting regularly on mobile-related topics. The views he expresses are his own and do not necessarily reflect those of BIA/Kelsey.

The post The Skinny on the New iPhone Guidelines appeared first on BIA/Kelsey - Local Media Watch.

Last week, Vic Gundotra, Google’s vice president of engineering, made a blog post announcing 100 million users a month for Google Maps for Mobile. In a fragmented, emergent mobile world, mapping is one area where there is a dominant leader. (Note that Gundotra’s post also includes a nifty little graph of Google Maps for Mobile’s evolution over the past five years.)

Hiding behind the mapping front end is Google’s frontal assault into the local search and small-business advertising market. The functionality Google Maps provides on a mobile device is truly amazing, compared with what you could do two years ago.

Read the rest of this post.

The post The Google Maps Behemoth appeared first on BIA/Kelsey - Local Media Watch.

Last week, Vic Gundotra, Google’s vice president of engineering, made a blog post announcing 100 million users a month for Google Maps for Mobile. In a fragmented, emergent mobile world, mapping is one area where there is a dominant leader. (Note that Gundotra’s post also includes a nifty little graph of Google Maps for Mobile’s evolution over the past five years.)

Hiding behind the mapping front end is Google’s frontal assault into the local search and small-business advertising market. The functionality Google Maps provides on a mobile device is truly amazing, compared with what you could do two years ago. In one week last week, I used Google Maps on my iPhone to:

– Find a way around a traffic jam driving into D.C.
– Find a pharmacy to battle my summer cold in NY.
– Find a hiking trail in western VA.
– Find a nearby bike store to get my wife’s bike fixed.
– Find the fastest subway route across NYC.

Not to mention, our company is currently working with the (very easy to use) Google Maps API to integrate mapping/GPS into two client apps in development. Virtually every client map integration we do is based on Google Maps.

Assuming I’m a somewhat typical user, the Google Maps business model is working — I use the maps’ free functionality almost daily, but some small percentage of those uses are revenue generators — certainly a search for a bike store and a pharmacy qualify as such. As I become accustomed to using Google Maps to find almost anything in the real world, searching for local businesses becomes part of that mix. Now extrapolate that out three to four years to a world where Gartner says half of all all U.S. Web usage will be from a mobile device.

All the while, Google is adding capabilities for SMBs to interact directly with Google — Place Pages follow the age old Google model of providing a very good service for free (in this case free business listings for SMBs), and then finding clever ways to generate revenues from premium services. And as with everything Google, the service is platform-agnostic, accessible via anywhere via a mobile browser at m.google.com/maps or via native apps for iPhone, Android, BlackBerry and other devices.

It seems, at least in these early innings of the great mobile wave, that Google has successfully been able to transition from Web search to mobile search by focusing on the one cornerstone of mobile: maps/location. Competition will surely intensify, especially on non-Android devices, as the other major players wake up to the new reality. But for now, Google has been able to do what AOL couldn’t do in broadband and Yahoo couldn’t do in search — successfully navigate to the next gen platform.

_____

Tobias Dengel is CEO of WillowTree Apps Inc., a mobile applications developer. He is also BIA/Kelsey’s new technical editor and will be posting regularly on mobile-related topics. The views he expresses are his own and do not necessarily reflect those of BIA/Kelsey.

The post The Google Maps Behemoth appeared first on BIA/Kelsey - Local Media Watch.

Google posted a somewhat innocuous-sounding legal update to its Android Developer Terms and Conditions a few weeks ago:

In the spirit of transparency, we wanted to highlight the changes:
• In Section 13.1, “authorized carriers” have been added as an indemnified party.
• Section 13.2 is new in its entirety, covering indemnity for payment processors for claims related to tax accrual.

The developer community is anticipating that this may be a very big deal. It could give Apple’s iPhone a run in an area where it has remained unchallenged — in-app purchasing. The consensus is that Google will attempt to use carrier billing to emulate Apple’s iTunes platform.

Read the rest of this post.

The post Is Android Launching In-App Carrier Billing? appeared first on BIA/Kelsey - Local Media Watch.

Google posted a somewhat innocuous-sounding legal update to its Android Developer Terms and Conditions a few weeks ago:

In the spirit of transparency, we wanted to highlight the changes:
• In Section 13.1, “authorized carriers” have been added as an indemnified party.
• Section 13.2 is new in its entirety, covering indemnity for payment processors for claims related to tax accrual.

The developer community is anticipating that this may be a very big deal. It could give Apple’s iPhone a run in an area where it has remained unchallenged — in-app purchasing. The consensus is that Google will attempt to use carrier billing to emulate Apple’s iTunes platform.

With its original post, Google provides a handy Trackbacks list of selected stories linking to the post. Sites from all over the world are abuzz over this story, all with the same sense of anticipation — when will Google launch carrier-based in-app purchasing?

An obvious question is why has this taken so long? Carrier billing has been around almost since mobile phones were first launched. The main reason, as always, is probably economics. Carriers are used to taking 50 percent to 60 percent. Developers would never go for that. Apple’s 30 percent already feels like highway robbery. So the real breakthrough here might be in economics — carriers are seeing what’s going on with iTunes and want a piece of the in-app revenue stream, even if it’s much lower on a per-unit basis. The rapid growth of in-app revenues has them singing, “We’ll make it up on volume.”

Right now, the main in-app purchasing channel on Android is PayPal, which requires extra keystrokes. Every interactive marketer knows that every keystroke hurts close rates. The brilliance of the iPhone is you can buy so much stuff, including the apps themselves, with one tap. If Google enables carrier billing with one touch, it will be a significant breakthrough toward leveling the economic playing field vs. the iPhone from the perspective of publishers and developers.

A key difference will be that the Android payments will initially go to the carrier, whereas iPhone payments go to the device manufacturers (Apple). We’ll not know for a while how those revenues are split between the carriers, Google and publishers/developers, but in any event, the carriers will add a financial incentive to push Android devices through their channels. If this platform takes off, the losers may be financial services companies that charge their respective tolls for credit card purchases, including PayPal.

The details of this purchasing system are the subject of much conjecture in the developer blogosphere right now. What we do know is that consumers buy more when given more and better payment options, especially if easier and trustworthy. No matter how it plays out, the net effect of an Android in-app purchasing system tied into carrier billing will be that another piece of foundation has been laid for the rapid growth of mobile commerce.

_____

Tobias Dengel is CEO of WillowTree Apps Inc., a mobile applications developer. He is also BIA/Kelsey’s new technical editor and will be posting regularly on mobile-related topics. The views he expresses are his own and do not necessarily reflect those of BIA/Kelsey.

The post Is Android Launching In-App Carrier Billing? appeared first on BIA/Kelsey - Local Media Watch.

Rewind to the year 2000. Virtually every TV ad featured both a URL and an AOL keyword. “Visit us online at weather.com or AOL KW: Weather.” The pundits said the AOL walled garden would come down. They were right. Will native apps suffer the same fate?

The AOL content world came into place because at the time the typical Web site experience was horrible. The content was lame, many Web sites looked like a Jackson Pollock painting, and they took forever to load. The Internet was commonly called the World Wide Wait. All those problems sound familiar? Just change the date to 2010, add the word mobile, and here we are.

AOL’s breakthrough was to make interactivity accessible to the average user. It did this by creating a walled garden of largely curated content, running on its own proprietary platform, Rainman. Rainman took content and allowed it to be downloaded one time, saved on your computer and have processes run locally instead of through your Internet connection. Much like native apps do today.

Read the rest of this post.

The post Apps vs. Mobile Web: Where to Develop Could Be a Function of ‘When’ appeared first on BIA/Kelsey - Local Media Watch.

Rewind to the year 2000. Virtually every TV ad featured both a URL and an AOL keyword. “Visit us online at weather.com or AOL KW: Weather.” The pundits said the AOL walled garden would come down. They were right. Will native apps suffer the same fate?

The AOL content world came into place because at the time the typical Web site experience was horrible. The content was lame, many Web sites looked like a Jackson Pollock painting, and they took forever to load. The Internet was commonly called the World Wide Wait. All those problems sound familiar? Just change the date to 2010, add the word mobile, and here we are.

AOL’s breakthrough was to make interactivity accessible to the average user. It did this by creating a walled garden of largely curated content, running on its own proprietary platform, Rainman. Rainman took content and allowed it to be downloaded one time, saved on your computer and have processes run locally instead of through your Internet connection. Much like native apps do today.

As bandwidth expanded, the value of the AOL’s Rainman decreased, and eventually was completely wiped out by the scale of the standards-based HTML approach.

Today, we are at a similar juncture. Native apps still offer a meaningful advantage over Web apps, but the difference will continue to shrink as bandwidth improves and the OS/carriers open up more functionality to Web-based programs.

Using the iPhone as an example, here’s a summary of key functionality you can only access using a native app today:

– Accelerometer
– Camera
– Record audio/video
– Push/Local Notifications
– Immersive Games (open GL)
– Calendar access (iOS 4)
– Background processing
– iAd

In addition, a native app (again using iPhone) offers:

– Distribution on App Store — this currently can have marketing value, similar to getting distributed on AOL did
– Curated software — this is especially important for new brands/products — it gives users comfort that the application is “legit.”
– Speed/performance for quick content “ easier to store certain content elements, such as splash pages, on the phone

The significant disadvantage of native apps is cost — with a Web app, you can hit most smartphones with one project. With native apps, you will have to publish three times and soon four times (iPhone, Android, BlackBerry, Windows Mobile 7) to hit 95%+ coverage.

Burger King is a great example of what you can do with a Web app. Type in “bk.com” on your computer, and then type it into a WebKit-based smartphone browser (such as iPhone or Android) — completely different experiences, each optimized for its environment. Users are coming to expect a mobile optimized/Web app experience when they hit a URL from a mobile phone. This is a big deal — 12 months ago a user would expect to get the same Web site when typing in a URL on a computer or mobile device.

So where do we end up on the native vs. Web app debate? It’s all in the timing. Given the rampant growth in mobile traffic, a mobile-optimized site or Web app is a baseline for virtually every Web site. But for now, given the advantages that native apps still offer, most companies will also reap meaningful benefits from a native app strategy, at least on the leading platforms.

_______

Tobias Dengel is CEO of WillowTree Apps Inc., a mobile applications developer. He is also BIA/Kelsey’s new technical editor and will be posting regularly on mobile-related topics. The views he expresses are his own and do not necessarily reflect those of BIA/Kelsey.

The post Apps vs. Mobile Web: Where to Develop Could Be a Function of 'When' appeared first on BIA/Kelsey - Local Media Watch.