I began typing up this issue and before I submitted it I solved the problem, but since it cost me all morning to resolve and I've seen it before, I figured I'd post it to help others out if they should run into the same issue.
I lost all the destination simulators in a single XCode project save for MacCatalyst and any physical devices. The cause was turning on Mac Catalyst. It's not quite that simple since I am using two different development computers running different version of MacOS. I was quite careful to not have the project open on the two different systems at the same time since that has caused other minor issues issues in the past as well.
I did some work on the second system to resolve issues with MacCatalyst, then closed that and returned to the original computer and discovered all the simulators were missing from the destination drop down. They're there under Windows -> Devices and I can add others but they never show up on the drop down. Other projects work fine.
I'll provide the solution below.
After trying restoring the project file and restoring XCode and deselecting Mac Catalyst all to no avail. I tried de-selecting iPhone and/or iPad and magically the simulators re-appeared. That's all it took.
I'm running into an issue where my iMac, with over 100G free, gets Disk Full Error after running Flutter for an hour or so.
When I reboot I get dozens folders in my Trash "Recovered Files" that are around 2G each.
The issue is actually described fairly well here (with screenshots): https://github.com/flutter/flutter/issues/56270
However, the moderator closed every comment as "off topic" (seems like several people are having this problem). So I figured it may be a good idea to bring this here to see if anyone else has found a solution for this?
I'm running VSCode and when I run Flutter Doctor I'm 100% compliant. Using the latest Flutter/Dart/MacOS/Xcode/Android Studio versions. I am primarily building my Flutter app to macOS platform (desktop).
I tried the suggestions in the above issue post and none of these worked for me (re-installing cocoa pods, re-installing Xcode, re-installing Android Studio).
I actually ran into this issue about a week ago. The comment linked to had put me on the right track, where they mentioned it only happens when they have an iOS device attached to their machine.
If you see something like this error in your VSCode output log when launching your app, then it's likely the same issue.
Failed _shouldMakeReadyForDevelopment
If you have a device attached and it's locked, I believe something in the Flutter env attempts a connection over and over causing these files to fill up.
However, this happened to me once even when I didn't attach a device and I found out it was because I had "wirelessly" attached a device in Xcode when I was doing iOS development for another project. So just sitting at my desk with my iPhone nearby was enough to cause it to try to connect over and over again, even if it wasn't attached.
I removed my iPhone from Xcode's wireless device list and that seems to fix it.
Can confirm, running flutter with an attached ios device eats disk space.
This is happening to myself and another developer on my team. I lost 200 GB of disk space yesterday. It's a frustrating productivity killer.
I am using the latest flutter
flutter doctor reports everything as fine
xcrun --find simctl is fine
Using Android studio 3.6.3
Latest patched Catalina 10.15.4
This morning I opened the Android Studio IDE with an android device and an ios device connected. I opened a get info window on my hard drive and left it open. Then I did nothing but watch the info window. No builds or anything. Over the course of a couple minutes, I watched 7 GB disappear.
I shut down the IDE and the loss stopped. I reopened the IDE with only the android device attached. I waited and watched for a few minutes. No loss of disk space.
Then I reopened the IDE with just an ipad attached and the losses started again. Then I unplugged the ipad and left the IDE open and the losses stopped.
Same here but happens also when just running Android Emulator.
This needs to be fixed A.S.A.P - its a dealbreaker!
When the problem happens and the disk runs full, my system slows down so much I can hardly do a thing. To free up disk space and get operational again quickly, there's two options:
Restart. Then the cache files are either deleted or end up in "Recovered Files" in Trash, as described by #william-t, from where you can delete them.
Directly delete the cache files in "TemporaryItems" (for me that's below /private/var/folders/bc/gw57z9dn4rn2v6df7306k9sh0000gn/T)
I know this is not a solution to the root cause of the issue, and it still helps a lot, as long as there's no true fix...
I ran into this problem when iOS 10 was released. They are updating their device definitions so fast, that our small dev team can't match their speed. In result we need to develop on previous versions. But now our app crashes on 10.1 and we cannot debug. We need to wait for whole download to happen. Is it so hard to manage dev disk image to a place ? do they maintain disk image? or any other solution to the problem.
Problem
Instruments' Time Profiler is stripping all symbols except system libraries from my app, despite the fact that I have disabled this behavior in all relevant build settings in Xcode — but only on one development machine. The other dev machine behaves normally.
Description
Instruments' Time Profiler is stripping all symbols except system libraries, despite the fact that I have disabled this behavior in all relevant build settings in Xcode — but this is only happening on one of my development machines. I have two development machines running the same version of OS X, Xcode, and Instruments, and each machine is using an identical copy of the same Xcode project with identical build settings, schemes, and other configurations, and the app is profiled using the same test device (iPhone 4S with the latest public version of iOS 5).
Machine 1
- Mac OS X 10.7.4
- Xcode 4.3.2 (4E2002)
- Instruments 4.3 (4321)
Machine 2
- Mac OS X 10.7.4
- Xcode 4.3.2 (4E2002)
- Instruments 4.3 (4321)
Steps To Reproduce
Open included sample project on each machine.
Make sure the iPhone 4S is selected as the test device.
Select Product > Profile
When Instruments launches, select Time Profiler and continue.
Run the app.
Notice how the symbols are stripped when running on the iMac (Machine 1) but not on the MacBook Air (Machine 2).
Expected Behavior
Symbols from my own code should appear in the Time Profiler on both machines.
Regression
I have tried all of the following, with no change in the actual results:
Rebooting the machine.
Trying other Xcode projects
Deleting the "Derived Data" for all projects in the Xcode Organizer.
Re-symbolicating the document in Instruments (carefully selecting the correct DSYM file in ~/Library/blahBlahBlah…)
Final Notes
Here is a link to a .zip file of a sample project: Sample Project .zip
I was finally able to get it to work by a method that's just shy of a nuke-and-pave scenario:
Make absolutely sure all symbol stripping is disabled for your current build configuration. Make sure you've done this for your Release config if that's what's being profiled for Instruments.
Delete the app from the iOS device.
Restart the iOS device.
Restart the Mac (I don't trust Xcode or Lion at all to quit all relevant processes otherwise).
Launch Xcode, go to Organizer > Projects and delete Derived Data for the affected project.
Clean your project. Hell, why not?
Build and profile for Instruments.
Choose the Time Profiler in Instruments for clarity.
The first run will not show the symbols, but don't quit. Leave Instruments running!
Re-symbolicate the document in Instruments, navigating carefully to the correct dSYM file for the current build. This should be easier since you've deleted the derived data in step 5.
Now you should be able to see your symbols. It helps if you hide non-objective-C symbols.
Why do I suggest that you delete the app and restart the iOS device in Steps 2 and 3? I have a suspicion that Xcode doesn't perform a clean installation of each build, but may install deltas, such that the symbol addresses present in Instruments are a mixture of the current build plus previous builds. If so, then this issue is even more common for someone like me, who shares a single test device between more than one Mac. This assumption could be wildly incorrect.
If the above steps don't work for you, please let me know in the comments. I'd like to create a detailed radar report at some point in the future.
I'm not sure that it has been fixed in the 4.3 but this is a known problem in 4.2 seen here
Instruments
There is a known issue with the Profile action from Xcode 4.2. After a build in which no source files have changed, Instruments will be unable to gather symbols for the target application.
This affects projects where both:
The Release configuration is selected for the Profile action.
(default)
The Strip Linked Product build setting is set to "Yes”, or
a custom Run Script build phase strips the product. (non-default)
The workaround is to do any one of the following:
Perform a "Clean" on the product before initiating the Profile
action.
Do a Clean of the product and temporarily set the Strip Linked
Product build setting to "No" while Profiling.
Set the configuration of the Profile action to Debug.
Run successive profiles directly from within Instruments when you do
not need to rebuild. When developing Mac apps, using the GC Monitor
template in Instruments may cause Instruments to crash. To
workaround the problem please consider migrating your application to
ARC.
I've had a similar problem for days. I was able to profile the Debug configuration, but not Release. First I tried to make a copy of the release configuration (as suggested somewhere on the web), but that copy did not work either.
Then I made a copy of Debug, called it Profile, tried it and the symbols of Profile were shown in the profiler. Great! I then changed the optimization levels etc. to the same as Release, and now it works! Just wanted to share this, as this comment would have spared me hours...
Have been facing the same and stumbled upon this thread.
I realized that I first profiled the app with release build and after changing the scheme in Xcode for the same app, the profiler was still unable to symbolize. I have tried all obvious solutions you mentioned above but in vain.
The profiler somehow is still referring to the first build (release build)'s settings and hence it is not able to symbolize. So, I just changed the app's bundle identifier for testing purpose so that a new app is created altogether for profiling purpose. I could check the code where leaks exist now.
Try it out and let me know if this works for you too. Still pondering over why Instruments is failing to symbolize though.
I had a similar issue where I had no symbols in my os x application that I built from the command line (so in this case it is not an iphone or xcode issue). It turned out the problem was due to a bad DYLD_LIBRARY_PATH that contained my PATH. When I got rid of all those non-library paths, such as /usr/bin/, it worked.
I have a lot of third party frameworks whose symbols and binaries are unfortunately getting lost.
Additionally, my app's binary was getting lost.
I.e. if I selected File > Symbols, clicked my target, and found the similarly named item, the Binary Path was showing up red.
The solution was to go to Instruments > Preferences > Symbols, and add /Users/<MY_USER>/Library/Developer/Xcode/DerviedData to the search paths. Library is not indexed by Spotlight. After doing this, I have at least had the symbols for my app. The little circle next to my app's name goes from Yellow to Green when I do this, and persists between restarting Instruments, unlike other solutions to manually set the binary.
Let me know if you can tell me how to get all the ones for my third party frameworks. I use Carthage for some, others installed manually. Have had no luck with these yet.
I've managed to solve this by:
Disconnecting the device
Deleting the iOS Device Support files for the device's version of iOS in ~/Library/Developer/Xcode/iOS Device Support
Reconnecting the device and letting Xcode reinstall device support.
To be safe I first quit Xcode and Instruments, deleted derived data, and did a clean build as mentioned above, but no need to delete the app or restart any devices this way.
Try open XCode 3 and him Organizer. And try add from this Organizer a devices to both machines.
Just open Organizer and wait him processes. If you're see a button "Use for development" then click him.
Sometimes, XCode 4 can't add a device a truely for full development.
I have a serious ongoing issue with Xcode 4. I have been using Xcode 3 for years, and had everything set up perfectly. All my Build Configurations worked A-OK.
I updated to iOS 5 GM, and naturally I have to use Xcode 4 to submit my app to the Store or use TestFlight. I can't change my Build Configuration. I've tried making a new "Scheme" (which are stupid IMHO, when the old system worked 100%), and everytime I do, I set everything the same, I go "Product" > "Archive"....it works, and I share the IPA to my Desktop, to upload it to TestFlight, or I save it as a ZIP and send it to Application Loader.
IT NEVER WORKS. On TestFlight, my testers will install it, and immediately the application will crash. It won't even launch, no matter how I build the app, regardless of Scheme. It worked 100% and I have made ZERO changes since updating to Xcode 4.
Xcode 4 only works when I wish to "Debug" my app on my own device. It builds, installs and runs perfectly. Why won't it work on AdHoc or App Store?
PLEASE HELP! I'm ready to pull my hair out.
To answer this question, it was an absolutely STUPID issue!
I was checking the size of my Info.plist for any changes, and for some ridiculous reason only Apple can comprehend, updating to iOS 5 made that code obsolete. So the use of the code in my Release/AppStore/AdHoc builds was making it crash on launch. Once I commented the code out, everything is back working 100%.
Strange.
Even Apple Technical Support couldn't figure it out and they had my whole project to peruse. Apple REALLY need to improve their software when they change it. Not create a massive learning curve for their users and encourage code-cleanups if the SDK decides it doesn't like 4.3 code.