My employer recently entered into an agreement with another company to share the source code for an iOS app that we developed. We haven't yet published this app in the App Store but plan to do so in the future. During the course of development, we've obviously created an app ID, provisioning profiles, certificates for development and remote notifications, etc. all of which are (obviously) tied to my employer's enrollment in the Apple Developer Program (ADP). The app itself is currently configured to allow Xcode to manage signing automatically.
Before we deliver the source code for this app to the other company, I need to make sure that none of my employer's information is present in the project source (so that the other company has to use their own info). I've looked through all the project-related files I could find and the only thing I really saw was a small section in the project.pbxproj file that looks like it is related to signing.
I would guess that this is something that a lot of people who decide to share their source on Github do but I'm still fairly new to iOS/Xcode app development so I was hoping that someone who has dealt with this before could offer some insight? Thanks very much!
If you just want to make sure they cannot get your company's signing identity, you can just send them the project. Since you are using automatic code signing, they would need to have your company's Apple developer ID credentials to sign in to the developer account in order to have Xcode generate a certificate and profile to sign as your company. None of the critical signing files are included in the Xcode project folder.
When you enable automatic code signing and sign into the Apple ID, Scode will generate a certificate and private key, which go into that Mac's Keychain, and a provisioning profile is generated and downloaded, which goes into a specific directory that is common for all projects (https://stackoverflow.com/a/45642752/3708242) and outside of the project directory.
As #Jack states in his answers, there are other pieces of information in the files you might want to scrub, but there is no risk you would be giving them access to your code signing information by sending them the project as is with automatic code signing turned on.
Long story, short, just send them the project directory.
Just clear the bundle identifier in Project->General->Bundle identifier -> set it empty.
For notification other company/Vendor will use there separate certs with respective Apple account.
In every top lines of .swift files there is commented by default code which includes Mac name, you can remove it.
Related
Here's the story:
I created a free developer account to build an app for a client.
I used this info for the Identity and Signing:
It came time to upload the app to TestFlight and to use the client's developer account.
I created the account in xcode using their apple id and updated the signing like so:
But now I got this error.
It was clear, so I updated the Bundle Identifier to this:
But again, now I am getting a different error, and I don't know what to do.
I do not have an iOS device to register, nor do I care to get one, since I'm not doing the testing - they are.
I did create an app in the App Store Connect, and it is set up like so:
As you can see I created it to match the Bundle ID from before and still no luck.
Any help is greatly appreciated. I just want to be able to get my Xcode project onto TestFlight using someone else's developer account (with their consent of course).
It needs to have at least one iOS device registered in order to create the development profile. Ask your client for the UDID of one of their devices and add that manually to the developer portal. If they don't have one handy, feel free to use: f978c5f2e861f71b340125a4fa8d130a6254a0b3 which will work.
Alternatively, switch to manual signing and do everything manually. That's my preferred method, but some say Xcode is finally good at managing profiles etc for you.
The only way to do this without a device is to turn off "Automatically manage signing" and manage everything at the Member Center.
You will need the distribution identity / certificate first. If the team already has one, you will need them to export it to you; otherwise you cannot upload.
Then register the app.
Then make a development certificate, and a distribution certificate for the app store, and download and install them.
Now you can archive and then export to the app store.
I'm using Xcode 6.3.2, and I'd like to let another people to build and create the .ipa files of my projects, but I don't want neither to expose my Apple Developer account information, nor create users for them in my team... is that possible? Either by using Xcode, either by commands line.
Thanks in advance
EDIT: The goal is to prevent those external people from being able to submit apps to the App Store by means of my Apple Developer account and from being able to see the other apps managed in the account.
EDIT2: Does providing the distribution certificate to external people make possible to them to submit binaries to the App Store?
After reading your edits, I think I understand more clearly what you are trying to do. Basically, you will simply need to provide the other members of your team with the following:
The private key used to generate your app store distribution
certificate.
The distribution certificate
The app store distribution
provisioning profile
This will allow those team members to work on, and build the app for the app store. Without your Apple developer ID password, they will not be able to log into iTunes Connect to see the other apps you have. While they will be able to build the app for app store distribution, you (as the only one with the apple ID password) will have to be the one to submit the compiled app to the store.
So basically, your development team will create the apps. When you're ready for release, they can do an "Archive" in Xcode to create the .app that has been signed for the app store (using the provisioning profile and signing identity that you provided them in the three files I mention above. They will zip up the .app and the .dSym files into a .zip and send it to you. You will then log into iTunes Connect and set upt the app to be ready for the new binary, and then use the Application loader to upload the .zip to apple for review. Once you have gotten a successful review, you will again log into iTunes Connect to release the app. So at no point will the developers have access to submit apps or see other apps you have in the store.
Also, the development team will not need the provisioning profile, cert, and key until they need to build for the app store. During the development phase, there is no problem with them using their own developer accounts to build and test the app.
One additional thing to note is that Apple is changing the roles that are available in iTunes connect. You may want to review those new roles to see if some combination of those roles my work for your team setup.
From http://9to5mac.com/2015/06/12/wwdc-itunes-connect-testflight-limits-account-switching/
After several apps are added to an account by its admin, developers
can now assign user roles to individuals on their team— app manager,
developer, or marketer— with each allowing varying access to iTunes
Connect features. App managers, for example, will be able to create
users, assign user roles, change pricing, and submit apps for review.
Marketers will get access to updating store metadata, uploading promo
material, and requesting promo codes. Users assigned the developer
role will be able to upload binaries, and view crash logs and store
metadata.
Apple recently introduced Free-provisional-profile and/or free-developer-certificate support.
But it's limited (see below note).
To utilise that follow below steps suggested by Apple,
In Xcode, add your Apple ID to Accounts preferences, described in Adding Your Apple ID Account in Xcode.
In the project navigator, select the project and your target to
display the project editor.
Click General and choose your name fromthe Team pop-up menu.
Connect the device to your Mac and choose your device from the Scheme toolbar menu.
Below the Team pop-up menu, click Fix Issue.
Xcode creates a free provisioning profile for you and the warning text under the Team pop-up menu disappears.
Click the Run button.
Note that said support is limited, for example, the capability to sell things with "Apple Pay" would not even build with a free-certificate.
Yes, there are several ways to solve your problem.
You can create .ipa file with you provisioning profile and give them the file, they can you use application called "Application Loader", they can use this application to upload the .ipa, this should resign your application with their provisioning profile. I did not try this but it should work.
When you create an archive of you application, it will be listed in "Organizer", go to that location, and give them that .app file alone. Then they can use any third party application(can be downloaded from Mac Appstore) to resign the application with their profile. In this case, you are completely hiding your information. They can even change the application icon, default image.. etc during the resigning process.
When you build your application in release mode an .app file is created, this is unsigned binary. You can search for .app file in your Xcode project itself. Just find the location, and give them that .app file alone. Then they can use any third party application(can be downloaded from Mac Appstore) to resign the application with their profile. In this case, you are completely hiding your information. They can even change the application icon, default image.. etc during the resigning process.
Hope this helps.
No, There is no way to compile a .ipa without a provisioning profile (device compile, not simulator compile). To do this, you would go XCode->{AppTarget}->Build Settings->Code Signing->Code Signing Identity, and set 'Don't code sign".
Trying to compile afterwards will fail with
CodeSign error: Code signing is required for product type
'Application' in SDK...
EDIT: The goal is to prevent those external people from being able to
submit apps to the App Store by means of my Apple Developer account
and from being able to see the other apps managed in the account.
You have two options:
Send them your Source code + XCode Project, and not the library.
Compile the code using "iOS Developer" Code Signing identity, and not "iOS Distribution" identity.
Anything signed with iOS Developer can never be sent to the AppStore.
Anything signed with iOS Distribution can never be run on a device
unless it is downloaded from the AppStore.
They can never see what you have for sale, nor publish anything unless they have your AppleID username and password
When you build a project in xcode, you specify the provisioning profile/certificate pair in the build settings, and when exporting an archive, you specify an additional provisioning profile to use. What is the reason for asking for this information twice?
Edit for clarification: I've gone through the contents of a bunch of my generated .ipa files, and there seem to be two locations that pertain to signing/provisioning. The document in the _CodeSign folder (which seems to contain encrypted hashes of the file contents, to verify contents/source), and the .mobileprovision file, which seems like it would be added when the build is exported. At this point in time, I don't see anything that would indicate the purpose of the provisioning profile selected in build settings.
You specify a provision profile in the build settings that Xcode uses to sign the app. This makes it possible for you to run your app on a device during development, for example. If I remember correct, in the past the project build settings was the only place where you could specify the profile to use, so you'd typically set the Debug build to use your development profile, and your Release build to use the distribution profile.
At some point (Xcode 4, I think), application archives were introduced to make things easier for developers. You create a single archive and then distribute the app it contains in different ways. You can do an ad hoc distribution to send out to your testers, and then you can use the very same archive to submit to the app store, or create a version for enterprise distribution, depending on the type of program you've joined. But since different distribution methods require different profiles, Xcode asks you for the profile you want to use when you distribute.
Xcode's Archive function is a huge convenience -- it takes a lot of the complexity out of submitting your app, and also takes care of saving the symbols file for each version you distribute so that you can make sense of any crash logs you might receive. It's a recognition of developers' need to use the very same build of an app in different ways. If it seems a little odd that you specify the provision profile to use in two different places, so be it -- that's a rough edge that might get cleaned up in a future Xcode version.
I don't know of any authoritative information on exactly how app signing works, but I think it goes like this:
the provision profile contains your certificate (which includes your public key), and is signed with Apple's private key
you sign your app with the private key that is the counterpart to the public key in your certificate
the device uses Apple's public key to authenticate the profile, and then uses your public key from the profile to authenticate the app signature
if everything matches up, the device will run the app; if not, the app will fail to install
Forget about the "app binary" and "ipa" being signed separately -- I think that's a red herring, and it's unlikely that iOS has to validate two different signatures.
Not sure, but think - First time xCode sign just binary app, and second time whole .ipa archive.
I've recently taken over a project as a freelancer. I have during the development used my own account so I changed most of the debug/release/etc to my own "iPhone developer" etc in the project.
Now, however, it is time to send the update to the actual app store. I've gotten access to the last developers account, I've downloaded the distribution profiles which I assume I need.
The problem now is that, as far as I understand, I need the last developers ".developerprofile" for signing purposes. Or is there some other way? I can't seem to download it from the apple developer account.
This is the first time I am doing any kind of release so I am a bit shaky on the whole provisioning stuff as I've only developed locally and for that xcode manages everything perfectly so far.
If you can you need to get the P12 file from the previous developer - stack overflow
You actually do not need the previous developer's certificate or provisioning profiles in order to continue the project on your own.
It's relatively easy to revoke the previous developer's certificate and provisioning profiles (via the Apple Developer Portal) and recreate new ones on your machine.
Once you log into http://developer.apple.com/ios, look for the "Certificates, Identifiers & Profiles" section.
we have a little Problem here and I hope you guys can help me out!
Situation:
We are enrolled in Apples Developer Program (for distributing Apps in the App Store). Since last week we're also enrolled in the Enterprise Program (for in-house App distribution).
Problem:
We proceeded with the development and building of the Apps. But we didn't knew that we have to use two different developer certificates for the different Programs. We have now 2 certificates with the same name and XCode is producing an error message each time we want to build the app saying "the certificate cannot be assigned exactly".
Question:
How do we change the name of one of the developer certificates?
Many thanks for your help in advance!!!
You already have default login keychain So you can add one certificate in login keychain. And then create new saperate keychain with different name and add your second certificate to that keychain. Now in your Xcode target setting find keychain certificate path to be used for target and choose appropriate keychain path.
e.g. For one certificate path ........./login/.....
For another certificate change path to ......../mynewkeychain/......
I feel your pain, as I have been in the same situation before. You can't easily change the certificates' names. Apple usually does not allow that. Dhawal's answer is correct, in that you will have to put your certificates into different keychains.
If you want to script your build process, you have to unlock and lock the appropriate keychains security unlock-keychain before you call xcodebuild. So that only the one certificate you want to sign with is accessible.
There are two very good projects that make managing the keychains and building a lot easier:
Openbakery's Gradle Xcode Plugin
rayh's xcoder for use with rake