Private Calls Restricted: Apple Decides How Developers Call Documented APIs


News: Private Calls Restricted: Apple Decides How Developers Call Documented APIs

  1. "If you want to write code for a platform where the only thing that determines whether you're going to succeed with it is whether your audience loves it, the iPad isn't for you."  -Cory Doctorow

    Sometimes, there's a way to write about something controversial, make your point, and at the same time, bring together both sides of an issue to a point of common understanding. Alternatively, you can write something in a way that simply draws a line in the sand, and forces both sides of the debate to get their backs up against the wall. You only need to read a line or two of a Cory Doctorow's column to know which way the ink in his pen flows.

    "As a copyright holder and creator, I don't want a single, Wal-Mart-like channel that controls access to my audience and dictates what is and is not acceptable material for me to create." -Cory Doctorow

    The discussion is both timely and pertinent, especially with the release of the iPad, and the updated license agreement for iPhone development. Just take a look at section 3.3.1 of the new iPhone Developer License Agreement:

    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).

    Doesn't this sound rather restrictive? John Gruber interprets this as essentially banning Adobe's Flash-to-iPhone compiler. If that's a true assertion, then it certainly puts a damper on Adobe's Flash Professional CS5 release. Lee Brimelow, platform evangelist at Adobe and the author of The Flash Blog, gets even more to the point when he says, quite simply, "go screw yourself, Apple!"

    "If you want to live in the fair world where you get to keep (or give away) the stuff you buy, the iPad isn't for you."  -Cory Doctorow

    Certainly, Apple has the right to control the quality and secure nature of its products, and nobody wants to see poorly written or compiled programs allowing viruses and bugs to run rampant on their handheld devices. But just how far is too far?

    Well, if you want an opinion on these subjects, something with which you can either strongly agree, or vehemently disagree, check out Cory's column. John’s is solid as well.

    "If you want to live in the creative universe where anyone with a cool idea can make it and give it to you to run on your hardware, the iPad isn't for you." -Cory Doctorow

    Why I Won't Be Buying an iPad, by Cory Doctorow

    Does the iPhone License Agreement Ban Adobe's Flash Compiler?  by John Gruber

    Go Screw Yourself, Apple! by Lee Brimelow

    Threaded Messages (12)

  2. Doesn't this post belong on  :)
  3. The Pervasiveness of Java[ Go to top ]

    Indeed, Apple has its segment in the client side, but there is an effect on simply the adoption and acceptance of Java when major players in the industry marginalize our language of choice.
  4. Cross Compiler[ Go to top ]

    A viable way around this problem is the use of a cross compiler.  You code in one language and then emit code in one of the supported languages using a runtime library.

    We did it for years with C++ prior to the release of real C++ compilers on many platforms.

    I do not think the phrase "Applications must be written in" has any substance. 

    This is probably just a short term way of killing Flash.

    What do others think?
  5. Short Term Remedy[ Go to top ]

    A way of killing Flash? I don't like Apple's business practices, but I don't like Flash either. Hmmm. Is the enemy of your enemy's enemy still your enemy?

    What would be Apple's motive though? What is in it for them to kill flash? 
  6. Cross Compiler[ Go to top ]

    Cross compilers specifically won't work, as the ORIGINAL source code will not be in C/C++/Obj-C.

    The goal is to get iPhone developers to write iPhone apps. The goal to ensure that those writing those apps are focused on the platform, to not let the iPhone become a "commodity" platform for "generic" mobile applications.

    If you want to distribute code for the iPhone, you're obligated to write for the iPhone, not some other, generic, platform agnostic toolkit.

    That's the driver behind all of this.
  7. But is that good?[ Go to top ]

    The goal is to get iPhone developers to write iPhone apps. The goal to ensure that those writing those apps are focused on the platform

    So, is that a good thing, and if so, why? Why shouldn't developers be allowed to write applications that might run on multiple devices other than the iPhone? Is there a sound, technical reasoning behind this, like the security or the quality of the applications that are deployed, or is it just an anti-competitive practice by Apple?
  8. But is that good?[ Go to top ]

    It's both, sound technical reasoning and "anti-competitive".

    The sound technical reasoning is you don't get lowest common denominator interfaces for you apps. It's good in that you have code running the native iPhone infrastructure rather than something that's potentially mimicking some aspect of another platform levered on top of the iPhone. It's good in that your developers are basically required to understand the ins and outs of the iPhone platforms specifically rather than their toolkits views of it.

    For example, in the Java world, beyond perhaps worrying about drive letters and different file separators, a basic Java app "just runs" with NO understanding of the underlying Windows platform. Yet, obviously, Windows isn't really quite that shallow. So, it's kind of hard for someone with no Windows knowledge to really leverage the Windows OS.

    So, the native toolkit requirement means that the developers need to have some depth of knowledge (though certainly not "expert") of the iPhone OS and environment to develop their applications. In the end, you will likely end up with applications that better work with the iPhone OS, leverage the in-built services, etc.

    Overall that can result in "better quality" applications on the iPhone.

    We have all seen bad cross platform ports, the native development requirement helps reduce that problem.

    From the "anti-competitive" point of view, that's an interesting turn of phrase. The move is VERY competitive. Basically, competitors are going to have to compete without iPhone developers. Competitors are going to have to have to compete and attract developers on their own for being something besides simply a "mobile device". There will need to be a compelling reason to convert a (now) dedicated iPhone developer to run on your platform, rather than hoping that they'll come to your platform "for free" using a cross platform toolkit.

    "Unleveling" the playfield is what competition is all about, frankly.

    Do you consider MS development of .NET to counter Java anti-competitive, which is effectively the same thing, if perhaps less formal, that Apple did? I certainly don't.

    So, for the short term at least, in the mobile space, you will have iPhone developers, and "other mobile" developers. Apple feels that it's worth distinguishing their device at the development and application level from other platforms. It's not going to be a "generic Java ME" phone.

    The mobile space is already fragmented. The fragmentation is what promotes the development of cross platform toolsets in the first place. But what you end up with is applications developed to the constraints and boundaries of that toolset, not the underlying platform.

    Doesn't do Apple much good to innovate on its mobile platform some new feature only to have it go unused because A) other platforms can't do it yet and B) the Predominant Cross Platform Toolkit (whatever that may be, if one ever rises) doesn't support it either (because of A).

    We see this today with folks browsers developing new capabilities, that "no one uses", because everyone wants cross platform compatibility.

    So this move lets Apple accelerate their platform, being MORE competitive, because they "know" that their development community has no reason to hold back and not leverage the platform to the hilt.
  9. Very well put, and very well written. That's an interesting take, especially with all the discussion on today about the problems with the Java Community Process (JCP) being dragged down by so many vendors accepting the lowest common denominator, as opposed to embracing innovation. Not sure if I completely agree, but you've certainly made the position much easier to understand. Thanks!
  10. The secondary effect of Apple's move impacts my company PushToTest. Apple's proposed changes to the iPhone OS 4 SDK license appear to lock out Appcelerator Titanium from the iPad/iPhone/Touch marketplace. That would have a negative impact on Appcelerator's prospects as a viable business.

    Last year I asked "Maybe we don't need objects to build client side apps?" I wondered what it would be like to build a client side desktop application using Web technology (Ajax, Javascript, etc.) I put my money where my mouth is by deciding to use Appcelerator Titanium to build the TestMaker Editor. I documented the design here. I recorded a screencast with the Editor developers to explain the process we followed, the techniques we used, and the generally favorable experience. 

    It just does not make sense to me to be building anything requiring a user interface with Java SWING. The advantage of using Web technology to deliver desktop, mobile, and dedicated (aka iPad) user interfaces is strong: Single code base, large developer community, end-user acceptance of Web interface standards. From that perspective Objective C and XCode is just as bad of a decision as Java SWING.

    The closest I've seen Apple and Jobs response to criticism is in Greg Slepak's  (of TaoEffect) blog. Jobs apparently responded directly to Greg and pointed him to John Gruber's blog

    I don't have any issue with a proprietary vendor trying to deliver a great user experience for its customers. My problem is how wide Apple limited support of its platform and the secondary effect it has on PushToTest's technology partner.

    Secondarily I don't think Apple understands how widely used Flash is for content playback (as opposed to application development.)

    Lastly, it seems to me a very USA-centric thought process at work at Apple. Itâ??s the same thinking that got us into Iraq, that we just saw in the Healthcare debate, and that used to be a defining Microsoft behavior. It is the belief in oneâ??s own right to make decisions with an assumption that we know better than anyone else and without regard to some better good in the world. We have to get past this thinking. The world will be much better off when we aspire to creative, maintainable, and high quality solutions to our problems.


  11. Headline[ Go to top ]

    I think the headline here is a bit misleading - maybe it's the use of the colon that implies the second statement relates to the first one??

    Because the definition of private API calls is that they are undocumented. More to the point, it's generally 'a bad idea' to use private API calls in any framework - what would be better still would be managing this through the programming language and compiler, rather than via legal agreements and static analysis of submitted code.

    What is more objectionable is when Apple's own apps use APIs not available to other developers - this has shades of MS Office, or the Safari/Firefox performance issue (where Safari on OS X used undocumented calls). 

    I can understand the argument that these things are likely still in development and subject to change, but in which case, why not keep any non-public code in a private framework to the application(s) - which is how, historically, a lot of OS X frameworks have evolved (i.e. they have often started as common libraries for the iLife, iWork and Final Cut Studio applications). 

    (As for the restrictions on using other programming languages - that's a whole other debate).
  12. My first thought was of Java ME. I've been holding out hope that Java 7 memory, performance, and footprint would improve enough that we could argue keeping Java off the iPhone simply didn't make sense anymore (not that it ever did). This kind of puts the last nail into the Java ME coffin on iPhone.

    Too bad since I was really thinking just how great mobile Java could be with a world class Java ME 3 implementation on the iPhone.
  13. Well, everyone is speculating on this now. Is a lawsuit between Adobe and Sun over this cross compilation compiler issue far away?