Some things I notice while reading this, and no offense is intended here:
- If I’ve tried everything, either I’ve done that and there’s nothing more anyone can do or suggest, or it means that I really didn’t try everything and I’m, well, it means that I’m misrepresenting the current state of things.
- I’d avoid paraphrasing error messages. Error messages can sometimes be subtly different, and sometimes we just misread them. If there are errors I don’t understand, I would want to post the errors or diagnostics as shown.
- I’d avoid blaming the tools. I absolutely used to blame the tools I was using too, but learned the hard way that the error being encountered was usually mine. I have actually caught a few compiler errors and tooling errors over the years, but that's been rare in mainstream IDEs and compilers. When reporting an error such as Xcode not working, that’s a fairly serious claim, and I’d want to post a fairly detailed list of steps to reproduce the error, so it is clear to the folks supporting Xcode or the compiler or whatever the bug report target might be can quickly isolate and identify the error and can then use the reproducer to test the fix. I’d prefer to provide succinct proof of the error.
- There’s no supporting code or evidence or errors included in the “not working” here, so there’s little to build upon and little to tailor an answer upon.
- The phrase “not working” is one I’d generally avoid using (in isolation), writing this as somebody with an IT role, or in app or system development roles. Not without added details about what is not working, what was tried, etc. We’re reading a bug report, pretty clearly something here (what?) is not working. The question then becomes what, and why.
- If I’m posting a question when following some example, I’d reference that or link to that, so others can know what I was trying to do and trying to follow, and whether there might be issues or concerns or confusions with the example. (In the following, I’ll mention some issues with the linked example used below, too.)
The following link is an older intro to using the Swift package manager and command line and using Xcode, and it still works with Xcode 14.3.1 on macOS 13 (specifically 13.6.1 on Intel), with the exception of the deprecation of the swift package generate-xcodeproj stuff. That was deprecated, and Xcode can now open the package directly without needing that. Where the linked example shows swift package generate-xcodeproj, skip that and open Package.swift instead, and you’ll be in Xcode looking at what the package manager has created; at a hello world example program. Which can be built and run
https://xebia.com/blog/learning-swiftpm/
This is Xcode 14.3.1 on macOS 13.6.1 Intel with command line tools installed and a Swift executable created (swift package init --type executable):
$ swift --version
swift-driver version: 1.75.2 Apple Swift version 5.8.1 (swiftlang-5.8.0.124.5 clang-1403.0.22.11.100)
Target: x86_64-apple-macosx13.0
$ # [other commands expunged here]
$ ls -Rl
total 8
-rw-r--r--@ 1 mrhoffman staff 505 Dec 17 12:14 Package.swift
drwxr-xr-x 3 mrhoffman staff 96 Dec 17 12:14 Sources
./Sources:
total 8
-rw-r--r--@ 1 mrhoffman staff 95 Dec 17 12:14 main.swift
$
Yeah; Xcode clearly creates some hidden files here, too. (That from the “total 8” stuff.)
TL;DR: With some more details of what you’re attempting and encountering, and the tooling, and with what tutorials you’re using if any, we might be able to better tailor an answer here, and get you moving again.