Letter to Steve Jobs
probablyinteractive.com
probablyinteractive.com
As John Gruber stated, the real reason behind the band is to prevent someone from establishing cross platform development tools that will trivialize the choice between getting an iphone and another phone/OS.
What's to stop a tool developer producing an Objective C library and compiler that can target both iPhone and Android? The original source would still be in Objective C. If it was developed specifically for the iPhone, and only later for Android, it wouldn't be a compatibility layer - only the Android port would count as the compatibility layer, with the iPhone original being the native one.
So let's all hope Android (or any other mobile platform) is very successful. Yes, you iPhone-Developers, too should wish for Androids success!
I think Apple isn't used to being in control. Cross platform on OSX generally means poor versions of programs designed for other platforms. That isn't an inherent factor of cross platform tools, its because OSX is a minority OS. For instance in all the complaints about Firefox on OSX noone has stopped to think that Firefox on Windows is equally developed on a compatibility layer.
With the iPhone OS dominance in handheld software compatibility layers, Android and other platforms will be the minorities dealing with poor ports. Cross platform tools will be designed for iPhone OS.
Having said all I've said against section 3.1.1, I'd have to say I support banning Flash CS5 from the App Store, there is just no need to blanket ban compatibility layers. Maybe Apple should institute a framework whitelist - it'd certainly be up their alley in terms of control, and would let decent platforms like Unity continue.
It may also be worth nothing that the particular case of Lua was already prohibited under the iPhone DPLA section 3.3.2 which states that no interpreted code may be included unless it's run by Apple's interpreter(s). Wax embeds a third-party Lua runtime that does just that.
That said, there was talk about moving Wax to llvm-lua such that the resulting application would be compiled machine code. The new clause precludes this option entirely.
The only uncertainty left, now, centers around enforcement. There are a number of PhoneGap and Wax powered apps already in the store, and PhoneGap was even blessed as an approved framework. Only time will tell if that blessing stands.
Even though I can't build iPhone applications, to me this ban makes sense for the following reasons:
1.) Limits the total number of applications. Apple knows that the "100,000+ apps" is just marketing. How many unit conversion applications do you need or does Apple want clogging up their approval process.
2.) Reduces the velocity of the application submissions. Having a more controlled ecosystem means that everything isn't done at once. This is core to Apples strategy. Roll things out in phases; build features that people want over time. Cut&Paste, Multi-tasking...
3.) Forces people develop iPhone applications on Mac hardware.
4.) The more layers between you and the developers building the applications increases compatibility issues, which are out of your control.
5.) The more layers between you and the developers building the applications decreases the speed at which applications can take advantage of new features. Apple releases a new api now any developer using a 3rd party framework needs to wait for that framework to support the new API. This impacts the significance of the new feature.
There are relatively few conversion applications in comparison. Conversion applications are really not a problem.
How about the twenty or more music sequencer applications? Currently I would not easily find out which one is really good. Should Apple limit people submitting these applications? I'd rather have the market decide and have users rate these applications and an effective way to search for applications that are above some rating level.
Apple should think harder about presenting these applications to the user in such a way that finding and evaluating gets easier. It might also want to think about the rating mechanism and how it works.
Apple should spend less time in legal battles or building fences.
Also, I think there needs to be:
6.) Prevent the possibility of Adobe gaining ground with an iPhone IDE. While I think it's unlikely, Apple would be hurting if masses decided Flash was a more productive way to create the many basic Apple Apps (such as fart apps, conversion apps).
7.) Hurt the Adobe CS5 launch. Days before release, really?
http://appshopper.com/music/a003-guitartube
Scroll down to see the other apps created by this developer. They're all cookie-cutter apps, each one for a slightly different genre of user. He has a Picasso video lounge -- for all those users who want to join the Picasso social networking video channel. I think the number of apps is pretty meaningless when you have dozens of crappy apps like this.
Apple's decision starts making some sense to me now (I don't develop for iPhone, so the ongoing drama is rather distant for me). The choice of languages - C/C++/Objective-C - clearly indicates that Apple wants efficiency, not just quality. Just add one layer between the language and the CPU (e.g. a virtual machine) and your phone's battery will die 5 times faster.
I'm sorry for the dynamic language folks, but we are back to the era of bits and bytes, at least when it comes to smaller mobile devices. I think smarter manufacturers of mobile devices will do something about it pretty soon, once they see the boost of quality in the iPhone market. Provided that actually happens, of course.
Battery life is not much affected by a dynamic language. Because no one with a clear mind will implement things like decoding of video in a dynamic language. But what people want is to implement GAME LOGIC in another language and not in C.
The real battery life that matters is based on costly processes (like flash) and using costly services.
Navigation is such a thing. There are many many applications for Navigation. ALL of them are a huge source of emptying your battery.
I have used a single navigation application presenting a map and recording my track - battery life goes down to two hours. The reason is the screen, the internet connection for the map and the GPS receiver - all demanding power.
But people want to use those things. So in a car the iPhone gets electricity from the car. On a bike there are electricity adapters also.
There is NO reason to assume that a software written in a high-level language and translated to C will empty battery five times faster.
YOU CAN WRITE BATTERY EMPTYING SOFTWARE IN ANY LANGUAGE - AND SOME OF THESE APPLICATIONS ARE VERY USEFUL - LIKE NAVIGATION APPLICATIONS.
Take for example a program for the iPad that plots complicated mathematical formulas.
Apple forbids translating the formulas to machine code on the iPad - because that would implement another programming language and runtime on the iPad. So Apple's restriction SLOWS things down. At the same time besides computing the formula the plotting application does mostly calling UI function (drawing, 3d stuff, etc.) and waits for user interaction (zooming, rotating, ...). You can write that part in any language - it is mostly calling platform functionality. So in this domain it either don't matter (because the UI code is mostly calling to the platform) or is getting worse because of Apple's policies (because you can't compile complicated formulas on the device, because that would violate Apple's developer restrictions).
Do you know how (a + b) works in different languages? Have you ever looked into Python, Ruby, Java, C/C++ (and (+ a b) in Lisp if you wish)? The difference is huge.
In dynamic duck-typed languages (a + b) means checking the types of the operands before you can decide what + means and before you actually do something, for example add integers, or maybe float's, or maybe concatenate strings, or maybe throw an exception if anything's wrong with the operands. Let alone variables take up more space - and that's another source of power consumption - because they can be of any type.
From my observation, dynamic languages are 3 to 10 times less efficient. And I wouldn't bet on developers' "clear mind" like you said.
Edit: and I'll let you go with "bullshit" (which you edited later) and a lot of irrelevant, emotional demagogy.
(+ a b) can be optimized in Lisp. You might not know it, but Lisp has type declarations and several compilers are making good use of it. This widens the range of software that can be written in Lisp. Typically this allows the core logic to be written in plain Lisp and more challenging parts in Lisp with type inference and type declarations - the yet more challenging parts can be written in C or assembler - some Lisps have inline assemblers or inline C - all have extensive interfaces to call routines written to C calling conventions.
(+ a b) can be optimized in Lisp
(a + b) in C is always as optimal as it can be on a given platform. You don't put special effort to make it optimal ("oh, maybe I should declare a and b as typed... let's ask this on the forums if my compiler supports it and in what way").
The effect of type declaration on numeric operations is pretty much the same for all Common Lisp compilers that support that. The type declarations themselves are standardized. What is often different is the amount of type inference a compiler does.
* (defun twice (a) (declare (fixnum a)) (the fixnum (+ a a)))
TWICE
* (disassemble 'twice)
; disassembly for TWICE
; 02AB2CBF: 488D0C12 LEA RCX, [RDX+RDX]
; C3: 488BD1 MOV RDX, RCX
; C6: 488BE5 MOV RSP, RBP
; C9: F8 CLC
; CA: 5D POP RBP
; CB: C3 RET
Actually I would prefer C code to be slower and more safe by default. For that I would trade speed in a lot of places.
Guess what, Lisp and others have C FFIs and Objective C bridges and can call Apple's library.
The only reason Apple is welcomed/accepted to do so by many (developers and users) is the excellence in their execution. Apple is not an “open” company - it never has been.
Especially as a developer one should have understood from the beginning that using their tools might possibly be somewhat of a Faustian bargain.
Sometimes I myself feel quite guilty for having chosen this path (trying to become an iPhone/iPad indie) but then I remember myself that the benevolence of this “dictator” is not really targeted at me as a developer but the users.
I admire that approach and that is why I am not sure if users will really benefit from these particular kind of policies/politics. I was planning to partially use iPhone WAX not only because I really like Lua (and it’s highly embeddable scripting capabilities) but because of productivity reasons as a one-man team. In spite of introducing additional layers of abstraction I think it wouldn’t have significantly impacted performance (Lua is fast).
I never cared about Flash nor any Adobe tools though and I am still among the ones who don’t care that much if they have to use C/ObjC because I like to use that set of technology but I see myself for the first time to become more than a little wary.
This is all about using C# and Flash to create complete apps.
I still maintain my stance regarding the main culprit in this debate, being that Flash should be set fire to and urinated on for the shitty product it is, but I definitely feel that the collateral Apple is causing here is a potentially much larger problem than the Flash problem they solved by the ban.
Yeah new policy sucks, Steve won't change it even if you send thousand of letters, sometime he might bother to answer, but it'll be the same thing.
Although if he answers, that's great, because then you can publish it again and HN can be flooded with more "letters to Steve" and "Apple stole my teddy bear" stories.
I'm hopeful that my letter causes change, but I haven't asked for an outright removal of the ban, but a clarification on these techniques.
... saying you and your apps are banned.