next »

[dto1138]

I have an opinion piece over at my site called Thoughts on iOS Games, and why I will not be releasing any of my games for the platform. Basically the SDK terms prevent it anyway, but I will argue that its bad for basically every game developer out there.

The article is here: http://dto.github.com/notebook/apple.html

Thanks everyone.  --dave

[Average Software]

I have no interest in these platforms either, even without considering that my language of choice (Ada) isn't allowed.

However, your argument has a few flaws:

and, surprise, two of Apple's sanctioned languages, Objective-C and C++, were both implemented first as translators to C—even though code translation is forbidden.

Red herring.  The way these things were implemented originally over 20 years ago has no relevance.

Besides, if you actually write C by hand, you have to use and understand pointer arithmetic, and you have to do it morning, noon, and night.

I can't even remember the last time I had to use extensive pointer arithmetic in C, and I do a fair amount of C programming.  I think this is an overblown claim.

Objective-C, a simple and elegant object-oriented extension to C developed in the early 80's under the influence of Smalltalk. It's nice, but all you can really do with it now is develop OSX and iOS applications, so you lock yourself into developing for Apple.

Objective-C is supported by GCC, which is available for damn near anything.  Most of the Cocoa API has been cloned by the GNUStep project.  There is very little lock-in here.

Apple has begun making extensions to the Objective-C language that may very well be enhancements—they've added something resembling first-class anonymous functions, from what I gather. But these changes will also further idiosyncratize the platform.

Objective-C has no formal language standard.  Apple are the primary users by far, and pretty much control the direction it moves in.  I'm not a fan of the situation, but you can't really call them extensions, since there is no formal base to extend from.

I agree with your stance wholeheartedly, but you may want to revise some of your points.

[dto1138]

My argument about Objc and C++ having been previously implemented as translators, is QUITE relevant because it just shows that translation is part of how programming practice develops and advances and thus raises questions about forbidding translation.

I don't think I am overstating the case with C and pointers. Even without explicit arithmetic you still have the problem of dangling pointers and buffer overflows---I'm not sure how you are programming in C to *systematically* eliminate those.

As for this:

Objective-C is supported by GCC, which is available for damn near anything.  Most of the Cocoa API has been cloned by the GNUStep project.  There is very little lock-in here.

Please visit http://wiki.gnustep.org/index.php/ObjC2_FAQ this page which is the GNUStep people's FAQ on Apple's "Objective C 2.0". Money quote: "Currently, no features of Objective-C 2 work with GCC." Apple forked GCC and are doing their own thing now.

[Average Software]

Please visit http://wiki.gnustep.org/index.php/ObjC2_FAQ this page which is the GNUStep people's FAQ on Apple's "Objective C 2.0". Money quote: "Currently, no features of Objective-C 2 work with GCC." Apple forked GCC and are doing their own thing now.

Apple were the primary maintainers of the Objective-C compiler in GCC.  They had every right to fork it, and the source is available as required under the terms of the GPL.

When Apple decided to move to the Clang compiler system, they stopped working on GCC.  Until that point they were regularly porting their code into the main branch.  Someone just needs to step up and do the work.  All of the source is freely available, Apple isn't hiding anything.  Clang is open-source, freely available, and supports Objective-C 2.0.

Apple is not alone in this behavior either, several companies (AdaCore, RedHat, IBM, Intel, and others) maintain their own forks of GCC, and they are under no responsibility to commit changes to the mainline suite.  Apple hasn't done anything wrong in this regard.

My argument about Objc and C++ having been previously implemented as translators, is QUITE relevant because it just shows that translation is part of how programming practice develops and advances and thus raises questions about forbidding translation.

Your argument is this:
Objective-C and C++ compilers have been implemented as translators to C.
Therefore, Apple should allow code that was translated into C, C++, or Objective-C.

The conclusion does not follow from the premise.

I don't think I am overstating the case with C and pointers. Even without explicit arithmetic you still have the problem of dangling pointers and buffer overflows---I'm not sure how you are programming in C to *systematically* eliminate those.

