Oh that’s kind of a good news! I don’t know why I couldn’t find this ticket on my (many) google searches. Nice find @yojimbo2000!
I tried removing the .assetpack extension, but Xcode automatically adds:
Dropbox.temp_caseinsensitive_rename
I’ve added my name to the list of people having issues with this. No Dropbox or other external assets, just assets that are part of the Project (for things specific to this project) or Documents (for things that are used across several projects) folders within Codea.
/OnDemandResources is a red herring. It’s just an unfortunate coincidence that it uses the .assetpack suffix that Codea Xcode export used until now. As far as I can tell, it’s for loading resources as they are needed from a remote server, which is not, as far as I can see, what any of us are trying to do.
Yes, it looks like one of the strategies they’re using to reduce the base size of apps. I can certainly change the name of the assetpack, but… it’s another thing trying to change it in the runtime.
@Rodolphe ok, instead of removing the extension altogether, what happens if you just change it to something like .assets?
There is a further problem with this approach. Even if this folder extension passes the validation process, and even if we’re able to read files at this new extension (which I believe we can do) using os.getenv , io.open and file.read, there seems to be no way to actually turn the raw data read by file.read into a usable image. readImage seems to only accept files in the asset packs. Maybe I’ll start a new thread on this specific issue, as it’s somewhat separate from the main problem.
Eck, this is really gonna screw up my project, gonna have to copy over alot of resources and launch screens etc to a new export by the looks of things 
Hi everyone, I’m currently working this issue through by submitting some dummy apps to the App Store to find where the error is. Once it’s resolved I’ll try have an updated project template you can download until the next release of Codea is available.
So it does appear to be an issue with the term “assetpack” appearing in folder names anywhere within the app package.
I will be uploading a new runtime that enables bitcode and also looks for the term “assets.”
I seem to have solved this with a work around. I am a complete novice, especially in xcode, but this seemed to work.
After archiving your project, locate the asset packs for the archive. I did this by choosing xcode-preferences-locations and choosing a different location for the assets to a custom folder so I could find them easily. Then I archived the project and the assets appeared in the custom location.
Then (via finder), in the folder where the archives are, I found a folder named with today’s date. Inside is a package. Right click and choose ‘show package contents’. Follow the path: products-applications and there is your app.
Once again, right click and choose ‘show package contents’.
Inside here is a folder called ‘AssetPacks’. Inside here I found ‘Dropbox.assetpack’. Based on what’s written above, I simply changed this to ‘Dropbox.assets’ and… hey presto! I could validate no problem.
@RaspingZeus while that will fix the submission error, it will lead to an error when the Codea runtime attempts to access any assets located in Dropbox.assetpack. I will be updating the runtime shortly to allow for .assets extensions instead of .assetpack
It seemed to work though. I deployed the app, image files included, via itunes connect. I am looking at it on my ipad now!
Thanks for the fast response Simeon, I’m excited to submit my app hopefully soon!
@RaspingZeus that’s odd, it shouldn’t work! But if it does then that’s good to hear.
@Rodolphe should have a new runtime up today with instructions on how to update your exported projects.
Thank you!!!
This is amazing @Simeon!!! Will you post a link here?
Okay, here’s the solution for now (I’ve tested with the “Validate…” option in Xcode and it passes).
- Find the file named
libversionin the root of your exported project. It will contain a version number, most likely2.3.1. Change it to2.3.2 - Delete
libcodea.aandlibtools.afrom yourLibs/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”)
- Build and test your project
- Archive your project
You can now also re-enable the “Enable Bitcode” setting for you Xcode project, as the 2.3.2 version of the Codea runtime library has bitcode embedded. This will let you take advantage of App Thinning when it becomes available.
Just curious, are we not replacing libcodea.a and libtools.a with new ones?