I have some code calling this method: mutating func readOffset() UInt64 { let offset: UInt64 debugLog("readOffset") switch (self.formatVersion) { case .v42: let offset32: UInt32 = self.reader.get() offset = UInt64(offset32) case .v43: offset = self.reader.get() } return offset } If I put a breakpoint on the switch statement, Xcode never stops there, and if the debugLog() call is commented out, I can't even step into the function at the call site; it just runs to the next breakpoint in my code, wherever that happens to be. If I put the breakpoint on debugLog(), it stops at the breakpoint. If I put breakpoints at the self.reader.get() calls, it stops at those breakpoints AND I can step into it. This is a unit test targeting macOS, and optimization is -Onone. Xcode 12.4 (12D4e) on Catalina 10.15.7 (19H524).

I’m writing an app that, among other things, displays very large images (e.g. 106,694 x 53,347 pixels). These are GeoTIFF images, in this case containing digital elevation data for a whole planet. I will eventually need to be able to draw polygons on the displayed image. There was a time when one would use CATiledLayer, but I wonder what is best today. I started this app in Swift/Cocoa, but I'm toying with the idea of starting over in SwiftUI (my biggest hesitation is that I have yet to upgrade to Big Sur). The image data I have is in strips, with an integral number of image rows per strip. Strips are not guaranteed to be contiguous in the file. Pixel formats vary, but in the motivating use case are 16 bits per pixel, with the values signifying meters. As a first approximation, I can simply display these values in a 16 bpp grayscale image. Is the right thing to do to set up a CoreImage pipeline? As I understand it that should give me some automatic memory management, right? I’m hoping to find out the best approach before I spend a lot of time going down the wrong path.

