In Xcode I have created UI-less application. I tried to add following code: import CloudKit let container = CKContainer.default() And it is failing with: In order to use CloudKit, your process must have a com.apple.developer.icloud-services entitlement. The value of this entitlement must be an array that includes the string "CloudKit" or "CloudKit-Anonymous". If I go to project and select my Command Line Tool target I don't see CloudKit capability that I usually see in UI based applications. So, is it impossible to use CloudKit from Command Line tools?

Hi, I have been tasked with porting our C++ codebase from Windows/Linux to MacOS. Our setup uses Premake to generate platform specific project files. On Windows it creates a Visual Studio solution and project files, on Linux it creates makefiles, and on MacOS it generates an Xcode workspace and project files. Our project hierarchy looks something like this: Solution/Workspace S Project A (shared library) Project B (shared library) Project C (shared library) Projects D to R (About a dozen or so - all shared libraries) Project V (application) Project W (application) Project X (application) Project Y (application) Project Z (application) Projects B and C depend on A. Projects D to R are dependent on some or all of the projects A, B, and C. Each application is dependent on projects A, B, and C, and some of the intermediate projects D to R. (The exact dependencies vary according to the application.) Additionally, some applications can load shared libraries dynamically according to their state/settings. I.e., not all shared library dependencies are known at build time. Initially all building typically happens on the command line. Once our build script has run Premake to generate the project files, it proceeds to build everything. Further builds can happen within Visual Studio/Xcode as part of the normal workflow. However, building must happen on the command line for DevOps CI/Release builds. On Windows, for example, MSBuild lets me build the entire solution for a given configuration (Debug/Release/etc) in a single command. This builds projects A, B, C in order, followed by the intermediate projects (D to R), followed by the applications (V to Z). Each project is built once. Same deal for Linux. Make builds each project in turn according to the dependencies with a single command. Each project is build once. On MacOS, however, xcodebuild doesn't let me just build the entire workspace for a given configuration. I can specify a workspace, but then I have to also specify a scheme. Or I can just specify a specific project. However, when I build a specific project, Xcodebuild always builds all dependencies. So my build script at the moment explicitly builds projects D to R, followed by applications V to Z. This, however, leads to the ridiculous situation of Xcode building projects in the following order: D, C, B, A E, C, A F, C, B, A G, B, A etc... V, F, G, H, C, B, A W, G, I, C, B, A X, K, C, B, A etc... With the obvious effect of our MacOS builds taking 20+ times longer than their Windows/Linux counterparts. So, my main questions are: Is it possible to just build every project in the workspace once? Or if that can't be done, is it possible to not build project dependencies? I.e., can I just build the single project I specify? If neither of those are possible, how can I optimise my builds so that they don't take half a day to complete? I should point out, removing the project dependencies isn't an option. If project A is genuinely out of date, it should be built if I build one of the applications. Xcode should be smart enough to realise that it doesn't need to build everything every time.

For MacOS I wrote a Terminal Command Line Tool to help me do number crunching calculations. No need for UI. This works great as-is, but there are opportunities to make the work more interesting by giving it some graphical representation like a heat map of the data. To that end I want the terminal to launch a SwiftUI code to open a window given an optional command line parameter that would display this visual representation of data in a new window. It would be nice to interact with that window visualization in some ways using SwiftUI. I originally thought it'd just be as easy as creating a SwiftUI View file and then throwing what normally appears under @main into a launch function and then calling the launch function from my main.swift file: import SwiftUI struct SwiftUIView: View { var body: some View { Text("Hello, World!") } } #Preview { SwiftUIView() } func LaunchSwiftUIApp() { //@main struct SwiftUIApp: App { var body: some Scene { WindowGroup { SwiftUIView() } } } } Of course this doesn't work. I've already have the command line code just spit out various png files via command line so looking to make those visualization a little more interactive or readable/organized by coding some SwiftUI stuff around those current visualizations. Anyway. Looking around this doesn't seem to be a thing people normally do. I'm not sure how to setup the Terminal Command Line Tool code that I wrote to optionally launch into SwiftUI code.

