First off, I’m just talkin’ here. We won’t know anything directly until Ansca says one way or the other, but I wanted to present a scenario which would, I believe, be a solution should Apple say no to the way things are currently done.
From all I’ve read, it looks like Apple is trying to shut down the idea of a “cross-platform/language-toolkit”. They want all their apps to be written specifically for the iPhone because then the cost to be supported on other phones will be very high to developers. Why? This forces developers to “lock-in” to the iPhone (due to the cost of re-engineering on multiple platforms, debugging on multiple platforms, etc) and the direct result is a set of Apps which are only available on the iPhone. This strategy really only works as long as you are the number one smartphone… but… when a developer can create an App for 3 or 4 other platforms by writing it using an SDK like Corona, suddenly it’s not a question of whether or not the iPhone is the number one smartphone, but whether or not it maintains the market share against positions 2, 3, 4, etc. *That* is the pitfall they are setting themselves up for and I sincerely hope they understand that. If they take this step, they’re going to piss off a not insignificant number of developers and they might just find out what happens when we can build for 4 other devices with one codebase and simply ignore the iPhone.
At any rate… here’s the bottom line question: If *I* were to take the lua source code, compile it under my XCode iPhone project, and create strings of lua inside my own obj-c files, call the lua engine with those strings… am I legal under the TOS? I believe the answer to that question is absolutely 100% yes. This is no different than using XML or my own home-grown macro language. It’s no different than creating a library of utilities that creates and manipulates the UI. It really isn’t.
Take that a step further and now I’ve created my own library under the XCode iPhone project system which encapsulates the lua engine. Now I can reuse that library with all of my iPhone apps. This is *no* different than using a gzip or xml library. Following the same idea of encapsulating my lua inside of my obj-c files in my iPhone app, I’m still 100% in the clear. Why? Well “var = display.newText(…)” is absolutely no different than making a call to a class I write which does the same thing as display.newText does. There is no logical distinction. Take that a step further, it’s no different than calling a compression routine in the gzip library. Someone else wrote that, but I’m using it.
Now I’ll step back and say this: There are plenty of times where I have, in the course of designing projects, used any number of rapid-prototyping systems to create my application and then the final step has been compiling for my release binary.
In the iPhoneOS 4.0 world, I would suggest that *one* way (if necessary) to comply with Apple is for Ansca to release a library we can link to and have the simulator (as-is) that we can prototype with. The final piece of the puzzle is a standard template that is generated which allows us to open up the project in XCode and build our App. Even if there’s no template generated and I have to create the new XCode project myself, then set up the library for linking, and incorporate the lua into my own obj-c files (this could be easily done by using gzip to create a string that is stored in an obj-c file)… even if I have to do all that, it’s still far less work than using Apple’s development path.
Yes, it would require some more work on our part for the final step and would likely make some folks who don’t have the expertise simply punt on the whole thing, but I would guess that most of us could accomplish this final step without much trouble.
Thanks for a great product, Ansca. I hope everything works out!
Scott [import]uid: 5659 topic_id: 762 reply_id: 1560[/import]
