I have an application already in the store that use Keychain to store passwords.
I want to publish an update of the application, the problem is that I don't have the original certificate anymore (it was expired and I created another).
Reading Apple's documentation it says:
Note: On iPhone, Keychain rights depend on the provisioning profile
used to sign your application. Be sure to consistently use the same
provisioning profile across different versions of your application.
If I edit my provisioning profile with a different certificate, will my users lose their passwords when I will upgrade the application?
Thanks
if you can upload the app into the store (so update the old one), the users will not recognize anything of this ;)
What's saved in their keychain will be bound to the Bundle an stays at least until the application is deleted.
You can revoke and re-create your cert, and assign it to your provisioning profile without any further consequences.
Related
I have an iPhone app that uses the keychain for authentication-related storage.
I also had an expiring Provisioning Profile.
In the documentation for keychain access it states:
On iPhone, Keychain rights depend on the provisioning profile used to
sign your application. Be sure to consistently use the same
provisioning profile across different versions of your application.
Because my Provisioning Profile was expiring, I renewed it (in the provisioning portal), downloaded it, and double-clicked it which "installed" it into XCode's organizer.
After submitting an update to the app to the app store, I'm basically seeing an empty keychain (user's are being asked to log in again).
My question is: does renewing the provisioning profile used to sign an app affect keychain access when the renewed profile is used to submit an update to the app? The docs just say to use "the same provisioning profile", but is unclear about whether a renewed profile counts as a different profile (as my experience described above suggests).
What gives?
Update
Solved with help from tc's answer. Looking at the embedded.mobileprovision file in each of the .ipas submitted to apple revealed that an expiring certificate and provisioning profile were used to sign version x of the app, and a different certificate and provisioning profile was used to sign version x+1 of the app (culprit: "Automatic Profile Selector" feature of XCode for the Code Signing Identity).
The 1st certificate and profile were leftover from when a developer used a different iOS Developer Program account to develop an unrelated app (on the same machine, with the same OSX user). Provisioning profiles across multiple iOS developer program accounts are apparently all stored together in ~/Library/MobileDevice/Provisioning Profiles, so they are all candidates for XCode's automatic profile selection feature.
I changed the code signing identity by selecting a totally different distribution profile that I mistook as a renewed/valid version of the expiring distribution profile, and submitted an update. Same app, different cert, different provisioning profile == empty keychain. D'OH.
The keychains you're allowed to use is determined by keychain-access-groups in the entitlements, which is limited to a subset of the keychain-access-groups in the provisioning profile, which is determined by the "bundle seed"/"prefix"/ (ApplicationIdentifierPrefix in the provisioning profile), set in the "App ID".
Assuming you've kept the old submitted app (or have the .ipa from iTunes, which is just a zip), look at embedded.mobileprovision in both the old and new apps (less Foo.app/embedded.mobileprovision in a terminal should do the trick, or you can open it in a text editor although sometimes they'll pick the wrong line endings). You're looking for something like this (you may see extra keys for push/iCloud):
<key>Entitlements</key>
<dict>
<key>application-identifier</key>
<string>A1B2C3D4E5.com.example.MyApp</string>
<key>get-task-allow</key>
<false/>
<key>keychain-access-groups</key>
<array>
<string>A1B2C3D4E5.*</string>
</array>
</dict>
You can also view the actual entitlements your app was signed with:
codesign -d --entitlements - Foo.app/Foo | vis
IIRC the keychain access groups default to e.g. A1B2C3D4E5.com.example.MyApp, but you can set this to anything you want provided it matches A1B2C3D4E5.* (Xcode 4 even has a nice GUI entitlements editor). If the bundle prefix is different, that'll cause the problem you're seeing. I think you can change it back provided you haven't enabled push/Game Center/etc.
As long as your app's bundle id doesn't change there won't be any issue with the keychain.
Considering that we all have to renew our certificates and distribution profiles every year, it would be chaos if doing so broke the keychain access for our apps.
I have one app that's been in the App Store for over 4 years. It uses the keychain. It has been updated several times over the years, many times with an updated provisioning profile. There have been no keychain issues.
For anyone else searching, I had a different issue. The manual steps I followed to resign the ipa resulted in it having no entitlements, which means no keychain access. So I created a script to resign the ipa but keeping the entitlements from the original. I posted it at http://baltaks.com/2013/08/resigning-enterprise-ios-apps and will keep that updated if required.
I am currently about to start work on an iOS app for somebody but they have there own Apple Developer account which they would like to us. How do I go about setting my MAC up so that I can use their account to build, develop and test their app on my Devices?
I am assuming that I will need to create a separate user account on my MAC. I have done this but when I try to install the certificates that they have created I get errors such as "Valid signing identity not found".
Why could Apple not make this process simple, I am always having to refer back to the documentation and still get confused just to start creating a new app!
You do not have to create a new user account on your Mac for this, but I know some developers prefer to have separate accounts when they are working with more than one developer account, for ease of development & distribution provisioning profiles.
If your client adds you (by Apple ID --> email address) as a team member to their account (assuming their account belongs to a company and not an individual) then you can start the development process by requesting and later receiving a signed development certificate. You'll then also need the required provisioning profile(s) to develop/distribute builds of the app.
No, you won't need to create separate account. Xcode provide the facility to use several provisioning profile and certificate at the same time.
For more information check this thread - Multiple Certificates/Provisioning Profiles in one Xcode organizer?
First of all you don't need to create new account on your Mac to develop iOS application. In Xcode 4 it become very easy to start developing and signing application. All you need to do is go to Organizer (most right button on Xcode toolbar). In Provisioning Profiles section you can see Refresh button on the botoom of the screen. When you click it ask you about your developer account information such as account name and password. Then it tries to install all profiles and certificates to your Mac automatically. Then you could select your profile and sign your app. If automatically install fails, check yourself that you download all you need for this.
Create keys on your mac and submit to Apple.
Download your certificate and WWDR certificate. Two!!!!
Add your device to the devices section and create Development certificate (Distribution as well ). Download it manually or via refresh in Xcode Organizer.
Hope it helps. Sergey!
Once you have your Apple Developer Account Credentials, You can follow gist I have created:
Apple's Code Signing Process
sorry for my bad english but i'm italian.
I have to release an app that will work on only a few devices. What should I do when the provisioning profile expires? Will the app continue to work or should I release it again with the updated profile?
thx all
No the app will not work after the mobileprovision expiration date. You need to renew your mobile provision, build again and sign the app with new certificate and resent to users the new mobile provision file and the new app.
Edit:
You can submit for an enterprise account an you will not have this issue again.
Not sure what you're really asking, but here is a quick answer with some points that might help you.
Ad hoc provisioning profiles last for 1 year. After a year the certificate is invalid and the application won't work any more. At this point you will have to create a new certificate (usually just renew the certificate will work) and re-release built against the new certificate. This will mean that anyone using the application this way will have to remove the app from their device and install the new package you send them.
When you release an application on the app store the certificate is permanent, you don't have to renew anything and apple will deal with it itself.
If you archived it, all you need to do is create a new .ipa (by selecting "Share" in the organizer) and sign it using the new profile.
If you didn't archive it you need to build it again and you'll need to reselect the code signing identities in the project settings.
Either way you need to send a new build or a re-signed archive to your testers, the new profile alone won't work.
In the Keychain Services Programming Guide it states the following:
"On iPhone, Keychain rights depend on the provisioning profile used to sign your application. Be sure to consistently use the same provisioning profile across different versions of your application."
Which I have no problem with but I would like to test that if I provide an update to my app in the AppStore that it will still be able to access the old values stored in the keychain. I have tried to test by updating the app with a version signed with an ad-hoc distribution profile that contained the same bundle id and product name as the original but it could not access the old value in the keychain.
Is the only option to submit the update to the AppStore and hope that it will work?
This is a good question.
One of the main reason why you might want to store some data in the keychain is to prevent malicious users from accessing it. This is quite a dry sentence on its own so I recommend reading about how someone might access that data.
Another way to access keychain data would be to create a malicious app with the same app ID as the target app. Apple have secured this route by requiring the provisioning profile to be the same.
So, to answer your question, you can only test the keychain data in update from the same provisioning profile, i.e.
Ad hoc to Ad hoc
App store to app store.
App store to app store is not really an option since it will be too late by then (your update will be on the market). So instead you need to delete your app store app and install an ad hoc version. Then recreate your data on the keychain, then update to the latest ad hoc version and test that it worked.
Of course this requires you to have an archived ad hoc version of the app thats currently on the app store. If you don't have this, then its not possible to test an update.
Unless I am mistaken, to update an app in the app store you need to use the same provisioning profile. Therefore, since you will be using the same profile, you should have access to the same keychain items.
It's actually not the provisioning file that matters, but the app ID. Specifically the Bundle Seed ID that you set when creating an App ID. Keychain access is governed by it. So as long as your profile uses an app ID with the same Bundle Seed ID you can continue to access the info in the keychain. I have a few apps that do this.
This allows you to to create a suite of apps that can all access the same keychain items as long as you set them to use the same Bundle Seed ID. So if you do a light and a pro version, they can both access the same keychain info while maintaining separate bundle identifies for things like user defaults.
SFHFKeychainUtils may be your good choice.
It's a wrapper to access keychain.
More about: SFHFKeychainUtils :http://www.ioslib.com/archives/sfhfkeychainutils/
I want to update an existing App in the App Store, but the profile I used expired (I'm not sure, if it has something to do with the corresponding certificate which also expired..). Since Apple tells me in the How-Tos:
Use the same Distribution Provisioning
Profile to build each new version of
your application
I don't know, what to do. Can anyone help?
The important part is keep the same bundle id.
If your provisioning profile has expired or you has to generate another certificate, it doesn't matter.
Get anew version of you provisioning profile, build your app and it should be fine.
If the profile is expired, simple renew it or generate a new one. I did it yesterday, my dist profile was expired and I simply deleted it and generated a new one.
Once a new one certificate is generated, download it, delete the old one from your keychain and add the new one.
After that, try to build your app. (Sometimes restarting Xcode is required)
Every profile and every certificate will expire. As long as the developer account is still the same, simply creating a new distribution cert should do the trick.
You need to keep exactly two things the same: the enrolled iOS Developer account you use, and the Target Identifier Property in Xcode (becomes the Bundle Identifier in the app). Do that, and the result will be an update to the same app in the App store.
Everything else you can renew, recreate in the portal, install on a new Mac, etc., including App IDs (wildcard on not) created in the portal, Developer or Distribution certificates, and provisioning profiles in the portal, installed in Xcode or on the iDevice. You can also change the Bundle display name (under the icon), the Product name, the Target name in Xcode, and maybe even the name of the app as it appears in the App store (if it's not misleadingly different).
Renew your certificate and provisioning profile at the iOS Developer Portal.