When I compile my Xcode project using the xcodebuild command, I observe long incremental build durations. For example, compiling a new, empty project in Xcode only takes around one second. The same project takes 7 seconds to compile using the xcodebuild command. I've noticed that xcodebuild hangs at the "GatherProvisioningInputs" phase. Steps to Reproduce: Create a new Xcode project (iOS app template) Build the project in Xcode with timing summary enabled Build the same project from the command line with the following command: time xcodebuild -destination 'platform=iOS Simulator,name=iPhone 15 Pro,OS=latest' I would appreciate any insights or suggestions on how to improve the build times when using the xcodebuild command. Thank you in advance for your help!

I would like to use devicectl to take a picture of my iPhone screen on iOS 17. So far I have successfully performed, Launching and exiting the app I created. Reboot the iPhone connected via USB etc.... I used to use libimobiledevice, but when I bought a new iPhone with iOS17, I can't do it anymore.

Hello, I'm trying to use devicectl to observe Darwin Notifications on my iPhone. Instructions: OVERVIEW: Observe a Darwin notification on a device. Note that this command will wait for 300 seconds by default before exiting. You can override this by providing a different --timeout value. USAGE: devicectl device notification observe --device <uuid|ecid|udid|name> --name <name> ... [--verbose] [--quiet] [--timeout <seconds>] [--json-output <path>] [--log-output <path>] DEVICE OPTIONS: -d, --device <uuid|ecid|udid|name> The identifier, ECID, UDID, or name of the device. COMMAND OPTIONS: --name <name> The name of the Darwin notification. This can be passed multiple times to observe multiple Darwin notifications. OUTPUT OPTIONS: -v, --verbose If given, provide more logging output than normal. -q, --quiet If given, output will include only errors. -t, --timeout <seconds> The overall command timeout in seconds. If this limit is exceeded the command is abandoned as a failure. -j, --json-output <path> An optional path to write a JSON file with command results. Note: JSON output to a user-provided file on disk is the ONLY supported interface for scripts/programs to consume command output. -l, --log-output <path> An optional path to write all logging otherwise passed to stdout/stderr. OPTIONS: --version Show the version. -h, --help Show help information. Executed command: xcrun devicectl device notification observe --device XXX --name com.example.Notification Result: Darwin notification observation started. 300.0 seconds remaining: On iOS, I'm posting a Darwin notification using: CFNotificationCenterPostNotification(center, CFNotificationName("com.example.Notification" as CFString), nil, nil, true) My CFNotificationCenterAddObserver on iOS does receive this notification. But the devicectl does not. Also no results when I remove the observer on iOS. How can I send a notification in such a way that it is picked up by the devicectl observer?

FeedbackID: FB13636921 I'm using /usr/sbin/screencapture -v -x -C -k -R 0,0,500,500 /path/to/a/movfile/in/a/folder/in/my/apps/sandbox/Group/Container in my app to allow users to capture screenshots and recordings. Screenshots keep working fine on macOS Sonoma 14.4b23E5196e, but video recordings no longer work. I'm guessing the following log output has something to do with it: default 15:01:53.151819+0100 screencapture sampleBuffer: start recording time: 3123.604833 target: 3123.474266, overshot: 0.130568 error 15:01:53.185179+0100 screencapture <private>:246:<private> Not writable url (null).!folderIsWritable == true error 15:01:53.185236+0100 screencapture <private>:50:<private> We could not create a byte stream! error 15:01:53.185252+0100 screencapture <private>:87:<private> NULL byte stream. error 15:01:53.185298+0100 screencapture <private>:3479:<private> ### Err -45, error 15:01:53.185312+0100 screencapture <private>:3814:<private> ### Err -45, error 15:01:53.185334+0100 screencapture <<<< AVCaptureMovieFileOutput >>>> Fig assert: "status == 0 " at (AVCaptureMovieFileOutput.m:2522) - CMIOFileWritingControlTokenStartWriting (err=-45) error 15:01:53.185374+0100 screencapture <private>:1885:<private> ### Err -67452, error 15:01:53.185388+0100 screencapture <private>:303:<private> FigMovieFormatFileWriter::PostProcessMovie: WriteMovie() errored!!! -67452 error 15:01:53.185476+0100 screencapture <private>:4687:<private> consolidate movie fragments err : -17913 default 15:01:53.185610+0100 screencapture <<<< AVError >>>> AVLocalizedErrorWithUnderlyingOSStatus: Returning error (AVFoundationErrorDomain / -11800) status (-45) default 15:01:53.186201+0100 screencapture didFinishRecording: No trim finish. duration: 0.000000s size: 0, error: Error Domain=AVFoundationErrorDomain Code=-11800 "The operation could not be completed" UserInfo={AVErrorRecordingSuccessfullyFinishedKey=false, NSLocalizedDescription=The operation could not be completed, NSLocalizedFailureReason=An unknown error occurred (-45), NSURL=file:///Users/eternalstorms/Library/Group%20Containers/group.com.apple.screencapture/ScreenRecordings/3ED15EE7-A814-47A7-A398-29D5A6AD03C1.mov, NSUnderlyingError=0x6000031d80c0 {Error Domain=NSOSStatusErrorDomain Code=-45 "fLckdErr: file is locked"}} error 15:01:53.186290+0100 screencapture recording failed. The operation could not be completed Are there new entitlements we need for this in our apps starting with macOS Sonoma 14.4? Or is it a bug? Calling it directly from Terminal works. Thank you, Matthias

