I have an iOS app installed in iPhone from app store, now if I have an updated version 1.1 for the same app at app store and I'm getting some sort of informative alert from the older version 1.0 (New version is available...).
If I click on alertview's ok button, it redirects me to the new app link in browser. I download my new version then.
Please provide answers of following questions :
Will it replace old version?
Will it replace sqlite and image folder on the document path? (Both version is having same named sqlite file, say abc.sqlite1.0 and same folder name, say imagesToBeCopied)
Will it append the sqlite entitie rows with new rows for same entity?
How can I install version 1.0 again from app store? Is it possible to get it anyhow?
Please provide your valuable answers on it, which can help me out to reach to some solution.
Thanks.
1.Will it replace old version?
Yes, the app bundle will be replaced by the new one
2.Will it replace sqlite and image folder on the document path? (Both version is having same named sqlite file, say abc.sqlite1.0 and same folder name, say imagesToBeCopied)
No, the documents directory is not affected by the update process. If you have procedures in your code that update the documents directory, they will still run, but without any changes it would be no different to a normal launch of your app - e.g. if you check for and copy if needed, something from the bundle to the documents directory, this will only happen if the target file doesn't already exist.
3.Will it append the sqlite entitie rows with new rows for same entity?
This is not related to the update process. If you want to modify the data as part of the update, you will write this specifically in first launch code for your new version.
4.How can I install version 1.0 again from app store? Is it possible to get it anyhow?
No, the updated version replaces the old one on the app store.
To the best of my knowledge...
Yes, the new version of the app will replace the old version.
Yes it will replace your sqlite file, assuming your paths did not change across versions. If you want to handle this sort of case it is your responsibility to include logic in the newer version of the app to check for the existence of the sqlite file and overwrite or modify it accordingly.
No, all modifications to the sqlite file need to be done manually by the new version (see #2).
As of now, not possible to do this through the app store. Only one version of any app can be placed for "sale" at a time. You would have to do this through other means (testflightapp.com for instance [for adhocs for devs]).
Related
Hi I struck at core data migration issue. I have developed a app which is new version of an existing app in Appstore. But i don't have source code of previous version and don't know exactly that whether core data was used in old version or not. So how to update my app (which has core data) to Appstore without any crashes. Any quick solution please?
Since you mention in a comment that you want to ignore the old data, you don't need to do any kind of migration. Model migration is about updating existing data to work with a newer data model. The only danger would be if the old app used Core Data and your new app attempts to use a persistent store file with the same file name. Then your app would attempt to load the old data, since it would find that file with the correct name.
The easiest way to test this is:
Install the existing app (from the app store)
Use this app until you're sure it's saving some data
Install the new version from Xcode. Since it's an upgrade, it will overwrite the app store copy.
By then you'll know exactly what happens when upgrading. If you get a Core Data related crash, change your Core Data setup to use a different filename. Then delete the app from your iOS device and repeat the test from above.
I am struggling with an issue related to Core Data.
In my app, I use Core Data for storing and retrieving the values. In my latest version, I added some attributes to entities from the old version. I updated the app from the App Store, and when I click on the page where we need to display the contents from Core Data, it is crashing.
If the old version of the app is removed and the new one is downloaded, then it doesn't crash.
My requirement is any alternative there is to fix without having to remove the old version of the app (merging the old version with the new version).
Any suggestions on how to fix this issue?
Thanks in advance.
Did you setup versioning of core data? IF so, in your Xcode project navigator, your .xcdatamodeld should be drop down with multiple .xcdatamodeld underneath it. And then in attribute inspector with the parent .xcdatamodeld selected you pick your current version.
If the changes are minor, this will take care of it's self when you load new app version ontop of older version.
If the changes are major, you need to setup handling for this in your app delegate to tell the app how to move data between the two versions.
You have to migrate the Core Data store from the old Version to the new one.
This tutorial show's how this works: http://www.raywenderlich.com/27657/how-to-perform-a-lightweight-core-data-migration
My app's 2nd version adds two new entries to the database. But the new items are only gets listed in the app's table view if I uninstall the app from the phone and install the new version. Otherwise the new entries are not getting updated to the DB. Entries are listed in a plist file.
How do I force it to update the DB (without losing data) ?
Thanks in advance.
You need to have some kind of version identifier in your database, and when you app launches, always check it. If you find it is an older version, add the additional data that needs to be added than update the version number. This means that your plist needs to keep track of what is new by database version.
Note that the lack of a version identifier can be treated as a version identifier (that is null is older than version 1).
My released version appears to be using a old model version of Core Data, xxxDB 101j instead of xxxDB as defined in the VersionInfo.plist (package contents of xxx.xcarchive submitted to the app store). This has not been an issue on development devices or releases to TestFlight.
It is using the last listed version in VersionInfo.plist, not the version defined in the NSManagedObjectModel_CurrentVersionName property. Interestingly all the versions have a .mom file including xxxDB but xxxDB also has an .omo file as well.
Has anyone bumped into this issue and found a work around?
The workaround is to add a new version model, make that the current version, clean, archive and submit. At this point in time, the NSManagedObjectModel_CurrentVersionName property is not used when your app is submitted to the app store. It uses the last listed model in the VersionInfo.plist.
The behavior in the testing/adhoc environment is different to go live
Like many developers, my iOS app was just rejected for having downloadable content that was being backed up to iCloud. I've searched for a clear answer to this question but have not been able to get one.
Apple says that you should implement a 'do not backup' attribute to your files, however, they also state (https://developer.apple.com/library/ios/#qa/qa1719/_index.html):
The new "do not back up" attribute will only be used by iOS 5.0.1 or later. On iOS 5.0 and earlier, applications will need to store their data in /Library/Caches to avoid having it backed up. Since this attribute is ignored on older systems, you will need to insure your app complies with the iOS Data Storage Guidelines on all versions of iOS that your application supports.
My app supports iOS 4.0 and later. Does this mean if I want to maintain support for iOS 4.0-5.0, I have no choice but to put all my content into the Caches folder? Or, can I just add the 'do not backup' attribute and keep the files in /Documents? If I have to keep the content in the Caches folder, can I prevent these files from being purged in low storage situations? Finally, are there any developers who have put files in the Caches folder and know how often they do get purged?
Any advice or help would be greatly appreciated. Thanks a lot!
The concern area is the iOS 5.0, which supports iCloud, but does not recognizes “do not backup” attribute. In this case, all the data of the app inside documents directory is likely to get backed up to iCloud. For the iOS versions below 5.x:
the iCloud backup is not valid.
the "do not back up" flag is not relevent. It would not produce any warnings during compilation.
Hence the data can be kept in the documents directory, with "do not back up" flag appropiately added to the contents (files/folders), for all the versions. The problem is for the version 5.0 only.
i think you can find similar question like this :
What is suitable location for creating sqlite file?
and as per my thinking it is better to store files in library with new directory rather than document directory..
No it's wrong that tou say. I've solved your same problem in that way. I saved my database and directory images in directory Documents/.. flagons those As do not backup as suggest by Apple. In that way for devices that are updated to 5.x or more that files are not backup to iCloud; for others there are no changes because there are no support to iCloud.
This is a best practice because files that are not concerning user we do not backup in iCloud. All other files that you don't want to redownload must be saved in Documents flagging it as do not backup. If you save it in Caches folder those are deleted in a short time when you close the app and must be redownloded when you open it again.