Is there documentation describing the semantics of a Metal CIKernel function? I have image data where each pixel is a signed 16-bit integer. I need to convert that into any number of color values, starting with a simple shift from signed to unsigned (e.g. the data in one image ranges from about -8,000 to +20,000, and I want to simply add 8,000 to each pixel's value). I've got a basic filter working, but it treats the pixel values as floating point, I think. I've tried using both sample_t and sample_h types in my kernel, and simple arithmetic: extern "C" coreimage::sample_h heightShader(coreimage::sample_h inS, coreimage::destination inDest) { coreimage::sample_h r = inS + 0.1; return r; } This has an effect, but I don't really know what's in inS. Is it a vector of four float16? What are the minimum and maximum values? They seem to be clamped to 1.0 (and perhaps -1.0). Well, I’ve told CI that my input image is CIFormat.L16, which is 16-bit luminance, so I imagine it's interpreting the bits as unsigned? Anyway, where is this documented, if anywhere (the correspondence between input image pixel format and the actual values that get passed to a filter kernel)? Is there a type that lets me work on the integer values? This document - https://developer.apple.com/metal/MetalCIKLReference6.pdf implies that I can only work with floating-point values. But it doesn't tell me how they're mapped. Any help would be appreciated. Thanks.

In my macOS SwiftUI app I have a list of "layers" on the left. Clicking on a layer focuses it on the right for acting upon. Each link has a little eye icon that's used to toggle visibility of that layer in the view to the right. I'd like to be able to click on that eye button without selecting the layer or activating it. Is that possible?

I've got the following code that updates a @Published var messages: OrderedSetMessage property: swift public func add(messages inMsgs: [IncomingMessage]) { for msg in inMsgs { let msg = Message(fromIncoming: msg, user: user) self.messages.append(msg) } self.messages.sort() } In my SwiftUI view, however, .onChanged(self.stream.messages) gets called three times each time a single message is added. I tried operating on a local copy of self.messages, and then just setting self.messages = local, but that didn't change anything. Maybe the issue is on the SwftUI side? In any case, how are published updates to a property coalesced?

As in the locked question here - https://developer.apple.com/forums/thread/674534, I'm constantly running into this error: Compiling failed: 'main' attribute cannot be used in a module that contains top-level code Once it starts, it's not clear how to stop it. No changes were made to my AppDelegate (It's a mostly-UIKit app that I'm adding some SwiftUI views to). It compiles just fine with a regular build, but the SwiftUI preview can't build it. This is proving to be a real hindrance. I can sometimes clear the condition by cleaning build and test results, and relaunching Xcode. But not always. I filed FB9104575 and included the diagnostics.

I just created a new macOS app project in Xcode 13 beta. SwiftUI, unit tests, no Core Data. I just noticed that it does not add the traditional "Products/MyApp.app" group and file, and I can't figure out how to add those via the UI. At least one solution online edits the pbxproj file directly; I'd rather not do that. Is there any sanctioned way to add this? Is not having it a bug?

I recently created a new app record in AppStoreConnect. The app is still in development and testing, so we use this for TestFlight builds. The app has a complete app icon internally, and shows up in the Simulator and devices correctly. But in AppStoreConnect, it shows the generic app icon placeholder. I contacted Apple support about this, and they told me I needed to include the app icon in the app. I told them I already do, and showed them the screenshots. They basically said sorry, not my problem, try the dev forums. So here I am.

In this talk , at 12:00, the speaker refers to code associated with this talk. But I can't find it anywhere. Is it available?

How do I handle URLs in a SwiftUI app? The only thing I can find is to put onOpenURL in my App's WindowGroup view content, but that makes a new window for every URL that gets handled.

I've developed a specialized web server in Swift using Vapor. I want to set it up to run reliably on macOS using a LaunchDaemon. It should start at boot and be restarted if it crashes. I'm having trouble finding a good guide to the latest flavor of launchctl, and how to use system domains. This is my plist: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Debug</key> <true/> <key>Label</key> <string>com.latencyzero.FurnaceController</string> <key>Program</key> <string>/Users/rmann/Desktop/Run</string> <key>ProgramArguments</key> <array> <string>serve</string> <string>--hostname</string> <string>0.0.0.0</string> <string>--port</string> <string>80</string> </array> <key>KeepAlive</key> <true/> <key>Listeners</key> <dict> <key>SockServiceName</key> <string>http</string> <key>SockType</key> <string>tcp</string> <key>SockFamily</key> <string>IPv4</string> </dict> </dict> </plist> And I'm trying to invoke it like this: $ sudo enable system/com.latencyzero.FurnaceController But nothing happens. If I try kickstart, I get an error: $ sudo launchctl kickstart -p system/com.latencyzero.FurnaceController Could not find service "com.latencyzero.FurnaceController" in domain for system $ sudo launchctl kickstart -p uid/501/com.latencyzero.FurnaceController Unrecognized target specifier. Usage: launchctl kickstart [-k] [-p] <service-target>         -k      Terminates the service if it is already running.         -p      Prints the PID of the service that was started.         -s      Starts the service suspended so that a debugger may attach. <service-target> takes a form of <domain-target>/<service-id>. Please refer to `man launchctl` for explanation of the <domain-target> specifiers. Bootstrap also doesn't work as I'd expect: $ sudo launchctl bootstrap system/com.latencyzero.FurnaceController Usage: launchctl bootstrap <domain-target> [service-path, service-path2, ...] <service-target> takes a form of <domain-target>/<service-id>. Please refer to `man launchctl` for explanation of the <domain-target> specifiers. The plist is in /Library/LaunchDaemons/com.latencyzero.FurnaceController.plist I'd rather not have to launch this in a user domain, as I'm handing this app off to my client, and the fewer customization needed, the better.

I've got a Game @StateObject in my app that's passed to my main ContentView. I'm trying to figure out how best create a SCNSceneRendererDelegate instance that has a reference to the Game state, and then pass that to the SceneView inside my ContentView. I'm trying to do it like this, but obviously this doesn't work because self isn't available at init time: struct ContentView : View { let game : Game var scene = SCNScene(named: "art.scnassets/ship.scn") var cameraNode : SCNNode? { self.scene?.rootNode.childNode(withName: "camera", recursively: false) } var rendererDelegate = RendererDelegate(game: self.game) // Cannot find 'self' in scope var body: some View { SceneView(scene: self.scene, pointOfView: self.cameraNode, delegate: self.rendererDelegate) } } The intent is that in my renderer delegate, I'll update my game's simulation state. Because my game state is an ObservableObject, everything else (I have a bunch of SwiftUI) should update.

I'm not sure why, but it seems my Xcode project is trying to build for x86 (on my M1 Mac), even though both Debug and Release configurations have ONLY_ACTIVE_ARCH = YES. It's clearly trying to build for x86, as evidenced by the -target x86_64-apple-macos13.0 in the invocation. But I can't figure out why. The full link stage output: Ld /Users/me/Library/Developer/Xcode/DerivedData/MyProject-fbzxsemlztqkmsgdutlriortdmmd/Build/Products/Debug/MyProject.app/Contents/MacOS/MyProject normal (in target 'MyProject' from project 'MyProject')     cd /Users/me/Projects/MyProject     /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -target x86_64-apple-macos13.0 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.0.sdk -L/Users/me/Library/Developer/Xcode/DerivedData/MyProject-fbzxsemlztqkmsgdutlriortdmmd/Build/Intermediates.noindex/EagerLinkingTBDs -L/Users/me/Library/Developer/Xcode/DerivedData/MyProject-fbzxsemlztqkmsgdutlriortdmmd/Build/Products/Debug -L/opt/homebrew/opt/llvm/lib -F/Users/me/Library/Developer/Xcode/DerivedData/MyProject-fbzxsemlztqkmsgdutlriortdmmd/Build/Intermediates.noindex/EagerLinkingTBDs -F/Users/me/Library/Developer/Xcode/DerivedData/MyProject-fbzxsemlztqkmsgdutlriortdmmd/Build/Products/Debug -filelist /Users/me/Library/Developer/Xcode/DerivedData/MyProject-fbzxsemlztqkmsgdutlriortdmmd/Build/Intermediates.noindex/MyProject.build/Debug/MyProject.build/Objects-normal/x86_64/MyProject.LinkFileList -dead_strip -Xlinker -object_path_lto -Xlinker /Users/me/Library/Developer/Xcode/DerivedData/MyProject-fbzxsemlztqkmsgdutlriortdmmd/Build/Intermediates.noindex/MyProject.build/Debug/MyProject.build/Objects-normal/x86_64/MyProject_lto.o -Xlinker -export_dynamic -Xlinker -no_deduplicate -fobjc-arc -fobjc-link-runtime -framework Cocoa -lcurses -lLLVMAnalysis -lLLVMBitReader -lLLVMCodeGen -lLLVMCore -lLLVMExecutionEngine -lLLVMMC -lLLVMObject -lLLVMRuntimeDyld -lLLVMScalarOpts -lLLVMSelectionDAG -lLLVMSupport -lLLVMTarget -lLLVMTransformUtils -lLLVMX86CodeGen -lLLVMX86Desc -lLLVMX86Info -lz -Xlinker -no_adhoc_codesign -Xlinker -dependency_info -Xlinker /Users/me/Library/Developer/Xcode/DerivedData/MyProject-fbzxsemlztqkmsgdutlriortdmmd/Build/Intermediates.noindex/MyProject.build/Debug/MyProject.build/Objects-normal/x86_64/MyProject_dependency_info.dat -o /Users/me/Library/Developer/Xcode/DerivedData/MyProject-fbzxsemlztqkmsgdutlriortdmmd/Build/Products/Debug/MyProject.app/Contents/MacOS/MyProject ld: warning: ignoring file /opt/homebrew/opt/llvm/lib/libLLVMAnalysis.a, building for macOS-x86_64 but attempting to link with file built for macOS-arm64 ld: warning: ignoring file /opt/homebrew/opt/llvm/lib/libLLVMBitReader.a, building for macOS-x86_64 but attempting to link with file built for macOS-arm64 ld: warning: ignoring file /opt/homebrew/opt/llvm/lib/libLLVMCore.a, building for macOS-x86_64 but attempting to link with file built for macOS-arm64 ld: warning: ignoring file /opt/homebrew/opt/llvm/lib/libLLVMExecutionEngine.a, building for macOS-x86_64 but attempting to link with file built for macOS-arm64 ld: warning: ignoring file /opt/homebrew/opt/llvm/lib/libLLVMCodeGen.a, building for macOS-x86_64 but attempting to link with file built for macOS-arm64 ld: warning: ignoring file /opt/homebrew/opt/llvm/lib/libLLVMMC.a, building for macOS-x86_64 but attempting to link with file built for macOS-arm64 ld: warning: ignoring file /opt/homebrew/opt/llvm/lib/libLLVMRuntimeDyld.a, building for macOS-x86_64 but attempting to link with file built for macOS-arm64 ld: warning: ignoring file /opt/homebrew/opt/llvm/lib/libLLVMObject.a, building for macOS-x86_64 but attempting to link with file built for macOS-arm64 ld: warning: ignoring file /opt/homebrew/opt/llvm/lib/libLLVMX86Info.a, building for macOS-x86_64 but attempting to link with file built for macOS-arm64 ld: warning: ignoring file /opt/homebrew/opt/llvm/lib/libLLVMTarget.a, building for macOS-x86_64 but attempting to link with file built for macOS-arm64 ld: warning: ignoring file /opt/homebrew/opt/llvm/lib/libLLVMSupport.a, building for macOS-x86_64 but attempting to link with file built for macOS-arm64 ld: warning: ignoring file /opt/homebrew/opt/llvm/lib/libLLVMScalarOpts.a, building for macOS-x86_64 but attempting to link with file built for macOS-arm64 ld: warning: ignoring file /opt/homebrew/opt/llvm/lib/libLLVMSelectionDAG.a, building for macOS-x86_64 but attempting to link with file built for macOS-arm64 ld: warning: ignoring file /opt/homebrew/opt/llvm/lib/libLLVMTransformUtils.a, building for macOS-x86_64 but attempting to link with file built for macOS-arm64 ld: warning: ignoring file /opt/homebrew/opt/llvm/lib/libLLVMX86CodeGen.a, building for macOS-x86_64 but attempting to link with file built for macOS-arm64 ld: warning: ignoring file /opt/homebrew/opt/llvm/lib/libLLVMX86Desc.a, building for macOS-x86_64 but attempting to link with file built for macOS-arm64 ld: in '/opt/homebrew/opt/llvm/lib/libunwind.dylib', building for macOS-x86_64 but attempting to link with file built for macOS-arm64 clang: error: linker command failed with exit code 1 (use -v to see invocation) If I change the ARCHS to just arm64, then it builds fine.

When stepping through code in the Xcode debugger, hovering over a variable in the context causes a little popover to appear, displaying the value of that variable. Is there any way to disable this behavior? I find it gets in the way and I never use it.

What is BUNDLE_EXECUTABLE_FOLDER_PATH? I came across this in a freshly-created iOS project (Xcode 14.2). In the unit tests target it created, it set TEST_HOST to $(BUILT_PRODUCTS_DIR)/MyApp.app/$(BUNDLE_EXECUTABLE_FOLDER_PATH)/MyApp As far as I can tell, nothing sets BUNDLE_EXECUTABLE_FOLDER_PATH, and I can’t find it in any of the existing Xcode build settings. It's not set for Run Scripts, either, although these are close (and yes, this is an iOS project, not sure why one is MacOS): export BUNDLE_EXECUTABLE_FOLDER_NAME_deep\=MacOS export BUNDLE_EXTENSIONS_FOLDER_PATH\=Extensions A project I created several years ago does not have the TEST_HOST predefined that way.