Linked by Thom Holwerda on Thu 8th Apr 2010 22:38 UTC
Apple John Gruber has found out that cross-compilers are no longer allowed in iPhone OS 4.0. "My reading of this new language is that cross-compilers, such as the Flash-to-iPhone compiler in Adobe's upcoming Flash Professional CS5 release, are prohibited. This also bans apps compiled using MonoTouch - a tool that compiles C# and .NET apps to the iPhone. It's unclear what this means for tools like Titanium and PhoneGap, which let developers write JavaScript code that runs in WebKit inside a native iPhone app wrapper. They might be OK."
Order by: Score:
Really???
by nathbeadle on Thu 8th Apr 2010 22:58 UTC
nathbeadle
Member since:
2006-08-08

Is there any legitimate reason for this or is this just Apple pushing people out? This seems a little too far for me, and I'm normally an Apple fan!

I'd love to see some effort put into getting rid of ridiculous apps, or a better organization system instead of such general categories as GAMES and BUSINESS.. let's make that stuff easier to manage!

Reply Score: 4

you've got to hand it to them...
by poundsmack on Thu 8th Apr 2010 23:00 UTC
poundsmack
Member since:
2005-07-13

When Apple decides to commit application platform genocide on something they really go full on... kinda sad really. Don't get me wrong I like HTML5 and am not a huge Flash fan (though 10.1 fixes almost all of my issues with it), but forcing people away from a platform like this is just wrong. Then again, maybe Steve Jobs had a past life where he lead the Crusades... who knows...

Edited 2010-04-08 23:01 UTC

Reply Score: 4

Words fail me
by Praxis on Thu 8th Apr 2010 23:06 UTC
Praxis
Member since:
2009-09-17

This is just ridiculous, this is perhaps the best example of apple control freakism I have ever seen.

I can see apples motivation behind this, the last thing they want is too make it easier for developers to support other platforms. If you want to write for the iphone it must be for the iphone alone, none of this write once run anywhere crap. This is something that purely effect developers though I doubt this gets much press. Even thought this is clearly a shot at Adobe, lots of devs are going to get hit in the crossfire. That sucks.

At least we still have the internet, web apps are something that Apple can't wall off just yet.

Reply Score: 6

RE: Words fail me
by ggeldenhuys on Fri 9th Apr 2010 20:36 UTC in reply to "Words fail me"
ggeldenhuys Member since:
2006-11-13

This is just ridiculous, this is perhaps the best example of apple control freakism I have ever seen.

Apple is absolutely ridiculous! It shouldn't be about the programming language, but how well the application interacts with the device.

The developers of the Free Pascal Compiler worked damn hard to get iPhone support and translate the API's - now Apple wants to ban such a compiler even though you can write perfectly good iPhone applications with it.

Apple, you are f**ken nuts! I hope developers leave the iPhone market in droves. Developers should move to something more open - and where developers are treated with respect. After all, it's the developers writing the apps that make a device more popular.

Reply Score: 3

Look and feel issues or hardware sales?
by bousozoku on Thu 8th Apr 2010 23:08 UTC
bousozoku
Member since:
2006-01-23

The way that the development tools work, especially Interface Builder, is rather specific. They try to keep the look and feel and inner workings in a certain order.

As much as Apple used to bind everyone to the Human Interface Guidelines in the 1980s, could they be doing the same here or is it just a way to fix the loophole for Adobe and others are getting caught in the crossfire?

I suppose there is also another possibility: hardware sales. When developing for iPhone OS, you must have Apple hardware running Mac OS X, or so they say. Do those building through Flash and the translation tool need Mac OS X or Apple machines at all?

Reply Score: 3

Major reason for this...
by whartung on Thu 8th Apr 2010 23:13 UTC
whartung
Member since:
2005-07-06

The primary reason behind this is to fragment the developer space.

It will simply not be practical to create an application, from a single source base, that can be run on the iPhones C runtime, Adroids Java runtime, and Windows 7 Silverlight runtime.

Consider this another shot of the platform wars.

With scarce mobile developer resources, companies will have to choose where to put their dollars. And right now, the iPhone still has the mobile mindshare if you're targeting the mobile market.

Now, a company can write something for the iPhone, perfect any server technology, etc. and then release a new client for the other platforms leveraging their "done it once" expertise from the initial iPhone project. But what that ends up being is having a product on the iPhone first, with other platforms later.

Obviously not all shops will follow this course, but since the iPhone is the "800lb" gorilla right now, MANY will, and all of these efforts, incrementally, push the iPhone system as the premiere mobile platform.

Reply Score: 7

RE: Major reason for this...
by ebasconp on Fri 9th Apr 2010 00:13 UTC in reply to "Major reason for this..."
ebasconp Member since:
2006-05-09

The primary reason behind this is to fragment the developer space.


As far as I remember, Microsoft tried to do this several years ago with its IE and a lot of time they won a lot of market share and a lot of developers developing just for IE instead of doing the cross-platform thing. But in the long term, this kind of dirty plays did not triumph because the open standards and interoperability always win.

