Lambda the Ultimate

I wish I could believe that this will hurt their developer mindshare.

Paul Graham has some interesting things to say about Apple's Mistake.

Bracha in Closing the Frontier:

Q: How is a programming language interpreter like pornography?

A: They’re both banned at the iPhone App store.

Easy to enforce in lots of cases, though. Speculation (in the link above) is that Adobe's soon to be released Flash->iPhone compiler is a primary target.

I guess one (interesting) way to think about it is to consider compilation that maintains human readability (whatever that amounts to...)

As written, the clause rules out all use of other languages. But Apple probably means the primary source language, which is much more clear cut.

Modern software development uses little languages all over the place:

- Build languages, such as ant, Maven, or jam

- Expression languages, such as "SUM(A1:A5)" and "find:cell phones -iphone"

- AI decision-making languages, such as "price LT threshold ==> SELL"

- UI-layout languages, such as (pane (label "Okay?") (button "Yes") (button "No"))

This is before getting into tools that aren't strictly source code. Things like bug trackers and configuration management. They all have their own little languages.

I daresay you can't be a productive programmer, by today's standards, without a small army of little languages.

I experience the realization not too long ago, that every program we write implements a language. Some are quite simple some are more 'complete', some are graphic, some are 'mouse click' languages, some might even be audio languages. But every user interface amounts to a set of linguistic rules and expressions.

I think this awareness has informed and perhaps improved my own application programming. It is a useful way to look at user interfaces - what sort of language are we forcing a user to learn? How different is it than other languages the user is familiar with? Ideas such as the 'principal of least surprise' fit into this model.

For an obvious example, the C program that implements GHC; for a less obvious example, the program that implements a music player like Amarok. Both have in common a set of expression rules and syntax that they allow.

You might want to review the work of Clarisse de Souza. Her writings on Semiotic Engineering of human-computer interaction share your insight that user interfaces are a form of language.

The semiotic approach (study of signs and communication) explores the relations between the strict program language and the natural language used by the humans creating and using the application. Mismatches between the operations available in the formal code (which supports a limited set of allowed meanings) and the informal users (which can generate unlimited interpretations of the program) are a major source of user errors.

In particular, the author's intent when creating the tool must be somehow transmitted to the user through the application interface. Users will infer their own meanings, and if the intent is not well expressed, those meanings will be faulty.

If Apple does "find out", and decides you are worth suing, they will compel you to produce your original source code by discovery, and then have you testify under oath that it really is original. It's up to you if you want to commit perjury in such a situation.

Extremely relevant to LtU as "The Programming Languages Weblog." PL diversity is important for us PL researchers you know...

The business angle, and Apple's feud with Adobe, are not relevant for LtU, of course. PL diversity, as Sean said, is not only relevant for LtU, it underlies what LtU is all about!

One cannot meaningfully discuss a company's technical decisions without reference to the business angle. The business angle in isolation, of course, would be just be off-topic chatter.

Not really, since I am not concerned with the rationale for the decision, but with its implications.

Understanding the rationale can help you anticipate the long-term implications. For example, one speculation is that Apple is primarily concerned with abstraction layers which let you create portable apps. If that's correct, then it might be possible to get them to tailor the developer agreement more narrowly, so that any PL you use has to expose all the UI APIs directly, and not offer any of its own.

On the other hand, if Apple's goal is monopoly for its own sake, then they're never going to open up even that much. If you want to discuss the implications, then it'll be useful to know which scenario we're looking at.

Or you might rule that it's too early to talk about it, since none of us know what Apple wants.

I think the rationale is more simple than that. It's just battery life, since you mostly pay for abstraction in terms of clock cycles.

There are more reasonable ways of doing this, which they can already do in their approval process - examine the power usage during a representative use of the app.

Adobe has asked Apple to expose certain APIs that would reduce power consumption. Apple has refused, probably on the basis that these APIs are unstable and will not exist in future releases - but also because Apple views their own APIs as all the user should need to use the platform. Things like QuickTime are differentiators.

There are no reasonable ways of achieving power consumption without a better instruction set to target (e.g., the Apple's hardware acceleration API). Jan Ozer, who consults for Adobe, has written about this in the past. This power consumption problem with Flash applies to MAC OS X laptops, too.

I guess testing goes far, but formally you run into halting problems and stuff.

It's not a bad decision on their part. They keep APIs and libraries light as not to clutter the OS with all kinds of bits, and -I assume- give reasonable performance with low battery consumption. Can't say I am that against it. What it doesn't take into account is that you can abstract all you want in an application, like embedding LUA. But that still makes sense from Apple's point of view. It just means that maintenance on their part remains low, and people can expect reasonable performance without too many software issues from the device they bought.

I find it pretty fair, albeit that it hints that there should be better ways of doing so.

Apples allows JavaScript. This negates any argument about the performance. Also note that things like GWT seems to be banned as well.

There are actually two somethings potentially relevant that have been bugging me about their policy.

First, Apple is attempting a quality control move based on language difficulty: their high-level languages (those in the browser) have horrendous performance, making them suitable pretty much only for static content, so their policy limits interactive applications to their low-level languages. This, in turn, turns away much of the developer community. Those already invested in the platform benefit from this (and I generally perceive an undertone of this when they discuss non-inherent issues like consistency). So: are there software quality benefits from *enforcing* usability barriers? Forcing the use of Objective-C by those unaccustomed to it would make me think not. However, obviously taking a bit of a jab, maybe Haskell code is beautiful because the audience has been screened.

Second, the sociolinguistic implications of this move are fascinating, which I previously brought up.

It's nebulous and overly broad precisely so that it can be selectively enforceable. Legal documents are not programs which Apple's lawyers are obligated to blindly execute. A better reading of something like this is "you're probably doing something wrong, but as long as you stay on our good side and don't flagrantly violate the agreement, we won't say anything".

Which isn't all that unusual. If even a tenth of what's written in contracts, licenses, and laws was actually enforced fully, literally, and universally, society would probably collapse. This often seems bizarre to many programmers, being the precise opposite of a computer's tendency to do only, exactly, and all of what you tell it to.

Strained justification of LtU relevance for this comment: Legalese is a terrible programming language, I wonder if it could be improved?

Legalese is a terrible programming language, I wonder if it could be improved?

Nick Szabo and Mark Miller seem to think so, among others.

The general purpose computer will exist so long as there are general purposes.

Not necessarily. Computers just have to be general enough for almost everybody. If locked-down machines like the iPad become the norm (which has got to be Apple's long-term goal), truly general machines will be pushed into smaller and smaller niches. Eventually, if you want to do PL research, you'll need a machine 10 or 100 times as expensive as what you can get at Best Buy.

I was surprised by this as well, especially since MacRuby development seems to be headed up inside Apple, and sits on the Objective-C runtime.

Regardless, you still can embed Lua (or any other interpreted language) in your C code, and write much of your app in it. But you need to keep the iPhone library interfacing in C, and not write a full bridge that's accessible via a custom language.

Actually, embedded interpreters, compilers, or virtual machines were already banned on the iPhone, even before the latest rev of the dev license. This new version limits freedom even more, by even prohibiting you from using source-to-source translation.

Actually, not quite. The ban was on interpreters running "downloaded code", not interpreters in general. I have it on pretty good authority that interpreters that didn't run downloaded code were acceptable.

Now, note the use of past tense; I'm not sure what this new agreement means for the "embedded interpreter" scenario, but I'm guessing it's not good. My only thought is that a number of App Store games must be using some sort of interpretation of scripts, and I doubt they'd be banned given Apple's attempt at courting the casual games sector.

That used to be true. Here is the clause from the original iPhone SDK agreement:

No interpreted code may be downloaded and used in an Application except for code that is interpreted and run by Apple’s Published APIs and built-in interpreter(s).

but more recently (sometime in 2009, I think?) Apple changed the terms. Here is the same clause in the iPhone OS 3.2 SDK agreement, with the relevant change highlighted:

No interpreted code may be downloaded or used in an Application except for code that is interpreted and run by Apple’s Documented APIs and built-in interpreter(s).

If you are finishing up your Masters in Computer Science, have determined that a Ph.D. in Comp Sci. is not for you, but you also dread going into the real world to become a "software engineer" or project manager, then apply to Law School and see if you can get an internship at the Software Freedom Law Center with Dan and the gang! ;-)

...Novell, Appcelerator, Corona, Adobe, etc. will be needing you! ;-)

