My app depends on the user granting Accessibility access (Allow this application to control your computer). There’s no formal permissions API (that I know of) for this, it just happens implicitly when I use the API for the first time. I get an error if the user hasn’t granted permission. If the user grants permission and I'm able to successfully register my CGEventTap (a modifier key event tap), but then later revokes it, key responsiveness goes awry. I don’t get any kind of error to my callback, but I do get tapDisabledByTimeout events periodically. I believe something is causing significant delays (but not preventing) in delivering events to my tap. Upon receiving this, I'm considering attempting to register another tap as a way to test permission, and disabling the real one if I no longer have permission. Does anyone have any better ideas? For Apple: see FB13533901.

In the abominable new commit line diff view, I have no idea what the colors mean. Some text is highlighted in a cream color, other text in purple. Googling just turns up people hating the view, as I do. I haven't found anything in the Xcode docs that explains the coloring. Looking at my files, I think cream is a deleted line and purple is added lines. Is that right? Light mode.

I've run into a linker error, but when i go to look at the build transcript, all I see is an excessively formatted set of lines, with no way to see the linker command. There used to be a little icon you could click to see exactly what Xcode was trying to do.

I've been working on a Swift PM wrapper for the libtiff library, which I installed on my Mac via Brew. So far so good. But I just tried adding it to my visionOS project. and it complained that it was trying to link against a library built for macOS: building for 'visionOS-simulator', but linking in dylib (/opt/homebrew/Cellar/libtiff/4.6.0/lib/libtiff.6.dylib) built for 'macOS' I wish Brew would build universal libraries, but it doesn’t, and they have no interest in doing so. What are my options? If I build libtiff from sources, it’s still a bit of a pain to build against a different SDK. libtiff has its own Makefile I’d rather not try to edit. Can I make an xcframework out of it? Can I statically link it into my Swit wrapper library? Do I need to hack together a C build target in my Package and copy the source files over to it?

It seems that there’s still no way to get all TIFF tags from a TIFF image, is that right? I've got these GeoTIFF images that have a handful of specialized TIFF tags in them. Calling CGImageSourceCopyPropertiesAtIndex(), I can see basic properties common to all TIFF images, like dimensions and color/pixel information, but no others. Short of including libtiff, is there another way to get at the metadata? I've tried all of the options in CGImageSourceCopyAuxiliaryDataInfoAtIndex. I've written a few bugs about this since 2020, all ignored.

I've got a Data of deflate (zlib)-compressed data that decompresses properly using NSData.decompressed(), but does not decompress properly using compression_decode_buffer(). The working code looks like this: let compressedData = Data(bytesNoCopy: buf.baseAddress!, count: readCount, deallocator: .none) let dataWithoutHeader = compressedData[2...] let ucData = try (dataWithoutHeader as NSData).decompressed(using: .zlib) as Data The non-working code looks like this: let samples = try [Float](unsafeUninitializedCapacity: sampleCount) { buffer, initializedCount in print("Count: \(initializedCount)") try compressedData.withUnsafeBytes<UInt8> { (inCompressedBytes: UnsafeRawBufferPointer) -> Void in let destBufferSize = buffer.count * MemoryLayout<Float>.size let scratchBuffer = UnsafeMutableRawBufferPointer.allocate(byteCount: compression_decode_scratch_buffer_size(COMPRESSION_ZLIB), alignment: MemoryLayout<Int>.alignment) defer { scratchBuffer.deallocate() } let decompressedSize = compression_decode_buffer(buffer.baseAddress!, destBufferSize, inCompressedBytes.baseAddress!, inCompressedBytes.count, scratchBuffer.baseAddress!, COMPRESSION_ZLIB) print("Actual decompressed size: \(decompressedSize), destBufferSize: \(destBufferSize)") } initializedCount = sampleCount } It ends up printing: Actual decompressed size: 46510, destBufferSize: 1048576 (1048576 is the correct size. What data is returned does not appear to be correct.) I have tried it both with and without the first two bytes of the compressed data buffer, and with and without providing a scratch buffer.