Reply Score: 2

RE[2]: Major reason for this...
by whartung on Fri 9th Apr 2010 00:27 UTC in reply to "RE: Major reason for this..."
whartung Member since:
2005-07-06

Yea, long term I don't see this going well for them. It's a matter of how long they retain their 800lb Gorilla-ness.

Basically it's a Windows vs Unix war in the enterprise space. Windows is windows, Unix is Everything Else. MS wants to promote windows development as it ties folks to their platform. Windows is the platform for First Choice for most client applications.

So, you can write applications for the iPhone, or for Everything Else. But not both (with the same source base). As long as the iPhone is dominant (and this will help keep it dominant), it's a win for Apple. But once Everything Else becomes the platform of first choice for consumers and developers, Apple can simply remove the clause from the dev agreement and join the band wagon, having held their lead as long as possible.

Reply Score: 2

RE[3]: Major reason for this...
by Delgarde on Fri 9th Apr 2010 02:24 UTC in reply to "RE[2]: Major reason for this..."
Delgarde Member since:
2008-08-19

But once Everything Else becomes the platform of first choice for consumers and developers, Apple can simply remove the clause from the dev agreement and join the band wagon, having held their lead as long as possible.


Unlikely. Suppose Apple pull this strategy, and nobody else does. Developers are then in the position where they can code once for iPhone, and once for anything else (supported by cross-compiling frameworks). If iPhone then slipped from being the #1 platform, you might wonder whether those frameworks would take the time to support it, given the precedent Apple have previously set.

Reply Score: 2

RE[3]: Major reason for this...
by moondevil on Sat 10th Apr 2010 08:28 UTC in reply to "RE[2]: Major reason for this..."
moondevil Member since:
2005-07-08

Since when Unix is everything else?

There are many more OS out there than just Windows and Unix.

And for Unix lets also not forget that there are lots of OS specific APIs in each Unix out there. If you really want to take advantage of certain OS features you have to step outside the POSIX calls. Even with POSIX you might hit semantic differences among them.

This is nothing new, since the beginning of computing each vendor wanted everyone to use their own platform tools as a kind of lock in. IBM used to be very good at it.

Reply Score: 2

RE: Major reason for this...
by cb88 on Sat 10th Apr 2010 15:36 UTC in reply to "Major reason for this..."
cb88 Member since:
2009-04-23

Or... they will forgo iPhone development altogether as their working codebase no longer fits the platform

Android has made a significant dent in the iPhone market people that once would have had an iPhone now have a selection of various Andriod Phones to pick from that fit their taste (and not steve jobs') for instance it just so happens that a lot of people *like* having a physical keyboard

Reply Score: 1

ObjectiveC, C++ or C
by henderson101 on Thu 8th Apr 2010 23:15 UTC
henderson101
Member since:
2006-05-30

Baring in mind that the ObjectiveC runtime is fully accessible in C, and C is a language that Apple would seem to accept - the compiler simply needs to output plain C.

I suspect they are actually attempting to stop the likes of MonoTouch and Adobe FlashToiPhone. The MonoTouch guys did write a framework that translated .Net API to assembler and then charged over $200 for it... total rip-off when the ObjC tools are free. They are planning to port over some kind of Silverlight API compatibility, so this would be what Apple would mainly object to. FlashToiPhone just smacks of sour grapes though.

Reply Score: 2

RE: ObjectiveC, C++ or C
by Delgarde on Thu 8th Apr 2010 23:26 UTC in reply to "ObjectiveC, C++ or C"
Delgarde Member since:
2008-08-19

Baring in mind that the ObjectiveC runtime is fully accessible in C, and C is a language that Apple would seem to accept - the compiler simply needs to output plain C.


Nope. The wording is that "Applications must be originally written in Objective-C, C, C++", etc. Emphasis on "originally" - it's clearly the same intent as the GPL clause that defines the code as the stuff human developers actually work on, not the output of some processing step.

The purpose clearly is to force people to use Apple's APIs, to make it harder to build a product that can run on competing platforms as well.

Reply Score: 5

RE: ObjectiveC, C++ or C
by whartung on Thu 8th Apr 2010 23:26 UTC in reply to "ObjectiveC, C++ or C"
whartung Member since:
2005-07-06

Baring in mind that the ObjectiveC runtime is fully accessible in C, and C is a language that Apple would seem to accept - the compiler simply needs to output plain C.


No.

Here's the clause from the agreement:
3.3.1 Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).


Note the highlighted section. The INTENT of the clause is that code be written in C/Obj-C/C++/JS. Not cross-compiled INTO C and then compiled down in to the runtime.

That's pretty clear from this.

If you're not writing C/Obj-C/C++/JS for your code, technically you're in violation. In fact, arguable Googles Web Toolkit will violate this contract, since that code is originally in Java and compiled down in to JS.

