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.
Related
so I've developed an app. Now I manually placed the .app file into the /Applications folder of my iphone (root). Than I did:
It sounds like the application isn't
signed. Download ldid from Cydia and
then use it like so: ldid -S
/Applications/AccelerometerGraph.app/AccelerometerGraph
Also be sure that the binary is marked
as executable: chmod +x
/Applications/AccelerometerGraph.app/AccelerometerGraph
(via)
Than I used UICache to make the app visible. And if I run it it shows a black screen for a 1/4 second and then it closes...(I'm not a member of the iphone dev program).
Did I something wrong?
Is there a better way?
Thank you very much! :)
I just spent a perfect Saturday afternoon looking for a solution to the exact same problem. It is a code signing problem.
Here is what I was using Xcode4 and iOS 4.3 SDK . I was building to a test device an iphone 3G running iOS 3.1.2 (jailbroken)
NOTE: ldid method did not work for me and kept on throwing the following error (Some Details on why its not working I tried using armv6 architecture through xcode4 but ldid still gave the same error):
codesign_allocate: object: MyAppName.app/MyAppName malformed object (unknown load command 4)
util/ldid.cpp(582): _assert(0:WEXITSTATUS(status) == 0)
Here is what worked for me:
Step 1. Create a Self Signed Certificate.
1- Launch Keychain Access.app. With no items selected, from the Keychain menu select Certificate Assistant, then Create a Certificate.
Name: iPhone Developer
Certificate Type: Code Signing
Let me override defaults: Yes
2- Click Continue
Validity: 3650 days
3- Click Continue
4- Blank out the Email address field.
5- Click Continue until complete.
You should see "This root certificate is not trusted". This is expected.
via (note: you dont need to be a member of the iphone dev program to make this work even though the title of the accepted answer in the link might suggest that)
Step 2. Set xCode to allow the self-signed certificate to be used
You have to edit the Info.plist file under /Developer/Platforms/iPhoneOS.platform/Info.plist
(I have installed xcode at a different location so that path for me was xcode4/Platforms/iPhoneOS.platform/Info.plist)
1- You will not be able to edit the file in its current location so just copy it to the desktop and open it in a text editor.
2- You need to Replace all instance of XCiPhoneOSCodeSignContext with XCCodeSignContext and save the file.
3- Then drag and drop the edited file back to iPhoneOS.platform folder and replace the old file. (Make sure xcode is not running if it is then restart it)
Step 3. Change the Code Signing Identity setting in your project
Change the code signing identity for your project and your target to iPhone Developer
1- In xcode4 you have to select your project (from the left navigator panel) -> Select you Project from the center under (PROJECTS) -> Build Settings -> Code Signing (expand the menu) and change all options to iPhone Developer
2- In xcode4 with your project selected from the left panel in the center of the screen you will see PROJECT and TARGETS. Now select the targets and do that same: Targets -> Build Settings -> Code Signing (expand the menu) and change all options to iPhone Developer
Step 4. Build the App and Deploy
1- Make Sure at the top of xcode next to the run and stop buttons under Scheme you have iOS Device (your device name) selected and NOT Simulator (this is how its done in xcode4)
2- Open the Scheme menu and with the iOS Device Scheme selected click edit scheme. Select Run from the left menu and under the Info tab set Build Configuration to Release
3- Now make sure you have your iOS device connected and its scheme is selected and hit Run (note: you will get some warnings but as along as the build succeeds you are okay)
if all goes well you should be able to see YourApp.app under the Products folder on the left side now select YourApp.app open it in Finder. Your app should be in a folder called Release-iphoneos Copy it to /Applications dir on your iOS device and respring or UICache to make it appear. (note: you dont need to use ldid now)
Hopefully your app will launch fine. I have only tried this with xcode4 so not sure if it will work for older versions.
Whenever I run 'build and archive' from XCode I get the following message:
Unable to copy dSYM file into archive.
Please make sure that your application has set the “Debug Information Format” build setting to “DWARF with dSYM File”.
I have checked my Debug format and it is set to the suggested value(DWARF with dSYM). Has anyone else ran into this issue, if so how did you fix it?
Try setting 'Generate Debug Symbols' to true in the build settings of the target you're trying to build and archive.
This solved the issue for me!
this worked for me ,i hope it help someone out there...
Goto to the build setting and search for "Generate debug symbol" and set it to Yes.
then search for debug information format in build setting and set "Debug information format" to "DWARF with dSYM file"
I just ran into the same problem, but I had an build script which removed the dSYM file before Xcode could. So it wasn't there and that was what Xcode was crying about.
I attached a screenshot, so perhaps the next one which runs into that problem can recover a bit quicker from that.
The 'Generate Debug Symbols' solution worked for me as well. After it worked once, I disabled the setting again, and I build & archive worked again, producing a file smaller by 700kb than the debug symbols enabled version. Not sure if this is actual savings after the app is on the app store, but it doesn't hurt!
That's how your build settings for both release and debug configuration should look like:
Generate Debug Symbols → Yes
Debug Information... → DWARF with DSYM
Deployment Postprocessing → YES
Strip Linked Product... → No
Strip Debug... → No
If there's still no luck, try check the Report Navigator.
The point is, dSYM file may be generated in another location, or not generated at all.
In my case, the dSYM file has not been generated, and there hasn't been a corresponding line that goes like "Generate Appname.dSYM ...in {path}"
But there's been Fabric installed, and it logged the fact of the dSYM file's absence:
Just filer the Report Navigator by "dSYM".
If dSYM is not generated in appropriate folder
Check environment variables, especially DWARF_DSYM_FOLDER_PATH and DWARF_DSYM_FILE_NAME.
To embed the dSYM within the app bundle, just set DWARF_DSYM_FOLDER_PATH to $(CONFIGURATION_BUILD_DIR)/$(EXECUTABLE_FOLDER_PATH) and DWARF_DSYM_FILE_NAME to $(EXECUTABLE_NAME).dSYM
Now the build should create dSYM for your target
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.
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.
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.