I'm an experienced C programmer and I know how to avoid those problems.  Do they occasionally happen?  Yes, of course, but these problems are hardly unique to C, and are common in many, many languages.  It's a general programming problem, not a C problem.

[dto1138]

Apple's right to fork GCC is irrelevant. My entire point in mentioning the language extensions to Objc was to highlight the idiosyncratization of the iOS platform---making code more dependent on the Apple-specific dialect of Objective C. Your comment that "someone just needs to step up and do the work" is not a valid response---it admits that keeping up with Apple would require such work as they keep moving toward Objc 2.0 and beyond. I still defy you to explain how porting the latest Cocoa API calls to GNUstep will happen with the push of a button, the way Adobe would have had us convert Flash applications to Cocoa. Somebody has to do the work, show me where the momentum is for working on anything relating to GNUstep.

Your argument is this:
Objective-C and C++ compilers have been implemented as translators to C.
Therefore, Apple should allow code that was translated into C, C++, or Objective-C.

Nonsense. My goal in pointing out that Objective C was once translated to C was to show that an Apple-prohibited practice could produce the EXACT same output as an Apple-endorsed practice, and that they thus have NO OBJECTIVE, EMPIRICAL BASIS FOR DECIDING BETWEEN APP SUBMISSIONS with regard to their "originally" being written in this or that. I heard that Adobe's Flash-to-iphone apps are readily identifiable, but this could change. Apple has admitted it thinks that cross-compilation would destroy iOS, and has defined this so broadly that a "white-list" of approved tools is required to rescue us from the NULL SET left by banning translation of programs---by banning programming. Apple wants to demarcate "originally written" apps from those that infringe, so they can approve the one and ban the other. But since their distinction is not even empirically intelligible, their decision making can have only some other basis.

[David Pittman]

Maybe I'm reading it wrong, but I think Apple is only prohibiting apps that are executed via an interpreter on the device. How would they even know if you pre-translated from another language to C?

[Average Software]

I think your misunderstanding my criticism.

I think what you're saying is correct, but your arguments are invalid from a logical standpoint.  You've written an opinion piece, and your rationale for your opinions is suspect.  Your article is full of unjustified logical leaps.

That is to say, you're right, but you're right for the wrong reasons.

I have some degree of formal logic training, so I can spot these things.  Your piece honestly reminded me of a politician's speech.  It seems OK at the time, but doesn't stand up to closer scrutiny.

This is a little bit better:

My goal in pointing out that Objective C was once translated to C was to show that an Apple-prohibited practice could produce the EXACT same output as an Apple-endorsed practice, and that they thus have NO OBJECTIVE, EMPIRICAL BASIS FOR DECIDING BETWEEN APP SUBMISSIONS with regard to their "originally" being written in this or that.

The problem is this:

Apple doesn't want Obective-C, C, or C++ code that was generated from something else.

You're arguing against this starting from the fact the such code can be generated from something else.  This fact is contained in the problem statement.

Joe doesn't want A that came from B.
B can produce A.
Therefore Joe should want A that came from B.

Your conclusion is contradicted by your first premise, therefore at least one of them must be false.  The first premise is known to be true, therefore your conclusion is false.

This is what is wrong with your article.

[slembcke]

OS X fanboi here, and former iPhone developer.

Hey dto, we talked on iDevGames irc last night.

Maybe I'm reading it wrong, but I think Apple is only prohibiting apps that are executed via an interpreter on the device. How would they even know if you pre-translated from another language to C?

They don't know exactly, but they still made a rule that said doing so violates the developer agreement. I'm quite sure that in the general case of any popular tool (like the AOT flash compiler) that does this is going to link to a library with very searchable binary strings.