So, there go your dreams of writing iPhone apps in Rabbit Scheme.

Reply Score: 4

Coincidental
by umccullough on Thu 8th Apr 2010 23:17 UTC
umccullough
Member since:
2006-01-26

Seems coincidental that just a few days ago I was reading this article:

http://blogs.adobe.com/cantrell/archives/2010/04/one_application_fi...

And now it seems Apple wants to make such a feat even more difficult...

Edited 2010-04-08 23:17 UTC

Reply Score: 2

If it's true...
by mrhasbean on Thu 8th Apr 2010 23:26 UTC
mrhasbean
Member since:
2006-04-03

...it's just plain silly. Let devs develop for multiple platforms and let the users choose what platform they're most comfortable with.

Reply Score: 4

v RE: If it's true...
by whartung on Thu 8th Apr 2010 23:28 UTC in reply to "If it's true..."
RE[2]: If it's true...
by Delgarde on Thu 8th Apr 2010 23:57 UTC in reply to "RE: If it's true..."
Delgarde Member since:
2008-08-19

Yea, cuz this has worked so well in the Linux marketplace...


Referring to Qt vs Gtk vs random widget library? Not the same thing here, though - that's an issue over *which* libraries are used, whereas this is about *how* Apple's standard libraries are used.

It basically says you must use those libraries natively, instead of writing to a cross-platform framework (like Flash) that can be transformed into a native app. Presumably it still allows you to code in C/C++ with an abstraction around the Apple-specific stuff, but it does rule out a lot of options...

Reply Score: 3

RE[3]: If it's true...
by whartung on Fri 9th Apr 2010 00:21 UTC in reply to "RE[2]: If it's true..."
whartung Member since:
2005-07-06


Referring to Qt vs Gtk vs random widget library?


Actually referring more to the consistency of the user experience end users have when running on Linux.

In Windows it's mostly not so bad, since the vast majority of applications use the native toolset, so most languages produce UI that work and look like all the rest of windows (Java a notable exception, of course).

Presumably it still allows you to code in C/C++ with an abstraction around the Apple-specific stuff, but it does rule out a lot of options...


I think things like GTK et al are specifically excluded. They want you writing to the Apple APIs, not something else that runs on top of those APIs.

An example, if you had a C program written against, say, Win32, then you had a library that presents the Win32 API to your C program, but runs on the iPhone OS, then you'd have, effectively, Windows source code compiling and running on the iPhone, via a compatibility library. Those are the kinds of libraries that they're disallowing.

Other abstractions (A new IMPROVED! NSDictionary!), likely not so much. Easier to use OpenGL, likely not, A full boat portable game kit, perhaps.

They want coders writing code for iPhones, not anything else. That's the gist of this.

Reply Score: 1

RE[4]: If it's true...
by Delgarde on Fri 9th Apr 2010 00:43 UTC in reply to "RE[3]: If it's true..."
Delgarde Member since:
2008-08-19

They want coders writing code for iPhones, not anything else. That's the gist of this.


Agreed.

Reply Score: 2

RE[4]: If it's true...
by Zifre on Mon 12th Apr 2010 01:01 UTC in reply to "RE[3]: If it's true..."
Zifre Member since:
2009-10-04

Actually referring more to the consistency of the user experience end users have when running on Linux.

If you use GNOME apps, then everything is pretty consistent. If you use KDE apps, then everything is pretty consistent. Even when you mix them, it's not so bad with QGtkStyle.

n Windows it's mostly not so bad, since the vast majority of applications use the native toolset, so most languages produce UI that work and look like all the rest of windows (Java a notable exception, of course).

Are you joking? Windows is ten times worse in this regard. Many, many applications use custom drawn widgets. Now, I can't think of any good applications that do this, but there are many (especially the junk that comes on PCs). In Linux, there are two toolkits - that's it.

Linux is definitely more consistent than Windows. (Of course, Mac is even better.)

Reply Score: 2

RE[3]: If it's true...
by Morty on Fri 9th Apr 2010 10:03 UTC in reply to "RE[2]: If it's true..."
Morty Member since:
2005-07-06

Presumably it still allows you to code in C/C++ with an abstraction around the Apple-specific stuff,


Let see:

3.3.1 Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

Nope, that sounds like a no go. Don't you try being clever making your own abstraction layer to keep your application cross platform. Can't have that on the holy iDevices, that would break the lock in and also be sacrilege.

Reply Score: 3

RE[4]: If it's true...
by qbast on Fri 9th Apr 2010 20:34 UTC in reply to "RE[3]: If it's true..."
qbast Member since:
2010-02-08

So I can use Qt and target simultaneously WinMo, Maemo, Symbian and (soon) Android or I could buy a Mac, learn Obj-C and code just for iPhone. Considering that Symbian alone has 3x bigger market share than iPhone, Apple can go to hell for all I care.

Reply Score: 1

