"do not backup" extended attribute in iOS 5.0.1 - iphone

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.

Related

Apple iphone app transfer or app replacement

We have built an inhouse version of an iPhone application that is to replace another that is already available from another developer.
I was wondering if you think we can use "app transfer" from the previous developer and in turn replace it with our own app. Previous developer has agreed for the transfer (ofcouse excluding his code). Therefore our question is if we can transfer his app to our development name and then replace the app with our own. Our goal is that the current users of this app will receive ours as an update to what they already have and not as a different app.
In short, transfer and replace so users get our app as an update.
Note:
Please note that as we were unaware of this "transfer" we submitted yesterday our version of the app with a slightly different name. Should we cancel submition (as it is still pending for validation) and follow some route you may suggest in your replies, or stay as it is now?
If you keep the Appidentifier the same between the original version and the new version you will submit, this should work as expected. (But nobody has much know-ho of the new "transfer" option yet)
So, you process would be as follows:
Hand the old developer your TeamID and your Apple ID
The old developer transfers the current App over to your team
Once done (no clue how long that takes), you have the app in your itunes connect
Now you add a new version of the App to itunes connect and mark it as ready to upload
You upload your newly coded app that meets these criteria:
Application Bundle Identifier is the same as with the App you're updating
Your new App is signed with a correct certifcate/provisioning profile (just correct for the appid, doesn't have to be the same one)
The BundelVersion and BundleShortVersionString are at higher than those of the already submitted applications.
So basically, it will work just like a regular update.

Copying data from a free iOS version to a full version of my app?

How could a full version of my iOS app access / copy the database / settings from the free version ?
I'm thinking of providing a free version of my app and I can't see how people then buying the full version could get access to the data from my free version ?
All apps are isolated on iOS. They are installed as different iOS system users. One user do not have permission to access another user's files. In the old times, one common approach to address this problem is to enable iTunes file sharing. And tell users to manually copy the files.
Your better bet is to use the freemium model to sell your app. Make the app free, and unlock extra features via in-app-purchase. This way, your files, documents, settings won't need transferring to the pro version. The app itself becomes pro after unlocking.
Here is the guide from Apple: https://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/StoreKitGuide/Introduction/Introduction.html (though not very intuitive).
The walkthrough here: http://troybrant.net/blog/2010/01/in-app-purchases-a-full-walkthrough/ is very helpful.
Last but not least, be aware that in-app-purchase is crackable. So please read: How to detect "IAP crackers"? , Verifying In App Purchase Receipt from Client , and https://stackoverflow.com/questions/4715414/apple-in-app-purchase-verify-receipt , verify in app purchase , In App Purchase Receipt verification within app .
Note that you are supposed to setup a server to validate iap receipts. Though it's doable from within the app, it's not safe. As far as I can remember, you can test in-app-purchase through StoreKit in iOS simulator v5.0, that should be Xcode 4.2. Before that, it can only be tested on a device.
#Dominik Hadl mentioned you can use a server to sync the file. The operation is usually complicated. If you prefer this idea, you can choose to use custom url scheme to launch one app from another to ease the operation. See steps below:
User press "Begin sync" in the free app to upload the file to your server
Server return the ID of the file to the free app
User press "Launch Pro App and Download my file", which leads to a custom url scheme to launch your Pro version (must be installed first), with the file ID
Pro version use the file ID to download that file directly
I think the only way how you can do this is syncing the data with some server, registering the device and the syncing the data back to the full version.
Because all iOS apps are sandboxed, they can't access any other application data (unless you have jailbroken iOS).
Since multiple apps can share the same iCloud container, I'd say that the best practice nowadays is to "simply" store the data in iCloud.
(I'm putting "simply" under quotes, because it is easy to put data in iCloud and take it out; but if you actually want to do syncing, you may need to do more than just "I'll load from iCloud and save to iCloud" in order to provide the best experience to the user.)

Data BACKUP on VERSION UPDATE. App Store

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.

What precisely happens when iOS installs an update to an app?

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.

Consequences of not updating the bundle version for an iPhone app?

I submitted an update for one of my iPhone apps last week and just realized I forgot to change the bundle version in Info.plist before I submitted. The update fixes a critical bug, so I want to get it into the store as soon as possible. The app update has not been approved yet. I am debating on replacing the binary with the updated bundle version or leave it.
What are the consequences of leaving the bundle version the same as the previous version of the app?
Apple may not accept the update as the bundle version is the same as what is currently on the app store
If it gets through Apple, iTunes will not automatically download or synchronize to the phone (you can see this behaviour using an ad-hoc distribution)
I'm surprised it even got through. I forgot to do that once, and itunes connect wouldn't accept my binary. I'd say you should leave it as it is, since you probably did change the bundle version in itunes connect, when you were uploading the binary, and so it should all work out. I'm not exactly sure though, cause I'm surprised it is even possible.