I’ve been distributing beta builds of my Codea-Runtime-based app via testflightapp.com. I’ve noticed that when I distribute a new build, the end user has to delete the existing version from their iphone/ipad before installing the new version, otherwise the app stays the same as the old version. Looking into it, I noticed that the existing code is stored in the Documents folder, which might explain why it’s retained, while the new code can be found under the Spacetime.app/Project.codea folder. So I guess my question is am I missing some vital step to get the new code to activate?
I’m using the original 1.3.6 version of the library BTW, so if this is known fixed in 1.4.1 just LMK and I’ll try that.
I believe this is normal regardless of how you distribute it. I was having issues with Xcode when I was trying to build an update for my app. Until the old version is removed (matching the Bundle ID) the new will not be applied to the device. The only way to actually “update” an app is via a distributed app store app.
When I built my previous game (built with Unity) I also had similar problems from time to time when deploying to the iPad directly from XCode.
But I never had the issue when distributing builds of that game as ad-hoc builds via TestFlight - those always updated fine. Are you saying you’ve had this issue with ad-hoc builds for a non-Codea-based game @Daemos?
I’ve had issues building in Xcode a newer version. While I haven’t used TestFlight for my apps, Xcode causes the same issue when running in the simulator or sending directly to a device.
Actually that raises an interesting point I hadn’t mentioned - for my Unity-built-game, building from XCode to simulator or device, I used to get the issue occasionally, usually when I made some significant change. But with my Codea game, it’s every single time. I still think there’s something about the Codea runtime that’s causing it, and the code sitting in the documents folder is my prime suspect, guilty until proven innocent!
@peteroyle the issue here is that Codea will not copy your new code over to the Documents directory unless the version number in the Info.plist is higher than the version you are updating.
Have a look in CodifyAppDelegate.m, specifically look at the following function:
You can modify this function so that it doesn’t use the version number check and just copies all files regardless. We generally update the version number information when submitting a build through TestFlight (on the App Store, this is a requirement).
Returns the value stored under “Version”, I believe this should be “CFBundleVersion”, but I’ll need to ask @Dylan — he wrote the migration mechanism and will know.
OK thanks for the info @Simeon. I think you’re right about that last bit because I have been updating the version and build number in the project settings in XCode (4.3) but it never caused the update to work properly. I’ll try updating versionForProjectAtPath to use CFBundleVersion and see how it goes.