Also, for anybody that says that GNUStep is an alternative to Cocoa, have you tried it? Mac developers really tend to like Cocoa in general, and I've never heard good things from anyone that's tried to use GNUStep for cross-platform development. It's not like they like Cocoa because they had their arm twisted by Apple in some developer agreement either. Given the option to Cocoa, Swing, SWT, wxWidgets, GTK, Tk, Qt, ... they happily choose Cocoa. Given the choice of languages to use Cocoa from, they often choose Obj-C but Apple also officially supports Ruby and Python (maybe Perl too?) and a lot of people use them. Have any Mac developers ever tried writing Obj-C for non-Apple platforms: No. Is Obj-C more or less effectively locked into Apple platforms simply because of practicality: Yes. You can't claim it's quite the same as Mono where you have a well maintained and fairly compatible implementation of Microsoft's CLR. Mono is waaaaay more compatible with the CLR than GNUStep is with Cocoa.

Basically what's frustrating here is that Apple is dictating innovation here by mandating the usage of certain tools and even techniques. Want to use a modern language that has garbage collection, dynamic closures, and lots of nice easy to read and use syntactic sugar? Too bad. You can't use Apple's GC, and they don't make public the API required to use something like the boehm collector. You can sort of use blocks on the iPhone by using PLBlocks, but the syntax gets messy pretty quick and the APIs are not there to make them useful anyway. I guess if you want syntactic sugar you can always use C++ if you want to deal with the dog that is Obj-C++. I don't hate Obj-C, it's a nice language for some things. I really like their Obj-C runtime, and think it would be an awesome generic base to build another language on top of. MacRuby does this by substituting the Obj-C runtime for the Ruby one and the LLVM JIT compiler instead of the Ruby interpreter. The result is pretty amazing with zero cost access to mix Ruby and Obj-C code and objects and native access to pretty much every OS X API. Apple will never allow this on the iPhone, and the real irony here is that MacRuby is an Apple project...

Well, the obvious response is that allowing such tools would let bad programmers make bad apps. The problem here is that those same bad programmers that would make a program that uses too much memory with a GC or is too slow because it's programmed poorly are still making iPhone apps anyway. Instead of allowing them to use tools to make up for their lack of skills/knowledge/experience/whatever, they are instead trying to force their way along using Obj-C. They are making programs that leak memory like a sieve and are slow/crashy because they rely too much on bizarre hacks because that's the only way they could figure out how to make it work. There are plenty of terrible apps on the App Store to make a pretty clear case for this. Who cares if a fart app uses 1MB more memory than it should or is taking 0.1ms longer to fart because it's using a non optimal language? GCing memory is more efficient 95% of the time, and the 5% where it's not requires more careful planning than simply using Cocoa's reference counting model. Obj-C already exclusively uses dynamic method calls and relies heavily on memory allocation, so it's already not know for it's insane performance. It's greatest strength IMO is it's ability to freely mix in raw C code for the few places where you need to optimize.

The difference between Apple's ideas about OS X development and iOS development are like night and day. They prevent you from using certain tools because they are afraid that you will make bad apps with them, and that will hurt their brand. Yet they do practically nothing to prevent armfuls of awful apps written using allowed tools. So really it's Apple deciding that their BS ideas to protect their brand are more important than the time of developers for their platform. I don't need Apple holding my hand telling me that garbage collection, JIT compilation or Flash programming is bad for society. I'm still waiting to see how the High Jobs is going to respond to the Unity CEO chewing him out for not understanding the game development market. After all, when Apple amended  the developer agreement to allow interpreted languages only with express written permission (WTF seriously?) they more specifically disallowed Unity as it's a "cross-platform development tool" that uses AOT compilation for the iPhone.

[dto1138]

Hi, thanks for your comments.

I don't think I am misunderstanding your criticism or your logic. The syllogism you start with is just wrong:

Joe doesn't want A that came from B.
B can produce A.
Therefore Joe should want A that came from B.

Your steps 1 and 2 refer to the Objective-C preprocessor issue, which was added later in the development of the essay, and could be excised from my article without changing much. Furthermore your step 3 presents a conclusion that is not the conclusion of my essay. My point is NOT to tell Apple what it "should want", but to explain why I will not develop for iOS, and to show other game developers that they are in the exact same boat.

