Related
I've developed SOL, an open-source macOS launcher.
Inside of SOL, I added the ability to run AppleScript commands, one of these commands allows me to lock the computer:
{
iconImage: Assets.LockIcon,
name: 'Lock',
type: ItemType.CONFIGURATION,
callback: () => {
solNative.executeAppleScript(
`tell application "System Events" to keystroke "q" using {control down, command down}`,
)
},
},
I have also added the correct entitlements for the hardened runtime (it is distributed only via DeveloperID and not via app store, so hardened runtime is the only capability needed)
<key>com.apple.security.temporary-exception.apple-events</key>
<array>
<string>com.apple.systemevents</string>
<string>com.apple.systempreferences</string>
</array>
The problem is: when I run the app via XCode it works fine, but once the app is packaged and distributed via DeveloperID signed binary, then the lock AppleScript stops working.
Looking at System Preferences I can see the app is still registered and has automation access:
Why does the script stop working? If I remove the permission and re-add it then it starts working again. Does it have to do with the binary? Or is there some permission model I am missing? I had a similar problem with folder access with a different app, so could it be something similar (a security feature I'm not aware of?)
EDIT 1:
Looking through the console.app logs there is also no error message.
EDIT 2:
I just managed to reproduce the issue while attached to XCode and log the output of calling the AppleScript:
Optional({
NSAppleScriptErrorAppName = "System Events";
NSAppleScriptErrorBriefMessage = "Sol is not allowed to send keystrokes.";
NSAppleScriptErrorMessage = "System Events got an error: Sol is not allowed to send keystrokes.";
NSAppleScriptErrorNumber = 1002;
NSAppleScriptErrorRange = "NSRange: {36, 48}";
})
But the app does have accessibility permissions but this still happens? 🥴
EDIT 3:
I just tried removing the app from the accessibility panel and re-adding it, and now the script works again. I killed the app and started it again, and it still works. So my guess right now, is that it has something to do with the binary. Maybe if I replace it with a new version then the accessibility setting doesn't work anymore?
After much gathering at hints all over the internet, I've come to the conclusion that the problem lies in having different binaries.
It makes sense that macOS does some binary check to make sure the application has not been swaped. I had therefore two binaries in my machine a "release" one, which was DeveloperID signed. And the XCode debug one, which uses a development certificate. So both are different and therefore do not pass the binary check.
The brute force solution is not to have a release version installed in my machine. Another solution would be to have the debug binary have a different bundle ID (com.ospfranco.sol), so that macOS allows both the release binary and the debug binary to have accessibility access.
My app's development provisioning profile expired a couple of weeks ago, so I went to the provisioning portal to get a fresh new one. After obtaining it, I visited the Xcode Organizer, removed the expired profile from my devices as well as my Mac, then imported the new profile. Xcode installs the profile onto my devices immediately, and my app runs again on the devices.
The problem is that while the Organizer is able to see the new profile and install it as normal, the IDE gets confused between the old one and the new one. Every time I try to build the app, it fails immediately. The error console tells me that Xcode can't find the old profile, because the GUID listed belongs to the old one. That's strange; I thought Xcode would've been aware of the new profile by now.
I've tried removing the new profile from my devices and my Mac, then reinstalling the profile. Doesn't work, Xcode is still trying to look for the old one. I've also tried selecting a different profile to make Xcode forget the old one, then selecting the new one. I've even tried manually entering the GUID of the new one in the Other choice. Yet Xcode still insists on looking for the old profile, which by now is already gone from my Mac.
How do I convince Xcode that I've generated a new provisioning profile for my app for it to use?
tl;dr: turns out I simply had to edit the project file manually to tell Xcode of the new profile. Now, I don't know why I had to manually update the project file. Perhaps I did something wrong during the process of importing the new profile to Xcode, so it didn't realize my new profile had come in. Or the file system choked midway and Xcode wasn't able to update itself. Oh well.
Now for the fun technical part:
IMPORTANT: As with anything else that involves modifying files you shouldn't be modifying: make sure to back up your .xcodeproj bundle and/or your entire Xcode project, or make sure your Xcode project is kept in proper version control. You don't want to mess up and cause Xcode to stop building your project onto your device, without anything to fall back on.
I peeked into the contents of my app's .xcodeproj bundle (Xcode is not running at this time). To view these, open your project folder in Finder, then Control-click on your .xcodeproj file and choose Show Package Contents:
Breeze.xcodeproj/
Daniel.mode1v3
Daniel.pbxuser
project.pbxproj
Then opened project.pbxproj in a text editor (it's text, not binary), and looked around for build configuration information.
There's a section labeled /* Begin XCBuildConfiguration section */ (which you can find using your editor's search function). It's a list of entries, each of which represents a code-signing configuration for a given profile in a given build configuration.
Here's information about the profile I use to sign my binary for development:
1D6058940D05DD3E006BFB54 /* Debug */ = {
isa = XCBuildConfiguration;
buildSettings = {
ALWAYS_SEARCH_USER_PATHS = NO;
"CODE_SIGN_IDENTITY[sdk=iphoneos*]" = "iPhone Developer: Daniel Tan (XXXXXXXXXX)";
COPY_PHASE_STRIP = NO;
GCC_DYNAMIC_NO_PIC = NO;
GCC_OPTIMIZATION_LEVEL = 0;
GCC_PRECOMPILE_PREFIX_HEADER = YES;
GCC_PREFIX_HEADER = Breeze_Prefix.pch;
GCC_VERSION = com.apple.compilers.llvmgcc42;
INFOPLIST_FILE = "Breeze-Info.plist";
IPHONEOS_DEPLOYMENT_TARGET = 4.0;
PRODUCT_NAME = "Breeze";
"PROVISIONING_PROFILE[sdk=iphoneos*]" = "36F99F3E-805F-47A7-95D4-FF8324711CBE";
SDKROOT = iphoneos;
};
name = Debug;
};
Of note is this line:
"PROVISIONING_PROFILE[sdk=iphoneos*]" = "36F99F3E-805F-47A7-95D4-FF8324711CBE";
That's the GUID reported by the build error; the identifier of my old, expired provisioning profile.
All I had to do was replace it with the GUID of the new profile:
"PROVISIONING_PROFILE[sdk=iphoneos*]" = "E6E6369E-FD58-4886-9C3A-72C9DAE36501";
I open my project in Xcode again, and now my app builds and installs on my devices successfully, using the new provisioning profile.
Here's how I did it in Xcode 4:
Select Don't Code Sign from Project > Build Settings > Code Signing
Clean the build
Build it again - should show an error like "this stuff needs signing"
Choose the new profile from the Code Signing
Rebuild
I was able to fix this error by changing it to "Don't Code Sign" in Code Signing Identity. Build, and you get the error "code signing is required for product type ...blah...". Then go back and select the right profile. Build and all good. This happened to me because my certificate expired and I renewed it. In addition to the above I also had to remove the old certificate from my keychain, and the Organizer.
Close de xcode
edith with texmate, youtproject.xcodeproj
Find this line "PROVISIONING_PROFILE[sdk=iphoneos*]" = "E8DEEBA3-FE0A-419F-9F7E-258572D55807";
Erase
Restart xcode build & archive for enterprise
To add to the solution above, you can use the lovely xcodeproj gem to help with stuff like this. Note, it does convert your OpenStep key = value; -style plist to XML. Note: I have found that Xcode changes it back if you make project file changes in Xcode later. Either style of file builds fine either in Xcode or from the command line. For a sample of how I use it
project = Xcodeproj::Project.new('Foo.xcodeproj')
csi_key = 'CODE_SIGNING_IDEDNTITY'
project.targets.each do |target|
target.build_configurations.each do |conf|
conf.build_settings[csi_key] = 'iPhone Developer: Cool Dood (XYZ123)' unless conf.build_settings[csi_key] == nil
end
end
Here's a gist of how I use it: https://gist.github.com/82times/5594887
My solution to this problem was:
Download your new provisioning profile
Double click the provisioning profile to install it
Go to the following directory on your mac:
/Users/<your.username>/Library/MobileDevice/Provisioning Profiles
Find the old provisioning profile that you no longer want (but keeps showing up in Xcode). This may come in handy for this step: https://github.com/chockenberry/Provisioning
Delete it
Completely exit Xcode
Reopen Xcode
You should now be able to select your new provisioning profile
Most answers did not work for me as they seem to be for older versions.
For Xcode 8.3.2:
Xcode->Preferences->Accounts
Select Apple ID
Double-click your Team
Click the '+' dropdown in the bottom left to "Create a certificate"
Choose iOS Development
Click 'Done'
After doing this I was able to tell Xcode was using the latest profile by clicking the 'i' info icon next to "Xcode Managed Profile" under Targets->General->Signing and confirming that the 'Created' date reflected the new one.
In my case, with XCode 5, when my developer certificate expired, I ran into this issue. I manually downloaded the new certificate and new provisioning profile. I added the certificate to the keychain and the provisioning profile to the devices in organizer.
However, XCode kept complaining that I cannot sign the app. I figured that in XCode 5 preferences, it still displayed the old provisioning profile and it didn't refresh to the the new one despite numerous reloads that I did there.
Eventually, I used iPhone Configuration Utility to delete the old provisioning profile and add the newly downloaded provisioning profile. After code signing worked as expected.
I thought that double clicking on the downloaded provisioning profile would place it into xCode Organizer Archive, but that just wouldn't work for me. The following steps finally worked for me.
Open xCode
Go to Product -> Destination -> iOS Device
Go to Product -> Archive
I accidentally deleted my target in xcode.
so i created a new one with the exact same name. in the target settings i again selected the proper codesigning identity
but now i can't compile for the device anymore. as soon as i want to build, i get:
CodeSign build/Release-iphoneos/myApp.app
....somestuff....
/Volumes/XCodeProj/myApp/build/Release-iphoneos/myApp.app: object file format invalid or unsuitable
Connad /usr/bin/codesign failed with exit code 1
I already tried to clean targets.
what could cause this problem and how to solve it?
May also be an issue with your install. Symlinking to the latest codesign_allocate cleared up the issue in my case:
sudo mv /usr/bin/codesign_allocate /usr/bin/codesign_allocate_old
sudo ln -s /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/codesign_allocate /usr/bin
In Mountain Lion, you can try to run this before codesign:
export CODESIGN_ALLOCATE="/Applications/Xcode.app/Contents/Developer/usr/bin/codesign_allocate"
Make sure the 'Executable Name' (CFBundleExecutable) entry in your target's info.plist matches the 'Product Name' specified in your target settings.
I had this issue when I was trying to codesign from the terminal. I had just installed Xcode 4.4 after uninstalling Xcode 3.0. Took a look at the Downloads in Xcode preferences and noticed that the Command Line Tools had not been installed. My issue was fixed after I installed this. I'm guessing the problem is more complex given the solutions here, but this might be something that future users want to check before they have to start diving deeper.
For me, this was occurring after upgrading to XCode 4.5.
The solution was simply to go to Preferences / Downloads and install the latest Command Line Tools.
I had the same problem and tried all sorts of build settings GCC4.0, search paths etc etc. It turned out to be nothing to do with the build settings in my case the problem was I put a dot in the target name i.e. I was targeting v3.0 SDK so I called the target Granade3.0.
I started a brand new project named "Grenade3zero", imported the sources from the original, fixed the appdelegate name to match the project name etc. build and go and it loaded first time onto the device and the simulator was also fine when I checked it. Looks like some characters are illegal in target names!
Thought I'd add my solution to this problem too... I've been struggling for a couple of weeks with this problem... having checked ALL the solutions above and changing more.
My solution was in the target build settings.
I had put in two options, armv6 and armv7. I changed this back to one single entry of normal and it built!
emcmanus answer worked for me but since Xcode 4.3 is now installed in the Applications folder and I removed the old /Developer folder, I had to change the path to codesign_allocate:
sudo mv /usr/bin/codesign_allocate /usr/bin/codesign_allocate_old
sudo ln -s /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/codesign_allocate /usr/bin
I tried all the above to no avail. What worked for me was to add the following to my build script:
export
CODESIGN_ALLOCATE="/Applications/Xcode.app/Contents/Developer/usr/bin/codesign_allocate"
I came across this post while researching my problem:
http://mobiledevelopertips.com/mac-osx/code-signing-error-object-file-format-unrecognized-invalid-or-unsuitable.html
For Mountain Lion before starting signing process Please run below command as first command.
For Xcode 4.x:
export CODESIGN_ALLOCATE="/Applications/Xcode.app/Contents/Developer/usr/bin/codesign_allocate"
For XCode 5:
export CODESIGN_ALLOCATE="/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/codesign_allocate"
Faced a similar issue in Jenkins running on Mountain Lion and Xcode 5.x.x without any command line utilities.
since the command line utilities are now bundled with Xcode 5.1.x
the following worked
sudo ln -s /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/codesign_allocate /usr/bin/
Go to 'Build Settings'
Go to 'Build Options' tab
Inside of the build options tab go find 'Debug Information Format' and change it's value from 'DWARF' to 'DWARF with dSYM File'. Should be in the dropdown.
It should work for you guys.
If your app has special characters in the Product Name in the target build settings, remove them.
For example, rename "Mat's app" to "Mats app" and it will build. You can of course have special characters in the display name.
I also had the same problem, and the cause was that my app target was linked to a static library and didn't provide its own source files (all sources were in the library and the app target only provided resources). Once I moved out one of the sources from the library to the app target, it fixed the code sign error.
I think that it was cause by one of Xcode DP(developer preview).
It could change default Xcode.app Path to Xcode DP.
So, U can check Xcode path by xcode-select --print-path
If U got some wrong directory then U could change path by xcode-select --switch
check this thread.
change xcrun developer path
It is better to use xcrun to locate the correct version of codesign_allocate as it can be different depending on whether it is an OS X binary or iOS.
This also allows Apple to change the location of various tools without breaking your script.
Use something like:
export CODESIGN_ALLOCATE=$(xcrun --sdk iphoneos --find codesign_allocate)
I would get the error when trying to sign my OS/X (not iOS) application with a digital certificate my company purchased from a root Certification Authority different from Apple. The problem would occur whenever I downloaded the certificate via Safari. Downloading the certificate using Firefox helped me get rid of the error.
Last night, the iPhone project was built perfectly.
This morning, I installed XCode 3.2.3 in a separate folder. When I open the same project in the old XCode 3.2.2 and re-built the project. I got this warning:
Application failed codesign
verification. The signature was
invalid, or it was not signed with an
Apple submission certificate. (-19011)
How can I fix it? Thanks!
For me the following steps resolved the issue:
Go to Product > Edit Scheme.
Open the Archive Profile.
Set Build configuration to Distribution.
I've encountered the same problem too. It showed that I had a duplicate certificate registration in my keychains. Removing one of them (I removed the one from my system keychain) fixed the problem.
Steps that helped me to resolve my problem:
Open KeyChain Access application
Select the 'login' keychain, and select in the bottom pane 'Certificates'
Switch to the 'system' keychain and see if there are certificates registered in both chains.
Remove one of them
Rebuild the application
I had the same problem, seems 3.2.3 messes with codesigning. I fixed it by re-running the 3.2.2 installer, no need to uninstall anything.
The parallel XCode problem can be addressed using the command line tool "xcode-select"
I found a similar problem caused by having XCode 4.2 beta installed. One of the embedded entitlements files was being placed in a different directory and was causing a file not found error.
The solution was to use xcode-select to verify and fix the XCode path.
Besides googling for possible solutions to this problem and trying them out (hoping that they help), here is an advice how to diagnose what causes this. The steps below apply to Xcode 4.2.
In menu, select View > Navigators > Show Log Navigator. The Log Navigator should be displayed on the left side.
In the list of builds, select the one that causes troubles. The log from the build will be shown in the main view.
Scroll to the very bottom. The last two steps should be CodeSign and Validate, where the Validate step contains the warning.
Expand CodeSign and inspect the parameters used to perform the code signing.
Expand Validate to learn more about the errors/warnings.
Also scroll up and inspect the heading for the build target:
Build Target (your build target)
Project (your project) | Configuration (selected configuration) | Destination ...
In my case, I found out that while doing the Archive build, the app was signed with the developer certificate. Inspecting the heading for the build target revealed that the Release configuration was used to build the archive. The remedy was to:
In the menu, select Product > Edit Scheme
In the Edit Scheme dialog, select the Archive build item (list on the left)
Change Build Configuration to Distribution
I had this issue after duplicating a build target. The original target was signed by the distribution certificate. However, when copying the target, Xcode decided to assign the Release configuration to the Archive build.
This happened to me today as I was moving an existing project into a new Git repository structure, while simultaneously using a development certificate obtained via being added to my client's team as a "Member". So lots of opportunity for things to screw up.
In my case, the issue turned out to be the "Build Products Path". I had it set to the relative path "../../../build" instead of an absolute path. This was causing the Validate tool to screw up since the actual path wasn't being collapsed properly. I changed it to an absolute path and the Validate tool then began to run successfully once more.
I submitted this as a bug to Radar as #8946204.
This is kind of an old post but I wanted to share what I learned (really remembered because I forgot this part.) I was trying to build my project against an ad-hock profile. I had forgotten that I needed to create a separate App Store profile (Provisioning Portal -> Provisioning -> Distribution). This was my first app I've submitted and the documentation is overwhelming so I missed/forgot about this part. Once I created the App Store profile and installed in XCode everything worked fine. Just wanted to throw this out there in case anyone else has this same issue.
Due to what hiroshi said you can change it there:
I just do is:
Open the Organizer
Go to Devices
Provisioning Profile
Click on the Profile you want to use. There you will see the profile identifier key.
Open the xcode project via textfile (the file in the xcodepj bundle)
Go to those lines and put the key in here
## -325,6 +325,7 ##
PREBINDING = NO;
+ "PROVISIONING_PROFILE[sdk=iphoneos*]" = "key goes here";
SDKROOT = iphoneos;
## -361,6 +362,7 ##
PREBINDING = NO;
+ "PROVISIONING_PROFILE[sdk=iphoneos*]" = "and also here";
SDKROOT = iphoneos;
Save changes and restart the Project
!!!That's what worked for me in XCODE 4!!!
If you go to the Organizer and select Provisioning Profiles, is the profile listed there? If so, have you checked that it's setting in the Project Settings/Build/Code Signing section?
I'm not sure, but reverting those changes in the project.pbxproj rescues me from failing to start my app in devices. The warning subject of the question remain though.
## -325,6 +325,7 ##
PREBINDING = NO;
+ "PROVISIONING_PROFILE[sdk=iphoneos*]" = "";
SDKROOT = iphoneos;
## -361,6 +362,7 ##
PREBINDING = NO;
+ "PROVISIONING_PROFILE[sdk=iphoneos*]" = "";
SDKROOT = iphoneos;
I fixed this simply by deleting my distribution certificate from keychain then downloading it again from the provisional profile
For the build warning or archive validation error "Application failed codesign verification", see Apple's complete list of potential causes at the following URL "How do I resolve the error: Application failed codesign verification?"
Best,
Simple Solution: Build your app using a DISTRIBUTION certificate and not a Developer cert.
While attempting to debug a build created using the 3.2 SDK on an iPhone device I receive the message "A signed resource has been added, modified, or deleted.".
I can clean, rebuild, then install with no error, but if I try to install without cleaning the error shows.
Anyone have an idea as to what might be causing this?
I found a workaround for the bug.
If you delete the .app file in build/Debug-iphoneos/ before building for the device, the app gets installed without errors.
And there is a simple way to do that before every build.
Make sure you have selected "Device" in the dropdown overview menu.
In XCode go to Project > New target...
Then find "Shell Script target" under MacOSX/Other
Name it and add it to the current project
Now, in the left navigation panel, under targets, expand your newly created target and double-click on Run Script.
In the window that opens replace "# shell script goes here" with "rm -fr build/Debug-iphoneos/*.app" (without the quotes).
Now open your main target preferences and under Direct Dependencies add your newly created target.
Build and Go! :)
This error occurs when there is a special character in the Product Name. In my case it was a "?"
If you change the Product Name it automatically updates the "Bundle Name" and "Bundle Display Name" so it is often the best choice to rename an app.
If you want to include special characters in the app name you have to manually rename the "Bundle Name" and "Bundle Display Name"
Bundle Name: This is the actual app bundle name in the file system such as "Awesome App.app". It is generally not visible to the user.
Bundle Display Name: This is a short name displayed under the app icon on the device. Since the bundle name would be truncated to "Awes…tion" you have the option to have a shorter name which fits better such as "Awesome App". It should be similar to the App Store name (set in iTunes Connect)
This is pretty clearly a bug in the 3.2 SDK, but I don't want to downgrade. I've found that doing a Clean by pushing Command+Shift+K, then Return is pretty fast before pushing Command+R to build.
Xcode 8, reason of the "A signed resource has been added, modified, or deleted." was that target was signed with an enterprise provision profile.
In my case, it happened when no changes were made. Make a change to any file and run again.
This can have several causes. The fastest way to figure out what is causing it is to go into Xcode, Window menu, Devices, then click the reveal button at the bottom of the pane to show the Console. Now attempt to run. You should see log output that names the specific files it is complaining about.
Most of the solutions previously posted are just artificial ways of getting Xcode to regenerate the contents of the build folder and/or re-sign the files.
In my case, my WatchKit extension was somehow acquiring references to Cocoapods frameworks that were only targeted toward the main app so they got signed during the build, then pruned later (as they were not used). Then on device, iOS complained that they were missing from the .appex folder for the extension. I ended up not needing any pods in the extension so I just removed them all and removed the extension as a target, then did some minor cleanup to remove the pod-related debris left in the build steps. Now everything works perfectly.
(SOLVED) This is a weird one. I tried everything I could find. Eventually I changed the product name from "Unit Tests (device)" to "Device Unit Tests" - removing the brackets. Now everything works. The spaces in it appear to be fine.
Previously on stackoverflow:
I've just run into this bug with two static library projects. One builds and tests using the GHUnit test runner on the device without a problem. The other projects will not install and gets this error. That means it's something thats different between these two projects. I've so far tried wiping the build directory, taking spaces out of the executable name, and various clean and builds as suggested here.
Same for me, thought it has something to do with multiple targets etc. because I changed a lot there. But it's highly possible that it's a Bug in the 3.2.2 release since I did not test extensively in this sdk version before the massive target changes in my project.
solved my issue!!!
I found out by accident that somehow a space " " found it's way into the Product Name of my app so it was called "First Second.app" instead of "FirstSecond.app". After deleting the space the issue was gone!
I changed it here:
right click on target
Get Info
Build Tab
Packaging Section
Product Name <- The name here will be used for the bundle (.app) name
Hope this helps, let me know!
Cheers,
nils
I could solved by changing project name.
[project]-[Rename] menu. "phase1 (new)" -> "pahse1"
I was getting this same error, but intermittently. I tried all the above and it still didn't work. Today I found what was causing it.
The error seems to occur when editing a xib in interface builder. If you try to run while the interface builder is open in xcode it will cause the above error. To solve just close the interface builder editor. i.e. just select a code file from your project so you are in the Source Editor.
The simplest (and probably most common cause) appears to be rebuilding without any changes.
So the simplest thing to cure it is to make a trivial change to a source file (such as adding a space, then deleting it), and then rebuilding.
If this doesn't work, feel free to try all the other answers here.
For months, I'd get this error without realizing it was due to such a simple cause. I'd usually do a Clean Build to get rid of it.
When I created ipa through terminal using xcodebuild commands, ipa created but while installing it I was getting same error. exportOptionsPlist solved my issue.
xcodebuild -exportArchive -archivePath projectPath/myapp.xcarchive -exportPath projectPath/myApp.ipa -exportOptionsPlist ProjectFolder/exportPlist.plist
In my case, Quit and restarting XCode worked.
For me the issue was related to the provisioning profile settings. The clue to this was that debug builds were installing ok, but release builds were not. I wanted to test a release build, so I ran the scheme with that build configuration.
I fixed it by duplicating the Release Configuration, then modifying those fields in the Build Settings to have the same provisioning stuff as if I am debugging it.
(Adding another build configuration will give you headaches if you are using Cocoapods however, then you'll have to modify your Podfile)
I'm getting the same thing, when installing on a iPod Touch. I can't link for the simulator (for other reasons), so can't say whether the problem occurs there.
Yes, rebuilding clean or deleting the app from the device allows me to install again. Neither are desirable, iterative solutions!
The minimal "cleaning" I've come across as a work around is manually deleting the Foo.app in the build/Debug-iphoneos directory.
it seems this is a bug in xcode 3.2.2:
iphonedevsdk
I had the same problem in Xcode 3.2.1 when I put a + in my app name. Specifically the "product name" in the build settings. It is fine to have a + in the bundle name in your Info.plist. The same probably applies to other punctuation characters.
Go to Window > Organizer > Projects > Find your project and delete derived data
I got this error intermittently while installing app using iPhone config utility on Windows7. Following solution works - Go to C:\Users\{lanusername}\AppData\Local\Temp and delete app specific folders (e.g. abc.app) and try installing app again.
I reported this bug on ICU (Windows versions) to Apple in June 2011. With the following workarounds:
The workaround is this ....
Win XP
1) Close ICU
2) Delete the temp folder: c:\Documents and Settings\[username]\Local Settings\Temp\[AppName].app
3) Delete the deploy folder: c:\Documents and Settings\[username]\Application Data\AppleComputer\MobileDevice
4) Restart ICU. Drag in the App and install normally.
============================
Win 7
1) Close ICU
2) Delete the temp folder: c:\Users\[username]\AppData\Local\Temp\[AppName].app
3) Delete the deploy folder: c:\Users\[username]\AppData\Local\Apple Computer\MobileDevice\Applications\[AppName].app
4) Restart ICU. Drag in the App and install normally.
=========================================================
I simply rebuilt my app, and that solved the issue.
I also faced the same issue. After wasting lot of time I realized that my product name has a special character "?" which cased the problem
Having the DerivedData folder at a network location caused this problem for me.
After trying everything else, I found out my workstation couldn't agree with the University server about what the time was. (It thought everything was always modified). I also had to clean for every rebuild to avoid that frustrating message.
In the end I gave up and built locally, changing Xcode > Preferences > Locations ... feeling altogether pretty dumb for having ever built over the network.
We ran into this issues on XCode_6.3.1. We were building a AppleWatch app, with an extension. We do have a bunch of Pods.. After debugging the issue for almost a bunch of hours, what we found was that there was an issue with the way a file was adde to the project..
It seems like some references to a unused file was sitting in the iPhone App, though it was used in the Watch App.. It turns out that the error XCode was showing was totally useless.
After removing this file and re adding it back to the project the project started working fine & was able to install to the device. To make it even harder to debug the issues, the debug version was installed without an issue, but was unable to install the norman version..
Make sure you add your files to the right target and, look at git history and see if there are lingering fragments that are added to the wrong target.
This is a very general error message indicating something is wrong during the validation process of the code signature. To find out the specific error, you can go to Xcode->Window->Devices and check your device log.
In my case, I have following console spew
Feb 1 18:53:07 iPod-touch installd[40] : 0x1001f8000 -[MICodeSigningVerifier performValidationWithError:]: 192: Failed to verify code signature of : 0xe8008017 (Signed resources have been added, removed, or modified)
Check on this 3rd party framework again, I found an extra CodeResources file under the framework root. Remove that file fixed the problem.