lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

At LogicNets, we have a fairly large Lua application which we have ported to run on both iOS and Android in a fashion similar to what you have described.

1. For details on getting Lua to run on iOS, take a look at my iLua project ( It's a little bit of a work in progress, but it should get you pointed in the right direction.

2. For Android, doing it from scratch isn't too bad, but you'll almost certainly instead want to use something like LuaJava (, AndroLua (, or LuaJ ( For our application, we used LuaJava (although we had to do some customization---for reasons not worth discussing here, we are still using Lua 4). Note that we did the Android port almost a year ago when Eclipse was still more or less the preferred IDE for doing Android work.

These days you should consider Android Studio instead. However, although in theory it supports the native development kit (NDK---the ability to compile C code, which you will need), my initial (limited) attempt at getting it to work was unsuccessful.

I'll just throw out that there are a few alternatives for doing cross-platform Lua. For example, Corona ( which you might also want to look at.

3. An important note about application architecture: for both platforms (Android and iOS), we have a native app that works as follows:

1. Does some initial setup and configuration
2. Starts a background thread has a Lua VM. This VM runs a simple web server we've written in Lua. 3. On the main thread presents a webview component (WKWebView on iOS, android.webkit.WebView on Android). This webview is told to load a URL from localhost.


On Android it is possible to do something like what you suggest: run your application in the background and have the user use a browser to interact with it. When your app launches it could create and run a service ( and not present any sort of UI.

I don't think you want to go that route. I think it's too awkward and confusing for the user. If you instead use an approach like we took, you will present the user a more unified experience which she has better control of.


On iOS you can't take the approach you described. You have to do something like we did because you can't have long-running background apps. Yes, I know all about foreground and background apps on iOS. But none of the mechanisms you can use for doing background processing will allow you to run a web server that doesn't get terminated pretty quickly. Note that running an app in the background is not the same as having a background thread running in your foreground app (I'm tired and not explaining this well).

Anyway, let me know if you have more questions.



Matthew M. Burke