This is a bit depressing. Especially with all your effort to get it working.

One, perhaps ignorant, question. How will they know which compiler you used? Will they really inspect every app?

Henry

http://ik.homelinux.org/

It's very easy to know what compiler was made to compile something. Every compile create different symbols and code structure to the binary. I can tell you in "naked eye" by viewing the binary content of a file, what was the compiler that created that code.
And if you add that the compiler banner, then even simple "strings" command in linux can provide you the answer :)

Ido

Yes, I forgot about `strings`. What about encrypted binaries? Perhaps they will just refuse them, too.

Henry

Henry Vermaak wrote

One, perhaps ignorant, question. How will they know which compiler you used? Will they really inspect every app?

They presumably already use an automated scanner app to check whether you only use published API's (manually checking millions of apps for that is simply infeasible, not to mention stupid). In that utility they can either check for some signature code that their compilers generate, or per identified other compiler/framework add a check for signature code/data generated by that compiler/framework.

Jonas

So then I guess fpc can fake it? The whole thing just seems so absurd.

Henry

In our previous episode, Henry Vermaak said:

That amounts to a constant cat-and-mouse game, requiring vast resources.

Jonas: what are your plans regarding this? Formally (e.g. on the FPC website) publish the end of IPhone support? (starting with 4.0 at least?)

It would most probably result in a cease-and-desist letter from Apple's lawyers.

Jonas: what are your plans regarding this?

None.

Jonas

If we look at C or Objective-C from a different view, then such a language could be just another compiler 'target' - how difficult would it be to add a C/Obj-C target to fpc?

I assume all ordinary machine code can be expressed in C too. C compilers can be good at optimizations, so the overall performance could be still acceptable. And yes, it would be some sort of virtual machine, but it's still C code. And a call to a framework/the OS is just a C call again.

I remember there was some similar work on a Java-Bytecode-To-C generator, making it possible/legal to run Java on an iPhone....

Would such a solution be practical or would it always be 'academic games'?

--Alexander

Alexander Grau wrote

If we look at C or Objective-C from a different view, then such a language could be just another compiler 'target' - how difficult would it be to add a C/Obj-C target to fpc?

No, it specifically forbids this. Here's the text:

"Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine..."

Henry

Also:

"e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited"

But that doesn't make sense what they write - A C program can be written by hand and by a generator. It's still a C program. No difference from the outside view. ?!

Alexander Grau wrote

But that doesn't make sense what they write - A C program can be written by hand and by a generator. It's still a C program. No difference from the outside view. ?!

Exactly, it's absurd. The worst thing about this fiasco is that people aren't even surprised that this happened.

Henry Vermaak het geskryf:

The whole thing just seems so absurd.

Absolutely! It shouldn't be about the language used, but rather the integration and usage of the running application itself. Apple is totally bonkers!

With all their "forced usage requirements" (regarding Mac OS + hardware, iPhone etc) on end-users and developers, what is next? Code may only be typed on a Qwerty keyboard or only written by right-handed people???

Such crazy restrictions that Apple enforces on all it's products should simply not be allowed.

Regards,
- Graeme -

The whole point of the change to the SDK agreement is exactly to forbid doing that sort of stuff.

Jonas

In our previous episode, Henry Vermaak said:

For me the carbon deprecation, making it COCOA and thus primarily Objective C only was the writing on the wall. And not just for IPhone.

I think the real question is to what extent this is performed. Writing a an arithmetic parser in C code is already writing a small virtual machine. Writing a script parser in C is a virtual machine too. And writing a smart C code generator can look like a virtual machine program ... or it can look like an ordinary C program.

I think it depends on the intepretation of the concrete code and Apple's agreements are subject to this interpretation.

Alexander Grau wrote

I think it depends on the intepretation of the concrete code and Apple's agreements are subject to this interpretation.

Of course it is (since, as was mentioned on the mac-pascal list, virtually every programmer has a personal library that wraps APIs to some extent). However, given that they explicitly forbid languages other than those listed, translated code and wrapper languages, I think it's pretty clear that at least in spirit FPC is not allowed anymore.

Anyone is of course free to keep using FPC for the iPhone (I'm not going to remove any iPhone support from the compiler in the foreseeable future) and to submit FPC-compiled apps to the AppStore. Just don't be surprised if they get rejected or suddenly pulled later on.

Jonas

There's of course nothing from preventing anyone from distributing their own app. There's no reason you *have* to submit your app to the app store. Admittedly, it makes it more difficult if your app isn't in the store, but folks can still download and install such apps themselves.

Really? I was under the impression that you need to jail break the phone to be able to install any app (or get a dev licence, of course).

Henry

Henry Vermaak wrote

"Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine..."

FWIW, I've read some other comments in the mean time (on Apple's closed iPhone developer forms) from developers complaining about the fact that virtually every somewhat recent AAA game title contains scripting code in one form of another for various purposes (scripting non-playable characters, enemy behaviour, ...). So I guess that Apple will have to make this requirement somewhat less restrictive in any case.

