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.
Related
A few years ago I wrote an iPad app that was to run on only a few of the client's iPads. They're currently having issues with the app exiting upon being opened. It turns out this is due to the dev provisioning profile associated with the app being expired.
I tried renewing the provisioning profile but am unable to access the Provisioning Portal because my dev account needs to be renewed. Renewing my account is not an option right now.
I'm aware that as of Xcode 8 users are able to install apps on physical devices for free. I don't have access to the client's iPads and have been issuing out updates by archiving the .ipa file and using diawi.com for them to install.
How can I just renew my provisioning profile so that my client can successfully open the app?
Thanks
This is not possible. What you need to do is generate a new, valid provisioning profile and run the app again on your client's iPad. However, I should note that for this type of development, Apple wants you to use ad-hoc distribution through the enterprise developer program.
Also, to be able to generate a new, valid provisioning profile you will need a valid account.
Ideally, your client should have their own developer account that they maintain, preferably an enterprise dev account (enterprise accounts don't require them to manage the specific device UDIDs the app needs to run on). With that, they could manage their own certs / profiles for the signing of the app. They could then grant you access as a team member to manage those things and update the app once a year.
Or, even better for them - you could even write them a script / use tools (like fastlane) to re-sign the app themselves so they could self provision. This takes you out of the loop for ongoing support, since it doesn't seem like you will / have provided ongoing support. Keeping an internal app running requires continual work (new OS updates, code signing expiration, etc.).
If you built an app for a client, you probably should have known / let them know that iOS doesn't allow unsigned apps to run on devices, and that developer provisioning profiles last at most a year. You also need to make sure they know you can't just write a native app and expect it to work forever. At some point (probably now, but they don't know it yet) an iOS update is going to break something you did in the app. The just can't see what is broken yet because your invalid cert is making it so the app can't launch. Given your lack of understanding of iOS code signing, I would assume that you likely did something in your code that was broken in subsequent iOS updates (given that very experienced iOS developers also have things break with new iOS versions are released).
At this point, I would explain them the situation and see if they would be willing to set up their own paid account (only $299 / year for an enterprise account) to get new profiles / certs set up to get the app back up and running.
I have an iOS app that I'm testing on my phone. I installed it through XCode. I've had the app on my phone for several weeks. After a couple of weeks the app no longer works. If I open the app it immediately closes. If I do a fresh re-install of the app, then everything works for a couple more weeks till it breaks again.
My theory is that the provisioning profile I used has expired, preventing the app from loading. This is expected as I'm installing the app through XCode and Apple probably doesn't intend for users to have a test build used on an iOS device for extended periods of time. My question is this, how can I set it so the provisioning profile doesn't expire? How would I need to adjust the code signing settings to adjust for this?
You cannot set provisioning profiles to never expire. Development provisioning profiles will expire after a set amount of time. For a free developer account with Apple, your profiles will be set to expire after 30 days. If you have a paid developer account, the profiles will last for a year from when it is created. Note that a new profile isn't created every time you build, so you have to keep an eye on the profile expiration date and generate a new one when you get to 10 months or so.
Apple will not let you go longer than this, as it would allow / encourage other distribution mechanisms. If developers could build an app and distribute it to other peoples' devices, and those apps could run indefinitely, someone would quickly develop a 3rd party app store and Apple would lose control of its ecosystem.
FYI - If a provisioning profile expires, the app will launch briefly, then shut down when iOS realizes that there is a code signing problem (also happens if your certificate has been revoked or has expired). You can check for sure by plugging the device into your Mac and monitoring the device console when you attempt to launch the app. You will likely see a code signing error in the logs.
Set device type to generic in Xcode.
Go to Product in the status bar on the top of your screen
Select Archive
Build your app as an AdHoc file
When its done, save that file somewhere, (I usually throw it on my desktop and then delete it)
Double click the .ipa file, Make sure your phone is plugged in and hooked to iTunes.
This should install the app on your phone.
I have had good luck with this, I hope it works for you.
Note: This may only be possible with a developers license, I'm not 100% sure.
My Enterprise app's provisioning profile became invalid yesterday. I renewed it via Xcode, but now the app on won't launch on any devices, and it's unable to download. Do I need to re-package the app and make all users download the update? The app has 3000+ users and making them all download it again would be a huge pain. Is there any way to update the profile, but not need to re-download the app? Shouldn't the device check against Apple's server and see the profile is now valid again?
If you have 3000 users, you really need to look into using an MDM / MAM platform to automate this. Every year when the provisioning profile expires, you will need to re-sign the app, and then re-distribute the app to all the users.
You can do something in-app, like check for a new version, and prompt the user on launch that they must download the new version. If you do this, make sure you push it out early enough that all users will launch the app and download the new version before the profile expiration date. So every year, 1 month before the profile expires, you push a new version to a particular location. Users will then get a pop up saying they must get the new version. They click OK and it fires off the install from the .plist, replacing the current version. We do it for a much smaller user base and it has been effective.
According to this link in the section "In-house apps | Providing updated apps", I should be able to just distribute a new .mobileprovision file instead of forcing users to install a new version of the app:
For users who already have the app, you may want to time your next
released version so that it includes the new provisioning profile. If
not, you can distribute just the new .mobileprovision file so users
won’t have to install the app again. The new provisioning profile will
override the one that’s already in the app archive.
How is that even possible? Isn't the distribution profile necessary for compiling/singing the app? I would like the convenience of just being able to distribute a new certificate, but I'm very skeptical this can even work. Does anyone know for sure? Or am I mis-interpreting this wording? If not, how can I make this work?
Apple said Provisioning profiles can be installed and managed using MDM, downloaded and installed by users from a secure website that you provide, or distributed to users as an email attachment to open and install.
So you can distribute only mobile provision profile and test the things.
One thing I observed that In case of Enterprise Distribution profile Device udid does not need to add in portal. The ipa file will install across all devices. It happens in case of Enterprise developer profile cases.
For Managing Updates Apple has said that:

"In-house apps that are distributed internally aren’t automatically updated. You’ll need to notify employees of the update and instruct them to install the app. If the application identifier assigned to the app in Xcode is unaltered, it will recognize the app as an existing app and install the update while retaining locally stored app data or preferences. For greater convenience, consider developing a function within the app that contacts the server for updates at runtime."
So I am guessing to send the users a push notification which would notify them about the update and ask them to install, once the click ok you can redirect them to your server where the app is hosted and they can install from there
So I took over an existing iOS app from a client, that is currently available for public use through the App Store. When I was given the project in xcode, I noticed that all provisioning profiles associated with the app had expired and all were under the name of the previous developer.
So, I added myself as a developer and joined the team and code signed the development copy under my credentials. I created a new ad hoc provisioning profile for testing, and released a version through TestFlight to some registered devices. No problems. The app is greenlighted to go live.
Can someone please help me out with the release process from this point on? Do I create a third new provisioning profile for App Store release, and tie it to the code signing in XCode? Is this going to be problematic considering the version that is live now is under completely different (expired) profiles from a different developer? Is there some alternative way I need to do it through Apple? I'm trying to be super cautious here... if for some reason I release the app and its crashing because of some step I didnt take by accident, the poop will hit the fan.
You're going to have to release it under a new name on the App Store and forfeit all the ratings and reviews. Apple won't let you swap developer profiles on an existing app.
Other developers may disagree, but it looks like a huge PITA. See here
Transferring ownership of an iPhone app on the app store
The official answer seems to be NO
I didn't interpret the question as regarding change of ownership of an app.
I read the question as: I've inherited maintenance of an app and we'll want to submit an update as the same seller.
In this case, you can generate your own certificates and distribution profiles, and you can then build and submit the app.
I have done this numerous times. That is, I have inherited responsibility for an app that I did not necessarily craft originally. I easily created new signing and provisioning credentials, appropriate for the app the be submitted as the seller (not me) on their behalf.
And for what it's worth, the App Store Distribution profile is necessary, but only used when the app is submitted, so Apple can ensure that it is coming from a developer that has the right to submit it. (Remember, these profiles are signed with the same certificates used to sign your app package.) If that Distribution profile should expire or change, it has no bearing on an app already in the App Store.