Hi, I'm trying to use the appIcon command of devicectl. I'm connecting to an iPhone 14 Pro running iOS 17.0.2. xcrun devicectl device info appIcon --help OVERVIEW: Request app icon generation from this device. This command searches for an app installed on this device and requests for its icon to be generated. USAGE: devicectl device info appIcon [<options>] --device <uuid|ecid|udid|name> --allow-placeholder <allow placeholder> --width <width> --height <height> --scale <scale> DEVICE OPTIONS: -d, --device <uuid|ecid|udid|name> The identifier, ECID, UDID, or name of the device. COMMAND OPTIONS: --app-bundle-id <app bundle identifier> Look for app icon information with the given application bundle identifier on device. Note: If both app-bundle-id and app-path are provided, only app-path will be used. --app-path <app path> Look for app icon information at the given application path on device. Note: If both app-bundle-id and app-path are provided, only app-path will be used. --allow-placeholder <allow placeholder> Allow placeholder icons to be generated. Note: Passing `true` will allow placeholder icons to be returned. Allowing placeholder icons will ensure no I/O is done on device. If you want to make sure you get the icon most accurate to your request -- which could use more resources on the device -- set this to `false`. --width <width> Request app icon generation with the specified width. --height <height> Request app icon generation with the specified height. --scale <scale> Request app icon generation with the specified scale. --destination <destination> Write the image (in png format) to the provided file on the host device. OUTPUT OPTIONS: -v, --verbose If given, provide more logging output than normal. -q, --quiet If given, output will include only errors. -t, --timeout <seconds> The overall command timeout in seconds. If this limit is exceeded the command is abandoned as a failure. -j, --json-output <path> An optional path to write a JSON file with command results. Note: JSON output to a user-provided file on disk is the ONLY supported interface for scripts/programs to consume command output. -l, --log-output <path> An optional path to write all logging otherwise passed to stdout/stderr. OPTIONS: --version Show the version. -h, --help Show help information. I've tried multiple variations of parameters and both apple-bundle-id and app-path, but always receive an error. xcrun devicectl device info appIcon --device XXX --app-bundle-id XXX --app-path XXX --allow-placeholder true --width 60 --height 60 --scale 3 --destination icon.png -j icon.json -t 10 -v With JSON output "error" : { "code" : 6007, "domain" : "com.apple.dt.CoreDeviceError", "userInfo" : { "NSLocalizedDescription" : { "string" : "CGImage was nil when attempting to write to a destination." } } }, Without JSON output 09:32:42 Acquired tunnel connection to device. 09:32:42 Enabling developer disk image services. 09:32:42 Acquired usage assertion. Application Icon Image Information • Is Placeholder - false • Size • Height - 0.0 • Width - 0.0 • Scale - 0.0 • Pixel Size • Height - 0.0 • Width - 0.0 Has anyone managed to successfully extract an app icon using devicectl?