I don't see how any syllogism could SUPPORT "apple should want X" as "should" reveals it to be a value judgment and also a sort of wager betting on what will be better for Apple in the future. Beginning with this as your syllogism's conclusion and then showing it to be unsupportable is not the feat of logical derring-do it might seem on first glance.

If you absolutely must have this article boil down to something resembling a syllogism, perhaps this will shed light on the issue:

Steve doesn't want A that came from B.

B can produce A.

Dave thinks this means Steve can't actually DECIDE between A and B.

[insert here 20 other reasons why the requirement is dumb, other than decidability.]

Dave thinks it's an unsustainable and vague distinction that will be applied according to Apple's interests and not according to anything resembling an objective and fair standard.

Dave thinks this is a show-stopping uncertainty (i.e. risk) for anyone whose technologies might touch the SDK language in question.

Dave will not be developing iOS games.

I'm happy to admit this misunderstanding being my fault, and I will probably add a clarification (a syllogism?) showing that my article has nothing to do with what apple "should want"---as if I have a chance of affecting that. The conclusion(s) I present in the essay are not designed to change Apple's behavior, they instead telegraph my horror at an "originality" requirement with no objective or rational basis that is nonetheless enforced with an iron fist.

 

[Craig Stern]

Steve doesn't want A that came from B.

B can produce A.

Dave thinks this means Steve can't actually DECIDE between A and B.

Not to pile on or anything, but "B can produce A" is actually irrelevant to the conclusion you're presenting here. The fact that B can produce A doesn't have any impact on the fact that Steve doesn't want A produced by B. All it does is say that you can use B to produce something Steve doesn't want. The conclusion doesn't follow from the premises.

Premise: Doug doesn't want pickels made from cucumbers.

Premise: A cucumber can produce pickels.

Conclusion: Doug can't decide if he wants pickels or a cucumber.

See what I mean? I liked your article, though.

[Tycho Brahe]

So would it be allowed if I wrote an app in obj-c, used a program to translate it to ruby then used another program to translate it back to obj-c? Or am I missing the point entirely?

[Average Software]

Steve doesn't want A that came from B.

B can produce A.

Dave thinks this means Steve can't actually DECIDE between A and B.

Not to pile on or anything, but "B can produce A" is actually irrelevant to the conclusion you're presenting here. The fact that B can produce A doesn't have any impact on the fact that Steve doesn't want A produced by B. All it does is say that you can use B to produce something Steve doesn't want. The conclusion doesn't follow from the premises.

The fact that the conclusion doesn't follow from the premises is the whole point.  The conclusion is false, and true premises cannot imply a false conclusion.

[mewse]

The iPhone is not an open platform like a Mac or PC.  That's really all there is to it.

Your complaints boil down to you being unhappy that the iPhone isn't an open platform where you can do whatever you want.  Which is a fair enough point of view, I guess, but --  speaking as someone who owns an iPhone and doesn't develop for it -- I think that having some basic standards and a small barrier to entry is important for ensuring the stability and the battery life of these small battery-powered devices.  It's one of the big reasons why I chose an iPhone rather than an Android phone.


Anyhow.  I'm a little puzzled about why you specified that you weren't going to program for iPhone, iPad, or iPod Touch, but didn't mention that you weren't going to program for the Wii, XBox 360, PS3, DSi, PSP, or Windows Mobile.  I mean, similar (and far worse) restrictions apply for those other closed platforms.  Why did you choose to single iOS out, when it's clearly only one of many closed platforms that you have chosen not to develop for?

[bateleur]

I mean, similar (and far worse) restrictions apply for those other closed platforms.

There's a difference of philosophy, though.

Most closed platforms require specific approaches because other options aren't available. The difference with Apple is that they are actively preventing efforts to get content onto their platform.

Despite all Steve Jobs' increasingly creative lies on the subject the reality is actually very simple: Apple know that if people can easily port content that removes much of the incentive for developers to create things specifically for their platform. They like people doing that, so they make it hard to port things.

And indeed the reason Android is taking a different approach is partly because they're short of content so they don't mind people porting stuff so long as it runs on their devices.

[mewse]

