Xcode Tool

[Penny Bozic]

Currentlypackage plugins are a function only of Swift Packages, and are not related to Xcode projects. It should be possible to have an Xcode project that uses a local package that uses a build tool plugin, though.

Rewatching the WWDC session on package manager plugins, I realised that my plugin needs to conform to both XcodeBuildToolPlugin and BuildToolPlugin, not just the former.

Would it be perhaps worthwhile inheriting BuildToolPlugin from the XcodeBuildToolPlugin protocol to enforce this?

The fix for me here was that my [ XCode > Preferences > Locations > Command Line Tools ] dropdown was empty. No idea why. But after clicking it and selecting the only available option my "active developer directory" error finally went away.

This error completely contradicts that setting the path to /Library/Developer/CommandLineTools is the workaround for the latest XCode/MacOS combo failing to find the command line tool commands under /Application/Xcode.App/ with the default path setting.

Hi! So I've figured out from this thread from the Xcode 14 beta days that to get build tool plugins running on a Continuous Integration server, you need to either set a boolean on the CI's system or pass in a -skipPackagePluginValidation parameter into xcodebuild.

The problem with this is that it trusts every package plugin, which is a gaping security hole, especially on CI systems that are creating builds. If someone were to add a malicious plugin to your codebase, it would run any time the CI built the PR, which seems real bad.

So Apple, i've got an idea : maybe people developping Xcode could start adding some god damn unit tests ? Screwing up the build of professional iOS developers that have no choice but use your tool is not ok !

I have in my projects a lot of .svg icons so is there any other (quicker)solution for fix this error? If i need to fix one by one it will takes me a lot of time :/ or hopefully Apple will release 15.3.1 version where this is fixed

The issue is still present in Xcode 15.4 beta 1, more than a month later. I guess, we cannot expect a fix from Apple in a reasonable timeframe and would have to recreate the asset, despite it working perfectly fine for years.

Have been having the exact same issue, but mine was building fine with 15.3, the update to 15.4 broke it. Came to the same conclusion that it was the .svg image causing it to crash but shocked at how specifically it is that it's an svg with gaussian blur (which mine also has). Kind of bummed and hope this is fixed soon since mine can't just be recreated, the whole point of the asset is that it's a 'glow' image, so the blur is necessary. At least now I know what it is and can continue developing.

If it serves someone, i found out that images with "/" in the name caused this same error, it took me a while to find out, since i was looking for gaussian blurs in my svgs and all, but none of that was the cause, it was names with /

I had a problem with SVG in XCode 15.3 and in 15.4. Moreover, the problem arises only from the code using SwiftUI, there is no problem in the part of the code where UIKit is used. Images that contained more than one slash in the path stopped being displayed, such as here "Flashlight/Icons/blink". I disabled the namespace in the "Icons" directory, replaced the path with "Flashlight/blink" and everything worked.

I was fortunately able to identify and fix the SVGs which were giving me problems. Both of the files had float values for size (height, width) and coordinates (x, y). Rounding those to the nearest integer value resolved the issue.

I don't recommend installing the full Xcode package unless you're developing software for an Apple device. The download will take too long and it will consume unnecessary disk space. Instead, try either of two faster methods.

Homebrew is the popular Mac package manager. Most developers need programming languages and utilities that don't come installed on macOS and are not included in the Xcode Command Line Tools package. Homebrew can install almost any open-source tool for developers.

If you haven't already installed Xcode Command Line Tools, you'll see a message that "The Xcode Command Line Tools will be installed." Press return to continue when prompted by the Homebrew installation script.

In the guide, I explain how to check if Xcode Command Line Tools Are Already Installed. I go into more detail about how to Install Xcode Command Line Tools with Homebrew. Finally, I explain how to Uninstall Xcode Command Line Tools, Reinstall Xcode Command Line Tools, and provide a List of Xcode Command Line Tools that you can use.

Edit More I think about it the more I think this is Kotlin Native specific. Clang and the Swift compiler are open source so there is no secret magic that allows these programs to generate binaries w/o needing XCode. Further, Go, GCC, OCaml, Crystal and many other compilers that have nothing to do with Apple are able generate assembly on MacOS w/o depending XCode either.