The iPhone/iPad OS and toolchain are so ingrained in the platform that it seems foolish to consider anything other than any of the fully supported C variants

Why? MonoTouch provides a .NET platform for running on the iPhone, and Unity started that road by providing a successful .NET game development platform for the iPhone. To my knowledge, these are the most well-supported (maybe only?), memory-safe garbage collected platforms for the iPhone.

Apple's previous terms were much more sensible, as they required only compiled code, not specific languages. This requirement is absurd.

Regardless, you still can embed Lua (or any other interpreted language) in your C code

No you can't. The agreement forbids interpreters.

I think the interesting/unfortunate part of the change is that it will almost necessarily lead to selective enforcement. After all, one of the main things we learn with implementing PLs, compilers, etc, is that, in a concrete sense, all programs are interpreters.

Quite. That was one of the points I was expecting to see mentioned.

I don't see it having a huge impact of anyone other than Adobe and Flash developers who will know have to learn Cocoa instead.

And, of course, anyone who wants to use a programming language other than C, C++, or ObjC. Imagine if you had been forbidden to use graph algorithms in your research, and you have a sense of the absurdity of this decision from my pov.

Now, of course it's true that's not the reason Apple did it, but I'm not actually obliged to adopt their point of view in preference to my own. (Maybe that will be in the next version of their developer license. :)

Dead link pls fix or remove?

Lockdown is common in underpowered devices, but the iPhone represents the (by far) leading smart mobile device and the tipping point for them. When you include Kindles and the iPad, which seem to be the next wave of smart devices, we have the locked down embedded mindset being applied to systems that don't really have the same limitations yet companies are bending over backwards to put them in. When you view it as computing classes (in the sense of Bell's Law) -- mainframe, pc, laptop/netbook, cloud, and mobile, this is quite a shift. I don't think it's maintainable due to competitive pressure, but we'll see.

Actually, on SmartCards it is the JVM, demanded e.g. by Telecom providers who wanted to load their own applets, which opened the system a bit.

I wonder if we would lead the same discussion if Apple prescribed using their API but utilized LLVM more thoroughly for their own purposes instead of sticking to GCC. I remember Thomas Lord wrote something illuminating a while ago about Richard Stallmans own very different locking in intentions regarding the GCC. The bewildering and backward oriented language decision made by Apple might be a remote echo of this and isn't entirely without irony.

Dear Oliver,

I am working with Peter Van Roy's researchers on porting Mozart to Android.
We already manage to run mozart applications on Android but there are performance issues because of the Java GUI.
Mozart is running fine and some improvements should help the GUI to be more responsive.
We would like to port Mozart on iPhone/iPod/iPad but there are some problems that we need to think about before.
Mozart should be released in version 1.4.1 soon and this release will be the starting point for the mobile support.

If you want to collaborate on this work, you can send me an e-mail to Jeremie.Melchior@uclouvain.be

Trying to argue Apple's position on technical grounds seems absurd given that they use Objective-C but..

Even if that's the case, I would trust a language to generate cooperative code better than a random entrepreneur trying to write Objective-C.

In the first place it is hard to check a development tool against the ability to create badly behaved programs. Apple is declaring, up front, that it will not attempt to do so.

Red herring -- Apple can do what they've already been doing, checking programs (which I doubt is a good check to beginwith).

primary security tool for this device

That sounds like a really, really bad idea [[though might be ok in a setting like AppEngine where a high-level and instrumentable language is used]]. However, I also don't think it's true. Security comes in layers, and even how the hw is structured in phones starts to provide some.

Finally, the undocumented API stuff is more of a software engineering mistake. There are many ways to have hidden these APIs from non-Apple applications if they so desired.

I'm not sure what your point is. Linux can already be installed on 'jailbroken' iPhones and probably iPads, and of course an iPhone running Linux is not going to access the App Store. There's very little interest in it because the iPhone/iPad hardware is not cross-subsidized by App Store revenue, although I suppose that strategy could be made to work in the future. Accordingly, Apple ought to care little if you wipe out iPhoneOS from your device and replace it with Linux, whereas they would be quite justified in worrying about jailbroken iPhoneOS devices running bootleg apps.

Thomas, you summed this up beautifully. I had wanted to write something similar, but was struggling immensely with the big picture - you nailed it.

Some comments:

This raises the questions: should programming language designers more explicitly aim to compete not only with other programming languages, but with traditional operating systems? Should programming language theorists begin to regard OS theory as an important sub-specialty of the field?

Competing with operating systems requires better support for resources. Languages should start with a TCP/IP networking stack that is more modular than Linux, but equal to its performance that comes from its monolithic structure. Ian Piumarta has started in this direction, Walid Taha has done some interesting stuff with resource-aware programming, and the Austin Compiler Project has done interesting research in transforming a clear protocol specification into efficient executable code.

~ We are entering an age of commodity computing, in which typical users have less and less say over what software can run on their systems. The theoretical significance of "legally banning new abstractions" is of growing, real significance because the day to day computing that people and businesses do is migrating towards (a) centralized computing utilities owned by third parties, leased under contract, and accessed under contract; (b) end-nodes (handheld devices up through "workstations" and "servers") which come with built-in DRM and strong contract terms that limit not only what music files you can play or what movies you can watch, but what software you can run.

This is one of the things the EFF and FSF have been fighting, and losing against. Linus Torvalds and Richard M. Stallman simply delayed the inevitable. More broadly, net neutrality is already a myth - what you access through the iPhone is a reflection of what you access through the App Store. The recent appellate court ruling against the FCC is irrelevant. It's also irrelevant whether Congress decides to pass net neutrality legislation or not. You cannot defeat the market, and the market is controlled by mega-corporations.

The upshot of this is that I think services with contracts based on capabilities will become more widely endorsed, out of necessity.

As an example of one implication, suppose that other platform vendors and commodity computing providers continue to follow Apple's lead. Academic programming language research and development can and will certainly continue but on what terms, and with what relevance?

Researchers will go to China, and Sean McDirmid will teach them mandarin, cantonese, and altanese. Half serious. American cryptography researchers did go to Europe in reaction to DMCA. So did *BSD developers. Researchers go where the laws won't apply to them. Do not underestimate labors of love.

The "unwashed masses" (sorry) of computer users have more or less used their magical machines first to type, then create small spread sheets, charts, contact databases, and now to communicate with other people and read lots of Web published stuff.

