What is the official, documented behavior when you install an update to an app?
This question asks the same thing, but the answer, which says that the app bundle is replaced but all other folders are untouched, does not provide any documentation. I have reason to believe that the app bundle, in fact, is not replaced, so I'd like to know for sure.
Please link to documentation!
From the iOS Application Programming Guide (see the "Files Saved During Application Updates" section within "The File System"):
When a user downloads an application
update, iTunes installs the update in
a new application directory. It then
moves the user’s data files from the
old installation over to the new
application directory before deleting
the old installation. Files in the
following directories are guaranteed
to be preserved during the update
process:
<Application_Home>/Documents
<Application_Home>/Library
Although
files in other user directories may
also be moved over, you should not
rely on them being present after an
update.
What you're seeing in the Why isn't my iPhone app bundle replacing the old one during an update? question is an issue where Xcode doesn't correctly detect/push updated resources to the device, which is a very different scenario.
Related
Recently, updated my app v1.0 to v1.0.1.
Then one of our tester said
'Lost all pictures that saved in app' (not photo library)
I found that installing the App with Xcode and updating the AppStore version on the device
will change the App's directory, so data will be lost. (But not all data. Some files are copied, in my case .db files. that's really odd)
ex)
/var/mobile/Applications/D108B86A-27A8-4665-A490-F1CBB94CE04A/Documents/
/var/mobile/Applications/CCCD0C25-C33E-498F-8D24-9AF243E01A21/Documents/
But it isn't normal process, maybe it causes problem.
Is there any possibility of directory change in normal process?(Install from appstore then update from appstore)
I wanna try 'Normal process' but there's no device that have old ver.
So can't make appear 'Update' button in appstore again :(
I found that updating app causes directory changed.
So should not save 'Full Path' at Database or file.
I had the same problem: ad-hoc version of app can't upgrade to appstore version. It just removes ad-hoc and installs app store. But during normal update process app store -> app store it replaces only app package so all should work OK.
My application downloads a database file from the internet server at first launch and then may redownload it if the server have a newer version of database.
This database file is stored in <Application_Home>/Documents directory.
Apple approved previous version of my app when there was no iOS 5.0.1 yet one year ago.
But now they rejected new version of my app becouse it does not satisfy the rules of data storage.
I read this article on Apple site. But I can't understand is it enough just set do not back up attribute to database file and keep the file in <Application_Home>/Documents or it's need to place it to another place?
And how to support for previous iOS versions?
I encountered the exact same situation about a month ago with a client's app. It was sufficient to just set the flag on the downloaded file(s) and resubmit. The process is quite straight forward using the Tech Note in the article you linked to.
As always with app reviews, your mileage may vary.
I am a little curious what happens in the situation when the user downloads a new version of application from App Store. I have an existing app, an eBook reader on the iTunes store (downloaded with customers).
Assuming that the customers have downloaded books to the existing version of application onto their iPad, now that a new version is available on app store & user downloads the same along with the app update i want the user downloaded books(on the previous version) to be backed up when a new updated version is installed.
Currently in my application i'm string these books in Caches Directory of Application Sandbox.
If there is a possibility of doing this, please provide some references?
A proper update will not remove the previous content of your sandboxed folders - hence I do not see a reason for a backup. Proper update means the user uses the iTunes update functionality.
Only once the user entirely removes the previous version and then installs the new version, the sandboxed files of the previous version will be gone.
I want to know, when Apple AppStore pushes an application updates to the user, and when the user chooses to download that application update, is it a partial updates or is it a complete reinstall for the application?
Assuming an extreme case, the developer only updated one image in the application and he submitted the updates to the app store, does apple smartly delivers the updated portion of the app, or it blindly redeliver the whole new application to the end user as an update?
It is a complete download and reinstall of the entire application binary, with only user data being preserved. This is to mitigate any otherwise irreversible corruptions during the update, since if the update itself is corrupted then it's just a matter of rolling back to what was previously installed on a device, preventing user data loss.
From Apple's developer docs:
When a user downloads an application update, iTunes installs the update in a new application directory. It then moves the user’s data files from the old installation over to the new application directory before deleting the old installation. Files in the following directories are guaranteed to be preserved during the update process:
<Application_Home>/Documents
<Application_Home>/Library
Although files in other user directories may also be moved over, you should not rely on them being present after an update.
It doesn't say out loud that it's a complete reinstall, however the first paragraph makes it quite clear why it is.
I have an unlocalized shipping app which has foo.xib in the main project directory. In preparation for localization, I moved this to en.lproj/foo.xib. Now, when I build my app and install on my test device, it ends up using the stale old foo.nib which must be there from before (the installation process must not remove old files in the app's bundle). Deleting the app from the test device and re-installing fixes it -- but I don't want my existing customers to have to do that.
Some of these are coming from calls to UIViewController's -initWithNibName:bundle method (to which I'm currently passing nil for the nibBundle). I can probably create an NSBundle instance here which points at the correct localized directory. The others are specified in Info.plist or in the "NIB Name" section in interface builder and I don't see a way to specify a bundle for those.
It might just be easier to rename all my xibs to (e.g.) en.lproj/newfoo.xib, then I presume it will find the correct nib at runtime. (And I'll have to remember to never again use the old "foo.xib" name in a new version.) Is there a more clever solution here though? (Other than going back in time and starting with en.lproj directories from the beginning ;-)
Thanks!
-Mike
Answering my own question in case anyone else runs into this issue. It appears that this is an artifact of the Xcode build-publish cycle, and it isn't a problem when user's upgrade via the App Store. I went ahead and published my update and no one has noticed problems that would result from stale resources.
As a speedup to development, it appears that Xcode only copies over resources that it detects have changed when you build and install to the simulator or a test device. (To prevent a game with 500MB of resources from having to be re-copied each and every time you build and test.) When you (re)move a resource from a project though, it does not detect this and (re)move the old copy. I will file a bug with Apple about it.
However, the App store does appear to do a clean install with each upgrade (copying over the user's documents directory) so this is not a problem from the App Store. I'm not sure if it is a problem when emailing beta testers an .ipa file or not.
I'm having the same issue. The problem is that the phone keeps a cache of the nibs. Somehow thus cache needs to be cleared for you to see the new localized nibs. I also don't want my users to have to delete the app since it stores data.
I just had the same issue but found a solution which works, even with Xcode's deployment quirkiness: Prevent UIViewController loading stale XIB from app bundle