I regularly see questions from folks who’ve run into problems with their third-party IDE on macOS. Specifically, the issue is that their IDE is invoking Apple’s command-line tools — things like clang and ld — and that’s failing in some way. This post collects my ideas on how to investigate, and potentially resolve, issues like this. If you have any questions or comments, please put them in a new thread here on DevForums. Tag it appropriately so that I see it. Good tags include Compiler, Linker, LLVM, and Command Line Tools. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Investigating Third-Party IDE Integration Problems Many third-party IDEs rely on Apple tools. For example, the IDE might run clang to compile C code or run ld to link object files. These IDEs typically don’t include the tools themselves. Rather, they rely on you to install Xcode or Apple’s Command Line Tools package. These are available at Apple > Developer > Downloads Occasionally I see folks having problems with this. They most typically report that basic stuff, like compiling a simple C program, fails with some mysterious error. If you’re having such a problem, follow the steps below to investigate it. IMPORTANT Some IDEs come with their own tools for compiling and linking. Such IDEs are not the focus of this post. If you have problems with an IDE like that, contact its vendor. Select Your Tools macOS has a concept of the current command-line tools. This can either point to the tools within Xcode or to an installed Command Line Tools package. To see which tools are currently selected, run xcode-select with the --print-path argument. This is what you’ll see if you have Xcode installed in the Applications folder: % xcode-select --print-path /Applications/Xcode.app/Contents/Developer Note All of the tools I discuss here are documented in man pages. If you’re not familiar with those, see Reading UNIX Manual Pages. And this is what you’ll see with a Command Line Tools package selected. % xcode-select --print-path /Library/Developer/CommandLineTools There are two common problems with this: It points to something you’ve deleted. It points to something unexpected. Run the command above to see the current state. If necessary, change the state using the --switch option. For example: % xcode-select --print-path /Applications/Xcode.app/Contents/Developer % clang -v Apple clang version 14.0.3 (clang-1403.0.22.14.1) … % sudo xcode-select --switch ~/XcodeZone/Xcode-beta.app % clang -v Apple clang version 15.0.0 (clang-1500.0.38.1) … I have Xcode 14.3 in the Applications folder and thus clang runs Clang 14.0.3. I have Xcode 15.0b5 in ~/XcodeZone, so switching to that yields Clang 15.0.0. It’s possible to run one specific command with different tools. See Select Your Tools Temporarily, below. Run a Simple Test A good diagnostic test is to use the selected command-line tools to compile a trivial test program. Consider this C [1] example: % cat hello.c #include <stdio.h> int main(int argc, char ** argv) { printf("Hello Cruel World!\n"); return 0; } % clang -o hello hello.c % ./hello Hello Cruel World! IMPORTANT If possible, run this from Terminal rather than, say, over SSH. You may need to expand this test program to exercise your specific case. For example, if your program is hitting an error when it tries to import the Core Foundation framework, add that import to your test program: % cat hello.c #include <stdio.h> #include <CoreFoundation/CoreFoundation.h> int main(int argc, char ** argv) { printf("Hello Cruel World!\n"); return 0; } When you compile your test program, you might see one of these results: Your test program compiles. Your test program fails with a similar error. Your test program fails with a different error. I’ll explore each case in turn. [1] For a C++ example, see C++ Issues, below. If your test program compiles… If your test program compiles from the shell, that proves that your basic command-line tools setup is fine. If the same program fails to compile in your IDE, there’s something IDE-specific going on here. I can’t help you with that. I recommend that you escalate the issue via the support channel for your IDE. If your test program fails with a similar error… If your test program fails with an error similar to the one you’re seeing in your IDE, there are two possibilities: There’s a bug in your test program’s code. There’s an environmental issue that’s affecting your command-line tools setup. Don’t rule out the first possibility. I regularly see folks bump into problems like this, where it turns out to be a bug in their code. For a specific example, see C++ Issues, below. Assuming, however, that your test program’s code is OK, it’s time to investigate environmental issues. See Vary Your Environment, below. If your test program fails with a different error… If your test program fails with a different error, look at the test program’s code to confirm that it’s correct, and that it accurately reflects the code you’re trying to run in your IDE. Vary Your Environment If your test program fails with the same error as you’re seeing in your IDE, and you are sure that the code is correct, it’s time to look for environmental factors. I typically do this with the steps described in the next sections, which are listed from most to least complex. These steps only tell you where things are going wrong, not what is going wrong. However, that’s often enough to continue the investigation of your issue. Vary Your Shell Try running your commands in a different shell. macOS’s default shell is zsh. Try running your commands in bash instead: % bash … bash-3.2$ clang -o hello hello.c bash-3.2$ ./hello Hello Cruel World! Or if you’ve switched your shell to bash, try it in zsh. Vary Your User Account Some problems are caused by settings tied to your user account. To investigate whether that’s an issue here: Use System Settings > Users & Groups to create a new user. Log in as that user. Run your test again. Vary Your Mac Some problems are system wide, so you need to test on a different Mac. The easiest way to do that is to set up a virtual machine (VM) and run your test there. Or, if you have a separate physical Mac, run your test on that. Vary Your Site If you’re working for an organisation, they may have installed software on your Mac that causes problems. If you have a Mac at home, try running your test there. It’s also possible that your network is causing problems [1]. If you have a laptop, try taking it to a different location to see if that changes things. [1] I rarely see this when building a simple test program, but it do see it with other stuff, like code signing. C++ Issues If you’re using C++, here’s a simple test you can try: % cat hello.cpp #include <iostream> int main() { std::cout << "Hello Cruel World!\n"; } % clang++ -o hello hello.cpp % ./hello Hello Cruel World! A classic problem with C++ relates to name mangling. Consider this example: % cat hello.c #include <stdio.h> #include "hello-core.h" int main(int argc, char ** argv) { HCSayHello(); return 0; } % cat hello-core.cpp #include "hello-core.h" #include <iostream> extern void HCSayHello() { std::cout << "Hello Cruel World!\n"; } % cat hello-core.h extern void HCSayHello(); % clang -c hello.c % clang++ -c hello-core.cpp % clang++ -o hello hello.o hello-core.o Undefined symbols for architecture x86_64: "_HCSayHello", referenced from: _main in hello.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) The issue here is that C++ generates a mangled name for HCSayHello: % nm hello-core.o | grep HCSayHello 0000000000000000 T __Z10HCSayHellov whereas C uses the non-mangled name: % nm hello.o | grep HCSayHello U _HCSayHello The fix is an appropriate application of extern "C": % cat hello-core.h extern "C" { extern void HCSayHello(); }; Select Your Tools Temporarily Sometimes you want to temporarily run a command from a particular tools package. To continue my earlier example, I currently have Xcode 14.3 installed in the Applications folder and Xcode 15.0b5 in ~/XcodeZone. Xcode 14.3 is the default but I can override that with the DEVELOPER_DIR environment variable: % clang -v Apple clang version 14.0.3 (clang-1403.0.22.14.1) … % DEVELOPER_DIR=~/XcodeZone/Xcode-beta.app/Contents/Developer clang -v Apple clang version 15.0.0 (clang-1500.0.38.1) … Revision History 2025-01-27 Remove the full width characters. These were a workaround for a forums platform bug that’s since been fixed. Made other minor editorial changes. 2023-07-31 First posted.

I have a command line tool that zsh refuses to run when built for Apple Silicon or as a univerisal binary (the specific message is zsh: killed TOOL_NAME). I can only get it to run if I build it exclusively for Intel/Rosetta. Running/debugging from within Xcode works fine for any architecture. The tool is a very simple C/C++ unix command-line tool; it doesn't have any external dependencies beyond the C runtime and the C++ STL. I suspect something in code signing is going awry, but I've tried various team and certificate combinations without any luck. I've also tried enabling/disabling the app sandbox, also without any luck. (The app is not for distribution so it doesn't really need to be code signed at all.) Any suggestions?