A few of us have been experiencing issues with submitting Codea projects with the Xcode 7 and its new assets-naming system (which happens to be the name currently used by Codea…) @Simeon has been working hard to promptly get us a new runtime which deals with new asset names, whoever, for people like me who exported their project a long time ago, things aren’t as easy, as we need to first update our projects to be up to date with the current runtime (before applying Simeon’s fix, that is).
I’ve had (I still haven’t resolved them, actually) issues updating my project, and, since I might not be the only one, I was thinking we could make a step-by-step of the process.
Here’s what I think I know:
On iPad, export a new, dummy project from the latest version of Codea
Open this dummy project’s folder on a Mac and replace Libs/libcodea.a, Libs/libtools.a, Libs/RuntimeResources.bundle, Libs/ToolsResources.bundle in your current project by the ones from the dummy project
copy the libversion file from the dummy project’s root folder to the current one
Convert your code to be Lua 5.3 compatible: make sure no floats are passed into math.random. If so, convert with math.floor(). Replace all “table.getn” with “#”.
Then comes Simeon’s tutorial on how to get this project ready for uploading on Xcode (verbatim from Simeon’s instructions):
Find the file named libversion in the root of your exported project. It will contain a version number, most likely 2.3.1. Change it to 2.3.2
Delete libcodea.a and libtools.a from your Libs/ folder
Delete the “AssetPacks” folder reference from the “Resources” group in your exported Xcode project — if Xcode asks you to move the files to trash say NO.
In Finder: rename the “AssetPacks” folder to “Assets”
In Finder: Rename every “SomePack.assetpack” folder within it to “SomePack.assets”
Drag the root level “Assets” folder back into Xcode, tell Xcode to add this as a “Folder Reference” (not a “Group”)
This is probably a stupid question, but how come you’re exporting a dummy project? (As in, why not re-export the actual project you’re wanting to post to the App Store?)
@yojimbo2000 Because that project was first exported more than a year ago, and all updates have been since made in Xcode. I’m guessing I’m not the only one doing this, am I?
@Erickyamato Oh I see, so I should do the opposite than what I’m trying to do… I’, try thins, thanks
Probably too many screenshots, bundle ids, icons, launch images and screens etc to deal with, I’m guessing it’s most likely easier trying to edit your project in xcode then to deal with that.
EDIT: never mind, looks like you’ve awnsered it, and by the timestamp looks like we posted at the same time
Note that while the steps above will get you to archive, you won’t be able to submit the app.
You’ll also need to open RuntimeResources.bundle and ToolsResources.bundle and remove the Executable File string from info.plist
Finally, you’ll have to deal with multitasking. Unless your Xcode changes include a storyboard, the easiest way is to select the “requires full screen” option
@yojimbo2000, can version control actually do that? I need to learn about this… Is there any free and private git around (I’m guessing this is too much to ask but well )?
Bitbucket lets you have free private repositories. Turning on Git in an already existing Xcode project is a little tricky, but there are plenty of guides if you google.
@Rodolphe thank you for posting this guide, @Mark thanks for the extra steps. I haven’t tried following them yet, as I’m not ready for verification yet, still just experimenting with putting apps onto the phone. But I’m sure I will be working through these steps soon.
@Rodolphe I was oversimplifying, and probably not being very helpful, sorry. I guess where Git can help here, is it can do a three-way merge between the new export from Codea (branch2), your current Xcode project (branch1), and the two branchs’ common ancestor, which would be the file you originally exported and started working on in Xcode (although, if you’ve not used Git so far, then the repository won’t know what the starting point was. Do you have your first export file somewhere, before you started making changes in Xcode? This might be a good place to start the repository with.)
The merge would produce conflicts in those situations where the same lines of code have been changed in different ways on branch1 and branch2. For the areas of conflict, you can resolve them on a file-by-file, or a line-by-line basis (you choose go with branch1’s version of this file/these lines; or go with branch2’s). I’ve no idea how many conflicts this approach would produce. I should stress that I’m still very much a Git beginner, and you might no find it helps you much! Or rather, it presents you with a new set of problems.
Is there any free and private git around (I’m guessing this is too much to ask but well 