So what? Today's users gobbling up pre-installed software is no different to me than Word Perfect users circa 1990 who had no concept of DOS directory structures and kept hundreds of docs in one directory that they *only* accessed from within Word Perfect, completely ignorant of the operating system at all.

A potential saving grace (has been in the past) is all the small to medium industry applications. Awkward and ugly stuff, like software to manage a textile printing shop - everything from contact management to Pantone colors to book keeping. Not exciting stuff, but stuff like that is ubiquitous in small business (that's most business) and it still drives lots of hardware, system, software and training sales. Outside the relatively mainstream hype, this (useful) crap kind of makes a big (boring) part of the small computing world go round and round.

Many/most of these folks won't every learn anything like C++ or Objective C or try to stuff their (Pascal and Basic, mostly) apps into a browser using Java Script. Just won't happen. Apple will come around or limit their market strictly to "consumers" - which will cost them serious change.

My current neurologist has the most automated office I've ever seen. Every Dr. and nurse has a pad-type device and all past records are at their finger tips, future appointments are scheduled on the spot, and prescriptions just spit out of a big fancy Xerox printer thingy. I image a whole bunch of companies are making a VERY PRETTY PENNY configuring systems like that for the health care industry.

Etc. blah blah blah. I wouldn't worry. A more open platform simply *WILL* exist sooner rather than later - because there's filthy lucre to be made :-)

As for Apple? I've never really assigned them any special status in my picture of the computer platform world. WHO CARES?

I've seen what Jecel Assumpcao, Jr. did with Merlin programming language/operating system and building his own laptops using FPGAs and bitblt for graphics, all by himself. I know creating a counter-culture will not be a serious issue (following up on naasking's point about a new Apple counter-culture revolting). However, pragmatically speaking, counter-culture movements have always resulted in consumers being denied access to fun leisurely enjoyments like modern 3d games.

If the market is indeed dominated by large corporations, then it is not a free market but a corrupt one, and it can and, historically, will be beaten. Corruption cannot be destroyed, but particular corruptive tools can be broken, as Thomas Covenant says.

"Dominance" and "empire", those militarist categories, hardly ever apply to markets, although they are very seductive metaphors. Market share must be conquered like territory. On the backside of success, being a "monopolist" has a negative appeal and is almost immoral and calls for resistance. The modern day liberal, worker-consumer still loves warfare, in particular when no one gets hurt.

if many economically significant platforms are subjected to measures similar to what Apple is doing, the programming language theorists and many other sorts of software theorists and engineers ought to just pack up and go home: the society will be legally barred from developing more sophisticated approaches to programming.

I'm not particularly concerned. Like Microsoft, only a counter-culture will compel more openness from Apple, or relegate them to a niche where they might be happy. Anti-trust convictions did very little to curb MS, but the open source counter-culture to MS's lock-in is very effectively dismantling its stranglehold.

Fortunately, while Apple got a significant first-mover advantage here, Google preempted Apple's draconian measures and already started the counter-culture with Android and the Dalvik VM. It seems to be going pretty strong so far.

As a first-gen iPhone user, I'm fairly certain I'll be getting an Android phone next, because iPhone development has just lost all the exciting PLT potential in my eyes.

It is becoming an unquestioned habit of upcoming generations of individuals and businesses to, as much as possible, give up control of their own computing needs and perform computing and communications subjecting themselves to relatively unconstrained contractual restrictions.

I'll just note that most "owners" are generally not themselves technically savvy, and thus they had already surrendered control of their computing infrastructure to IT staff. I'm not sure handling staffing is any less of a headache than dealing with a third-party service. I suspect it just shuffles the headaches around a little.

This raises the questions: should programming language designers more explicitly aim to compete not only with other programming languages, but with traditional operating systems? Should programming language theorists begin to regard OS theory as an important sub-specialty of the field?

The idea that Operating Systems are Languages is probably pretty uncontroversial and unsurprising. But the converse is also true: Languages are Operating Systems, it's just that most are pretty bad ones.

Of course, none of this is in any way novel. I was still crapping my diapers when Dan Ingalls wrote this in the Design Principles Behind Smalltalk paper:

Operating System

An operating system is a collection of things that don't fit into a language. There shouldn't be one.

That quote reminds me of Forth, where the language kernel is traditionally used as its own OS. Chuck Moore has the "guts" of his IDE driver posted here.

Not all meta-platforms are Tcl/Tk. Tcl/Tk, I will agree, tends to make applications that are quirky and unpolished, and that do not mesh well with the OS. However, what about Java, .NET, and web software?

As a sniff test, anyone who has used an Apple desktop or laptop is invited to consider how much of the software they use was developed specifically for Macs. Personally, I tried the experiment, and it went heavily in favor of the meta-platforms. I started out trying to live the Apple dream and using all of the software that is optimized for Apple. Over time, I grudgingly dropped mail, contacts, and calendar for Google equivalents. I never even tried XCode; as a primarily Java developer I use Eclipse, which is based on Java. I have used a variety of web browsers, but all of the big ones are multi-platform, including Safari. At this point, practically everything I use, except the core OS, is cross-platform.

The case against meta-platforms in general is interesting but does not look especially strong in practice. There is certainly a lot of crummy cross-platform software written. At the same time, the very best software is usually cross-platform!

I don't know why this is, but to speculate: cross-platform software has a larger user base, which through a mysterious step two leads to more resources to further develop the app. There are a variety of ways to fill in step two. Pay-per-copy software has more profit if it's cross-platform, which will partially be redirected back into further development. Open-source software will attract more developers, because it can scratch more people's itches. Popular software has more critics and commentators, which lead to a better pool of ideas existing for the developers to draw from. Popular software causes other software to interface with it, making the original software more valuable with no work from the developers. It's good to be popular, and cross-platform software has more room to be popular.

Software Factories and Software Product Lines are fundamentally meta-platforms.

So are 4GL code generators. The essence of these code generators is to generate 3GL code that optimizes for nonfunctional requirements given your functional requirements. This equates to 100% reuse of nonfunctional requirements code across all applications. -- Some software factories and software product lines are basically code generators/compilers in this respect.

If you actually look at the quality of code by many modeling tools these days like Eclipse's modeling framework, especially for managed languages, they are often superior to the quality of code output by developers. Modeling tools can also mask away performance optimization differences across versions of a managed runtime environment. e.g. javac transforming pure string concatentation into StringBuilder calls.

The same logic applies to GWT, and also for that matter mapping OCaml code to C or JavaScript, or even the published uses of Haskell for real-time systems in IEEE journals, through the use of FRP.

I've also seen a lot of "all languages are Turing-complete anyway, so what does it matter?" comments ...

If you bar the mythical sufficiently smart optimzer, and constrain the extent of white box composition, and impose a particular process and IO model from the outside, at least (a) and (b) have a reasonable basis. Both languages definitions and the environment inherently constrain language implementation.

For point (d), consider an intermediate possibility: executables are distributed, but only after static analysis, certification, and compilation by a trusted third party. Would it be reasonable to limit the language in this case? i.e. to Joe-E? Or perhaps a language that supports analysis of memory and CPU and power requirements? or process accounting? I think so.

That said, this isn't an argument capable of justifying the "originally written in" constraint. A high-level language can be an intermediate compilation target.

