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.
Related
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.
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 am updating in-house app for a client which they have a previous version currently on over 100+ iPads.
I want to push an update, but when i try to sign the app with the distribution provisioning profile it asks me for the private key. After searching, people suggested to revoke the old certificate and generate a new one on the machine i'm using so i can have the private key. I don't know if this is the best approach or not, but my client is concerned if I will be revoking the current In-House Distribution certificate, it will affect the applications which are currently distributed on those 100+ iPads? Thanks!
Unfortunately, yes. For enterprise distributed apps, the devices will regularly check with apples servers whether the certificate which has been used to sign them is still valid. So revoking the certificate will make those installations fail. Maybe not until the next reboot, maybe not when there is no internet connection available, but sooner or later, the app will refuse to launch.
If availability of the app must not be interrupted, you need to take precautions - for example by preparing the new version and notifying all users ahead of time that at a certain date, the old version will stop working and the new one must be installed.
Update:
I kept investigating and it appears like you can have two distribution certificates at the same time now. This is meant to eliminate gaps in app availability by allowing you to phase from one cert to another, way before the first one expires.
If this is still true, you might be able to simply create another distribution certificate without revoking the existing one. You will need to create new provisioning profiles as well (or update the old ones to use the new cert), but that shouldn't invalidate those already deployed. You would then be able to distribute the new / updated app and the existing installations will remain unaffected.
It has been some time since I last worked with enterprise distribution and right now, I don't have access to an enterprise dev account, so I can't try. But I don't think there is any risk if you just go ahead and try it - I assume the portal will either let you create a second cert or it just won't...
Toastor is correct - I recently had a discussion with Apple about this and it intentionally differs from App Store apps. When the distribution certificate is revoked (or expired) for an Enterprise app, the app stops working after expiration is reached, or revocation information is retrieved from Apple.
However if you manage several Enterprise apps, instead of requiring users to install a recompiled version of every single app with the new certificate, you may:
Push the new Provisioning Profile(s) to users over MDM (like Airwatch) **
Use a wildcard App ID for your apps and then as long as the user installs one app with the updated cert, it will apply to all apps that share that App ID
Allow users to download the updated Provisioning Profile without requiring an app install **
** CAVEAT: I don't code apps but do manage our certs, App IDs, and Provisioning Profiles. I haven't yet tested these approaches - it's my best effort based on notes from my recent discussion with Apple.
We are developing an iOS application for a customer who manages his apps under his own name in iTunes Connect.
I was wondering if there was a feasible way to validate an ipa when you are not the final instance which will actually upload the bundle to the App Store. A common scenario is that you deploy an application bundle to a customer so that he will be the one who manages the app in iTunes Connect, but you still want to make sure that everything checks out once the app is in your customers hands.
To be clear: we don't have access to our customers iTunes Connect but we archive the application with their distribution profile.
The idea which came to mind is to create a mock application in our own iTunes Connect without the intention to actually release the application. One could expand on this and actually do a pre-review of the app to make sure the app will not cause unpleasant surprises after we sent the archive to or customer. Will Apple throw any rocks in this path? I could imagine that they won't be happy that developers will let review the same app version twice...
You ask about whether the final Xcode archive could be tested. Yes, it can be tested. You should ask your customer to send you a copy of the submitted application, as it appears in the Xcode organizer). They would have to resign the bundle with THEIR AdHoc profile that should contain YOUR device, and send the IPA to you. You would then be able to check the final submitted app.
For the second part of your question, which is most interesting: It would be great to release the app in your account and then let the customer release it again. There are two problems: if the reviewer is the same, then your customer's app may be rejected. And: if the reviewer is not the same, it could pass validation with the first reviewer and fail with the second one.
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