Apple forbids Python on the iPhone/iPad

If you’ve been following the latest Apple chatter on the blogosphere, you’ve surely seen this: … _apps.html

This surprising new restriction not only definitively bars Flash apps, compiled or otherwise, from appearing on the iPhone/iPad, it will also disallow Panda apps written in Python. I suppose C++ Panda apps are still tolerated, but good grief.

This specific restriction on the language a developer is allowed to use is outrageous. Time will tell if this restriction holds up. :frowning:


By my reading, the prior verision prohibited this too, by the “private APIs” clause.

Original, according to the link:

You could “macro” a Python program entirely into C, but the “original” would still be in Python.

I observe they make no attempt to enforce it with the machine, only the law.

Why would you want to be a control freak?

This is actually pretty typical Apple behavior. They’re attempting to stomp multiplatform developing so that devs will have to make their apps for iPhone alone and this maneuver is just about the closest to that goal they can get. Sad, but not surprising :cry:

I would think that behavior would be so unattractive that they would lose all their customers. Why would you develop for Apple when you could develop for everything else? Sunken costs, people, come!

Jobbs take some lessons of management with Gates? :laughing:

Does this also apply to frozen Python applications? Technically, that doesn’t contain actual Python code, just CPython bytecode.

I think this turns into an interesting human/non human thing.

So I write a game in python. Then have rdb translate it to C++ on the iphone. I guess thats ok? Why? But what if we replace rdb with freeze? Now thats not ok?

I think so, I would argue that rule actually bars all apps even the ones written in C,C++,ObjC,Js.

Say I write an app in the shower. I don’t have the source but the idea and how the data structures look like and UX. The I translate this “mind app” to either c,c++,ObjC or JS. I use the editor, debuggers (just like i used freeze before). I cant use it on the iphone os 4.0.

I don’t think i can write iphone apps because i cant dream in objectiveC.

Needless to say i am not buying any thing apple again.

No treeform, your shower app is still OK; it is still “originally written” in C++/etc; even though it did exist in human thought prior.

But your rdb translation is not.

However, if someone else wrote it before you in a forbidden language, then it was “originally written” in that, so then it’s not OK again.

However, you might argue that its original “form” was human thought, not written, so therefore it is not originally written at all. This may have been treeform’s shower example’s point, I couldn’t tell.

Does “originally written in C” mean:

  • In C in its original form, or
  • In C in its first-ever written form

New version:

Incidentally, your JavaScript can’t compile and directly link against the Document APIs. And I think “ever again” is a little harsh; 10 years down the line Apple could get religion and be ok again… that is, lose religion.

The traditional reading of the “private API’s” clause is that it refers to private, undocumented API’s within Apple’s libraries, not to third-party software that is linked in. The first developers on the iPhone were hackers who discovered and advertised all sorts of undocumented API’s that Apple would prefer people didn’t use.

Up until this latest license revision, it has always been an option to ship Python code by bundling it all up within a self-contained application that can be compiled by Xcode–this is, after all, how Adobe had been planning to work around the Flash restriction. Until now.

Clearly the clause does apply to frozen Python applications, because the clause is not restricting the form of the code, but its origin. Only applications that are “originally written” in C, C++, or Objective-C are allowed.

treeform and castironpi bring up the excellent philosophical objections to this overly broad restriction. We could argue for days over precisely what constitutes “originally written”. But none of this matters, because this definition won’t get tested in a court of law: Apple is the sole dictator over what software is released in the app store, and they get to decide whether your software was “originally written” in one of their approved languages or not.

Whether you can hope to slip one over on them and translate Python code into C/C++ anyway, to be compiled by Xcode, is also kind of beside the point. This activity is expressly forbidden, and even if they couldn’t detect it, on some level it’s not legitimate, and we therefore couldn’t advertise that we had a solution for delivering Python applications on the iPhone.

Apple is taking the double-or-nothing gamble: they are forcing developers to develop either only for the iPhone, or only for everything else. They are hoping that they have enough mindshare in this space by now that most developers will decide it’s better to sit on the iPhone side of the fence.

It’s exactly the gamble that worked out so well for Microsoft in the 90’s. And I fear that Apple might be right, and it will work out for them too, as evil as it is.


And people thought Microsoft was a bad, evil monopoly. Apple is sometimes even worse.

I wasn’t going to say this for fear of heading in an offensive anti-apple direction… But this is my biggest reason for thinking Android phones > iPhones. Not python specifically, but the general closed vs open mindset.

It does bring up a question I’ve been wondering about. Do current smart phones, ie the Droid/iPhone, have enough power and resources to run smallish panda3d apps?

most modern smartphone processors have enough processing power to run an entire desktop OS. their 3d-acceleration might not be compareable to a modern gforce. but it’s still good enough to run a wide range of games. the tegra chips which are now starting to find their way into those devices are especially intresting.

What are Apple’s motives?

Microsoft lets you write “other programs”, programs in other languages or with other APIs, for computers its OS runs on.

Apple does too.

Just not its phones. So why phones?

Also: Can you link with someone else’s library, if they’re both in C? Would that count as an “other API”? Or does all your code have to be your own?

It reminds me of the movies, where the pet has to choose between the boy and his master.

Lastly, I believe your code can also be in JavaScript, it just can’t directly link against the Documented APIs.

We, the consumers, are a party to every sale Apple makes. So why do we keep them in business, if they act like this? If you could put one company out of business first, would it be MS or Apple?

Then why is there a EULA at all, or whatever it is?