I am a bit curious as to whether Apple's judgement will lead us to develop "code translation" tools that attempt to preserve style and comments and such to beat the system. The floundering 'language oriented programming' movement might see a little more interest.

Ehud --

As long as we are addressing this, figure I might as well open up another thread by hitting these myths from how I believe Apple would view them. I think you might be pleasantly surprised.

(a) some languages (as opposed to implementations) are slower and more resource heavy than others,

I would say Apple would agree with that myth. But more importantly they don't care about the distinction between languages and implementations. They aren't deciding between languages in some platonic sense but rather specific implementation that exist and are widely used for their platform today. To them, an implementation for them is a language. And they go, in their development documentation even further and talk about conventions as essentially being a language.

I.E. What they are concerned about is Apple's objective-C as compiled by LLVM / XCode using the conventions in their development documentation as contrasted with competitor's language / compiler / convention trio.

Arguably given their focus on convention in their documentation they might be advancing this aim. It is hard to know how much the average developer is absorbing of these more abstract notions.

(b) libraries are inherently inefficient,

I don't follow how that would come about. Apple preaches the virtues of using their libraries all the time. It is because they want people to use their libraries that they encourage Objective-C.

(c) code in C like languages is more amenable to analysis in order to prove good behavior than other languages,

I don't think they are saying this. Take for example the latest set of developer documentation which focuses on the issue of garbage collection vs. reference counting. They are pretty up front that because C like languages allow for casting to and from void pointers that they have essentially failed at getting garbage collection to work in practice for Obj-C apps. It is only because C languages are less amenable to analysis that they have to use a fairly complex conventional reference counting system to provide some of the advantages of automated garbage collection. And BTW they agree this applies to their OS code, so they aren't saying this is only something that happens to bad programmers.

Again I'm not sure if the average developer is reading the "why" parts of the ARC (memory management) documentation and not just the "how" parts. But the why parts could have been written by any LtU regular.

(d) even when executables are what is being distributed, clients should impose restrictions on the programming language used

They are being pragmatic. They want people to follow their guidelines for application construction for example Human Interface Guidelines. In general people writing in languages not supported by XCode are people who don't care what Apple thinks about how applications should be constructed and thus violates guidelines arbitrarily, and that diminishes the user experience for the platform as a whole.

So why shouldn't Apple demand adherence to their specifications?

So there's at least one area of research that will benefit from all this...

Ironically, after the Android Native Development Kit, Windows is now the only safe phone OS.

They support JavaScript, so perhaps you mean "fine-grained security" or "security with reasonable performance." Oddly, at least for multiprincipal systems, I view JS as safer than most mainstream languages.

I seriously refuse to take seriously someone that call C, C++ and Object-C "not safe".

It's the same line of someone saying that the world should ban airplanes 'cause they can be used for war.

Here on LtU, we take a lot of PL terminology for granted, such as the concept of a "safe language", which has a particular technical meaning that excludes C, C++, and Objective-C.

If you're new to LtU, I recommend the links under "Getting Started" on the left-hand side to get acquainted with how things are discussed here.

from cap-talk.

They have a been funding a Ruby implementation called MacRuby. It is still only at version 0.5, and it's not currently intended to work with the iPhone platform, but my guess is it'll wind up there soon after 1.0.

That pretty much defines a 'systems programming language'. Or any language suitable for developing frameworks.

The idea is to automatically resolve non-functional requirements, such as platform mapping. The idea originated (as far as I'm aware) in code generation tools such as the ones James Martin wrote about in the early '80s (but these were not very sophisticated) [edit: Although I suppose the use of microcode by Xerox to build portable platforms like the Alto is an earlier example]. In Model-Driven Architecture circles, where you have a Platform Independent Model and a Platform Specific Model, there is intended to be a clean separation of these models. The goal is to bury non-functional requirements from the purview of developers and the domain expert.

A meta-platform is not a system's programming language. It is a translation tool. The goal is actually to ignore the system as much as possible. Once you understand the system and its performance model, there is little need to keep writing directly to the system. This facilitates reuse.

edit: recently multimedia outlets like TechCrunch have latched onto meta-platform as a buzzword. Surprisingly, they are using it correctly. For example, Google's meta-platform for social networking subsumes Facebook. It commoditizes Facebook.

Somebody on Hacker News commented that this reads like satire. I can see how one can come to this conclusion :-)

Difference between the old and the new.

From the App Store Guideline:

We have over 250,000 apps in the App Store. We don’t need any more Fart apps.

Who knew? :)

Doesn't say they don't WANT any more!! :)

I believe they put the fart-app guy in charge of some part of the app store; take that as you will.

