Even if Xcode can handle 400 projects in one workspace, do you really want to make and manage 400 projects? Even if you automate their creation, once created, each project is separate - if you make a change you would like to have in each project, you have to make that change 400 times. You could edit each project using a script, but that approach is horribly fragile. I would prefer a single project which makes a generic target, with additional Run Script build phases to the target which make the target's output customer-specific, perhaps based on an environment variable. You can set environment variables from the Run Scheme, so you don't have to drop into the command line to build for a new customer from Xcode. This should make adding a new customer reasonably painless, and avoid duplication.

you can override connectClient and disconnectClient if you want to monitor connected clients. Make the number of connected clients a property of your extension. To communicate this asynchronously to your app, you can call notifyPropertiesChanged in your extension. In the app, install a notification handler using CMIOObjectAddPropertyListener.

"This example is a scene from Prehistoric Planet that has been converted to 3D for playback on Apple Vision Pro. Watch Prehistoric Planet in 2D on Apple TV+, where available. ". You're trying to play it back on a Mac.

if you open the Xcode Devices and Simulators window, find your phone in there, can you see any crash logs from the phone that tell you anything useful?

attach .onAppear to the contents of your details, kinda like this minimal example struct ContentView: View { var body: some View { NavigationSplitView( sidebar: { Text("Sidebar") }, detail: { Text("detail") .onAppear { print("details appeared") } }) } }

This doesn't usually happen to me, but I also don't have this icon in the top of my Xcode window: might that have something to do with it?

in another Terminal window: log stream --predicate '((process beginswith "tcc") and (message contains "<bundle ID of your tool>"))' then run the tool, should give you some clues

You signed with an Apple Development certificate, you can't notarize apps signed for development. They must be "signed with a valid Developer ID certificate", as the error message says. Development signing is for development, for use on your own computer or other computers mentioned explicitly in the Apple Development certificate. Distribution signing uses a different certificate, enabling the app to be launched without complaint on any machine.

I can't figure out what you're trying to do here. I tried to put your TestView() into a template project's ContentView, but nothing animated at all and your print statements were not called. Your code didn't compile because previousOffset = offSet should read previousOffset = oldValue could you post or provide a link to complete code which works, and provide an explanation of what you're actually trying to do? There would appear to be much simpler ways to offset a view with an animation.

You don't, usually. The first time your app uses the camera (e.g.makes a AVCaptureDeviceDiscoverySession ), the OS will figure out whether you have an entitlement to use the camera (com.apple.security.device.camera) and a usage string (com.apple.security.device.camera, or INFOPLIST_KEY_NSCameraUsageDescription). The OS will show the permission dialog, using your app's usage string. If you want to make this a bit more explicit, you can make a button in your own UI which deliberately provokes this OS behavior, perhaps as part of an onboarding flow. But you don't have direct control over it, because the OS is asking for user permission, your app is just awaiting user permission or an error.

Instead of layer.addSublayer(previewLayer) write self.layer = previewLayer in your CameraPreviewLayer.

You said "My ultimate goal is to examine the detailed error message " The error message will appear in the system log, along with all the other messages from numerous processes on your Mac. You could use the Console app to look at the log, but its filtering is a bit rudimentary. The only tool you need is the command line tool log. Try man log for starters, then go looking on the Internet for "macOS log predicate example" or something like that. You probably want to look for logs emitted by tccd (the Transparency, Consent and Control daemon) with the text "disable-library-validation" in the message field. You can also cause the problem, then quickly use sudo log collect --last 1m. This will write a .logarchive file into the current directory (it won't overwrite one that is there already), giving you an archive you can poke around in at your leisure. A minute of logs is still a pretty huge database, but it might be a good way to find out what predicate you should be using.

what makes you think there are any internal USB devices? Which devices do you think are missing? Why do you need the information? If you can't do anything with the device (because it is proprietary, and can only be accessed over the higher-level interfaces provided by Apple), why would you care about it?

The path to the developer directory is /Applications/Xcode.app/Contents/Developer, not ...Developers. (no 's' on the end). You do need to point at an existing directory. If you are using Xcode 14, and you renamed it Xcode14, your command should be xcode-select --select /Applications/Xcode14.app/Contents/Developer When you install command line tools, they are installed into the currently-selected Xcode. You are saying "my command line tools in Xcode are Xcode 15.3". Which Xcode do you want to use? You said you switched from Xcode 13 to Xcode 15, but you're using Xcode 14 - which is it? You can use multiple Xcode versions on one machine, but you have to be careful about running multiple xcodebuild commands at the same time if you want to target different tools, because the xcode-select command is system-wide. If you launch Xcode from Finder, you'll use the one you launch, you don't need to set anything. If you run xcodebuild at the command line, it will use the selected Xcode, which by default is the one in /Applications/Xcode. I usually make sure that the Xcode I use on a daily basis is actually called "Xcode", and any beta or previous versions I have lying around have a different name. It sounds like your build script is specifically looking for an app called "Xcode14". Maybe whoever wrote it named their Xcode "Xcode14". That's fine, but then you have to do the same thing (which is pretty strange if you're actually using Xcode 15), or change the build script. I know what I'd do...

if you change the bundle ID in your Xcode target, and select "Automatically manage signing", Xcode will create the required certificate. If you're not requesting any managed entitlements, and it sounds like you are not, you wont' need a provisioning profile. If your app wants to save to disk, and it is sandboxed (which is a requirement for a Mac App Store app), you'll need to add an entitlement to punch through the sandbox - that's under Signing & Capabilities, File Access Type, User Selected File. When you archive your app in Xcode, it will lead you through the process and pick the correct type of certificate for the distribution method you choose.