Just in case I can shed some light on this… I happen to be in the iphone developer program. After reading their docs and fighting my way in the community forums for quite some time I’m very familiar with their line of thought. They have always been obsessed with memory usage. That’s why they didn’t allow multitasking in the first place, so that the user doesn’t have dozens of apps running in the background. That way he/she only has one, and when you switch app, you free all the memory allocation cause the app dies.

So I’m pretty sure they are banning python now because they are gonna enable multitasking, and they probably don’t want scripted languages because they are associated with a bigger memory footprint. RAM has always been an obsession for them. I still think it’s silly but I bet this is the reason. Other reason could be security, a full interpreter running on the machine means millions of lines of code relying on private apis, it’s much more harder to secure the platform to prevent heap/buffer overflows leading to jailbreak this way. Also, maybe to overcome their fears of multitasking leading to freezes, they are gonna have some advanced memory management system with priority, scheduling, quotas, or something like that, and this would only be enforceable if nobody is using private apis (and if you use python you are using private apis indirectly).

Also, while I’m pretty sure one of these three (or several of them) are the technical justification, nobody can say if it’s a genuine move or if they are just using it as an excuse to suppress other languages and consolidate their toolchain (or both.) Just like the technical justification for no multitasking is to prevent memory exhaustion, but it could just be so that nobody implements a skype daemon that can permanently be listening for incoming calls, etc.

I don’t buy that. If resource utilization (memory or otherwise) were the issue, that wouldn’t preclude the use of any particular language. Sure, you could argue that some languages are less resource-efficient than others, on average; but that has nothing to do with whether any one particular application is sufficiently resource-efficient.

If Apple were only worried that no apps exceeded a certain memory usage, they would make that the restriction, not the language the app was written in.

Also, security doesn’t make sense as an argument either. We’re talking about userspace apps here. What difference does it make from a security standpoint if a portion of the code in my application happens to implement a Python interpreter? From Apple’s point of view, it’s all foreign code, whether I wrote it or Guido did. Python doesn’t have access to any part of the OS that my own Objective-C code doesn’t.

Similarly, I’ve heard (many) people argue that the motivation is to ensure a certain minimum quality for iPhone apps. Again, this doesn’t make sense: although it might be arguably true that the average Flash-developed game (for instance) is of lower quality than the average custom-developed game, it’s unreasonable to assert that all Flash-developed games are of insufficient quality to allow on the iPhone. If individual app quality were the issue, they would simply require a minimum level of quality on a per-app basis (and, in fact, they already do this, as many a frustrated developer can attest).

Also, remember that this license restriction is not a technical restriction: it doesn’t say anything about the nature of the resulting code. All it restricts is the app’s original language, regardless of any post-processing or language translation that might have been applied to produce the final result. As treeform and castironpi argued above, the “original language” isn’t even possible to quantify technically.

I can see no rational technical explanation for this license change. But it is perfectly reasonable from a business point of view, as an attempt to dominate the market.


-1 new license.
-1 proposed explanations.
-.5 good business*

In games of iterated cooperation and dominance, when the length of the game is known, it makes sense to defect on the last move, and therefore the second-to-last. In our intuition, this isn’t transitive to the first move, but the expected best move deteriorates.

When the length is not known, e.g. the game has a fraction chance of ending each turn, the asymptotes do not deteriorate.

-1 Apple’s outlook-- they are thinking too short-term, too mortal.
-1 Doing business companies with bad outlooks.

They want to restrict developers to the iPhone SDK instead of making Flash CS5 a valid alternative programing platform. And Adobe deserves punishment. Their application bundling policy for example. Taking ages for bringing their apps to Cocoa. Apple-Adobe relations have been better, but long gone is the DTP niche Apple felt comfortable in for way too long. Over are the days where whenever Apple introduced new hardware some Adobe exec had to endorse it. Flash has done a lot for Adobe, what did Adobe do for Flash? Flash on OS X is slow, instable and insecure. YouTube 1080p videos are unwatchable right now. 90+% of crashes on OS X are Flash-related. Flash in general and Flash/JavaScript (browser)games are the scourge of the internet. So I perfectly understand Apple if they don’t want Flash on the iPhone or the iPad.

I mean c’mon, did you really think iPhone development was to become a marketing power horse for Panda? And for every little sensor change in the iPhone you update Panda? Which by the way is the same argument that people make regarding Flash.
I always thought that web deployment and a development tool suite are far more important. Sure it’s sad to see some development effort wasted, but its obvious that this new regulation will not last long. Similar nonsense was brought down sooner or later in the past. They just brought up this wording to exclude Adobe and then they will figure out something more precise.

And oh look how Apple is bashed for this. Nobody blames Microsoft, Sony or Nintendo for dictating their development process. What’s the implication here? Sony sucks because you can’t deploy a Panda app on a PSP?

I’m pretty sure you can use Panda in at least the xbox and the psp. I don’t know about the wii. But maybe you know something that I don’t, what do you mean exactly? And are you talking of Python or of Panda?

And while we are at it, are we assuming that this new restriction bans Panda/C++ on the iPhone? Cause I was assuming it doesn’t.

Right, I’m also assuming it doesn’t restrict Panda/C++ development. Though it’s not 100% clear.


Nicely said!

As a bad consumer, I do buy stuff because I need them and not because they are tendance of the day. Hoping that Apple’s restrictions will disappear when a new “goldBoxGenerator” will be discovered, I’m still proud of my Imac for my artistic’s projects as I’m proud of my android for phone stuffs…

On the other hand, this license may be adapted if all Iphone users must jailbreak their toy to access a great tool/soft or game which is a must in tomorrow’s tendance.