Apple’s App Store Director Sells His Own Fart Apps [sorry, couldn't resist]

as long as the resulting apps do not download any code

I wonder if this means we'll be seeing court-defined distinctions between code and data.

[Or maybe it'll be like pornography: I can't tell you the difference, but I know it when I see it.]

as long as the resulting apps do not download any code

The download is not restricted in the case of JavaScript if it's run through WebKit's JS engine.

3.3.2 An Application may not download or install executable code. Interpreted code may only be used in an Application if all scripts, code and interpreters are packaged in the Application and not downloaded. The only exception to the foregoing is scripts and code downloaded and run by Apple’s built-in WebKit framework.

[Or maybe it'll be like pornography: I can't tell you the difference, but I know it when I see it.]

Funnily they use that line when talking about acceptable apps. From the App Store Guideline:

We will reject Apps for any content or behavior that we believe is over the line. What line, you ask? Well, as a Supreme Court Justice once said, “I’ll know it when I see it”. And we think that you will also know it when you cross it.

I was wondering the same thing as soon as that restriction came out. You can download images. At what point is a decompression algorithm complicated enough to consider the source data "code" that is executed by the decompressor? Is a declarative language like a data file format a programming language? What about shaders?

you can't bring code in through the app/network

Does this mean I can't even copy and paste a sample program from the web?

I think that would be ok, but not very convenient! Perhaps in the future we will develop languages and programming systems that are copy-paste friendly, copy-paste module systems anyone? Yucky.

I guess it will be possible (and allowed) to download a code package file via the browser and have an app like Codify handle opening of the package? Any comments/observations on whether that is license compatible and whether Apple will reject such apps?

Codify has an unapproved add-on that allows for code sharing. That's going through its own approval process. If it were a small number of code packages the most obvious would be for Codify to have code repositories which are applications add-ons and those can be in the App Store and distributed as an application add-on. If Codify ran its own "website" and vetted the applications on their side, they could most like have thousands of apps and I would suspect it would get approved....

But the download via. a browser and install... Applications aren't allowed to pass arbitrary data globs to one another. Any kind of state sharing (and they do use this term BTW) between applications is held to a much higher level of scrutiny than just application approval. There are some that are approved state shares but the approval is of the form: Application X is authorized to pass data type Y to application Z. Basically Apple does not want you creating your own OS components, that is applications providing services to other applications. They don't even really like this on OSX and have grumbled about it many times.

To be more general, having a web browser download code from an arbitrary website and install code, direct on the iPhone not through the iTunes website for random users would get the app rejected n a heartbeat. The same way the FDA isn't going to agonize over allowing a non-doctor to mix up boxes of unapproved drugs and sell them to people out of the trunk of his car, regardless of who opens the box.

Apple provides a mechanism for applications to add additional content called in-app purchases. Lots of applications download additional content inside the app and through the network. However, they need to be uploaded by registered developers who are associated with the application and Apple might ask for additional information.

And of course Apple is fine with applications downloading "data" from websites. For something fun like codify they are unlikely to be terribly strict about any sorts of restrictions providing the developer of codify has made sure that codify isn't creating backdoors into the system.

You cannot download code from websites and execute them (outside of javascript). That is pretty clear.

I never realized we finally found a distinction between code and data. That's a major result. Is it published somewhere?

The distinction is very murkey. Is markup code? Is a word document that consist of markup code? What does interpretation mean? When is rendering interpretation? Rendering a static document? Rendering an animation? When is simulation interpretation? And so on...

In the strictest reading of their rules, all applications are disallowed, of course, since their are no clear cut distinctions. All that Apple can do is be subjective.

You realize I was being sarcastic, I hope.

Ya, but its still an interesting topic.

That's the point, in this case people are downloading code from the App store, not from a website, as an add-on. But the mechanism of download is not is really important, what is important is that each of those add-ons programs has a registered developer associated with them and that developer has an official tie to the person who registered the interpreter. This creates a chain of accountability for the end user and for Apple.

Websites are another thing entirely, and obviously since that chain of accountability for the scripts don't exist the application is subjected to more scrutiny. But as I mentioned in the other thread there are tons of apps where people do download and install code from websites. Apple will allow it providing all sorts of other criteria are met. Gambit Scheme, which we discussed has a large web repositories and loads data from them to their iphone version via. the iTunes interface.

And of course the big thing that everyone keep skipping is...
Developers do not need to use the App Store to load software. If you just use the developer interface you can load whatever software you want and that software can do whatever you want. Apple's protections exists solely for people who either are not developers or do not have access to direct IT support. What keeps being quoted are the App Store guidelines, the criteria you need to meet for Apple to be a distributor for your software. The term for the sorts of people who need to freely load code from external sources is "developers".

Once a registered developer, or a registered support group takes direct responsibility for software X running on device Y Apple doesn't need to act as a gatekeeper, preventing Y from running into trouble.

The more fun tools there are to help people (and especially kids) dabble in programming, the better. This looks like a nice compromise for adding a bit of tangibility to a mostly-textual language.

That said, this kind of project kind of screams for the social aspect of something like Scratch, so it is unfortunate that the App Store rules make that impossible.

Codify is taking a big risk in hoping Apple will change, because they might not. And why should they? Programming is still not on their radar, and Codify will have to be really successful even with its limitations for this to occur.

Sharing is too hard to be practical right now. You are right, it is possible, but in practice there are too many barriers, which are all artificial.

Let's hope Apple under Cook is a bit more open than under Jobs.

Apple needs to maintain control, and will be conservative about what they accept to maintain control. I don't think Apple is being overtly evil, they are doing what they think is necessary and it affects us negatively. Apple cannot let users share code freely since this could become a new uncontrolled channel for app distribution. As soon as you allow someone to share scripts, they can give you scripts that subvert the app approval process.

Actually, any app that supports unwashed content can subvert the app store. Do you allow users to share sprites? Porn! This is the problem with manual vetting: it can only really work if apps are closed boxes. In order to ensure that vetting works, they try to make apps as closed as possible, they really don't have much other choice if they want to maintain control. Google, Microsoft, Amazon, to varying extents, suffer from the same problem here: it is not Apple being evil, it is the rise of the closed platform that we are afraid of.

I don't think Apple CAN open up further, so I'm assuming they won't since they are generally very smart people and not very ideological. If some engineers at Apple like Codify, this is irrelevant, they know what they are doing!

On an aside, Codify provides for a crappy coding experience, its basically a text editor with some keyword code completion and no member completion. Nice first try for them, but I hope it doesn't negatively affect our movement.

Apple hasn't so much loosened as they have given up control when it is impossible to maintain. Of course you can view porn on your phone, there are just usability barriers because Apple doesn't make it easy. Same thing with financial transactions that don't go through the app store. You can't embed the URL link to buy something in your app anymore, rather it has to be text and the user has to copy and paste.

Making something hard often means making it so undesirable that your market is severely neutered; i.e., the iPhone is not porn friendly.

Having scripts go through vetting to be shared is a no-go since this is not financially viable for the developer or for Apple. Rather, you have to create entire app experiences to share, which is fine if you want to build an app but often this isn't what you want to share.

LittleBigPlanet has an interesting take on sharing via community moderation to identify IP violations and inappropriate content, although this is a bit heavy handed (you can't really appeal if someone misflags your content). Sony can't vet everyone level that users want to share, and making sharing hard would defeat the purpose of the game. Suffice to say, something like LittleBigPlanet is not currently possible on the iPhone/iPad (you have to wait for a Vita), while no developer in their right would develop this for iOS without forward assurances from Apple that they would change their rules.

I'm not sure if by "our movement" you mean the LtU push towards LISPish style languages or the GNU project.

I meant our movement of touch-based programming, not LtU related but there are a few us who are doing this. Its much harder than throwing an editor on an iPad, which is what codify did, and no, we aren't in ivory towers (rather glass towers often working for major corps).

Having scripts go through vetting to be shared is a no-go since this is not financially viable for the developer or for Apple.

I'm not so sure. I can imagine this being doable. Say for example a collection of simulations connected to a textbook for iLuaBox (Lua seems to be very popular with the iPhone crowd, that's the reason I'm picking it), answers to sets like the Euler problems.... random scripts, no.

LtU -- I hate to sound stereotypical but LtU need to get out of the ivory tower. They absolutely should register with Apple as developers if they want to develop software for iOS. Apple is not going to facilitate people refusing to work within their system.

This is a strawman. Few people on LtU object to the idea of paying a developer license to distribute software through Apple's store. I certainly agree that that requirement is very reasonable.

The objection I and others raise, is about paying Apple more just to use and program my own device, the way I want. Apple is forcing people like me to pay an extortion fee to unlock my device's inherent capabilities. Obviously that's a little hyperbolic, but not by much.

It isn't meaningfully your hardware unless you are a developer. You are buying a condo with a tough owner's association, not a house.

To do what you want on iOS you need to by a house / be a developer. You should consider the cost of the SDK just part of the purchase price.

It isn't meaningfully your hardware unless you are a developer. You are buying a condo with a tough owner's association, not a house.

And now we come to the crux of the matter: Apple has the magical power to wave away your property rights. There is no equivalent to the Condominium Act delineating the rights of unit owners vs. the association for your phone; at the moment, whatever the "condo association" says, goes.

I'm honestly surprised that you are seriously advocating the position that purchasing something doesn't grant you ownership.

You should consider the cost of the SDK just part of the purchase price.

I consider the purchase price to be the purchase price. Of course, Apple would never say that the purchase price doesn't actually grant you ownership over your device, because that would be fraud, and offering to give you ownership for $99 would be extortion.

Richard Stallman is correct to be very wary of the iPhone platform; by using it, you abdicate all rights to Apple's whims, and you have no recourse, no appeals process, no transparency. I'm troubled that you seriously don't find this troubling. That's all I have to say on the matter.

I'm honestly surprised that you are seriously advocating the position that purchasing something doesn't grant you ownership.

Because I don't find it all that unusual. I've owned lots of cars. The state of New Jersey / California / New York / Minnesota had no problems regulating my usage and limiting my property rights. I own a home, the township regulates my usage. I can buy non-prescription drugs which when filtered and combined would make methamphetamine, if I were to in fact to do that, I'd go to jail. I own a scalpel, gauze, medical sponges and a suture kit; if I were to use my property to perform surgery I'd go to jail. Property rights are restricted all the time.

And in particular, my cell phone is highly regulated by my carrier. For example when I first started using cell phones, I could share a number between multiple phones that privilege resulted in widespread fraud so for the common good carriers eliminated it, and trying to circumvent those protections would be a crime today.

Property is often regulated. Frankly I'm thrilled that a technical company is stepping up to the plate and acting as a regulator in the public interest. Microsoft quite often completely failed to do that. For example, when spam started to be a serious problem, there were dozens of easy technical solutions involving changing or replacing SMTP, all that would be required would have been an organization to get most everyone to shift at once which Microsoft was in a position to do; 17 years later we still have a serious spam problem because Microsoft didn't take ownership of problems with their platform. Conversely when Microsoft did step up and address communal problems, like solving "DLL-Hell", life in general got much better for end users.

I'm thrilled to see a company stepping forward and playing the role of the government and setting up a regulatory framework for end user computing. I'm tired of living in the anarchy of Somolia, even though I own body armor, and an assault rifle and am a good shot; I welcome a sheriff. I get:

1. The absolute freedom from virus. Total immunity, even with hundreds of thousands of applications written by small developers.
2. Safe and simple installation and uninstallation. An application cannot damage my system.
3. Safe runtime performance for all applications. An application cannot change my system to increase its performance at the cost of other application's performance.
4. A safe application purchase and upgrade system including publicly available ratings and contact information.

Frankly the only freedom your side has been able to cite that I've lost is the right not to register with Apple as a developer if I can't handle things the way a civilian would and instead want to use my rifle and armor. I have far more freedom on my iPhone than I had on LG-Touch to modify the system.

I've been a supporter of Richard Stallman for over 20 years now. And Richard himself argued quite forcefully in the mid 1990s that Debian, as a platform should not allow applications/code that compromise the copyright status of the entire OS. That was why he fought so hard against KDE/QT under the QPL. Debian most certainly does regulate developers putting a trusted Debian developer in-between each and every single application and the end user. There is no freedom to arbitrarily distribute code to end users via. apt. Getting into the Debian distribution means going through an approval process and applications are rejected.

The information on the FSF website regarding Apple's policies is simply factually untrue. Apple's role is little different from what Debian does with its distribution. The main difference has been that Debian has from its earliest days existed in an environment where there are multiple Linux distributions so Debian policy is not effectively Linux policy and get confused.

Property rights are restricted all the time.

Driving is a privilege, not a right. All the other regulations you cite are because the changes to your property are not isolated to your property, which is not the case here.

And you still seem to blatantly ignore the fact that you have no rights at all in Apple's ecosystem, except what they say you do (subject to change at any time), and no appeals process when you get screwed.

And your platform safety properties are all myths, and I'm amazed you actually think you're free from viruses and trojans on iOS, and finally, that a sheriff is not even needed and cannot even provide this property.

All the other regulations you cite are because the changes to your property are not isolated to your property, which is not the case here

And platform standards that other users establish are not isolated to them. The fact that other users downgrade, complain and won't buy applications that violate Apple's HIG is the reason I have a consistent experience with Mac applications. The fact that Unix/Linux customers are willing to tolerate software without good defaults is the reason I lost weeks every year for the last 20 figuring out how to configure applications to do the basics.

Absolutely, users create a collective platform standard and then they are all effected by those standards.

And you still seem to blatantly ignore the fact that you have no rights at all in Apple's ecosystem, except what they say you do (subject to change at any time), and no appeals process when you get screwed.

Because as we have discussed multiple times that is simply not true. I have the right at any time to change to another group of master servers and be completely unaffected by Apple's rules, and I have right to a developer key which gives me the right to bypass any rule on a one off basis. The only reason people are influenced by Apple's rules is that they like Apple's rules.

And finally of course there is an appeals process. Apple funds the "App Review Board"
The App Review Board to provide you the opportunity to appeal the rejection of an application if you believe that the functionality or technical implementation was misunderstood. You will be able to submit details that the App Review Board will use to determine if the rejection of your app should be reconsidered.

I'm amazed you actually think you're free from viruses trojans on iOS

OK when you get over your amazement let me know where I'm wrong. How exactly is a virus going to spread from system to system?

Ideally, I'd imagine that sharing code in a modern hobbyist system should be "live" by default. ...Something like a halfway point between GitHub and a language-specific package manager like Cabal, but simplified and integrated into the language/IDE/runtime (since they are one and the same).

iPhone really isn't a hobbyist system. Honestly none of the cell phones are that open, the carriers would hit the roof. That being said someone who wants to use Git, Cabal, an integrated IDE... is a developer and should register with Apple as one and then... there are far fewer restrictions.

You are right that one can usually circumvent the borders of the various "walled garden" products out there. It is a bit much, however, to expect the target user of something like Scratch or Codify to do so.

I'm not expecting the target end user of Scratch or Codify to do so. I think that's why Apple has no problem with Codify telling end users how to scale the walls. Basically it is Apple protecting you from accidentally shooting yourself in the foot, not intentionally shooting yourself in the foot. I'd assume that Apple probably figures that if you are ready to scale the walls, to get Codify stuff you are either a PIA or close to stepping up to a developer's license. Either way they don't need to worry about it. The "adult version" of Codify is Corona and Apple has been supportive of Corona to the tune of selling tens of millions of dollars of Corona apps per year.

Corona does the same thing: Corona is a dialect of Lua with many more goodies that Codify running against an Objective-C engine so that the Lua has access to wrapped versions of the Cocoa API.

iPhone really isn't a hobbyist system

I was referring to things like Codify and Scratch, which are hobbyist systems.

I'd assume that Apple probably figures that if you are ready to scale the walls, to get Codify stuff you are either a PIA or close to stepping up to a developer's license.

(I'm unclear what "PIA" refers to here. A quick online search didn't turn up anything relevant)

I think I must be missing part of your position here. You keep saying that people who want to share code more freely should sign up for Apple's developer program and use the "adult version" of these tools, or else play with side-loading sorts of workarounds. But what about when the user is a teenager or younger? They may not have the money to become a registered developer, and may not have the technical ability, equipment, or parental permission to "scale the walls" and side-load or jailbreak.

Sure, "grown up" developers should use grown-up developer tools. Grown up developers also probably have a dedicated development machine, in addition to one or more mobile devices, so the lockdown has even less of an effect on them.

What about the child who has an iPad, but no PC?

I'll go further: what about the grown up with an iPad in their backpack but no laptop. I know a serious developer would wait until they got home to use their PC, but there are less serious developers who just want to create when they feel like it.

I was referring to things like Codify and Scratch, which are hobbyist systems.... [old -- I'd imagine that sharing code in a modern hobbyist system should be "live" by default.]

Oh I see what you meant. What I'd say is that this opens up potentially some very serious cross contamination. For example do you want to allow a script that can erase or change all the other scripts? While I don't consider "Word viruses" to actually be viruses, end users do.

iOS only has security at the Codify:Documents level below that it would have to depend on Codify's sharing system's security to "do the right thing". Codify is right now in negotiations with Apple to get approval for a sharing application likely trying to work out what "the right thing" is for young hobbyists. For older hobbyists Apple has had a lassez-faire attitude. With kids they are going to need additional protections, probably something like user scripts are protected and groups of scripts are protected from influencing one another. Also I think they are going to want some level of checking the Codify engine itself, maybe something like a security audit. In a year these issues will be worked out.

For Scratch the problem is that MIT Media Labs wasn't the author of the application, it was 3rd party. So the application author couldn't negotiate.

You keep saying that people who want to share code more freely should sign up for Apple's developer program and use the "adult version" of these tools, or else play with side-loading sorts of workarounds. But what about when the user is a teenager or younger?

Part of the problem is that person being discussed keeps changing. I think kids fall into a few different categories

1) Supported by a school or university. In which case their device should be registered under the Enterprise SDK registered to the school or university and exceptions to policies can be made by the system administrators supporting them. So for example a college that wanted to use iPad's wouldn't be effected by Apple's policies unless they wanted to be.

2) A knowledgeable adult is supervising them. My daughter for example, in which case the knowledge adult's developer's license allows them to do these things. And of course the knowledgeable adult knows how to scale the wall a 1/2 dozen different ways. The limitations facilitate the knowledgeable adult because the environment defaults to safe and the knowledgeable adult has to directly introduce dangers.

3) The kid is self supporting. The how to do these things is well documented, but not obvious. In which case the kid will search the web and learn how to do this stuff. Very similar to how kids 10-15 years ago used to install Linux, back then a good rule of thumb was that if you knew enough to get Linux to run then you knew enough to run Linux.

