> We use a different name & bundle ID for dev builds, but our ad hoc
> builds have the same name and bundle ID as the released app. This
> lets us use the Xcode Archive feature to create a final candidate
> which can be tested as an ad hoc .ipa file and then uploaded to the
> App Store as an app store .ipa file.
Yeah, Xcode's Archive feature really threw a wrench in the works (in that it is better than the scripts I hacked together, but not as easy to extend).
> It is also important to test updates by installing them on top of the
> previous release. If you don't test that way, you risk having all
> your existing crash & burn when they update because of unforeseen
> incompatibilities in the stored data.
True, but that's kind of a haphazard way to test that. What I've done to test data upgrading is use code to put old files in the app's Documents directory on launch. This allows you to simulate an upgrade so you can repeat the test while diagnosing and fixing the problem.
--
You received this message because you are subscribed to the Google Groups "iPhone Software Business" group.
To post to this group, send email to iphonesb@googlegroups.com.
To unsubscribe from this group, send email to iphonesb+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/iphonesb?hl=en.