Most closed platforms require specific approaches because other options aren't available. The difference with Apple is that they are actively preventing efforts to get content onto their platform.

What development options, specifically, are you saying aren't possible on other platforms, but are available (but prevented by Apple) on the iPhone?

Despite all Steve Jobs' increasingly creative lies on the subject the reality is actually very simple:

What lies?  Can you name three falsehoods he's made about development requirements for iOS, with specificity?  I can't think of any, myself.  But I haven't really been closely following his public statements on the matter, and so it's quite possible that I've missed something.

[waruwaru]

Most closed platforms require specific approaches because other options aren't available. The difference with Apple is that they are actively preventing efforts to get content onto their platform.

What development options, specifically, are you saying aren't available on other platforms, but are available (but prevented by Apple) on the iPhone?)

Basically, any "Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited".  The wording is so broad that could potentially excludes any sort of in-app scripting engine, and data-driven engines.

I don't think any of the "Wii, XBox 360, PS3, DSi, PSP, or Windows Mobile" platform disallow developers to create quality games in Python/Lua/Unity/others languages (as long as you can build the engine using provided toolchains).  Here is a list of apps that has an "intermediary translation layer" (google doc).  This effects not only the game developers, but also many of middleware vendors (Unity, MonoTouch, Appcelerator..etc).  Apple clearly doesn't care about its own ecosystem and developers.  Makes no sense to limit "how" an app is written.  Plenty of fart apps were written in ObjC, so the tools have no effect on app quality.  Apple itself has also given awards to many top ranking apps that were created in Unity (see the spreadsheet above).

Apple also seems to enforce this rule when they feel like it.  It is very obvious that this is a tactic to keep competitors (such as Adobe) out.  If you use an engine (written by you or not), Apple now has an execuse to remove your app whenever they want.

Despite all Steve Jobs' increasingly creative lies on the subject the reality is actually very simple:

What lies?  Name three falsehoods he's made about development requirements for iOS, with specificity.

Read his Thoughts on Flash.  Someone went through and listed 13.  It's true that Apple reserves the rights to do whatever they want within their own market.  As a developer, I choose not to support Apple with my work.  As a consumer, I can only vote with my money to not encourage a company with such anticompetive behavior.

[Perrin]

Read his Thoughts on Flash.  Someone went through and listed 13.  It's true that Apple reserves the rights to do whatever they want within their own market.  As a developer, I choose not to support Apple with my work.  As a consumer, I can only vote with my money to not encourage a company with such anticompetive behavior.

Most those things listed aren't lies they're just points the author disagrees with, but calling the article 13 lies makes more provocative article more likely to draw attention and argument. There must be a term for that because I'm fairly sure that's what the opener of this thread had in mind. Courting controversy is not a new technique for getting a bit of attention but it still works as well as ever.

Maybe I should write a blog post about why I've never bothered with Linux support for anything I've ever developed and see the storm that brews over that.

Personally I don't mind people developing for whatever platforms they like, it's just all the arguing about why their platform choices are "correct" that bothers me.

[ghostwheel]

I'm not even sure why this discussion is going on. I thought it was well established over the last 20 years that closed platforms are BAD. I mean, didn't we already go through this shit with Microsoft? Why does Apple get a pass? Anti-competitive, monopolistic behavior is BAD, no matter who is doing it. The funny thing is, the iOS platform is even MORE closed than Windows ever was. Microsoft never told anyone what software you could or could not run on their operating system. You can argue the specifics of interpreters and all that but it's very closed platform, period.

[mewse]

What development options, specifically, are you saying aren't available on other platforms, but are available (but prevented by Apple) on the iPhone?)

I don't think any of the "Wii, XBox 360, PS3, DSi, PSP, or Windows Mobile" platform disallow developers to create quality games in Python/Lua/Unity/others languages (as long as you can build the engine using provided toolchains).

Do you really think that Nintendo, Sony, and Microsoft provide approved Python, Lua, or etc. toolchains for their platforms?  I'm under NDAs for all those companies, but I don't think I'd be in breach of them by revealing that no, they do not.  If you want to code for any of those platforms, you're doing it in C, C++, or another similar language.  Not for technical reasons -- you could quite easily have an interpreted Python game run on any of their platforms.  

