On my mac when I install with pnpm and click folder cmd+i (info window) it shows 33,6 MB, but inside it shows only links to folders.
I assume that the real size is supersmall, but does Mac take this in account when for example calculating the remaining space on the disk? (Apple Menu -> About this mac -> storage) Because it seems that I'm still using a lot of space installing with pnpm, so it might be confused about the hard links?
Related
I have tried cleaning the simulator but it again occupies 6gb disk space on my Mac.
Can anyone suggest manual cleaning?
If the objective is to free up disk space occupied by Xcode-related and simulator-related caches and data, and not just iOS support files, there are other folders you can look into to consider removing files, besides ~/Library/Developer/Xcode/iOS DeviceSupport/ and ~/Library/Developer/Xcode/DerivedData that have been mentioned in the other 2 answers so far.
~/Library/Developer/Xcode/Archives/ contains data from your builds that can be helpful in the process of symbolicating/debugging deployed apps, but could otherwise be removed. Thankfully, it is organized by date, so you can choose to keep specific folders inside it, and delete the rest
~/Library/Developer/CoreSimulator/ contains simulator related data. It includes a Caches folder and a Devices folder. If you no longer need to run your apps on certain devices, you may consider removing those devices' corresponding folders in the Devices folder. The Caches folder may grow over time as well, and you can remove contents from there, and they should be regenerated as needed.
If you've been using this machine for some years, it may be worth looking for ~/Library/Application Support/iPhone Simulator. The simulator related files used to be there until around Xcode 6. So you may have files still there that you might want to delete (I did, on some older Macs some years back)
There's an Xcode specific cache (not about simulators), ~/Library/Caches/com.apple.dt.Xcode, which should be regenerated as needed, but may be less useful to clean up.
You could also consider running DevCleaner from time to time to remove unnecessary Xcode-related files.
Delete the contents of "~/Library/Developer/Xcode/iOS DeviceSupport/".
Remove all "paired devices" in iOS settings > Developer.
Connect iPhone to the Mac and pick "Don't trust".
Since the above is not okay for iTunes syncing etc, try the following:
Delete the contents of the folder "~/Library/Developer/Xcode/iOS DeviceSupport/" and then right click > get info > lock the folder.
Locking the folder will stop Xcode from copying the simulator files from the iPhone to that folder next time you connect them.
https://apple.stackexchange.com/questions/380024/how-to-stop-xcode-downloading-ios-support-package-of-my-iphone
It is possible that Xcode starts downloading it via nsurlsessiod so you can block it either
by using a firewall
https://apple.stackexchange.com/questions/393689/how-to-stop-catalina-from-contacting-apple-servers-when-executing-programs/393698#393698
Or by renaming the binary as explained at the link below. (I haven't tried it)
Xcode simulator constantly download something
Command-Option-Shift-K to clean out the build folder. Even better, quit Xcode and clean out ~/Library/Developer/Xcode/DerivedData manually. Remove all its contents because there's a bug where Xcode will run an old version of your project that's in there somewhere
By following this steps you can do....
For user who are not able to find library/developer path.
open Xcode( i am using Xcode 13) -> file -> workspace setting -> there will be a path at center of modal -> click on arrow button next to path -> on clicking it will open up the folder.
What are the specific differences between disk image file and .app extension in macOS
A disk image file or .dmg is a copy of a disk, a virtual disk. In it's simplest form a disk image is a file containing what would normally reside on a physical device say, a hard drive, thumb drive, floppy disk, etc.
A macOS application or .app file is a bundle or a collection of related resources from the view of the OS. For example the Safari.app bundle contains not just the executable, but Information property lists, resources such as icons, plug-ins, etc. Unlike in Windows, on macOS an application is not just an executable. It can and should be viewed as a self-contained entity that has the necessary frameworks and libraries to function on it's own. This is why you can simply drag and drop a .app to "install" a program on macOS. Finder in macOS treats this bundle as a single entity which is why you can just double click and launch it as if it were just an executable. If you right click and select Show Package Contents on a .app bundle you will see that it more resembles a directory. As an aside, a bundle may contain another bundle inside it, so an .app may have another .app inside such as a helper, sub-tool, etc.
In macOS how is a .dmg related to a .app? They're not really, but the delivery of an application is often done via a .dmg disk. If you download a .dmg from an application provider macOS will mount it as a virtual disk, show you its contents which often contains a bundle with a .app extension that you then copy and paste locally to install the application.
I've just had a Phonegap/Cordova iPhone app approved for the app store but noticed it claims to be available in a bunch of other languages including Northern Sami. I've found the list of languages in xcode under localizations and tried deleting them but if I restart xcode they re-appear.
I've also tried deleting lproj folders in the resources folders but that doesn't help either.
I'm at a loss to what to do next so any help would be much appreciated.
Here is a step by step guide of how I do it. (Order matters)
First go to the Resources folder in the Phonegap project. Within this folder there are several folders ending in *.lproj. Delete all of them except for en.lproj (Assuming your language is english).
Even though you deleted those files from your hard drive they're still linked in Xcode. Open up your *.xcodeproj and delete all of the folders from the side bar once again.
Normally this should suffice, but if you're still having problems go to the app's project tab (rather than target) and under info you can find and remove all the current localisations.
Oh and btw if this still isn't enough you can look at the details of your app's binary in iTunesConnect to verify if it worked before releasing the app.
I've just started playing with Xcode 4, and found that, no matter how I setup debugging symbols in the project, Instruments refuses to display source lines for stack trace items that correspond to my code. In only shows hex offsets and identifies my executable as the owning module. Turning on "Source Location" draws a blank too. This occurs even for the skeleton OpenGL ES project generated by Xcode (File → New → New Project... → iOS → Application → OpenGL ES Application).
This problem only occurs in Instruments (I've tried CPU and OpenGL tracing so far). Gdb picks up debug symbols just fine.
Do I have to do something special to see the source code for stack traces in Instruments, or is this a bug in Xcode 4?
So far, I've:
Changed Debug Information Format from DWARF with dSYM File to DWARF.
Changed Strip Debug Symbols During Copy from Yes to No.
Changed the build scheme to use the Debug build instead of the Release build with Instruments.
The other answers are good long-term fixes. If you'd rather not wait for Spotlight to rebuild its index and just need to get symbols for one Instruments session, you can ask Instruments to symbolicate the current session.
Choose File → Re-Symbolicate Document…
Locate your binary in the list that appears. It should be the same name you see on the Springboard. Select your binary and click "Locate."
Go back to Xcode. Control-click on your .app build product and choose "Show in Finder".
This will reveal the directory containing your binary as well as its dSYM file. Go back to Instruments, navigate to this directory, and select your dSYM file. The easiest way is to just drag the dSYM file straight from the Finder to the "Select dSYM" dialog in Instruments.
Finally, click "Symbolicate" in Instruments. You should now see symbols in the traces rather than hex offsets.
I had this issue today and solved it this way:
Edit scheme
Click on "Profile" on the left (this is the important step)
Change Build Configuration to Debug
That should do it. Note that for whatever reason, the build target is not set to the same build configuration as the profile target and this has tripped me up more than a time or two.
Try selecting a different code signing identity, i.e. provisioning profile, for the Release configuration.
I found out what the issue was, as I had the exact same problem.
The answer comes from: Missing symbol names when profiling IPhone application with Instruments
Ensure that you have compiled your code with debug flags enabled (e.g. -g3).
Execute dsymutil on your binary/dynamic library that you want to be able to access the debug information for.
This generates a dSYM bundle folder, and when indexed by Spotlight the debug information necessary is made available to Instruments.
I suppose in your case, it took some time before Spotlight had things indexed - and when it had, then things magically worked out.
It just started working; no rhyme or reason.
I have spent the last half-hour trying to get it to fail again, in the hope of providing a more useful answer here, but I can't, even after recreating the skeleton OpenGL program from scratch, retracing all of my steps.
I did open the symbolicatecrash script in emacs (It has been implicated elsewhere, wrt this kind of problem), and it started working after I did this. But at no point did I change or save it.
It's a mystery.
One reason for instruments having no symbols could be that Spotlight cannot find the dSYM file. So your change from DWARF with dSYM to DWARF is not a good idea. You should change it back since without a dSYM file, you won't get symbols anyway (at least this seems to be the case for Snow Leopard, I have seen reports that some people also got symbols without dSYM files, however, all those people were using Lion). After making the change, make sure you create a clean build (sometimes Xcode fails to generate the dSYM file on my system for non-clean builds).
If you still get no symbols after all that, something is wrong with your Spotlight database. Try adding the folder that contains the dSYM files after a build to the list of folders Spotlight shall not index and then remove it again from that list. This causes Spotlight to reindex the files.
If this also doesn't help, maybe your Spotlight index is completely corrupted. In that case, try the following on a Terminal:
sudo mdutil -i off /
sudo mdutil -E /
sudo mdutil -i on /
This causes Spotlight to first stop indexing your main hard drive, then delete all index data collected in the past and then start reindexing it. The lines above assume that your dSYM files are located on the main hard drive (and not on any other hard drive or network volume, otherwise you must replace '/' with the appropriate mount point of that volume). Give Spotlight some time to reindex before you try again.
In newer versions of Instruments (I have 5.1.1 (55045)), you can add additional paths to be searched for the dSYMs and source code
Open up Instruments' Preferences, then click the "dSYMs And Paths" tab.
Then add your path to the list.
Here's my environment...
XCode 8.2
Mac OS v10.12 Sierra
I had the same problem running in the simulator, and it was driving me nuts because ALL the standard go-to fixes were not working.
What did it for me was plugging my iPad into the MacBook and running an instruments session against said app on my plugged in iPad. Instruments properly symbolicated my app when running on the iPad, and then continued to work when I disconnected the iPad and ran instruments later in the simulator.
I suspect it had something to do with updating my project to use the following...
libsqlite3.tbd instead of libsqlite3.dylib
libstdc++.6.tbd instead of libstdc++.dylib
I don't know why that would be the case, but that was the ONLY project change I had made before my symbols were lost in Instruments.
I was testing an application called iTrash during which it seems like i have deleted the
"Contextual Menu Items " folder as its no longer present and i can no longer right-click
anywhere on my Snow Leopard. I don't have any backups. Can someone tell me how i can recover
that folder or if i can download the files needed to have in that folder (just the original
ones) to regain the Right-click again?
I managed to get around the problem by reinstalling the 10.6.3 update and also by replacing the Track preference file .plist using an app called Pacifist which allows you to look into MacOSX installation Disk or image and search and extract individual files, in my case the default .plist file for the System Menu Trackpad. glad to see the back of this bizarre predicament.