Hence, it would be useful if enough people send in their FPC-related comments via http://developer.apple.com/contact/, so the reworded version could maybe take into account our situation as well.

Jonas

Henry Vermaak wrote

Really? I was under the impression that you need to jail break the phone to be able to install any app (or get a dev licence, of course).

I don't think you need to jail break anything to put apps on the phone that don't come from the store, what's preventing folks from just uploading the apps to their phones then executing them as normal? perhaps there's something I'm not aware of here, but the developer kit is free to anyone who has an ADC account, you merely need to register with apple to be able to download the developer kit and develop apps. I have the kit, but haven't written anything, mostly because I personally don't see the need to put out useless apps just for the purpose of having produced an iphone app.
Sure it gives you bragging rights, but bragging about a number guessing game doesn't sound to me to be all that interesting, yet that's exactly the kind of thing I've seen, and to be honest, it kind of makes me not want to develop apps.
But I guess you'll get that with anything, so I really shouldn't let it bother me I suppose.
But anyhow, my guess is that apple just wants to ensure that all apps they promote are apps that are completely compatible with the iphone. It seems to me that if folks can demonstrate that fpc apps *are* 100 percent compatible, then apple will allow them as well. The whole reason for dropping carbon support is because it isn't being maintained by apple themselves anymore, and they are (eventually) going to have apis that will break under carbon usage. Also, because of the accessibility features in apple's os, which a lot of people now depend on, the cocoa interfaces are automatically supported by these apis, where carbon apps had to make special efforts to make themselves accessible, and most developers did not take the time to do this, and as a result, many applications were inaccessible to folks who depended on the accessibility features of the os.
I actually applaud apple's efforts in this area (the accessibility stuff, not the dropping of api support), because I am one of those individuals who depend on the features that allow voiceover to operate out of the box on a huge percentage of osx apps right out of the box, which is something that cannot be said for any other operating system. I would love to write full-blown cocoa apps using fpc, but as of yet, I've had zero luck in doing so, either because the gui generation kits did not work at all, I couldn't get them installed, or they generated code that did not comply with apple gui accessibility guidelines, and as a result, produced apps that did not work with voiceover, which of course leaves me out. I'm still stuck using command-line apps when using fpc, though I have no trouble producing accessible apps when using the sfml libraries under C/C++.
Which, really is a shame, but that's what we have to work with. The mono framework (via renasaince) seems to work for some, but I've been unable to get it to work on my system, so I'm stuck using terminal apps if I want to use fpc.

I'll make sure I complain to apple about not allowing fpc apps though, as I see no reason why properly built fpc apps should be excluded. The reasoning is sound, but sometimes companies tend to carry things too far, and I think this is probably one of those times. <sigh>

Travis Siegel wrote

I don't think you need to jail break anything to put apps on the phone that don't come from the store, what's preventing folks from just uploading the apps to their phones then executing them as normal?

Apple's code signing process. An application must be code signed using a developer certificate for that particular iPod/iPhone/iPad for the OS to want to run the application on that particular device. You can create certificates for 100 different devices via Apple's website (so people have to send you their device ID and then you can create a certificate for that device), and then it's over for a year (the certificates are valid for a year, and you can only reset the list of devices for which you have created certificates once a year).

Jonas

Travis Siegel wrote

perhaps there's something I'm not aware of here, but the developer kit is free to anyone who has an ADC account, you merely need to register with apple to be able to download the developer kit and develop apps.

Getting the certificates required to code sign applications (the process required to be able to run them on an actual device rather than only in a simulator) costs $99/€79 per year.

Jonas

Jonas Maebe wrote

Hence, it would be useful if enough people send in their FPC-related comments via http://developer.apple.com/contact/, so the reworded version could maybe take into account our situation as well.

Even though I don't program for the iPhone, I did email Apple with my concerns about their absurd decision. I also mentioned that developers worked hard on FPC to get iPhone support.

Lets hope enough developers complain!

My suggestion is to henceforth call FPC as Free Progressive C without any other change.

Problem solved. It is C now. They must approve all apps developed with it.

1+

I think this clearly demonstrates what Apple really wanted with their agreement: you must use the same tools they use. When Apple decides to use a C compiler, you need to use *their* C compiler too. When Apple decides to go for the Cocoa framework, you need to use that Cocoa framework too. If in the future, Apple thinks they need a new language or a new compiler, you'll need to use that too.

They didn't (couldn't?) write it in their agreement, but I think that's what they actually mean ('Apps need to be written with our tools').

++ on that ;-)

Alexander Grau wrote

They didn't (couldn't?) write it in their agreement, but I think that's what they actually mean ('Apps need to be written with our tools').

I don't see why they wouldn't have written that in the agreement if that's indeed what they meant.

Jonas