4) The kid is not self supporting, not supervised by a knowledgeable adult nor by an institution. In that case Apple is having to act in loco parentis, and I think caution is justified. Apple needs to take care of that kid's best interest. And they are doing that. Remember the parents made a deliberate decision to get an iPad (for example) instead of an Android tablet, a BBOS tables, a QNX tablet even though most of those tablets are available for considerably less money. They did that because they wanted Apple's managent, and the advantages that brings.

What about the child who has an iPad, but no PC?

Well up until very recently that wasn't even a possible configuration. It still isn't a recommended configuration. Apple is unequivocal that iOS devices are limited purpose adjuncts to main computers not replacements for them. My main response to kid type 4 and their parents is "doing stuff Apple doesn't recommend is likely to be bad". In which case the hypothetical kid either needs to:

a) Live within a very constrained universe, on a crippled piece of equipment designed to do far less than a general purpose computer. Programming would just be one among a hundred areas where the experience would be deficient.

b) Make the iPad into a semi-general purpose device. Get access to a computer for a short period of time and install an alternate OS like iPhoneLinux that isn't designed for a secondary device. That can be either the exclusive or the secondary OS.

c) Trade the expensive iPad for a less expensive laptop and have a general purpose computer.

Why would a parent buy an iPad for a kid that doesn't have a laptop and is old enough to operate a keyboard? IMHO the question is kinda like "what should a kid do to bike to school if his parents won't replace flat tires on his bike"

