Native UIKit iPhone Apps Written In Lua

http://www.mobileorchard.com/announcing-iphone-wax-native-uikit-iphone-apps-written-in-lua/

by mobileorchard • 17 years ago

34 30 17 years ago

mml• 17 years ago

woo!

spicyj• 17 years ago

I find the automatic garbage collection particularly impressive, but I wonder how it affects performance: Apple could have included the ability to use Objective-C 2.0's GC on the iPhone, but they didn't.

alttab• 17 years ago

That may have been a good thing.

In some cases, stacking two layers with conflicting policies could thrash from caching/garbage collection logic.

This is at least the argument of most full stack proprietary formats.

tumult5• 17 years ago

Actually, it's often not performance that's the problem like you might be thinking. Some apps, for example, actually become faster with Obj-C 2.0 GC enabled, since all of the retain/release message sends become noops. (Some will be slower, too, of course.)

What you do definitely lose is easy predictability of memory usage. Memory usage can spike when you don't anticipate it. On a desktop this is no problem, since you have a ton of memory to work with, and if you do use too much, it just swaps to disk. On iPhone, if you exhaust the memory, the phone reboots. Oops.

But I don't think GC is too far off for iPhone.

daeken3• 17 years ago

This seems to violate clause 3.3.2 in the iPhone SDK agreement, since it embeds an interpreter. That said, Apple's already accepted one app using it, so it was either ignored or in line with their intentions (even if not the wording).

Regardless, very cool. Saves me writing my own faux-VM for a project I'm working on. I'd intended to compile code to Obj-C and build everything on that, but this will save me a whole lot of time.

jawngee• 17 years ago

Wouldn't it save you a whole lot of time to do it in Obj-C in the first place?

daeken3• 17 years ago

The code is being compiled from Actionscript bytecode as part of a larger project. Although I'd planned to compile it to straight Obj-C, I'd still need garbage collection and AS-type (ECMAScript) objects.

mbrubeck2• 17 years ago

EDIT: This is wrong now; see below.

The SDK agreement seems (both in letter and intention) to be forbidding apps from downloading code that is run by a custom interpreter. It does not prevent an app from interpreting code that is part of the app itself.

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

daeken3• 17 years ago

That was my understanding as well, but the very latest iPhone SDK document says "downloaded or used" instead of 'and'.

yason• 17 years ago

I wonder if iPhone's browser does XML and XSLT, like all modern browsers do?

It happens that XSLT is Turing complete, and the browser can certainly download stuff from teh internet. This could mean that merely embedding the browser into your iPhone app effectively turns it into an interpreter for programs downloaded from anywhere. Sure it's sandboxed but technically that shouldn't matter. And I'm sure you could introduce hooks to the browser from native side, to make something interesting out of it.

cesare5• 17 years ago

The iPhone APIs are written in Objective-C (some are just plain C) which is a nice language with nice and interesting features. If you have to deal with these APIs anyway, using another language wouldn't change much. You will have to create objects in the same way, send them messages in the same way, implement the same callbacks etc. Code is not much terser or easier to write with these bridges since you're not abstracting much, if anything.

Performance will be affected, heavily, since you're running everything on top of an interpreted language (with garbage collection) which then must call the equivalent Objective-C function, for every single line of code.

Moreover, I don't believe that any of these wrappers (for Lua or any other scripting language) will ever cover all the APIs available on the SDK. So, what happens when I need to call one of these? What if I need to use some other library written in c, or c++? And what if I've use this code to write some apps, the projects stops being maintained and the API changes with a new release of the OS?

What does make sense instead, is to use a language like Lua as it is intended, embedding it in your app and writing only the interfaces for the parts that should interact with it. For instance, if you're writing a game, it would make sense to embed Lua to code the game logic (which would be completely independent from the iPhone specific stuff).

Just my two cents.

tumult5• 17 years ago

Check out MacRuby and some of the Obj-C bridges for other languages (MacRuby isn't bridged though), you'll be pleasantly surprised.

You still start out with the same set of classes and methods as in Cocoa+Obj-C, but how you abstract on top of it can be radically influenced by the language you're using.

Lexical scoping with real anonymous functions, for example, is a huge win. It catches Obj-C up to the 70s, at least :)

cesare5• 17 years ago

Yes, MacRuby is something slightly different.

Still, I would suggest people who are seriously interested in developing for the iPhone to check if plain Objective-C works for them, first.

My recipe is:

- Objective-C for the minimum necessary to deal with the iPhone specific APIs.

- plain C for critical parts which need to be optimized for speed and memory consumption.

- your favorite embeddable language implementation (mine at the moment is TinyScheme, but I've also used Lua) for scripting.

Also, consider that often you may need to include libraries written in c or c++. This is trivial to do from Objective-C.

davidw5• 17 years ago

My own language, Hecl, is written in Java, is no way as fast as the C version of Lua, and yet it provides acceptable speeds for apps on phones that are slower than the iPhone. Just don't try and write an action game in Hecl - save it for the configuration and level descriptions or something. So I don't think that speed is an issue for most applications; Lua is plenty fast.

I'm not 100% sure, but my experience has been that scripting languages are more compact in terms of code:

http://shootout.alioth.debian.org/u32/benchmark.php?test=all...

In terms of the API, well, that depends entirely on the project and their goals! A small, decent team of open source developers could probably cover most of the API in less than a year without particularly working that hard on it.

The real problem here is that interpreters for the iPhone seem to be a gray area at best (see discussion elsewhere here).

Anyway, looks like good work, and I think interpreters on phones are a great idea:-)

cesare5• 17 years ago

> I'm not 100% sure, but my experience has been that scripting languages are more compact in terms of code:

This is obvious. That's what they are for. But on the iPhone the tedious stuff is dealing with the APIs. And you would not gain much just by wrapping them with another language.

> The real problem here is that interpreters for the iPhone seem to be a gray area at best (see discussion elsewhere here).

As I have stated many times in other threads, there are apps (published on the Appstore) written with squeak smalltalk, games made with Unity (which uses javascript on top of Mono for scripting the game logic) etc.

What you can't do is to expose the interpreter to the user or to make it run code downloaded from the web.

Even if this wasn't the case, how could Apple even know, for instance, that I have statically compiled the Lua interpreter and used it to script part of the logic of my app?

allenbrunson• 17 years ago

I have never heard of or seen any iPhone APIs written in C++, although some of the low-level stuff is in C. It's possible to include your own C++ code, but I really don't think Apple has any of their own. Have you got an example?

cesare5• 17 years ago

Sorry, I meant 'C'. I've edited the comment.

Anyway, IIRC there's still some C++ somewhere (some parts of Core Audio, for instance) and some sample code from Apple itself also uses C++ here and there.

antirez• 17 years ago

Great point. The problem of developing iPhone applications is that the API sucks. Let me say this again: the iPhone API is not good at all, it is a crude example of how try to be veryCoherentAndOrtogonal: is not enough. A good API is a matter of design, any amount of MVC can't change this fact.

What hurts me is that the limits are neither of Objective-C. Ok you have to deal with 1980 reference counting, but there are high level data types such mutable arrays, maps, and so on. It's not hard to imagine an higher level interface using Objective-C.

My guess is that what deserves to be tried is to build an higher level API on top of an higher level language, so you can write:

createUITable(0,0,400,300,lambda {|section,index| .... })

Native UIKit iPhone Apps Written In Lua

Related Stories