Hi,
Is there a way to release Codea Apps on the AppStore without a Mac. I understand that there is the iOS developer programme that is required to release to the App Store, but I don’t have a Mac. What would be great if Codea were able to generate a fully packaged App that could be submitted directly to Apple for release on the App Store. Presumably it is a well documented series of steps that are required to turn a Codea App into an App that can be submitted, so surely the same steps could be achieved on an iPad/iPhone itself.
Alternatively, although not such a good option, would it be possible to provide a service on your website that Codea Apps could be submitted and some time later an App Store ready packaged is e-mailed back to the owner that they could then submit to Apple.
This option, I’m sure would propel Codea to a whole new level.
Thanks.
Phd.
That would be absolutely great! I am even ready to pay for that. Let’s say… 50€ for 1 app (a global price including several trial and errors).
I highly doubt you would be able to do that. There would probably be a lot of legal issues. 
I had a thought on this the other day. What If we created a little “cooperative” for Codea programmers that, for a flat fee, would ready an app for the store and act as publisher as far as Apple is concerned. But the rights to the app would stay with the creator(s)?
I think this would work.
@Phd, This would be absolutely fantastic In some sort of Utopia where benevolent Uncle Apple allows everyone to submit to the AppStore without restrictions and XCode has become as simple as MSWord. 
Humour aside, @veeeralp is probably right - I suspect there are some Apple Developer restrictions somewhere that means you can’t compile and publish apps without being a registered Apple Developer yourself and using the suite of Mac tools (XCode etc…) to generate your finished app.
It has been suggested that there are 3rd party Mac ‘Cloud’ based services such as www.macincloud.com that can allow you to work remotely (via a VPN) to rent time on a Mac - although I don’t know if anyone has tried this yet to develop Apps with Codea although this still requires you to be able to use XCode etc… I think you’d also need a pretty fast connection to get some sort of reasonable performance regarding testing, especially for games.
I guess the bottom line is unless TwoLivesLeft set up some sort of publishing model for Codea apps - your stuck for the time being with having to become an Apple Developer, buying or renting some Mac time and getting stuck into XCode.
I am ok to pay a fee for being an apple developper, but i’d like to avoid mac and Xcode. TLL could compile the lua code into an app and distribute it to the developper via tesflight for beta testing, so it is technically feasible. Would Big Brother really hate it? If more apps are made for the store, that will mean more money for them, so…? What i am not sure of, is if there is a real business model for TLL in doing this. Apple takes 30%, that would be ok for me if TLL would keep 20%: i would not do an app for the money, but for the fun and pride, otherwise that would ok to buy a mac to keep all the revenue.
@Jmv38 I’m not even sure each developer wold need to pay a fee. The cooperative could act as the conduit to Apple. For paid apps, the co-op could also pay out funds.
In some ways, it would be a more pure-play of the publisher / artist model originally behind companies like Electronic Arts, but with the role of publisher whittled down to the bare minimum.
Working it that way would also seem to open possibilities for shared promotions.
.@Mark i’ve got to go to a new year’s eve party, so we can talk longer tomorrow, but i would be really interested to be in something like that. If you have some views on how to proceed, what the status of the cooperative would look like, share it and let’s count how many people would be interested. TLL point of view would be appreciated too, as long as is far away from ‘no way!’.
@Jmv38 & @Mark - count me in. Although, the logistics and business model would need some serious thought to get it to work properly. As for Apple, lets hope there are no ‘gotchas’ in their T&Cs that could scupper this.
@Jmv38 To do things correctly for paid apps, there would be a couple of paperwork steps. Paid apps means having a DUNS number, and a DUNS number requires some form of business registration. The easiest thing to do would probably to form a chapter S corporation as the “owner” of the cooperative. I’ve looked through the documents on some artist co-ops and farmer’s co-ops and have a basic idea how this could be put together. I’ve also done a pretty careful reading of Apple’s dev program documents, and don’t (on first read) see anything there which would rule out this approach.
Note that all the extra steps could be avoided by having one individual front for the co-op but that individual would be at considerable risk should a legal issue pop up. Better to put in the business insulation. Alternatively, an existing partnership or corporation (including TLL) could “own” the co-op if anyone has already gone through the steps of getting such an entity in place.
The co-op would have some annual costs to deal with in fees and accounting. Then there would be pure time and effort involved in compiling and submitting each app, plus cost of distributing funds. Oh, and the co-op would likely need to maintain at least a simple web presence, etc.
@Simeon, apologies for dropping this discussion into the forum if it makes you at all uncomfortable. Since you’ve already given us the tools, and a place to chat, I don’t want to push it.
I was thinking more along the lines of, individuals stumping up the $99 for the developer account, but then some how being able to farm off the App package generation via some automated process web-site service, or preferably by Codea itself performing the necessary steps to build the App for publication.
As far as Apple are concerned, if they get their developer license fees then that’s all they are concerned about, it doesn’t really matter how or who actually compiled and packaged the App for publication.
Happy new year from France. Here it is 0:30!
If @PhD was right that would make things much simpler. The cooperation could be on the Xcode generation. But we would probably also need to distribute the compiled code (through testFlight for instance) to the developper first, as a beta tester. Someone must test the resulting app before releasing it to the app store. And this means a special compilation and distribution adapted to each ipad (they use the UDID apparently), which is provided by companies as TestFlight (however i don’t know how much they charge for that).
@Mark: i don’t know which country you are from, but each country having its own set of laws, it is probably going to be a headache if we have to go into paperwork. After all, all we need is 1 mac, a little money, and most of all 1 guy really eager to make this service happen, mostly for fun the first year, and maybe to make money out of it later, if it turns out that the whole thing makes sense economically. Because there must me at least one person willing to work out the compilation on his mac for us people who don’t want to. Said that way, the whole thing seems more unlikely…
Tell you what, if someone has an app ready to go, I’ll make a pass at compiling it and shooting it back to you. Then you can see if, beyond the compile stage, you run into any Mac-only obstacles. I don’t believe you will.
The biggest time suck in getting an app submitted is getting together the necessary graphics (icon and store images) and just walking through Apple’s submission process.
If someone wants to provide a publishing service we would be okay with it. We can’t do it because there is too much overhead in handling payment distribution, updates, communication.
The main problems I see are distributing payments for paid apps and handling update publishing. It’s a lot of work, and usually fairly tedious. I’m looking at adding Xcode export to Codea so that people don’t have to mess around with the runtime as much.
.@Simeon in pbly right about the 2 problems:
-1/ distributing payments: this means the submission has to be made by the author, involved in the Apple dev program.
-2/ Handling update publishing: this means the compiling service should be a web service where we can upload the codea project, and get back a compiled Xcode program (if that makes sense). So one can do it as many times as needed, without bothering someone. An improved run-time would certainly be a must for this. Maybe TLL could provide this compiling service, and just that? Some apps do provide compiling services on their server (even for free: slideShark is the best ppt viewer for the ipad, and they compile the ppt on their server for us).
.@Jmv38 the big issue is code signing. Users would have to upload their apple certificates — including private keys — in order for the server to sign their binary. So this might actually be quite tricky for many users. Correctly setting up your certificates requires a Mac anyway (for Keychain) — and if you’re doing that, then it’s not that hard to go the whole way and download Xcode as well.
I’d like to have Codea export a ready-to-compile Xcode project. That would go a way towards simplifying distribution. But compiling on someone’s behalf is tricky due to certificates and code signing.
.@Simeon Thanks for explaining that!
.@Jmv38 view is what I would envisage, if we were to go down the web-site service route, it would be up to the author to register as a developer with Apple, and proceed with any submission, therefore receiving any payments directly.
Equally, I saw an online service as just some automated system that could accept an exported Codea project (with whatever assets necessary to build the publication), which would perform the necessary compilation / packaging and email or store the results ready for download.
I did not know about the whole Certificates business, that could be the major problem to overcome.
.@Simeon, What exactly gets produced when compiling the Codea project under XCode using the Codea runtime?
Presumably there is some kind of bootstrap that loads the Lua code described in the project, then performs similar interpretation/compilation as the Codea App itself, and executes the code to run the App?