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.
Related
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 have mac os mojave and xcode Version 10.1 (10B61). I try build unity3D game. I can successfully build it to iphone 5S device. But when I try submit up to App Store it is not working.
What exactly happens:
On step "fetching app store configuration" xcode freezes. In active monitor I see it as unresponsible application (or something like it). And XCode take almost all free RAM (4.5GB). After sometime (around 20 minutes) mac restart (I have problem with iMac, it restart when use too much RAM, I don't think it related to xcode)
Actually, if I wait long enough (more then 15 minutes) it is start working.
XCode require a lot of RAM + SWAP
Here's an answer for someone who stumbles upon this later, I just want to share what helped me. I also ran into the same problem while trying to distribute a Unity-built game with Xcode (also contains pods).
I work on a MacBook Air 2013 with only 4GB of RAM, so whenever I do anything with Xcode, I first close everything other than Xcode, Finder and Activity Monitor. As soon as I start whatever it is that usually freezes Xcode, I switch to Activity Monitor and track what's happening with the memory.
In the case of freezing while "Fetching App Store Configuration...", the problem appeared to be RAM, more precisely SWAP. I did not have enough memory available on my hard drive, which Xcode tried to use for SWAP and just... well, failed. So I cleaned up my hard drive and finally it went through very smoothly, but it occupied about 9GB of RAM at its peak (5.4GB in SWAP).
So just try to have enough memory available to feed the beast, observe what's happening in Activity Monitor and you should be good.
When using Xcode 8's built-in source control, switching between two branches almost always causes Xcode to freeze and requires force quitting the app. My branches aren't particularly worlds apart. Doesn't seem like it's guzzling excessive memory or CPU either. What's the deal?
Turns out this is a known issue in Xcode 8 and 8.1.
It may be that your workspace or project is saved in iCloud. I turned off automatic saving of Desktop folders to iCloud, and moved my workspace from iCloud to my local desktop, and it works fine now.
My Xcode version is 4.6.2, which is the latest at this moment 2013.6.2, when I try to run a project(not a specified one) in simulator, it randomly freezes(stops) at indexing. I don't know if it's my macbook's problem because it's relatively a old one. My project is very light-weighted, just some demo. I'm a newbie. Normally, it works well, but sometimes it freezes at indexing, say 5% possibility.
And I cannot stop it even I clicked the "Stop" button at the right of "Run", and either if I close the simulator. I have to force the computer to shut down by keep pressing the power button. It brings damage to computer.
Anyone knows how to fix this? Or I have to get a newer one? Any help will be appreciated. THANKS.
Screenshot:
Xcode 4.6.2 in 1.4GHz, 2GB Ram
This is the main problem, the Xcode needs 2GB+ itself, and there are others applications and processes running in foreground and background.
I have 3GHz C2D, 4GB RAM, still at times it hangs at times :(
So, either you need to upgrade the hardware or degrade the Xcode version.
EDIT:
As you have Macbook air, you cant upgrade the RAM which is soldered to the motherboard.
The "verifying application" step of the build process in fully updated XCode 4.6 (and previously 4.5) often takes upwards of two minutes on my machine. Coworkers building the same application on similar computers have this step take only a couple seconds. My machine used to, as well, but does not anymore, for the past few months.
Does anyone know what could be causing this and how I can fix it?
Update your device to the latest version of iOS, 6.1.
Had the same issue, fixed after updating my iPad3.
Try rebooting your device.
I had the same problem using XCode 4.5.1 and an iPad 6.0.1, but didn't want to update at the time. In additional to a long 'Verifying Application' step, I noticed that copying resources over was also slower. After that, I disconnected the iPad and tried to delete my App, but discovered that even the device's delete alertview took several moments. So, obviously, for me, this was a device issue, and after performing a shutdown / restart of the device, xcode performed up to previously normal speeds.