RE[5]: If it's true...
by mutantsushi on Sat 10th Apr 2010 00:59 UTC in reply to "RE[4]: If it's true..."
mutantsushi Member since:
2006-08-18

moonbast wrote: "So I can use Qt and target simultaneously WinMo, Maemo, Symbian and (soon) Android or I could buy a Mac, learn Obj-C and code just for iPhone. Considering that Symbian alone has 3x bigger market share than iPhone, Apple can go to hell for all I care."

Yeah, but C++, C and Javascript are allowed... So what's the problem with QT?

Edited 2010-04-10 01:01 UTC

Reply Score: 2

RE[6]: If it's true...
by qbast on Sat 10th Apr 2010 09:07 UTC in reply to "RE[5]: If it's true..."
qbast Member since:
2010-02-08

This is the problem: "and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs". My app would link to Qt and only use iPhone API directly where something important is unavailable in Qt.

Reply Score: 1

RE[7]: If it's true...
by cb88 on Sat 10th Apr 2010 15:53 UTC in reply to "RE[6]: If it's true..."
cb88 Member since:
2009-04-23

Do they *document* the meaning of "the Documented APIs" elsewere in the license? If not then it could be any API al long as it is documented .... thats a long shot though

Reply Score: 1

Was Steve Jobs born in Braunau?
by kragil on Fri 9th Apr 2010 02:22 UTC
kragil
Member since:
2006-01-04

This is really something.
It will be interesting to see if OpenGL game engines will be allowed or not. They don't compile and directly link against the documented API AFAICT.
Miguel de Icaza will have to tone his love for Apple down a bit I guess (He can focus more on MS again).

It would be cool if Microsoft would do something similar with Windows8 .. then all Apple apps would stop working on Windows.

This is really stupid "my way or the highway" BS from Steve. In the end more open platforms will win again and Apple will be f--ked. 2017 = 1997

If Flash apps/games really are so bad why not let them fail in the app store? No, Apple can't have that. Big brother knows best.

But the dictatorship-loving Apple consumers will like it, no doubt.

Reply Score: 7

umccullough Member since:
2006-01-26

"But the dictatorship-loving Apple consumers will like it, no doubt.


I like my house looking clean and consistent. I don't want my neighbor dumping on my lawn. Get it?
"

You mean, you don't like when people put pink flamingos on their lawn, so you're glad the home owners association stopped it from happening?

Funny, I've always hated HOA's, they're usually made up of grumpy old people who have nothing better to do but tell others what to do.

Edited 2010-04-09 03:28 UTC

Reply Score: 5

alcibiades Member since:
2005-10-12

I like my house looking clean and consistent. I don't want my neighbor dumping on my lawn. Get it?

Not really. I don't see what difference it makes to anyone else what apps I run on my iPad or iPhone, if they don't want to run them, don't. I don't see what difference it makes to anyone else what I read on the devices. They can read what they like, can't they?

And I see even less what affair it is of the supplier of the devices what language I use to write the apps in. Notice from the language, that they are not simply saying what will run, what your code has to be compiled into. They are actually telling you what language your must first write it in. You must first write it in variants of C or Java. You cannot deliver C code which is the result of some kind of cross compilation from a non-favored language. No, get out there and learn C. Do not think you can write it in Python, and then cross compile. No.

Why not forbid the use of politically correct C++ IDEs, while you are at it? You agree never to use Eclipse, because we do not like IBM this month. Why not forbid developers to have Python installed on the PC they use to develop for iPhone or iPad?

Is there anything that Apple could do that would incur condemnation by the Cult of Mac?

And by the way, do not discuss this publicly, because the agreement you have just signed forbids it, and if you do, you will join the blacklist and never sell any software for any of our platforms ever again.

Its a truly awful company. Whatever you think of the products, the company is just horrible.

Reply Score: 7

Thom_Holwerda Member since:
2005-06-29

Its a truly awful company. Whatever you think of the products, the company is just horrible.


It's kind of like had Hitler invented the cure for cancer.

And yes, people, I'm joking.

Reply Score: 6

fatjoe Member since:
2010-01-12

I like my house looking clean and consistent. I don't want my neighbor dumping on my lawn. Get it?


I think you are mistaking "your lawn" with "someones lawn" in general. The letter i in iPhone is supposed to mean "I" as "I, the owner", not you or your [former?] employer Steve.

Reply Score: 1

F@ck Apple
by exigentsky on Fri 9th Apr 2010 06:06 UTC
exigentsky
Member since:
2005-07-09

They'd take your soul if they could. I hate when companies are so controlling... and at the same time I want their products so badly. I can't win either way.

Reply Score: 1

Battery
by huwnet on Fri 9th Apr 2010 08:35 UTC
huwnet
Member since:
2006-11-12

To what extent is battery life affected by these apps written using the tools from Mono or Adobe? I wonder if ensuring optimum battery life might be another reason for this?

Reply Score: 1

RE: Battery
by fatjoe on Fri 9th Apr 2010 09:34 UTC in reply to "Battery"
fatjoe Member since:
2010-01-12