Hello, @realdoug! I can confirm that currently, one cannot use Kotlin/Native targeting Mac without the Xcode presented. Can you please clarify why this can become an obstacle to your case? This question is unusual feedback, so the team would like to know more.

Hey, I just wanted to add on to this. The plan of my company was to use Kotlin native for our internal CLI tools, now as others said installing XCode on your device is acceptable but not satisfying. The much bigger issue being that we cannot generate our CLI tools with our CI. Is there any possibility that Kotlin native would not need XCode in the future so applications build with it could be build on a non-apple CI?

I've been trying to properly understand where AppStore looks to figure out what needs updating, but I haven't been able to find a certain answer yet. I tried editing the updatejournal file, but that didn't help, so I've since restored it.

I started to suspect that the fact that pkgutil shows some CLTools-packages might be the cause of this. Forgetting them does not work however as the bom are neither in /var/db/receipts or /Library/Receipts (the pkgutil --forget essentially fails because of this).

I did however find them after a lot of searching in /System/Library/Receipts. Those I can't delete though due to the system security. I can of course bypass that and delete them to see if it works, but I don't want to do that "just to see".

So I booted into recovery mode, disable SIP, moved all files from that folder that had com.apple.pkg.CLTools*in their name, and the update in the App Store went away. Then I booted into recovery again to enable SIP.

Know what it was? The receipts were in /Library/Apple/System/Library/Receipts. Removed everything with CLTools or SDK in the name and the system update for the CLT disappeared. THANK THE LORD. Not sure if SIP needed to be disabled for this or not (I had it disabled).

On a fairly recent Mac setup (Apple Silicon chip, macOS 12.0 Monterey Beta), having installed the Command Line Tools then uninstalled them by deleting /Library/Developer/CommandLineTools and running sudo xcode-select -r, I was still getting updates to the tools in System Preferences > Software Update.

Had the exact same issue with Command Line Tools update and went through the removal steps above. Cross checked with the Apple Dev site and the info there. Everything was removed. Checked and Double Checked.

For example, when we first introduced Swift to our music app, a requirement that we set for ourselves was not to worsen the developer experience. One metric for that is build time: is adopting Swift slowing our Xcode build times down or speeding them up? And how do we accurately measure that (without using a stopwatch every time we hit run)?

XCMetrics is an all-in-one tool that tracks Xcode build metrics for teams of all sizes. We built it with a flexible and extensible architecture in order to fit as many requirements as possible into its plugin system, allowing for customization of the information collected in every build.

The main method forwards the arguments parsing to XCMetrics. You proceed to create a XCMetricsConfiguration and add XCMetricsPlugin to it. Each plugin takes a dictionary of the environment variables passed to the post-action scheme environment and returns a dictionary of the metrics to be collected. You would then distribute your own custom version of XCMetrics and execute it with the same arguments to upload the logs with the new metrics attached.

We provide a Docker image that has everything needed to deploy the XCMetrics backend in any infrastructure. We also support a one-click deployment to Google Cloud via Google Cloud Run. Our documentation also contains examples on how to deploy to Kubernetes, if you fancy that.

XCMetrics has been in use in production at Spotify for over one year, and it has allowed us to make more informed decisions in regards to our project structure and investments. We have data pipelines and dashboards that are used every day to monitor the state of our codebase and tools.

You can learn more and watch a demo at XCMetrics.io. We are happy to receive bug fixes and improvements on GitHub. And make sure to check out our contribution guide, which explains more advanced concepts of the project.

[Command Line Tools] enables UNIX-style development via Terminal by installing command line developer tools, as well ass macOS SDK frameworks and headers. Many useful tools are included such as the Apple eLLVM compiler, linker, and Make.

Kinsta offers premium managed WordPress hosting for everyone, small or large. Powered by Google Platform and strengthened by Cloudflare, they take performance to the next level. All hosting plans include 24/7/365 support from their team of WordPress engineers. Get started with a free migration today.

Just Getting Started with WordPress? I write a lot about WordPress development but if you're just getting started, I recommend checking out WPBeginner. They have free training videos, glossary, and more.

3a8082e126