I think there’s a chance that the reasoning behind the now infamous change to Section 3.3.1 of the iPhone Developer Agreement is much deeper than the community has thus far considered. There’s a pattern that Apple has been following since the beginning of the iPhone project that may be hiding “the truth” in plain sight.
They’ve been slowly training us developers to stick with the documented stuff and use their higher level APIs. They want us to accept their abstractions and work within them. This is usually rationalized under the guise of safety, compatibility, and quality control. Those are fine and acceptable reasons by themselves, but what if there’s another purpose lurking behind the curtain?
I think there’s a chance that Apple is slowly building Objective-C into a managed environment similar to Java/.NET. At some point in the future they could define an Objective-C HD (or whatever :P) that no longer maintains total compatibility with C. Since they use LLVM a lot now, they can even use that to analyze your code to make sure that pointer accesses are safe and controlled. Anything that isn’t safely confined to your own app would be an error. Access to the Objective-C runtime functions could possibly even be revoked. After which point, Objective-C HD no longer compiles to machine code but instead to an intermediate representation.
By doing something like this, they can abstract the actual underlying CPU hardware and architecture out of the applications themselves as well as maintain a truly safe sandbox where private and undocumented APIs simply will not be allowed to work. Apps on the App Store would be submitted in this intermediate format which they can translate into the machine code that’s native to whatever CPU happens to be in the device you’re downloading the app for or they could simply put a JIT in iPhoneOS (although there’s no reason to waste the CPU cycles on the device if they can translate them once on the backend - at least for mobile stuff).
Ultimately OSX itself would probably go this way as well. Each new app would become sandboxed to public and documented APIs and the OS transforms from the traditional thin hardware abstraction layer to a much thicker platform abstraction layer which provides high level and clearly defined services. Of course due to legacy constraints, I would expect an OSX transition of this nature to take many years and be a more gradual process. The iPhone platform is a great way for them to experiment with the idea since it’s been closed and heavily regulated from the start. (I do not think any of the closed-ness of the platform has been an accident and nor do I think it was done for malicious intents of evil-like control that pundits attribute to Steve Jobs and Apple.)
(Ultimately, I think the entire web may transition from HTML/Javascript/CSS to a kind of standardized instruction format like a bytecode, but we’re probably a decade or more away from that if it should ever even happen.)
So how does Section 3.3.1 lead me to this? Well, if Apple was getting ready to close off and eliminate total access to the hardware itself, they certainly don’t want people writing tools that target the CPU directly, generating machine code, or making other unsafe assumptions about what your code can do just because it happens to be technically possible to do right now. It’d make it harder for them to make this transition and it’d also lead developers to potentially wasting a lot of time building something that won’t be useful at all in the (near?) future. The contractual restrictions on private and undocumented APIs were only the start. Section 3.3.1 may be a clue that the next step will make those unapproved APIs entirely inaccessible and impossible to actually use at all.
Apple wants to reinvent computing. You didn’t think they’d just constrain themselves to the end-user experience, did you?
@BigZaphod
This entry was posted on Friday, May 21st, 2010 at 10:26 am and is filed under Programming, Thoughts. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.
0 comments:
Post a Comment