I began developing iOS apps under my father's developer account due to the age restriction, but now I have my own, and have transferred my apps over to it. I now want to update an app of mine that creates and maintains data on the device local to the app.
Since my father's account is still active, I can still sign the app via that account's "Team" in Xcode, and everything works fine when installing on a device. However, I want to sign it with my own account in case my father ever decides to stop renewing his membership, but if I do, whenever I try to install it over top of the old version I get an error in Xcode with the title "App installation failed" and the message "Could not write to the device".
After googling around, people suggest to simply delete the old version of the app from the device and install the new version, but since the app utilizes its local documents directory, this would mean that all the user's files would be deleted when deleting the app, which is unacceptable, since this is the main feature of the app.
Since the app has iTunes File Sharing enabled, users could copy all their files off the device via iTunes, delete the app, install the new version, and copy all their files back. However, some users do not have computers, owning solely phones or tablets, so this is also unacceptable since they would not be able to download the update without losing everything. Plus, many of the apps users are older folks that aren't great with technology, which would just make this a massive pain for everyone.
I haven't tried anything except changing the signing team because I don't want to mess anything up by polluting my account with manually created certificates and provisioning profiles that end up not working. It seems strange to changing the team doesn't work since we have to get a new distribution certificate every year which still changes how the app was signed when releasing an update. I must be missing something since it seems like this is a common enough scenario that Apple would have a process to do it.
What else do I need to do?
Notes:
Xcode usually automatically creates provisioning profiles for apps (assuming the "Automatically manage signing" checkbox is checked, which it is), but has not created one for this app on my account, every though when I roll my mouse over the info icon next to the "Xcode Managed Profile" line in Targets -> myApp -> General, it says it has a provisioning profile under my account's development certificate.
I have access to the certificates and provisioning profiles of my father's account on my computer, so grabbing the p12 of the certificate used to sign the current release isn't applicable.
It's been a while since I asked this question, but if I remember correctly, I think the answer was that I simply didn't have to do anything.
The issue stemmed from the fact that I was trying to install an app that was signed with different credentials than the currently installed version was signed with. For example, if I have an app installed that is signed by account1, then installing any app with the same bundle ID but signed with anything other than account1 (let's call it account2) will fail. In my case, account1 was my father's account and account2 was my account.
When it comes to the App Store, after reviewing your app, Apple signs it and publishes it to the App Store. As a result, everything on the App Store is signed by Apple.
This means that the version of the app submitted under account1 is Apple-signed, and after being transferred to account2, any versions account2 submits will also be Apple-signed. From the final user's perspective, since the old version (submitted by account1) and the new version (submitted by account2) are signed by the same entity (Apple), there is no conflict and the user never knows that the app was transferred to another account.
So even if you see conflicts on your end, the end user won't. To stop seeing them, simply uninstall any versions of the app that were signed with account1 and install your new version signed with account2. Everything should work just fine.