I'm trying to automate the install of Xcode on an OS X machine. I've come across this question that got me most of the way.
The script given in the second answer gets the appropriate dmg mounted, and then uses installer to install the pkg. Except these days (e.g. version 7.3.1) Xcode is given as an app bundle inside the dmg, so there is no pkg to install. So I tried to simply copy it to /Applications via
cp -Rf /Volumes/Xcode/Xcode.app /Applications/
The resulting Xcode in my /Applications folder is 9.1 GB. But if I simply rename that bundle, manually open the dmg, and then drag & drop Xcode onto the Application shortcut, I end up with an Xcode that is 10.51 GB in size. Yet when I ask opendiff to compare the two, it tells me the contents are identical...
Does dragging & dropping from a dmg do something else under the hood, besides simply copying the app into /Applications? If so, is there a way to achieve the same via the command line?
Related
I've installed Xcode on a mac and when I try to start it I get a little window open saying 'Verifying Xcode' with a status bar scrolling across, anyone got a fix rather than reinstalling?
If you don't want to wait forever, this might help:
xattr -d com.apple.quarantine '/Applications/Xcode.app'
Running a command to get through Gatekeeper sounds like the way to go, since you downloaded it from a trusted source. This is a common occurrence when installing large bundles in Mac OS X. Basically, Gatekeeper examines your entire bundle, making sure that there is no suspicious code. This is one of the many things that keeps Mac OS X as secure as it is. You have two options:
1: Give it time.
Or,
2: Manually tell Gatekeeper "It's okay, this is from a trusted source". How do we do this? Well, first fire up the Terminal and navigate to your Xcode.app folder. (Or type in cd and drag-and-drop Xcode from your applications folder), then hit enter.
Next, run the command:
xattr -d com.apple.quarantine Xcode.app
Now, be careful getting past Gatekeeper if whatever you are installing is even slightly from an untrusted source, or else you introduce a security risk to your computer. In my case, opening new versions of Xcode quickly is the only time I will ever run that command.
anyone got a fix rather than me reinstalling?
For anyone else seeing a very long "Verifying Xcode" phase, just give it time. The indeterminate progress bar stays up there for a long time (tens of minutes) while Gatekeeper looks at the (very large) Xcode bundle to make sure that it's legit. Eventually, you'll get the familiar message along the lines of "This application was downloaded from the Internet. Do you want to continue?" Or, if the bundle doesn't check out, you'll of course get a message to that effect.
Almost every answer here recommends running xattr -d on the file. This deletes the file's extended attributes (like com.apple.quarantine) so OSX will not run the verification phase. You should only do this as an absolute last resort if at all. Apple explicitly recommends leaving Gatekeeper enabled to validate your version of Xcode after XcodeGhost malware was spread to popular iOS apps via infected versions of Xcode.
If you're stuck trying unarchive an Xcode beta .xip archive, try this:
Open the Archive Utility app. (Open Finder by hitting ⌘+spacebar and type "Archive Utility")
Choose File->Expand Archive and select the Xcode archive.
I had same issue. Quick fix is to open terminal from application or type terminal in spotlight and enter below command.
cd /Applications - This will move to applications directory where Xcode is present
xattr -d com.apple.quarantine Xcode.app - This will bypass Gatekeeper in OS X and will launch Xcode quickly
Note: If you have changed name of Xcode (say Xcode7-1) then you should enter ... Xcode7-1.app command. Refer screenshot
open terminal -
1.Type cd drag drop your xcode (for path) then enter
2.next xattr -d com.apple.quarantine Xcode.app enter
agree for terms and condition
For Xcode 8:
To skip the verifying process on El Capitan for Xcode 8, download Xcode 8 at the developer downloads page, then open terminal.
Following this, type
xattr -d com.apple.quarantine
Then drag your xcode 8 download into your terminal window.
It should look like this:
A lot of talk here about exempting Xcode-beta.app from Gatekeeper, but for me, I had to make the .xip file exempt.
I placed Xcode_8_beta_6.xip into /Applications, then in Terminal, changed directory to /Applications and ran:
xattr -d com.apple.quarantine Xcode_8_beta_6.xip
Then double clicked the .xip to get it to unpack.
running xattr -d com.apple.quarantine Xcode.app worked like a charm. Waiting on the "verifying xcode" didn't work, as it never completed.
Also you can remove Open Warning for entire directory Applications via the command in the terminal:
xattr -d -r com.apple.quarantine ~/Applications
it's work for me:
open Terminal cd to path Xcode.app
xattr -d com.apple.quarantine Xcode.app
You can try the command:
xattr -r -d com.apple.quarantine /your_path_to_xcode/Xcode.app
If you do not use -r, you will have to run the same command for the iOS simulator later on. I am not sure what other executables are hidden in this bundle and are quarantined.
If you have time, the recommended method is to leave the verification to complete so that everything is verified properly.
I had the same issue (Macbook Pro, Mid 2015, OS X 10.11.15) and was able to fix it without using the terminal to bypass Gatekeeper:
Trash all previously downloaded versions of the file and empty the trash. (If you haven't emptied your trash in forever this may take a long time. You can selectively delete the offending .xip files manually to save time.) I found multiple instances that would not delete because they were currently in use.
Restart your computer. Now you should be able to delete any .xip files in the trash without issue.
Download the Xcode8 beta again (don't stream media while doing this to save on time and packet loss.) and open it.
If this doesn't do the trick, open up terminal and follow one of the answers above.
Run the following command making sure this is your Xcode's location on the system & replace the xcode name with actual name which code be xcode2 or Xcode 3 incase if you have more versions of Xcode on your machine..
All the best ..
xattr -d com.apple.quarantine Xcode.app
Just wait for process to get over with.. sometimes it takes longer than the usual time but ends up showing the alert boxes for next process! sit back let it finish. :)
If you are not logged in to Xcode try logging in with any Apple account.
Today was the first time that I tried - and failed - to symbolicate a crash log on a newly bought MacBook (let's call this machine MB1). MB1 came with Mac OS X 10.9 pre-installed. I tracked the problem of the failing symbolication down to Spotlight not indexing any of my .dSYM bundles (without the Spotlight index, Apple's symbolicatecrash script fails to locate the .dSYM bundle that matches the crash log). I came to my conclusion because
mdfind "com_apple_xcode_dsym_uuids == *"
does not print anything, although I have several .xcarchive bundles in my ~/Library/Developer/Xcode/Archives folder, and they definitely contain .dSYM sub-bundles whose UUID I can print with dwarfdump --uuid. I also have a couple of .dSYM bundles inside my project's build folder (DerivedData), but none of them are indexed either.
The short and easy question therefore is: How can I tell Spotlight to index my .dSYM bundles?
In case there is no easy answer for this easy question, here is what I have already tried on MB1:
Check permissions of files and folders in ~/Library/Developer/Xcode/Archives (they are all OK, 755 for folders, 644 for files)
Run mdimport ~/Library/Developer/Xcode/Archives (has no effect)
In "System Preferences > Spotlight > Privacy" first add and then remove the ~/Library/Developer/Xcode/Archives folder (has no effect either)
Check with mdutil -s / that indexing is enabled for the volume (it is)
Erase and rebuild the entire index mdutil -E / (takes maybe 10-15 minutes, but still has no effect)
To go into more detail: I have an older MacBook (let's call this machine MB2) that was my dev machine before I switched to MB1. On MB2 I never had any trouble with symbolicating. MB2 had Mac OS X 10.8 installed while I was still actively developing on it, but I recently upgraded MB2 to Mac OS X 10.9.
Today, running mdfind on MB2 still gives me a lot of .dSYM bundles, both from the Archives folder and from the project's DerivedData build folder. These are all old files from the Mac OS X 10.8 days, but apparently Spotlight keeps its index across OS upgrades. I thought it would be interesting to see how Spotlight behaves when new files are created, so I did the following:
Fire up Xcode on MB2, create a new archive, and run mdfind. This finds the intermediate .dSYM bundle inside the DerivedData build folder.
Delete the intermediate .dSYM bundle and run mdfind again. No results this time, i.e. the .dSYM bundle inside the Archives folder is NOT found!
Make a copy of the .xcarchive bundle created in step 1 and place the copy in the root of the user home directory. Run mdfind. This finds the .dSYM sub-bundle within the copied .xcarchive bundle!
At this point, I jumped to the conclusion that because ~/Library is a hidden folder this is what prevents Spotlight from indexing stuff within it. This can be easily confirmed by creating a regular file inside ~/Library and searching for it (no hits), then moving the file outside of ~/Library and searching again (1 hit). Unfortunately, this theory falls flat on its nose because of two reasons:
~/Library was already hidden in Mac OS X versions prior to 10.9, but this never prevented Spotlight from indexing .dSYM files
The "hidden" flag is not all that keeps Spotlight from indexing stuff in ~/Library: If I unhide the folder with chflags nohidden ~/Library, that does not make the regular file visible to Spotlight.
Back to MB1: I tried to repeat step 3 from above, i.e. make a copy of the .xcarchive bundle in the root of the user's home directory, then run mdfind. Surprisingly, on MB1, the result is different from MB2: mdfind still finds no .dSYM bundles whatsoever!
At this point I give up and hope for your help. My conclusion is that Mac OS X 10.9 is somehow responsible for my problems, but for the life of me I can't figure out why this is so. In case it helps, here are a few additional configuration details:
MB1: Xcode 5.0.2 and Xcode 4.6 are installed, 5.0.2 is the default (set with xcode-select). Also installed is Homebrew. The system is a clean install of Mac OS X 10.9.
MB2: Xcode 4.5, 4.6 and 5.0 are installed, 4.6 is the default. Also installed is MacPorts. The system is an upgrade install of Mac OS X 10.9 (previously installed .
Peeking into an Xcode application bundle reveals the following Spotlight importers:
caradhras:~ --> find /Applications/Xcode-5.0.2.app -name \*.mdimporter
/Applications/Xcode-5.0.2.app/Contents/Applications/Application Loader.app/Contents/Library/Spotlight/MZSpotlight.mdimporter
/Applications/Xcode-5.0.2.app/Contents/Library/Spotlight/uuid.mdimporter
Running this command
mdimport -g /Applications/Xcode-5.0.2.app/Contents/Library/Spotlight/uuid.mdimporter ~
finally indexes the .xcarchive bundle that is in the root of the user's home directory. It does NOT index the bundles in ~/Library/Developer/Xcode/Archives, though, even when I explicitly point mdimport to this folder.
The question remains: Why is uuid.mdimporter not run automatically?
EDIT
The solution was to reboot the machine (logout/login might have been sufficient), archive bundles outside of ~/Library are now properly indexed. The reason why I needed to reboot probably is this:
I am using a privileged admin user (A) for installing software, but I am using a different, non-privileged user (U) for normal work, such as developing with Xcode.
I was logged in with user U at the time I installed Xcode with user A
Since that time I have never rebooted, nor made any logins (I prefer sending my machine to sleep over night instead of shutting it down). Presumably, the list of active Spotlight importers is updated (probably by launch services) only when logging out/logging in, or after a reboot.
Anyway, during troubleshooting I found that you can check the list of active Spotlight importers by running mdimport -L (note that different users can have different Spotlight importers active at the same time). Unsurprisingly, after the reboot uuid.mdimporter is now listed, while before the reboot it was not.
Here is a useful Apple document that I found after some googling: Troubleshooting Spotlight Importers.
FINAL SOLUTION
Configure Xcode so that the archive folder is located outside of ~/Library. In Xcode 6 you can do this in the Preferences dialog, under the "Locations" tab.
My Java application has a launcher which is a .app and a helper app which is bundled with it.
I am trying to make .pkg installer with a background image using the following commands:
pkgbuild --root "./Temp" --identifier "com.company.id" --install-location "/Applications" --sign "signature" "temp.pkg"
productbuild --package-path "temp.pkg" --distribution "./Distribution.xml" --package-path "./Temp" --resources "./Resources" --sign "installer signature" "$FINAL_PKG"
When I look in the directory at ./Temp both of the .app folders are there and when I deconstruct the .pkg with:
pkgutil --expand "temp.pkg" "temp"
I see the .app folders but sometimes one of the .app folders do not show up when it is installed from the pkg. They always seem to show up the first time it is installed, but on machines where the application is installed and deleted many times (like on test and development machines) one of the .app folders will eventually not show up. I am wondering what could be going on here?
Initially we had the helper app inside a separate directory as the main app and in this case, the helper app would sometimes not get installed but the main app always would be. Next, we tried putting the helper app inside of the main app and then this worked the first time but the next time I tried to to install from the installer the main app wasn't there!
I have had roughly the same problem. It appears that the OS X installer uses information about already installed packages and application bundles in order to decide where and if to install new packages. As a result, sometimes my installer did not install any files whatsoever, and sometimes it just overwrote the .app bundle in my build tree. Not necessarily the one used to build the installer, but any .app bundle that OS X had found. In order to get the installer to install the files properly I had to do two things:
Tell OS X to forget about the installed package
sudo pkgutil --forget <package id> Not sure if this is needed for you nor in my case, but it is probably a good idea anyway.
Delete all existing .app bundles for the app. If I didn't do this, the existing app bundle was overwritten on install instead of the app being placed in /Applications. Maybe there is a way to prevent this while building the installer package, but I haven't found it.
If you can you should probably try to make your application self contained so that users can install it by just drag and dropping it into /Applications. Of course, this only works if you don't need to install anything outside of your .app bundle.
If you don't want to (or can't expect other users to) hunt down and delete all existing copies of the app as described by villintehaspam, or just really need the app not to be relocated, you can provide a Component Property List file with BundleIsRelocatable set to false.
An easy way to create a valid version of the plist file is with pkgbuild --analyze; then you can edit the one property and use the file. E.g.:
pkgbuild --root myapp.root --analyze myapp.plist
/usr/libexec/PlistBuddy -c 'set :Dict:BundleIsRelocatable false' myapp.plist
pkgbuild --root myapp.root --component-plist myapp.plist [...other options...] myapp.pkg
I want to remove all existing SDK versions as well as Xcode 4.
Xcode 4 Guide says to do this:
sudo /Xcode4/Library/uninstall-devtools --mode=all
But I don't have Xcode4 at this location and the only place I see it is under /Developer/Applications
I've already run the uninstall-devtools that was previously found in /Developer/Applications and then did a reinstall.
What else can I do to completely remove everything and start from scratch?
I use this command:
sudo /Developer/Library/uninstall-devtools --mode=all
Edit (1 year later):
If you've downloaded Xcode from the App Store, it's self-contained, as #mediaslave suggests. You can just drag it to the trash or use AppZapper (or a similar utility) to remove the developer tools.
If you're looking to update it, you can also do that straight through the App Store.
sudo /[xcode-path]/Library/uninstall-devtools --mode=all
Normally, [xcode-path] means /Developer, but if you have multiple versions, for example 3 is the first installed, 4 is second, /Developer will be xcode 3's root derectory and /Xcode4 for xcode 4.
Ensure Xcode, iOS Simulator, and the Mac App Store apps aren't running, then trying running the uninstall script at this (different!) location:
/Library/Developer/Shared/uninstall-devtools
This is where I found it.
Also delete Install Xcode.app from Applications folder, and Empty Trash.
Then run App Store again, and find/install Xcode.
su (or sudo su, whatever)
find / -name uninstall-devtools
This will reveal where the utility is...
If you have XCode 4.3.1, just Move To Trash the XCode.app file in the Applications folder.
If you have installed xcode from Mac App store, then you need to delete it from Launch pad. You can do this by locating xcode icon in launch pad, long click on the icon till it starts dancing. Then delete it and wait for a while till the xcode.app is deleted from /Application. If you manually delete xcode.app from /Application, App store will continue to think its installed and will not allow you to reinstall in future.
I tried to uninstall this by deleting it, but the AppStore still thought that it was installed. I deleted some preferences files in my /private directory, which made the AppStore "forget" that I had installed Xcode. I used the following command:
sudo find / -iname '*xcode*' 2> /dev/null | egrep '^/private.*' | xargs -I file sudo rm -rfv file
Which deleted the following files from my computer:
/private/var/db/receipts/com.apple.pkg.XcodeMAS_iOSSDK_6_1.bom
/private/var/db/receipts/com.apple.pkg.XcodeMAS_iOSSDK_6_1.plist
/private/var/folders/7d/n34963zx62s7znxyzn3dn6bh0000gq/C/com.apple.Xcode.503/CachedSpecifications-Xcode
/private/var/folders/7d/n34963zx62s7znxyzn3dn6bh0000gq/C/com.apple.Xcode.503/CachedSpecifications-xcodebuild
/private/var/folders/7d/n34963zx62s7znxyzn3dn6bh0000gq/C/com.apple.Xcode.503
I do not know what these files are used for, but it made the AppStore forget that it was installed, which is what I needed to happen. In my case, the AppStore was not allowing me to update to the new version of Xcode.
My goal is to create a .pkg that will simply instruct the Mac Installer to simply install files, like fonts, from the .pkg to a directory when run. I've tried using Xcode, but it seems more application oriented.
How do I configure Xcode with a generic document so I can Build and Archive, then Share using the Organizer to create the .pkg?
The Copy Files Target appears to be in use only at build time, so that doesn't seem to be much help.
You should use the PackageMaker application, not Xcode. You can find it under /Developer/Applications/Utilities.