Bullshit,

MonoTouch is not JIT, it is compiled to ARM binary. Given the current state of ARM C compilers, and the inefficiency of ObjC message hub, and the built-in SIMD support of Mono, I think the mono approach is actually more effective.

Reply Score: 1

Unity3D
by fatjoe on Fri 9th Apr 2010 09:51 UTC
fatjoe
Member since:
2010-01-12

Here is a list of Unity3D games that will be thrown out:

http://unity3d.com/gallery/game-list/

[Unity3D compiles C# code directly to ARM assmbler using the MonoTouch suit, there is no JIT or abstraction layer].

Edited 2010-04-09 09:52 UTC

Reply Score: 1

RE: Unity3D
by Thom_Holwerda on Fri 9th Apr 2010 09:53 UTC in reply to "Unity3D"
Thom_Holwerda Member since:
2005-06-29

Wow WTF no more Colorbind? That is by far my favourite iPhone game!

Reply Score: 1

RE[2]: Unity3D
by fatjoe on Fri 9th Apr 2010 10:15 UTC in reply to "RE: Unity3D"
fatjoe Member since:
2010-01-12

And then you have "OMG Pirates!"...

Reply Score: 1

RE: Unity3D
by vivainio on Fri 9th Apr 2010 12:37 UTC in reply to "Unity3D"
vivainio Member since:
2008-12-26

Here is a list of Unity3D games that will be thrown out:


Sets a nice precedent, doesn't it?

Does anyone still pretend to be surprised?

Reply Score: 3

RE: Unity3D
by reduz on Fri 9th Apr 2010 15:49 UTC in reply to "Unity3D"
reduz Member since:
2006-02-25

As a game developer, this sucks. I hope Adobe and all game development studios push apple really hard for this. Imagine what would happen if Microsoft, Sony or Nintendo were to forbid cross platform code! It would be kind of like "Only exclusives allowed, sorry!"

Reply Score: 2

RE[2]: Unity3D
by mutantsushi on Fri 9th Apr 2010 17:50 UTC in reply to "RE: Unity3D"
mutantsushi Member since:
2006-08-18

Yes, game platforms are definitely the obvious comparison, and nobody could imagine their 'maintainers' (MS/Sony/Nintendo) would BAR developers from using whatever tool they want.

But seriously, Apple CAN'T equitably enforce this because they would be removing most of the most successful/impresive games on iPhone which they have been promoting alot. This is going to be the equivalent of New Orleans ordinance against 'manhandling a sandwich', BS laws that are only used against those who meet the unstated true category of public (private) enemy... just like "flying while arab". But who can develop under this regime where you don't really know when "the law" will be applied to you? (presumably they won't apply it to their own MacRuby project, but still)

Reply Score: 1

RE[3]: Unity3D
by reduz on Fri 9th Apr 2010 21:48 UTC in reply to "RE[2]: Unity3D"
reduz Member since:
2006-02-25

Yeah if you write your own code it's fine and Apple will not figure out what you are doing, but if you sell a product, you can't go around saying that although your product is illegal, Apple will not notice.

Reply Score: 2

RE[2]: Unity3D
by moondevil on Fri 9th Apr 2010 21:19 UTC in reply to "RE: Unity3D"
moondevil Member since:
2005-07-08

Funny. That is exactly how the games industry works.

Many publishers do require exclusive content in a specific console.

Reply Score: 2

RE[3]: Unity3D
by mutantsushi on Sat 10th Apr 2010 00:57 UTC in reply to "RE[2]: Unity3D"
mutantsushi Member since:
2006-08-18

moondevil wrote: "Funny. That is exactly how the games industry works.
Many publishers do require exclusive content in a specific console."


What?
Yes, console makers promote exclusive titles.
Every single maker does ALLOW cross-platform titles, though.

Edited 2010-04-10 01:01 UTC

Reply Score: 1

RE[4]: Unity3D
by JAlexoid on Mon 12th Apr 2010 21:01 UTC in reply to "RE[3]: Unity3D"
JAlexoid Member since:
2009-05-19

Console makers not only promote exclusive titles, but support successful exclusive titles.

Reply Score: 2

RE: Unity3D
by JAlexoid on Mon 12th Apr 2010 20:58 UTC in reply to "Unity3D"
JAlexoid Member since:
2009-05-19

Yep, this is a direct hit at people like Unity3D. Since Unity3D are actually making a system to develop games for a lot of devices at once. And that is exactly what Steve wants.

Reply Score: 2

Monopolistic practice
by siki_miki on Fri 9th Apr 2010 12:45 UTC
siki_miki
Member since:
2006-01-17

This move shows that Apple is very afraid of Android, WinMo7 and Blackberry app markets. It's a full blown platform war for world dominance (also a disaster for Adobe). But the move (revoking some memories of evil Microsoft) can be dealt with.

First, you need to write applications in C/C++ or even Obj-C.

Keep all platform interfaces encased with ifdefs. By using a text preprocessor, you can strip suspecting ifdefs before submitting to Apple.

Of course, one also needs something to translate to language (or VM bytecode) used by other platforms. This is the hard part as iPhone's apps use native language, so it won't work with some features of C/C++/Obj-C. I wouldn't be surprised if Google is already working on something like this. Yes, it requires extra work to do your app this way instead of using cross-platform libs, but it's worth it if you manage to support iPhone+ other platforms while competition can't.

If in any scenario Apple starts to loose the mobile platform war, this will loose them many developers and they will have to revert the decision.

Reply Score: 3

RE: Monopolistic practice
by mutantsushi on Fri 9th Apr 2010 17:44 UTC in reply to "Monopolistic practice"
mutantsushi Member since:
2006-08-18

This is the totally absurd part, because as you point out the language restriction really does almost nothing to prevent cross-platform programming, it is just penalizing LANGUAGES which may be easier to program with, even for SOLELY Cocoa-focused apps (e.g. using MacRuby, Haskell, etc).

I think what Apple wants is for people to be targetting it's libraries, rather than using 'converters' like Adobe is promoting which just reconstruct designs to fit Apple's libraries rather than target them from the get-go, but they're really taking a shot-gun approach here by banning people using alternative langauges who may very well be directly designing with Cocoa in mind. (Not to downplay the fascism of restricting non-Apple libraries in the first place)

Not to mention that nobody can seriously expect them to consistently implement this, given OpenGL game engines and their own MacRuby project(!).

Seriously, the platform I see with the most promise at this point besides OSXTouch is MeeGo using... C++ and QTScript (Javascript). So this move is effectively going to help MeeGo by making MeeGo the only platform with language compatability with Apple's licence...

Reply Score: 2

Even ballmer got it...
by bryanv on Fri 9th Apr 2010 13:50 UTC
bryanv
Member since:
2005-08-26

Developers Developers Developers Developers....


Apple just keeps on pissing off it's 3rd party Developers.


Folks, it's not worth playing in Apples walled garden. Just walk away.

Reply Score: 6

RE: Even ballmer got it...
by qbast on Fri 9th Apr 2010 22:16 UTC in reply to "Even ballmer got it..."
qbast Member since:
2010-02-08

You don't get it, it is all for developers. It is just iPhone devs are about most masochist bunch out there so if Apple does not bend them over every now and then they feel neglected.

Reply Score: 2

RE[2]: Even ballmer got it...
by vivainio on Sat 10th Apr 2010 07:14 UTC in reply to "RE: Even ballmer got it..."
vivainio Member since:
2008-12-26

You don't get it, it is all for developers. It is just iPhone devs are about most masochist bunch out there so if Apple does not bend them over every now and then they feel neglected.


Funny related article:

http://blog.kischuk.com/2010/04/09/apple-and-iphone-developers-caug...

Reply Score: 2

How would they tell?
by FunkyELF on Fri 9th Apr 2010 19:08 UTC
FunkyELF
Member since:
2006-07-26

How can they even tell? When you put something in the app store (which is a feat all its own) you don't give them the sources do you? You just give them a binary.

I guess they could look for certain known symbols left by known cross-compilers.

Time for these cross-compilers to use randomization and obfuscation.... how would Apple be able to tell?

Reply Score: 2

RE: How would they tell?
by umccullough on Fri 9th Apr 2010 20:21 UTC in reply to "How would they tell?"
umccullough Member since:
2006-01-26

How can they even tell? When you put something in the app store (which is a feat all its own) you don't give them the sources do you?


It would at least immediately hurt any open source apps that are ported.

But more than anything, it sends a message to the devs. If they suspect your app is "translated", expect to get a denial letter. And you'll probably be required to prove otherwise if it wasn't - guilty until proven innocent.

Reply Score: 2

RE: How would they tell?
by moondevil on Fri 9th Apr 2010 21:12 UTC in reply to "How would they tell?"
moondevil Member since:
2005-07-08

By requiring access to the original source code?

Reply Score: 2

RE: How would they tell?
by whartung on Fri 9th Apr 2010 21:31 UTC in reply to "How would they tell?"
whartung Member since:
2005-07-06

How can they even tell?


Time for these cross-compilers to use randomization and obfuscation.... how would Apple be able to tell?


Right, because, you know, actually abiding by their limitations that you agreed to when you signed up to be a developer, that doesn't mean anything. Just your virtual "name" on a "piece of paper". Obviously, that's not worth much.

There's certainly no expectation by Apple that the developers actually, you know, follow through on what they've agreed to in order to join the program.

But any cross platform process, with any reasonably wide distribution, will have identifiable markers in the resulting code. That's a feature of their design, the regularity of it, the abstractions they provide. They may have issues detecting a one-off, in-house framework, but anything else will be obvious.

And what you don't seem to appreciate is that by stipulating this, there simply won't BE any frameworks made for the iPhone OS. There's not profit in it for the makers, and the customer simply won't risk investing in them.

The price of being "caught", using whatever mechanism, is simply too high -- the Apple ban hammer of not just this app, but potentially all of your apps from the App store.

This clause kills existing frameworks dead, and stops development on any potential tool sets. Anyone serious about the platform simply won't use them.

Reply Score: 2

RE[2]: How would they tell?
by Thom_Holwerda on Fri 9th Apr 2010 23:26 UTC in reply to "RE: How would they tell?"
Thom_Holwerda Member since:
2005-06-29

Right, because, you know, actually abiding by their limitations that you agreed to when you signed up to be a developer, that doesn't mean anything. Just your virtual "name" on a "piece of paper". Obviously, that's not worth much.


Err, these developers agreed to a different agreement. This is a NEW limitation.

Reply Score: 1

RE[3]: How would they tell?
by mutantsushi on Fri 9th Apr 2010 23:31 UTC in reply to "RE[2]: How would they tell?"
mutantsushi Member since:
2006-08-18

No Thom, you must acknowledge and RESPECT the fact that Apple can require developers to get an Apple tattoo on their left butt cheek and become fruit-a-tarians if they want to continue in their lovely freely-amended-at-Apple's-will licence to sell Apps for Apple's "There's an App for that" iPhone/iPad. What? Are you against good-right-kapitalism? Do you doubt the second coming of Jobs?

Reply Score: 1

RE[3]: How would they tell?
by whartung on Sat 10th Apr 2010 00:06 UTC in reply to "RE[2]: How would they tell?"
whartung Member since:
2005-07-06


Err, these developers agreed to a different agreement. This is a NEW limitation.


You're right, it is a new limitation.

In theory, if you've accepted the agreement for 3.x, and you're not developing against the 4.x SDK, then you're not under this obligation.

But then, by the same note, there's no reason to hide the fact either, is there?

When Apple stops accepting 3.x apps in the app store, your existing, in-the-app-store app will likely be grandfathered in. It's not been suggested or confirmed yet that the new limitation is retroactive. Could be, probably isn't, but could be.

Afterwards, when Apple is accepting only 4.x apps in the app store, you'll be obliged to use the new agreement.

Of course, there'll be no reason for subterfuge then either, being as the agreement was accepted with good will and full knowledge of the new limitation, right?

Reply Score: 2

Ad blocking too....
by alcibiades on Fri 9th Apr 2010 20:46 UTC
alcibiades
Member since:
2005-10-12

Of course, when you control the apps, you control the browser, and you control the plugins, and so when you introduce iAds, well, you can stop the bastards, sorry I meant the customers, you can stop those very valuable members of the community, from installing plug-ins to block the ads.

This, folks, is going to be great. Now you can go to people who want to buy your ad space, and you have an unbeatable value proposition: forced watching. They will have no choice. They will watch them ads. Nothing they can do about it. No apps which let them do anything about it will be allowed. Its a total end to ad blocking! Its the greatest thing since ads were invented.

No mute button either. No app will be allowed to have one. Be as loud as you want.

Or they can buy another phone, of course....

Reply Score: 3

Comment by cefarix
by cefarix on Fri 9th Apr 2010 23:20 UTC
cefarix
Member since:
2006-03-18

W.T.F.

Reply Score: 1

Fun
by ArcadeFX on Sat 10th Apr 2010 12:26 UTC
ArcadeFX
Member since:
2005-07-06

It should not affect people who build C/C++ and Objective-C based APIs. Same routines and target multiple platforms (mobile to desktop OSes). Unless Apple decides to ban C/C++ functions then those people are good. The routines call Apple's Native routines in Objective-C and are compiled with X-Code (api layers).

That means developers can develop in Visual Studio, X-Code, GNU/C++, Java, etc. Yes the developer needs to know the language, but they use the API Layer routines to handle things. If you write your routines, classes etc based on the API Layer it works great.

They just don't want you to code in Java, Flash, C# and then with a Magic Wand translate to iPhone.

Reply Score: 1

RE: Fun
by whartung on Sat 10th Apr 2010 15:59 UTC in reply to "Fun"
whartung Member since:
2005-07-06

It should not affect people who build C/C++ and Objective-C based APIs. Same routines and target multiple platforms (mobile to desktop OSes). Unless Apple decides to ban C/C++ functions then those people are good. The routines call Apple's Native routines in Objective-C and are compiled with X-Code (api layers).


That's specifically what they don't want. The entire point of this clause is to eliminate eliminate "cross platform" code from running on the iPhone. The only code that can legitimately port to the iPhone is Mac OS code, and perhaps GNUStep code.

They don't want QT, or VC++, or anything else running on the iPhone. They don't want people write to compatibility layers. They want folks writing to the iPhone SDK. They don't want someone writing "new XYZButton" which then calls the appropriate "new iPhoneButton". If you want a new iPhone button, subclass iPhoneButton or whatever.

If your code is not targeting the iPhone as its primary UI library and toolkit, i.e. it's targeting something else, some other system, or some shim x-platform library, then it's disallowed.

Reply Score: 2

RE[2]: Fun
by mutantsushi on Sat 10th Apr 2010 18:12 UTC in reply to "RE: Fun"
mutantsushi Member since:
2006-08-18

Excepting that the new policy kind of does a shitty job of barring QT, as long as you write with C/C++/Javascript.

Once again, people are making the mistake of equating different languages with different APIs and translating to fit Cocoa. Look up MonoTouch. Look up Wax. You can target Cocoa and only Cocoa just fine, with the exact same degree of native platform awareness as Obj-C, using other languages. What is the problem if a developer wants to use libraries of pre-made extensions onto Cocoa?

I am not waiting for Apple to be nice though. I am waiting for them to get a letter from EU competition commissioner or US anti-trust agency.

Reply Score: 1

RE[3]: Fun
by JAlexoid on Mon 12th Apr 2010 21:33 UTC in reply to "RE[2]: Fun"
JAlexoid Member since:
2009-05-19

I am not waiting for Apple to be nice though. I am waiting for them to get a letter from EU competition commissioner or US anti-trust agency.

Based on what? For having only 25% of US smartphone market or 15% of worldwide market? Microsoft got smacked for having over 90% of market, no mere 25%.
And even though they are the dominant player in the PMP market, iPod Touch is not the major product in that category.

Reply Score: 2

Good times
by rebus on Sat 10th Apr 2010 16:23 UTC
rebus
Member since:
2009-10-25

In a few years iPhone OS will go Open Source, but it will be the move of a desperate, like it was with Nokia and Symbian.

Reply Score: 1

Microsoft does the same thing for XBox
by mnem0 on Sat 10th Apr 2010 21:00 UTC
mnem0
Member since:
2006-03-23

Apple added the "original source language" clause because they want devs to write in Objective-C rather than Flash or other cross-platform languages. They do this because they want as many apps as possible to be iPhone exclusive apps.

Microsoft is just as closed down. They do the _EXACT_ same thing for the XBox:
http://www.diygamer.com/2010/04/report-machinarium-refused-xbla/

Reply Score: 1

moondevil Member since:
2005-07-08

Where is this the same thing? Only through your Apple pink glasses!

Microsoft, like any other publisher in the games industry has the right to decide which games they want to publish on their platform. This is a rule well known in the games industry and happens all the time.

What Apple is doing on the other hand, is completely different! They are changing the rules in the middle of the game, about which languages you are allowed to use for their platform.

Edit: corrected a typo

Edited 2010-04-11 15:35 UTC

Reply Score: 2

mutantsushi Member since:
2006-08-18

Right, if you read the comments on that link you find out that XBLA in fact has tons of non-exclusive games, MS just doesn't want to publish (i.e. promote) games that are not exclusives, which makes sense - that doesn't stop other from doing so. Not to mention the normal (DVD-based) games where non-exclusive titles make up a huge proportion, and which are the gaming experience people usually think about first with platforms like XBox, PS3. Last I heard, Apple is not signing a promotional contract for every App in the AppStore, that's up to the developer.

Also notice that Microsoft doesn't care what programming language or tools you use for your game.

Edited 2010-04-12 18:45 UTC

Reply Score: 1

JAlexoid Member since:
2009-05-19

Right, if you read the comments on that link you find out that XBLA in fact has tons of non-exclusive games, MS just doesn't want to publish (i.e. promote) games that are not exclusives, which makes sense - that doesn't stop other from doing so. Not to mention the normal (DVD-based) games where non-exclusive titles make up a huge proportion, and which are the gaming experience people usually think about first with platforms like XBox, PS3. Last I heard, Apple is not signing a promotional contract for every App in the AppStore, that's up to the developer.

Also notice that Microsoft doesn't care what programming language or tools you use for your game.


I hate MS for all the wrong and right reasons, but I have to agree with you. XBLA is not the ONLY distribution channel for XBox, but AppStore is the only distribution channel(The one that was so hailed as the most wonderful thing that iPhone has).

Edited 2010-04-12 21:38 UTC

Reply Score: 2

I wonder if Qt is OK?
by Moochman on Sat 10th Apr 2010 22:34 UTC
Moochman
Member since:
2005-07-06

Qt seems like it might be safe, since it's C++... Now they just need to make it happen.

Reply Score: 2

Apple's method
by DigitalAxis on Sun 11th Apr 2010 05:34 UTC
DigitalAxis
Member since:
2005-08-28

Apple's iPhone policies seem pretty consistent to me.

You will develop for us, and only us. You will do so in the manner we specify, and you will only develop the programs we allow you to. Should your programs be of value, we will pay you, though you must never forget you create at our pleasure. You shall never speak of this agreement.

Edited 2010-04-11 05:36 UTC

Reply Score: 2