How is one supposed to use ShareLink(items:subject:message:)? It makes no sense to me. It accepts type Data for items. But Data's Element has to be String or URL or similar. How does this even work???

In Ivory, there are custom menu items in the ShareLink sheet that pops up. How can I customize my own ShareLink?

Near as I can tell, Compression doesn't support LZW, is that right? I'm not sure if the available compression algorithms implicitly know how to decompress LZW. FB14643019

How does one print from a SwiftUI app (on macOS)? Is there any SwiftUI or Swift API for this, or do I just use the old AppKit APIs (https://developer.apple.com/documentation/appkit/printing)? What if I wanted to print from iOS?

AVKit provides the SwiftUI view VideoPlayer, and allows you to add an interactive overlay. But that overlay is normally placed behind the system-provided playback controls. Is there any way to suppress those controls, without resorting to wrapping AVPlayerView?

I'm using the SwiftUI .fileImporter() modifier to present a file open panel to the user, and then I access the returned file URL using String(contentsOf:encoding:). Then I get an error, "The file “order_history.csv” couldn’t be opened because you don’t have permission to view it." The thing is, my app (recently created in Xcode 16.1 beta from macOS template) has the User Selected File entitlement set to "Read Only." It should allow reading such a file, should it not?

I'm trying to write a SwiftUI iOS/macOS app that allows users to collaborate, but I keep running into limitations. The latest is that I can't figure out what the UICloudSharingContainer equivalent is on macOS. It doesn't seem like there’s a SwiftUI version of this, so I have to write a lot of platform-specific code to handle it, but it's not clear what the AppKit equivalent is.

I'm trying to get the CoreDataCloudKitShare example to work, but having trouble. The first error I see when running the InitializeCloudKitSchema target (on macOS) is the following: error: CoreData+CloudKit: -[NSCloudKitMirroringDelegate _performSetupRequest:]_block_invoke(1242): <NSCloudKitMirroringDelegate: 0x60000229c0f0>: Failed to set up CloudKit integration for store: <NSSQLCore: 0x15b807830> (URL: file:///Users/rmann/Library/Application%20Support/InitializeCloudKitSchema/CoreDataStores/Private/private.sqlite) <CKError 0x600001311290: "Partial Failure" (2/1011); "Failed to modify some record zones"; uuid = 3E1B1380-AE1C-4B14-97A8-7F60B4A8F3EF; container ID = "iCloud.com.example.CoreDataCloudKitShareH6F2W964VK"; partial errors: { com.apple.coredata.cloudkit.zone:__defaultOwner__ = <CKError 0x60000132f810: "Permission Failure" (10/2007); server message = "Invalid bundle ID for container"; op = F3987848B25CEED7; uuid = 3E1B1380-AE1C-4B14-97A8-7F60B4A8F3EF> }> I see a database in the Dashboard with that container ID, but don't know what it means by "Invalid bundle ID for container". I've seen several other posts about this across the web, and the only answer is ever "seems to be an Apple issue, wait a bit."

The SwiftUI templates provided by Xcode typically create an in-memory store for preview purposes. I started from one of these templates and added the necessary code for working with CloudKit shares, but now the existing preview store creation gets runtime errors I'm struggling to understand. The ultimate error is: FAULT: NSInternalInconsistencyException: Unsupported feature in this configuration; { store = "<NSSQLCore: 0x12e26b170> (URL: file:///dev/null)"; } There are other things in the log like: warning: Multiple NSEntityDescriptions claim the NSManagedObject subclass 'Trip' so +entity is unable to disambiguate. This might be due in part to the normal full stack being instantiated during a unit test, but that was the only way I could step through the code to try to see what was causing the SwiftUI preview to crash. I can't build the full core data stack as normal, because then the unit tests and previews pollute the real store.