I agree that the category of user here matters a lot, and I appreciate that this has sometimes lead to people in this thread talking at cross purposes.

I think the line you draw between your cases (3) and (4) is a bit harsh, though. I can think of a lot of children who are "self-supporting" enough they can do great things in something like Scratch (or Logo, Alice, Squeak, etc.) without a lot of parental hand-holding, but who don't have the requisite knowledge (or tolerance for arcana) to do something like install Linux on their phone (or their one-and-only computer).

I may have a bit of a bias on this subject, though. I still remember the copy of HyperCard that came installed on my family's first Mac, and the impact in had on me.

Remember these sorts of apps already do exist for iOS. There is a good Logo. There are a ton of BASICs.... That exists and more are being created. The issue you had discussed was sharing. And Hypercard was a very serious vector for viruses on Macs, lots of people credit it as the first "macro virus" platform, beating Word by a few months. It enabled inexperienced programmers of all types to construct custom software, and many a young virus writer got their start.

And I agree with you about 4's. 8 years ago, my wife who doesn't know what a for-loop is and certainly doesn't know what a device driver is nor what they do, wrote essentially a custom device driver for herself in Applescript. I think she's a perfect example of the kind of (4) and how these easy tools allow people to do the cool stuff you are talking about. I don't think that ever would have happened on iOS with its policies against changing functionality, we aren't disagreeing on the negative consequences. I can tell you from personal experience, she benefits enormously from the safety of iOS, she loves the fact that nothing she does can hurt her system. The safety allows her to experiment much more freely than she can on OSX where she has to worry about the possibility of hard to reverse changes.

Since you picked Hypercard, one of Hypercard's direct descendants is Run Time Revolution's LiveCode. Runrev personal edition and student edition of LiveCode for iOS runs on OSX, that is it requires a cross compile. They expect you to also buy the Developer SDK from Apple. So even for students who want to deploy they have to be paying $100 for LiveCode (vs. generally $300 for the pro version) and $100 for the SDK (assuming the school doesn't use the Enterprise version).

That is even Hypercard (essentially) has to follow Apple's model of building software for virtual hardware running on the Mac and cross compile, not treat the iPad like a development platform. And I agree that this modern Hypercard gets rid of the whole casualness which allows for discovery. Someone has to be at least semi-serious to use LiveCode at all. Apple is aware of this and is trying to make things easier, Apple is seriously considering allowing them to bundle a mini version of the iOS-SDK that allows for the creation of private apps only (no AppStore), with the student version of LiveCode for free.

Also, LiveCode for iOS doesn't use the run time library but rather is a statically bound application. Runrev met with Steve Jobs in early 2010 and knows what he wanted in terms of making LiveCode safe enough for the runtime engine, and they are slowly moving their product in that direction. No one has published the specifics so I don't know what Steve Job's issues were, but according to the CIO of RunRev they were not small thing they could knock off in a few months.

Basically things are better than people say, the situation is much more nuanced than the absolutist language you hear and in general Apple is slowly finding an appropriate way to meet everyone's needs. No one has ever done what Apple is doing, in terms of created an environment this configurable for end users while at the same time this safe. It is very easy to say "iPad's should do X" not so easy to balance out all the various plusses and minuses. By 2015 or 2020 it is entirely possible that iOS (I suspect on Macbook air) is a premier kid's and school's development platform because they do anything without any fear at all of harming the system.

Apple no longer has the Objective C-only requirement, they allow code from other languages; they also allow interpretation as long as you don't side load code from an outside source.

Terms of the license are not enforced technically, but rather you have to disclose what your app does. If you are honest, then you will get rejected. If you are dishonest, then your app will get banned after the unwanted behavior is identified, and your account will possibly be suspended if the violation is blatant. This is a very effective filter, since most people are honest up front. Only the virus writers will be sneaky about this, and they will probably eventually be found out via the community of users.

How do you create a virus for a general end user's version of OSX?

For example you can't move from system to system. An OSX device doesn't know its own private keys and thus can't generate a provisioning file for itself.

Worms aren't the only kind of virus, while even worms are viable if you can compromise the system.

Any system has an attack vector, its only a matter of how hard it is to exploit, and given the interest in Apple systems recently, I'm sure people will find holes. Technological solutions include static analysis, sand boxing (including via processes), managed languages, and so on. They are only so effective (can't filter porn yet), and come at the cost of flexibility, so they aren't pushed too hard. Instead, social/legal/economic solutions work well enough, at least for now.

