Try to commit my first iPhone application to Subversion found that there's "code signing identity" section in my xcode project.pbxproj file.
CODE_SIGN_IDENTITY = "iPhone Developer: my username here...;
"CODE_SIGN_IDENTITY[sdk=iphoneos*]" = "iPhone Developer: above...";
The issue is, in our team we use different provisioning which bound to our device. So when other want to run the code on device, they have to change this line. We can share one provisioning to across this, but that way have several downside. Is there any other way to solve it? i.e. include code signing section to another file which not commit to SVN?
As long as you have just one signing identity, you can just use "iPhone Developer" as your codesigning identity. Codesign will search for an identity containing "iPhone Developer" and use that.
You can base a project or target configuration on the contents of an xcconfig file that is not checked in to Subversion or is otherwise customized per developer. Add an appropriate xcconfig file to your project and then choose the file from the "Based On" pop-up at the bottom of the Build tab in the Project Info or Target Info window.
For example, you could have a DeveloperSettings.xcconfig file in the project whose contents on your system are:
CODE_SIGN_IDENTITY = "iPhone Developer: favoyang"
while its contents on my system are:
CODE_SIGN_IDENTITY = "iPhone Developer: cmh"
These settings will be inherited by either the project or target configuration that is set to be based on this file.
You can use $(USER) in your build setting definition to include your short user name.
For example:
CODE_SIGN_IDENTITY = "iPhone Developer: $(USER)";
That will use the contents of the USER environment variable in the definition of the CODE_SIGN_IDENTITY build setting.
The obvious choice would be to create other build configurations.
Why are you "changing this line" directly? You should almost never directly edit anything in the .xcodeproj file bundle.
Instead, you should be changing this within your build settings. To be more specific in your case, you need to add several more build configurations, one for each member of the team. That member can then build using their own provisioning file withouth messing with any other build settings.
Related
How do I set the provisioning profile int he export_options for gym in fastlane? I have my profiles in my Documents folder. Does gym automatically locates it or I need to specify the path to the file? I know using match is the preferred way but right now I'm still asking permission if I can upload provisioning profiles and certs in git. So in the meantime I'm doing it without match. Can someone help me with this. I'm new to fastlane and I'm not a swift dev.
How do I set the provisioning profile int he export_options for gym in fastlane?
A: If you run xcodebuild -help you will see the available keys for the export options and their configuration:
provisioningProfiles: For manual signing only. Specify the provisioning profile to use for each executable in your app. Keys in this dictionary are the bundle identifiers of executables; values are the provisioning profile name or UUID to use.
Does gym automatically locates it or I need to specify the path to the file?
A: Yes it does, in the same way than Xcode does, since gym is kind of a wrapper for "xcodebuild" command (the one that Xcode uses of course). So by providing the name or UUID should be enough. Of course this means that the provisioning profiles should be downloaded on your machine, Xcode -> Preferences -> Accounts -> Download Manual Profiles should do it.
You can see this lane as example:
desc "your description"
lane :release do
gym(
workspace: YourApp.xcworkspace",
scheme: "YourApp",
configuration: "Production",
output_name: "YourApp.ipa",
export_method: "app-store",
export_options: {
signingStyle: "manual",
provisioningProfiles: {
"YourApp.bundle.id" => "The name of the provisioning profile",
"YourApp.bundle.id.OtherExecutable" => "The name of the provisioning profile"
}
}
)
end
I don't want to create another repro to host only the certificates and stuff so I prefer to do it manually too.
Understanding how the signing works fro iOS can be a little tricky, this article helped me a lot to fully understand it. If you want mode details feel free to ask :)
Do a manual build, export with Xcode and copy the generated ExportOptions.plist file
I am trying to create a LITE version of my iPhone app by using different targets. So I have duplicated the release target 'Checklists' and it will name it 'Checklists copy'. I have managed to change the name of the actual .app that is created but not the target name. Any ideas?
So the .app is named via the product name. The target name is an identifier for the build settings, which are actually built using a scheme. The name you see when selecting what to build is a scheme, and you can rename those by clicking on the bar and going to "manage schemes".
To rename the target you just click on the name and it will turn into an edit box.
I have seen a few questions similar to this. So the target settings override the project settings. I got that, but if I don't want to override the project settings, is that what the "Don't Sign" option is for?
What am I supposed to do after archiving my app, when it asks if I want to re-sign it? If I have set the signing at the project or target level, should this be set to "Don't Sign"? What happens if I elect to re-sign it? Does the signing done during the previous archiving step get overridden and replaced with the new choice?
Can I look into an archive (.ipa) file and see what provisioning profile was used? I don't see the option in Finder to open it like I can open other bundles. How can I do this?
Just unzip the ipa (unzip appname.ipa) and do the following on the results:
codesign -dvv Payload/appname.app
It should show you the cert used.
I inherited some source code and am now trying to adhoc compile it.
However, I'm seeing this error message
CodeSign error: The entitlements file '/Users/teepusink/Documents/i_think_the_original_guys_path/Entitlements.plist' is missing
Where can I change that path? I do see that there exist an Entitlements.plist file and I've changed the Code Signing identity to mine.
Thanks,
Tee
Got the same problem and had to fix it manually in the XCode project file. XCode did not accept my changes via "Get Info".
make a backup first!
open your .xcodeproj file by right clicking the file in Finder.app and selecting "Show Package Contents"
open project.pbxproj
search for "/Users/teepusink/Documents/i_think_the_original_guys_path/Entitlements.plist"
delete the lines with CODE_SIGN_ENTITLEMENTS = "/Users/teepusink/Documents/i_think_the_original_guys_path/Entitlements.plist";
After that I was able to re-add the Entitlements.plist file and it showed up there with the correct path and the build process ran without errors.
You can change it by right clicking on your Target under Targets in Groups & Files, hit the 'Get Info' option. Select Adhoc from the Configuration dropdown at the top left, then change Code Signing Entitlements to the path of the Entitlements.plist file located on your computer.
Another easy way to fix a path is to just delete the file reference in your project, make sure the file is where you want it (move, copy, check out from the repository), and then (re)add the file/plist to your project.
I'm collaborating on an iPhone application, with the project files (.xcodeproj directory) checked into source control. One important setting is the "Code Signing Identity", which specifies the certificates to use to sign the application in order that it can run on the iPhone.
Each developer on the project has his own Code Signing Identity, so whenever anyone makes a change to the project, his Code Signing Identity gets saved into the project settings, and then everyone else inherits that change. They then have to change that to their CSI before they can continue.
Is there a way to have the Code Signing Identity saved in some local per-user project file that doesn't get checked into source control?
You could base the Xcode project on an .xcconfig file, then make each developer use their own .xcconfig file and keep the identity setting in there.
Either that or have your source control system ignore the file that contains the signature, in git you can create a file called .gitignore, theres probably a similar thing for what you are using. It means even though you've changed it the change won't get mirrored.
I worked around this by making different builds. The one named "Dev - Rob" had my settings in it, and the one named "Dev - [Other Guy's Name]" had Other Guy's settings.
We also used this to make builds like "Release - Beta" and "Release - AppStore" etc., for all situations where we'd have different signing configurations.