I have just updated my Xcode to X.Y.Z. Now I have a problem with the symbolication of the crash logs received from my tester and even from my phone too.
When I build the AdHoc distribution I am using the "Arhive" scheme, then I create the *.ipa file singing it with my developer credentials.
Is this the issue?
And I can't find the dSym files for these AdHoc builds.
Further to coob's answer, I find adding these directories to Spotlight's ignore list (System Preferences → Spotlight → Privacy) helps:
~/Library/Developer/Xcode/DerivedData/ (Xcode 4 build artefacts)
~/Library/Application Support/iPhone Simulator/ (file system for the iPhone Simulator)
Like this:
(See this blog post for additional detail.)
Update: from a comment by joerick: "This works, but it also meant that Instruments.app couldn't find the debug symbols, so I had to remove DerivedData from the Privacy list to do some profiling." - bear this in mind if you use Instruments.
For me, neither the line 323 edit nor the Spotlight exclusions fixed it. So I tracked down the issues in symbolicatecrash and published a patched version on github. Just replace /usr/local/bin/symbolicatecrash and your iOS crash reports will start symbolicating again.
This patch may not work for Mac apps, as it makes assumptions about the structure of the .xcarchive directory which don't appear to hold for desktop apps.
Edit: you may still have problems if Spotlight hasn't indexed your archives. You can get force an index by running the following in a terminal:
mdimport ~/Library/Developer/Xcode/Archives/
More info on troubleshooting here.
The symbolication script is having an issue finding the right binary/dSYM. It uses Spotlight to do this and often cocks up. Here's a few things to try:
Make sure your .app doesn't have a
space in it.
It may be finding the version of
your app installed on the simulator
(backwards, but it sometimes does
this for me). Reset your simulator.
Clear your build directory.
I had the same issue today. From my research on the web, there is an issue with the armv6 libraries that cause the symbolicate process to fail. I found the answer in the dev forums here.
For those without access, you need to create a copy of the symbolicatecrash script from /Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/. Edit the file and replace the 'die' on line 323 with a 'print' (this is why it's not working, the script fails here).
Then run symbolicatecrash against your crash log. You'll see the error from line 323, but then it will symbolicate all your lines and variables. It still fails for the system libraries, but it give enough information to fix your own bugs.
Hope this helps.
I think I had this issue, or something similar.
Xcode 4.0 wasn't showing the symbols for a crash I had from a tester.
I seemed to fix this by opening the xarchive that I had created, and copying out the dsym file from within it (right click and 'view package contents') to sit alongside it in the archive folder. I can't guarantee this was the solution - I was trying a number of other solutions at the time, but I know that I have the symbols now and didn't before. Worth trying?
To locate a dSYM file based on it's ID in a crashlog that looks like this :
Binary Images:
0x100000000 - 0x100021ff7 +com.developer.foobar 1.1 (2) <D1B7F956-7D79-3D4D-BA53-E9EBB368A9F8> /Applications/FooBar.app/Contents/MacOS/FooBar
you can do:
mdfind com_apple_xcode_dsym_uuids == D1B7F956-7D79-3D4D-BA53-E9EBB368A9F8
For OSX apps built with "DWARF with dSYM" you do not actually need the dSYM file and can use the manual approach at https://developer.apple.com/library/content/technotes/tn2151/_index.html#//apple_ref/doc/uid/DTS40008184-CH1-SYMBOLICATE_WITH_ATOS
Additionally to check the UID of a binary you can do something like
dwarfdump --uuid /Users/valexa/Desktop/GPSnote.app/GPSnote
UUID: 6194D2B0-4E61-3834-AD15-C279EB1848XX (armv7)
UUID: D1B7F956-7D79-3D4D-BA53-E9EBB368A9F8 (armv7s)
Related
I´ve found a strange issue with latest XCode 4.2 when trying to deploy my app to an iphone that just upgraded to 5.0.1.
It starts copying the debug info and the progress moves until the end, although it does not move beyond 'copying file 2 of 9'.
After it's done I get the message:
Xcode has encountered an unexpected error (0xC002)
No such file or directory, at ‘/SourceCache/DTDeviceKit/DTDeviceKit-867/DTDeviceKit/DTDeviceKit_Utilities.m:864’
in the organizer window. Any similar experience and clue on how to get over it?
Needless to say every party involved has been restarted dutifully, including myself.
Thanks for all your help
I found the following post helpful, although it is kind of dated:
https://stackoverflow.com/a/9944892/1031623
The only thing that I had to change is the following:
Close Xcode
Go to: "~/Library/Developer/Xcode/iOS DeviceSupport/5.0.1(9A405)/Symbols/System/Library/Caches/com.apple.dyld/"
Note: if you
don't have this folder, run Xcode, connect your device, and wait
until the error 0xC002 appears in Organizer - the folder should be
created by that time.
Create 3 empty files there called:
.copied_dyld_shared_cache_armv7 <== not 6
.processed_dyld_shared_cache_armv7 <== not 6
dyld_shared_cache_armv7 <== not 6
Run Xcode and enjoy the light next to your device eventually go
green:)
I have found a potential fix. I tracked the issue down to some files not copying into the ~/Library/Developer/XCode/iOS DeviceSupport/5.0.1(9A405)/ folder. I borrowed a friend's iPad with the 5.0.1 update, and attempted to use his device for development. It worked fine, and I noticed my iOS DeviceSupport/5.0.1(9A405) folder suddenly had many, many more files. I then connected my problematic iPad and bam, it just worked.
I attempted restoring, recovering, etc. and I could not fix the issue with these methods. I did the OTA update, and so did my friend, so our iPads were updated in exactly the same way. I do not have any explanation of the issue, but at least I have found a workaround.
If you don't have access to another device with the files, here's a zip file of them:
http://www.enemyhideout.com/ios/5.0.1%20(9A405).zip
Delete the ~/Library/Developer/XCode/iOS DeviceSupport/5.0.1(9A405)/ folder.
Then connect your device and go to the Organizer.
Xcode should recreate that folder and fill it up with informations from your device.
Thank you #Chris Hill, I was running into this on Xcode 4.3.1, but instead of
.../DTDeviceKit-867/... I was getting .../DTDeviceKit-1197/...
At first I replaced all the files mv -f ~/library/... and started up Xcode again, I deleted all the files I placed there from your pkg, So I tried with Xcode open, iPhone plugged in; and it worked perfect!
Thanks again
I have just updated my Xcode to X.Y.Z. Now I have a problem with the symbolication of the crash logs received from my tester and even from my phone too.
When I build the AdHoc distribution I am using the "Arhive" scheme, then I create the *.ipa file singing it with my developer credentials.
Is this the issue?
And I can't find the dSym files for these AdHoc builds.
Further to coob's answer, I find adding these directories to Spotlight's ignore list (System Preferences → Spotlight → Privacy) helps:
~/Library/Developer/Xcode/DerivedData/ (Xcode 4 build artefacts)
~/Library/Application Support/iPhone Simulator/ (file system for the iPhone Simulator)
Like this:
(See this blog post for additional detail.)
Update: from a comment by joerick: "This works, but it also meant that Instruments.app couldn't find the debug symbols, so I had to remove DerivedData from the Privacy list to do some profiling." - bear this in mind if you use Instruments.
For me, neither the line 323 edit nor the Spotlight exclusions fixed it. So I tracked down the issues in symbolicatecrash and published a patched version on github. Just replace /usr/local/bin/symbolicatecrash and your iOS crash reports will start symbolicating again.
This patch may not work for Mac apps, as it makes assumptions about the structure of the .xcarchive directory which don't appear to hold for desktop apps.
Edit: you may still have problems if Spotlight hasn't indexed your archives. You can get force an index by running the following in a terminal:
mdimport ~/Library/Developer/Xcode/Archives/
More info on troubleshooting here.
The symbolication script is having an issue finding the right binary/dSYM. It uses Spotlight to do this and often cocks up. Here's a few things to try:
Make sure your .app doesn't have a
space in it.
It may be finding the version of
your app installed on the simulator
(backwards, but it sometimes does
this for me). Reset your simulator.
Clear your build directory.
I had the same issue today. From my research on the web, there is an issue with the armv6 libraries that cause the symbolicate process to fail. I found the answer in the dev forums here.
For those without access, you need to create a copy of the symbolicatecrash script from /Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/. Edit the file and replace the 'die' on line 323 with a 'print' (this is why it's not working, the script fails here).
Then run symbolicatecrash against your crash log. You'll see the error from line 323, but then it will symbolicate all your lines and variables. It still fails for the system libraries, but it give enough information to fix your own bugs.
Hope this helps.
I think I had this issue, or something similar.
Xcode 4.0 wasn't showing the symbols for a crash I had from a tester.
I seemed to fix this by opening the xarchive that I had created, and copying out the dsym file from within it (right click and 'view package contents') to sit alongside it in the archive folder. I can't guarantee this was the solution - I was trying a number of other solutions at the time, but I know that I have the symbols now and didn't before. Worth trying?
To locate a dSYM file based on it's ID in a crashlog that looks like this :
Binary Images:
0x100000000 - 0x100021ff7 +com.developer.foobar 1.1 (2) <D1B7F956-7D79-3D4D-BA53-E9EBB368A9F8> /Applications/FooBar.app/Contents/MacOS/FooBar
you can do:
mdfind com_apple_xcode_dsym_uuids == D1B7F956-7D79-3D4D-BA53-E9EBB368A9F8
For OSX apps built with "DWARF with dSYM" you do not actually need the dSYM file and can use the manual approach at https://developer.apple.com/library/content/technotes/tn2151/_index.html#//apple_ref/doc/uid/DTS40008184-CH1-SYMBOLICATE_WITH_ATOS
Additionally to check the UID of a binary you can do something like
dwarfdump --uuid /Users/valexa/Desktop/GPSnote.app/GPSnote
UUID: 6194D2B0-4E61-3834-AD15-C279EB1848XX (armv7)
UUID: D1B7F956-7D79-3D4D-BA53-E9EBB368A9F8 (armv7s)
Probably a silly question. When running my project on the Device in the debug mode I get a lot of warnings al having the following string:
warning: Unable to read symbols for
/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.2.1
(8C148a)/Symbols/System/Library/PrivateFrameworks/
I think its due to the space between "4.2.1" and "(8C148a)". How can i get rid of it? It must be a setting somewhere in Xcode.
I dont have these warnings on the simulator.
thanks in advance, Christian
I was getting:
warning: Unable to read symbols for /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.2.1 (8C148)/Symbols/usr/lib/info/dns.so (file not found).
Version 4.2.1 does not include 'info/dns.so'. At least that was the case for me. However, it does exist in the 4.2 directory and is pointed to by the /DeviceSupport/Latest shortcut. I simply copy-pasted 'info/dns.so' to where the debugger was looking for it and that seemed to fix the warning.
I had this issue with 4.2.1 (8C148a), which I believe is caused by differing DeviceSupport files on the phone and in XCode. I tried many things, but eventually resolved it by deleting this folder:
/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.2.1 (8C148a)/
After this I plugged in my iOS device and was asked to connect and restore the symbol files from the device, and it worked normally again.
When you plug an iOS device (iPad) with a slightly newer OS than the the ones in the SDK, a button to download new symbols should appear in the Organizer window of Xcode. Hit it and wait.
I've seen errors like that when my device wasn't on the same version as what I was building for. Are you sure you're not on a 4.2 beta?
I don't think 8C148a is "final"; final builds numbers never seem to end in a letter (my phone is reporting "4.2.1 (8C148)"). I haven't debugged apps on it yet (I got bored waiting for it to extract symbols and went home).
4.2 GM was 8C134, so you're certainly running newer software, but something somewhere is getting the build number wrong.
But I digress.
What directories are in /Developer/Platforms/iPhoneOS.platform/DeviceSupport? If "4.2.1 (8C148a)" doesn't exist but "4.2.1" does, you might have luck doing something like this in Terminal:
cd /Developer/Platforms/iPhoneOS.platform/DeviceSupport
ln -s "4.2.1" "4.2.1 (8C134a)"
Equivalently, if "4.2.1 (8C148)" exists, do something like this instead:
ln -s "4.2.1 (8C148)" "4.2.1 (8C148a)"
You can generally use this trick to get Xcode to talk to a beta device without installing a beta SDK; this is useful if your company has some people running the beta (for testing purposes) and other people on the latest "final" (for release purposes).
There's a mismatch at the moment, where the released version of 4.2.1 is ahead of the SDK version 4.2
#Khrob's comment fixed it for me though!
Until they provide a solid SDK, a cool workaround is to :
1 - select the Executable ( In 'Executables' in the project browser ),
2 - get info and turn off "Break on Debugger() and DebugStr()"*
Cheers, and best wishes for 2011.
T
This does not disable NSLog.
I have 4.2.1 on an iPhone 3G and Xcode 3.2.5 running on a MacBook Pro with 10.6.6. After a clean install of Xcode, I was getting the prompt to download symbols for 4.2.1 after plugging in my iPhone. After the transfer, I would no longer get the prompt when attaching the iPhone, but I was getting tons of "unable to read symbols" messages.
First, what did not work for me:
Creating symbolic link to '4.2 (8C134)' with the name '4.2.1 (8C148)'
Creating symbolic link inside directory '4.2.1 (8C148)' like there is in '4.2 (8C134)' to the ../../Developer/SDKs/iPhoneOS4.2.sdk
Both of the above caused the 'UUID mismatch' errors for several libraries. GDB would start but appear to hang.
Finally, what is currently working for me:
% cd /Developer/Platforms/iPhoneOS.platform/DeviceSupport
% mkdir '4.2.1 (8C148)' # if it does not exist
% cd '4.2.1 (8C148)'
% cp ../4.2\ \(8C134\)/DeveloperDiskImage.dmg* .
% cp -r ../../Developer/SDKs/iPhoneOS4.2.sdk Symbols
Attempt to run debug session for an application and watch the Console. For each warning about a UUID mismatch, remove the file indicated in the log message (I had AudioToolbox, CoreMedia, and some others)
Stop GDB and try again, hopefully with success
At least for my application under development, everything now works fine. Hopefully, Xcode 4.0 will clear this up.
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.
I have an existing project that I was working on, and I recently decided to update my iPhone SDK and updated to the latest 3.0 SDK.
I update my SDK and go to open my existing project. Sure enough, there are some problems including some certificate problems and so on. Anyway, google and I were able to solve most of them, but I haven't had any luck on what I hope to be the last of my problems.
When running my program in the simulator, I now get
dyld: Library not loaded:
/System/Library/Frameworks/UIKit.framework/UIKit
Referenced from:
/Developer/iGameLib/iGameLib/build/Debug-iphonesimulator/iGameLib.app/iGameLib Reason: image not found
Now, I discovered the UIKit has moved to
/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator3.0sdk/
System/Library/FrameWorks/UIKit
and I have updated my target and project settings to point to that new framework location, but still when I build it, no luck.
I have also tried clearing out the simulator's applications and settings, still no luck.
The referencing .app is cleared when I run the "clean" menuitem, I have confirmed this, so clearly something in my project settings are still pointing to use the old UIKit location.
Where should I be looking?
I've gone as far as I can to help myself but I'm afraid I'm at a loss here. I don't see it under the target settings, or the project settings, or the plist, or any of the other files within my project.
I was getting the same error
dyld: Library not loaded: /System/Library/Frameworks/UIKit.framework/UIKit
The solution on my case was simply quit Xcode and try again.
OK, SO I HAVE THE ANSWER!!!
Quite simply, Xcode is not changing all of the variables correctly in the actual .xcodeproj file. So, here are the steps I took.
Get out of Xcode, you've got to do this job at the terminal. Bring up a terminal and go to where your project is. Find your .xcodeproj and go into it as if it were a directory. It looks like an actual file in finder, but it is one of those package directories.
Now, I couldn't get textedit to allow me to edit it, but you can go into nano, so like I did
sudo nano project.pbxproj which is under my .xcodeproj file/folder/package/whatever.
In this file, you need to find where the SDKROOT is set. Chances are there are a few places it is referenced, but you're looking for SDKROOT = iphoneos2.2.1 or something similar. Change ALL OF THESE (there are a few) to SDKROOT = iphoneos3.0
Now, you're half way there. do ctrl x and save the file. Next you're going to do ls and find out what the .pbxuser file is. Mine is myname.pbxuser. run the same command of
sudo nano myname.pbxuser
In this file, there are a HUGE number of references to the 2.1 iphone sdk directory. Do a search/replace of iPhoneSimulatorOLDVERSION.sdk, in my case it was iPhoneSimulator2.1.sdk
and change the 2.1 to 3.0. Be very careful with this though, I wouldn't want to know what happens when you mess this file up.
Save it and open xcode. CLEAN the project and build and run. Presto!
Check your target settings
Make sure you're actually linking to all of those frameworks in the Target (check under "link binary with libraries")
Make sure you've chosen the 3.0 sdk as your base SDK
Create a blank project and add your frameworks as before; if you still have issues, probably a borked SDK install
BTW, you shouldn't have to re-add sdk frameworks, as the paths are relative to the current SDK
Just trying to be helpful… not sure I can debug from here :)
I have had some similar problems with Xcode that seem to have no apparent cause. The fact of the matter is that Xcode does still have bugs here and there and sometimes you WILL run into a wall.
My Experience: Similar to your situation somewhat, on one particular occasion, an Xcode project I was working just stopped building for whatever mysterious reason, and no amount of cleaning, googling or SO-ing provided me any answers. So I simply created a FRESH, NEW project and filled the source-code from my corrupt project into that of the new project. The new project used the SAME source, libraries, resources, settings, mind you -- and yet it built with no problems. It took about 20-25 minutes to make the transfer but considering that I had spent several HOURS trying to address a bug that would not reveal itself in the corrupt project, the time was well worth it.
So, I'd suggest doing what I did: Maybe try creating a fresh project and transfer your old source and resources over.
Good Luck
I just deleted the UIKit.framework from the 'Frameworks' folder, right-clicked and added it back again.
Clean build, and no problem..
I had the same problem using Xcode 3.2.1 but it was solved in an easier manner. I realized I had recently disabled my target's environment variables, specifically ones to do with memory debugging (NSDebugEnabled, NSZombieEnabled, NSAutoreleaseFreedObjectCheckEnabled, MallocStackLogging, MallocStackLoggingNoCompact). The app ran once in the simulator after removing the environment variables but never again after that.
Quitting Xcode, the Simulator, restarting Xcode and doing a complete clean of the target (including it's dependencies off course) brought me back to a good state.
Same problem when launching my application without debugging.
In my experience the produced binary does not seem to be the culprit.
I created an app from the xcode wizard which does launch OK in the simulator (let's call it testApp, my application being called myApp), I tried to figure out where is the difference with my app.
otool -L myApp
gives correct (relative paths) to the frameworks, same as testApp
ps -E
DYLD_ROOT_PATH, DYLD_FALLBACK_FRAMEWORK_PATH, DYLD_FRAMEWORK_PATH, DYLD_LIBRARY_PATH environment variables needed by ld to locate the framework
are OK for myApp compared to the values of these variables when testApp is launched
I suspect that the problem lies somewhere in the communicartion between XCode and the simulator once the app is launched ... altough I can't find what's wrong ...
The solution that worked (at least for me) have certainly some big side effects but here it is :
quit xcode
browse the content of the package myApp.xcodeproj
unlock .model1v3 and .pbxuser for modification (the lock in the information panel (cmd-I on the file))
delete these two files
start xcode and retry to launch your application from there