Now, you may have an interpreted language built into part of your natively compiled game (and many commercial games do exactly this), but that's murky water -- the different publishers have different restrictions on when and how you can and can't do it.  And if you think that any of those other companies list those restrictions in a single clear, simple, and internally-consistant document, then you're completely wrong.

Apple clearly doesn't care about its own ecosystem and developers.  Makes no sense to limit "how" an app is written.

   Of course Apple cares about its ecosystem and developers.  And it makes perfect sense to limit how an app is written.  If you don't see the sense in why that is, then you probably need a little more real-world experience.  But here's a hint:  "Small, low-grunt, battery-powered devices".

Apple's focus on end-user experience may not match your personal priorities, but that doesn't mean that they don't care about developers.  Duh.

Plenty of fart apps were written in ObjC, so the tools have no effect on app quality.

Apple (like all closed system managers) don't approve software on the basis of being fun games or useful tools.  That sort of thing is left for the market to decide.  Apple's (and Nintendo's, and Sony's, and Microsoft's) job is to make sure that technically, the apps are up to scratch.  That is, that they don't unduly drain the battery, that they don't compromise the device, that they aren't likely to induce epileptic seizures, etc.  This is what people mean when they talk about "quality" in this context.  From this point of view, a well-coded native app will definitely be higher quality for a small battery-powered device than any Flash file would.  You have only to run a Flash game on an Android phone to understand why this is true.

Apple now has an execuse to remove your app whenever they want.

It's a closed system.  The owner of a closed system always has the ability to do that, and has always had the ability to do that ever since Nintendo's original Game Boy.  This is part of what being a closed system means.  There's nothing special in Apple doing this.  If you're complaining about Apple, you need to complain about Nintendo, Sony, and Microsoft as well -- they all do exactly the same thing, and worse.  

There's a really good argument to be made that we ought to loudly complain about these companies for exactly this reason, and I'd probably support that argument.  But that you choose to selectively apply this argument only to Apple shows that either you don't know how the real world works, or that you're just trying to sling mud at Apple for personal reasons.

What lies?  Name three falsehoods he's made about development requirements for iOS, with specificity.

Read his Thoughts on Flash.  Someone went through and listed 13.

As has already been pointed out, those aren't lies, and they also have nothing to do with development requirements for iOS.  The comments referenced in that article were all about the lack of support for Flash in Safari on the iPad.  Still waiting for someone to back up the claim of "increasingly creative lies" about the development requirements.

I'm not even sure why this discussion is going on. I thought it was well established over the last 20 years that closed platforms are BAD. I mean, didn't we already go through this shit with Microsoft? Why does Apple get a pass? Anti-competitive, monopolistic behavior is BAD, no matter who is doing it. The funny thing is, the iOS platform is even MORE closed than Windows ever was. Microsoft never told anyone what software you could or could not run on their operating system. You can argue the specifics of interpreters and all that but it's very closed platform, period.

What in the world are you talking about?  

• Windows was never a closed platform
• Apple isn't a monopoly -- it's a relatively small player in a big market, with strong competitors.
• Apple isn't behaving in an anti-competitive fashion, except for having made a popular product.

Again, if you're going to condemn Apple on the basis of having a closed platform (iOS), then you have to also condemn Nintendo, Sony, and Microsoft;  they're doing exactly -- exactly -- the same things on the Wii, the Xbox 360, and the PS3 (As well as on the GameCube, N64, Super NES, DSi, DS, GameBoy Advance, GameBoy, Xbox, PS2, PS1, and PSP.  And Sega did too, on the Dreamcast, Genesis/MegaDrive, and the Master System.  And NEC did too, with the TurboGrafix, and their other early consoles.  And they were -- and are -- far, far worse about it than anything Apple's done).

[oahda]

Thank you from saving me from writing all of that myself, mewse.
Every single word you've written represents my thoughts exactly.