<< Getting Started with the Bing Maps Silverlight Control, Visual Studio 2008 and Blend 3 | Continuously Display Lat Lon Coordinates in a Bing Maps Silverlight App >>

How will Apple’s New Developer Agreement Affect iPhone Mapping Apps?

by James Richards April 09, 2010

The Twitterverse and Blogosphere are all abuzz with yesterday’s news that Apple has apparently changed terms of its Developer Agreement to explicitly ban apps created with cross-compilers. This got me thinking about how this change might affect those of us developing mapping apps for the iPhone (and iPad).

The change that most people are talking about is in section 3.3.1 which now reads:

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

I have to wonder if ESRI’s iPhone SDK or CloudMade’s iPhone SDK or any of the location toolkits such as SimpleGeo’s iPhone SDK were “originally written” in one of the approved languages without the aid of a cross-compiler. If not, apps built with these tools could be banned.

As an example, the linked SimpleGeo page states that “The SGClient is a basic Objective-C wrapper around SimpleGeo's OAuth API.” What is SimpleGeo’s OAuth API and does it meet these new requirements?

I’d like to know from some of these vendors whether or not their SDKs meet Apple’s new requirements.

But even more disturbing is this language in section 3.3.2:

“An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise.”

That sounds to me like Apple just banned the use of any third party APIs. Scary.

For now, we have to take a wait and see approach until Apple clarifies these points. But even if we can move forward using these SDKs to develop mapping apps for the iPhone / iPad, are people going to be willing to risk investing in this technology under these conditions? Even if you do everything right by Apple’s standards, there is a very real possibility of getting banned in the future when Apple suddenly changes it’s terms again.

It’s well known that Apple acquired Placebase last year, but no one really knows what the Apple Geo Team is up to. Who’s to say that Apple won’t release their own mapping platform and ban the use of all other mapping platforms on their devices? Sounds crazy, but then again, it appears that Apple has banned the use of a Lua which helped produce Angry Birds (the best selling paid app of all time) as well as every single game created by Electronic Arts.

Does this news change your perspective on developing mapping apps for the iPhone / iPad? Leave a comment to share your thoughts…

1fde374e-f781-4cf0-b3cd-49e836b603b9|0|.0

Tags: apple, iphone, esri, cloudmade, osm, simplegeo

Mobile

ESRI ArcGIS iPhone API – Integration with Core LocationIntroduction Last week I started to familiarize myself with the ESRI ArcGIS iPhone API public beta ...ESRI ArcGIS iPhone API – First ImpressionsThe ESRI ArcGIS iPhone API was released to public beta today. Jeff Shaner blogged and tweeted about ...ESRI ArcGIS iPhone API – Class Breaks Renderer SampleIntroduction Here is a quick sample demonstrating the use of a Class Breaks Renderer in the ESRI Ar...

Comments

4/9/2010 9:56:20 AM #

Is 3.3.2 really new? That's just a way to ensure that you don't bypass the approval process by downloading and linking at runtime to your own binaries. That's always been the way, and has to really to match the sandboxing requirements.

More will come to light over time, but I don't think it'll change much more than MonoTouch (which was always going to be a Jailbreak-only thing, right?) and Adobe's CS5 Flash thing.

Nixta |

4/9/2010 10:14:27 AM #

@Nixta - Good question. 3.3.2 may not be new. I picked up on it from this post about MonoTouch: http://redth.info/2010/04/09/is-monotouch-now-dead-in-the-water-what-does-apples-new-iphone-developer-agreement-mean/ (Note: the post appears to be offline right now.)

I saw a MonoTouch presentation recently, and I was under the impression that MonoTouch based apps have made it into the App Store. So I think Novell was thinking of MonoTouch as a legitimate path to iPhone development - but I could be wrong about that.

james |

4/9/2010 11:05:21 AM #

Turns out I had no idea what I was talking about with MonoTouch and Jailbreak. You're right, though I don't see why it's been allowed all this time. It's strange to me that Apple would have allowed it, given the very clear rationale behind the approval process in the first place.

I had always assumed there was a level of source-code review involved in the approval process. I suspect that's realistically only invoked in rare cases though.

I kind of feel for the MonoTouch people from a development perspective, but at the same time I've never been a big fan of cross-compiling from a user-experience point of view, and the tight user experience is so critical to iPhone success.

Nixta |

4/9/2010 12:49:39 PM #

@Nixta - I understand your point about cross-compiling. But from the presentation I saw the other day, it looked like MonoTouch uses native iPhone UI elements defined with Interface Builder.

What I thought was compelling about MonoTouch (and their plans for MonoDroid) is the idea that you could use an MVC approach to build business logic once and share it among apps on multiple platforms - but that you would build each UI with the native tools following the interface guidelines for that platform.

I also feel for the people getting caught in the cross-fire of this fight. Unity 3D developers are all freaking out now too. Imagine being well into a development cycle using one of these tools, and now you can't release your app. Even worse, what if you were being paid by a client to develop the app with one of these tools that you recommended? Ouch.

james |

4/9/2010 10:15:15 AM #

James, Matt from SimpleGeo here. Wanted to clarify a few things. First off, our SDK was natively built using Apple's framework. Our OAuth API is no different than say, Facebook or Twitter's authentication methods using OAuth so no worries there.

Additionally, Apple couldn't ban third party API access at all, otherwise every Twitter, Facebook, Bump, etc. apps would be banned immediately. Our API is no different in that regard. I think they are mostly referring to the private APIs that are internal to the iPhone framework. Those have always been banned from use.

Hope this clears things up.

Matt Galligan |

4/9/2010 10:25:21 AM #

@Matt - Thanks for clarifying. I figured your SDK was natively built, but it's good to know for sure.

james |

4/9/2010 2:07:30 PM #

Hi. I'd like to add that the CloudMade sdk is also native objective c code.

I'd agree with Matt that a general prohabition of Apis and libraries is unlikely as it takes the whole service provider/enabler tier out of play, which is not good for apple, the developers or the users.

Jim Brown
CTO CloudMade

Jim Brown |

4/9/2010 4:25:14 PM #

@Jim - Thanks for letting us know that the CloudMade SDK is native code.

james |

Comments are closed