“In particular, we are relaxing all restrictions on the development tools used to create iOS apps, as long as the resulting apps do not download any code. This should give developers the flexibility they want, while preserving the security we need.”

So any tool or language, Scheme included, is fair game now. Let’s code!

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs.

to

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).

The intended effect is obviously to ban third-party abstraction layers, like then soon-to-be-released Adobe’s Flash for iPhone. But the wording is very broad and cover too many uses of other programming languages and technologies. Steve Jobs demoed himself the Tap Tap Revenge game for iPhone, which reportedly uses Lua. The backslash was too big to ignore, making Apple revise the agreement again. This time section 3.3.2 was changed from

3.3.2 – 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).

to

3.3.2 – Unless otherwise approved by Apple in writing, 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). Notwithstanding the foregoing, with Apple’s prior written consent, an Application may use embedded interpreted code in a limited way if such use is solely for providing minor features or functionality that are consistent with the intended and advertised purpose of the Application.

Although still requiring Apple’s prior written approval, it leaves the door open for the use of other programming languages on iOS devices. Apple Outsider believes this is all about Lua, and he may be right. But of course Lua is not the only game in town.

I always thought my use of Scheme in Reverso was ok with the previous version of the license agreement. No code is ever downloaded, and not interpreted either; Gambit-C compiles Scheme code to C which is compiled with Apple’s official tools to create a native library. But this changed with the new 3.3.1 section because my code was not originally written in one of the approved languages. James Long, who first compiled Gambit-C for the iPhone, claimed that Scheme was dead on the iPhone. But then Apple relented and changed section 3.3.2. What about now?

I believe that makes Scheme usable again, if used just like in Reverso: as a library. The application is written in Objective-C, but uses Scheme code (compiled to C) to only add features “that are consistent with the intended and advertised purpose of the Application”. Albeit it can be claimed that the code is not interpreted, this use follows the spirit of the law, even if it does not follow its letter.

I believe I have got the first Scheme application past Apple review into the iTunes App Store. It is yet another Reversi clone, called Reverso. It is a combination of 90% Scheme and 10% Objective-C, written with Gambit-C Scheme. James Long has already shown how to compile Gambit-C for the iPhone, and I started from there. My Scheme code is compiled to C by Gambit and later by GCC to produce native ARM code, bundled in a static library, which is ok with the iPhone SDK license agreement. The Objective-C then calls the library as a pure C library. The Scheme code deals with position evaluation, alpha-beta pruning, transposition tables, move legality, different strategies and so on. The Objective-C code deals with sound, animations, GUI, user preferences, basically everything that calls the iPhone OS API. Reversi was chosen because I like strategy games and it is much more algorithmic than artistic, and I am no artist.

The performance of the code is excellent. I used some Gambit-specific declarations, only fixnum arithmetic, pre-allocated a large heap, and called the garbage-collector every time the user needed to think. The search is not memory intensive, but the transposition tables are. I did not write a specific hash function but relied on Gambit-C’s table type. The boards used during search were retrieved from a pool (the newest Gambit-C has made subu8vector-move! a public API), so they did not put pressure on the garbage-collector. In the end it was a very successful experiment. Developing with Scheme is orders of magnitude more productive than with most other languages. Gambit-C is also one of the best Scheme compilers out there, and made my job a lot easier.

Update: There was a bug in the application that caused it to play poorly. The weak AI was not Gambit’s or Scheme’s fault, but mine. I already sent an updated version to Apple that will play much better. Besides fixing the bug, I am now using Zobrist’s hashing instead of Gambit’s own hash function, that performs poorly for game positions. It is still written in Scheme, though. Now I am waiting for the approval of the update, and to hear further feedback from my users.