They only allow a fixed set of languages right? They don't allow compilation to languages in that set? (whatever compilation means -- many companies use code generators). It's a bit unclear what's not allowed and what's allowed.

No that isn't right. Corona, which is a very heavily used commercial Lua system is a good example. There were terms until September 2010 banning other languages in theory. In practice they were mainly banning Flash game developers.

Mainly it the rules seem unclear because people are trying to handle this more abstractly than Apple is. Here IMHO is what the unofficial guidelines are:

1) Apple will do whatever it thinks is in the best interest of the platform. In practice the only rule is that Apple is the final authority and there are no rules only guidelines.

2) The more knowledgable your end users the more leeway you will have.

3) The more consistent your application is with the iPhone interface the more leeway you will have.

4) The more consistent you application is with Apple culture the more leeway you will have.

5) The more obscure and niche your app the more leeway you will have.

For languages which are heavily used, Apple will handle them on a case by case basis.
For example the original ban was mainly aimed at the Flash CS5 compiler. That ban came directly from Steve Jobs:

This becomes even worse if the third party is supplying a cross platform development tool. The third party may not adopt enhancements from one platform unless they are available on all of their supported platforms. Hence developers only have access to the lowest common denominator set of features. Again, we cannot accept an outcome where developers are blocked from using our innovations and enhancements because they are not available on our competitor’s platforms.

For Java there are ongoing discussions with Sun/Oracle. Apple appears interested in Jazelle (Java bytecode interpreter directly built into the Arm processor). So for that one I'd say Apple's position is "soon but not yet".

For CLI on ARM there is no question that Microsoft and Apple have had numerous discussions but the rumor mill is unclear where this stands.

For most of the languages the LtU people care about, I suspect Apple would be genuinely supportive.

How do you know this inside information on Apple's unofficial policy? Do you work for Apple?

Why did you ask the question about code generators? I started the whole post with a discussion of a specific example of a code generator that does over a million a month in business with Apple. Why ask the question if you aren't interested in the answer?

On the contrary, I am very much interested in the answer, because I was thinking about creating a development tool targeting iOS applications. But with the current uncertainty it's not worth the risk. Hearing the policy from an Apple employee, or from somebody who heard it from an Apple employee would certainly reduce that risk.

He's an apple certified technician, maybe?

Or a hardware pre-silicon validation engineer?

A development tool (i'm assuming professional) and this is for creating apps for widespread distribution (i.e. not small scale or corporate)? First off that kind of app would be running under OSX not under iOS. So most of this conversation is irrelevant.

If the tool is iOS specific (i.e. Cocoa) then in general Apple is going to be supportive. If it isn't Apple is going to make quality judgements either on the output of the tool or on your customer's apps. There is no way to eliminate the risk regarding development tools that aren't in line with Apple's preferred methodology. Developers / companies with 2 decades of connection to Apple have had problems on this front. But generally companies have been able to work through them. On the other hand the iOS Apple App store revenue is about 7x Blackberry App world, Android Market and Nokia Ovi combined. So if you want to make a commercial tool the only developers, on average, making much money right now are the ones doing JavaME or the ones doing iOS.

Given that code is data, doesn't this disallow all network communication?

Apple doesn't play word games, so no.

What's Apple's definition of code then, and how does it differentiate between different input that affects the execution of a program? i.e. between input that is 'code' vs input that is 'data'.

If they reject your app because you violated this rule, then the input was code.

Well naturally :p.

In any case, I thought of something:

Acceptable: A (data) and B (data)
Not acceptable: A (data), B (data) and A-some_relationship-B (code)

Or in other words, any relationship between inputs must have already been decided locally.

Wouldn't this allow instructions to state machines though? Hmmm.

Maybe we could disallow assignment instructions.

They don't define code or data formally, so they have discretion to decide when data crosses the line and becomes code. Most of the time, its easy to tell when the line is crossed, therefore they don't need to worry about the gray distinction between the two terms. Again, they aren't playing scientists or even lawyers where terms have to be defined unambiguously. And to be honest, can you really blame them?

You are getting good answers below. The big thing is Apple doesn't play computer scientist here. Code and data are defined in a business sense.

1) Does the end user think of it as code or data. pdf documents are obviously code but thought of as data for example.

2) How safe is the interpreter? Does the interpreter create security holes? And relative to how big the security holes are, who is the app marketed too? Apple is much more liberal on applications designed for the sophisticated user and much less liberal on apps designed for children.

3) Does the interpreter and the code running on it fit with or detract from the overall platform direction? For example
a) Does the end user experience an iOS look and feel. For example iOS applications have graphics built for the screen size, while Android developers tend to use scalable graphics. Which does the end user experience?
b) What is the download size. Does it make images smaller or larger?
c) Does it create the possibility for external markets and commerce?
d) Are the code developers fundamentally iOS guys. As the Apple announced new directions for the platform at WWDC can they expect the interpreted code to follow?

____

If you are using an interpreter to make "insanely great" software available, that's good and Apple is going to be looking to qualify your application if they can do so safely. If you are using an interpreter to save programmers the trouble of having to learn anything about the iOS platform and churn out generic applications without any concern for end user experience, that's bad and the rules will be strictly enforced.

Quite literally the same interpreter app could pass or fail depending on soft factors like target marketing.

Hey Jeff,

Is this something you came up with on your own or is this something that Apple has said. If the latter, I would love to get my hands on some kind of reference.

Apple doesn't want a permanent clear cut policy because they don't want people to think of ways to comply with the letter but not the spirit. For example low value apps had occurred to apple until they pulled several hundred of Khalid Shaikh's apps (topic specific news aggregators for a higher price). The issues with runrev and Corona are well documented (both interprets that Apple has been somewhat supportive of).

It is my description of what they do in practice. I look at the objections to applications I think it is pretty easy to derive. For example look at a classic like thoughts on flash. The objections Jobs lists:

1. Apple doesn't want a competitors closed platform. Either open or under apple's control.
2. Apple wants to implement technologies in ways optimized for their hardware
3. Apple wants cocoa developers not generic developers
4. Apple considers quality of implementation important in whether to allow larger systems.
5. Apple wants software that meets their interface standards, and use the interfaces provided.
6. Apple will be stricter the more important the interface. They don't want widely used software holding the platform back.

I'll quote the last paragraph:

Our motivation is simple – we want to provide the most advanced and innovative platform to our developers, and we want them to stand directly on the shoulders of this platform and create the best apps the world has ever seen. We want to continually enhance the platform so developers can create even more amazing, powerful, fun and useful applications. Everyone wins – we sell more devices because we have the best apps, developers reach a wider and wider audience and customer base, and users are continually delighted by the best and broadest selection of apps on any platform.

You are never going to get a binding official statement because people always think of ways to do stuff that Apple doesn't like.

I wasn't looking for an official binding statement, but just some reference on the spirit argument that I could reference and quote when further work is done. It makes total sense to me that Apple would avoid a strict legalistic or structural definition of what a "valid" app given that so many of the criteria are necessarily subjective. As engineers and researchers, we might not like this, but I don't see a decent alternative that allows them to maintain control.

Eventually, we should start looking at open ecosystems again: how can we make our open unwalled gardens safe without building real walls? Can we leverage crowdsource reputation and editorial controls such as those used on Wiki to create a high-quality garden where noise and malicious apps are somehow vanquished or at least obscured?