What??? What??? Mac Codea??

@toffer, Here you go. The video link is a few posts down.

@Jordan I don’t think we need a Codea IDE for the Mac. XCode is just fine for app development.

Right now, you can export a project from Codea, edit the Lua files on the Mac, and run projects in the emulator. That actually works very well, and the process is pretty simple. What I’d like to see is basically just the runtime and some project templates for XCode, so writing a Lua app for the Mac would be no different than writing an Object-C app.

Ideally, you would be able to start XCode, and see templates for “Codea game for Mac”, “Codea app for Mac”, “Codea game for iOS”, and “Codea app for iOS” in the new project window. You just select one of those and get to coding.

If you want to port your app to mobile (or from mobile to desktop), you could just start a new project and copy the source files.

As to the differences between apps and games: apps should allow for multiple frame buffers, switchable via setContext(), and we need an API to create and move windows. I don’t think we need bindings to the native UI library: in fact, I’d rather not see that. That way Codea could be more easily ported to Windows, Android, and Linux. By keeping the API simple, you have less stuff to implement on each OS.

@tomxp411: Bingo. IMO “Codea for Mac” should really just be the Codea API we all know and love, coupled with some sort of build/configuration/asset pipeline utility. Those of us who already code on our PCs/Macs already have our preferred code editors/IDEs (hint: mine is not XCode), so there is no need to reinvent the wheel there. As for including bindings for native UI controls…I’ve never been a fan of that idea anyway. Some people might not want to hear it, but Codea was not meant to be a UI toolkit. It’s strength lies in it’s easy access to low level graphics functionality, with a focus on simplicity, prototyping, and learning, and I feel like that’s where the effort should continue to be spent.

Though business applications might not be the first thing most Codea users tackle, I find Codea extremely suitable for doing my day to day work, with the two exceptions being the lack of the standard UI controls and access to the GPS data. It’s that lack of access to the standard bits that caused me to write Cider, and it’s precisely Codea’s ease of prototyping that makes it such a powerful tool for writing business apps.

After all, most in-house apps aren’t written to bang the metal and crack the 60fps barrier, they’re just there to serve some specific purpose for a small group of people. I find Codea + Cider excellent for sitting down and making a little interface, and usually by the end of the day I can have an app on someone’s iPad (or iPhone) that collects some little bit of data, or relects some messages from a service on the company network.

If I was writing these same apps for a general audience, I’d probably look to another IDE, but I’m not. Really, just those two things (UI bits + GPS) would save me ever trying to remember the arcane syntax of Objective C again.

@Mark however, I think Codea is the perfect tool for writing simple business tools. We just need the UI elements to make that happen, so we’re spending our time on business logic, rather than UI code.

I need to run my (non-game) projects on all three platforms. While I agree the IDE itself is an already solved problem on the desktops, the runtime library is not. I am having some success moving between Codea and Love2D, but only because I am not using 3D or physics. And it takes iExplore’s ability to mount the iPad as a drive so I can run scripts to manage the moves, as a simple drag’n’drop does not do the needed fix-up maps. A true native Codea runtime with its UI widgets, that can be invoked from the IDE (XCode or ZeroBrane), would help this immensely.

@dwarman - While those are good suggestions, keep in mind, there are only 2 people developing Codea. Along with that, Codea is a game engine made for prototyping (originally). Simeon has looked into building a UI API, but the demand of features in an API like that is enormous, and would take an extensive amount of time to make.
That being said, it is easily possible to have the OpenGL Codea frame as simply part of an app. If you look at the available functions in the runtime, it was even designed for something like this.