Hello there 🤓 We have this elderly QuickLook plugin that I am trying to revive for Big Sur... (Well, it seems to be a problem on Big Sur only.) The thing is that it uses NSTemporaryDirectory(). This directory can be written to when built locally in Debug/Release configuration. But when doing an Archive/Notarized builds the plugin cannot write to the directory. I have here found that in this case it gets its NSFileExtendedAttributes set to com.apple.rootless! So somehow System Integration Protection (SIP) kicks-in! I have found two workarounds: If I disable SIP ($ csrutil disable from Recovery mode) then it works. If I enable the Hardened Runtime exception 'Allow DYLD Environment Variables' then is also gets write access to the temp directory. My question is: Can one give a proper explanation for why SIP kicks-in? Could we have misconfigured something? Let me know if you need additional information, thanks. Best regards, Jens Schwarzer.

According to https://developer.apple.com/documentation/iokit IOKit is supported for iOS/iPadOS 16.0+. I was trying to figure out what that exactly meant by using Xcode 14.1 and build for iPadOS 16.1. But I just get "No such module 'IOKit'" if I have import IOKit in any Swift file. Wondering if it is an error in the documentation or if I have to do something extraordinary? Thanks :)

We have an issue with creating an ordinary TCP socket connection to a device that is connected on a link-local net (simple peer to peer Ethernet). Our code is in C++ and we use the normal POSIX socket API. The scenario is like this: We have a device with ordinary Ethernet connected to a USB-Ethernet adaptor. We plug in the USB-Ethernet adaptor in a Mac or iPad. The device establishes link-local IP address and announces a service via mDNS/DNS-SD The Mac/iPad Bonjour system picks up the device service and we get the information in our app. Our app want to connect to the service using a normal TCP socket connection to the device's link-local address. So far this is normal and working as expected. However from here something unexpected happens: We create a "socket()" and do a "connect()".  WireShark shows that the TCP connection is established on the correct interface, with the correct destination IP/port, but with a source IP/port from a different interface. Fx. the TCP SYN from the Mac has destination ip 169.254.5.253 (correct) but source IP 192.168.1.101 (wrong - that IP does not exist on that interface). Consequently the TCP connection never get established. Workaround: We have found out that using "bind()" to bind the socket to a specific source link-local IP on the relevant interface works. Then the TCP SYN comes out with correct source IP. However binding an outgoing TCP that is a very unusual thing to and we are surprised that it doesn't just work without it. Other information: Parts of this issue seems to be timing related. Without the "bind()" it sometimes works if we retry the connect after timeout. Occasionally it works the first time. Having a Ethernet switch in between also sometimes helps. Have we missed something or is this a problem in macOS/iOS? Thanks! :)

We have an iOS/iPadOS app that uses the ImageCaptureCore framework to communicate with PTP cameras. The same app also works with the 'macOS Catalyst' destination. But we like to deprecate the use of macOS Catalyst and then use 'Designed for iPad' destination instead. But when I use this destination then no cameras are provided to the app (ICDeviceBrowser)! :( I've noticed that on iOS devices the 'Settings app' usually shows that our app is allowed to use 'Camera'. But this possibility doesn't appear when the destination is 'Designed for iPad'. To my understanding below entitlements are used for a 'real' macOS app (including Catalyst), but I have added it anyway with: com.apple.security.device.camera com.apple.security.device.usb com.apple.security.personal-information.photos-library all set to YES and also the same privacy-related entries needed for iOS. Any pointers would be appreciated, thanks! :) macOS 14.1.1; Xcode 15.0.1

Hello there :) We have an iOS/iPadOS app that uses the ImageCaptureCore framework for PTP communication with cameras. In general, it is working just fine. But in "Xcode > Organizer > ’our app’ > Crashes" we get a good amount of different – yet similar – crashes in this framework. So we can just observe that a good amount of end-users get those crashes. But we are not able to reproduce them ourselves... I've checked the stack traces of the other threads but nothing suspicious got my attention. Any good idea of how to address these crashes shown below? Happens on iOS 15–17. Thanks!

I have an app that uses FrameworkA and FrameworkB. FrameworkA is simple, i.e., no dependencies. FrameworkB includes FrameworkA, which is normal. But it also uses pieces of FrameworkA's public interface in its own public interface. Yes, I find that a bit odd... (I didn't make those frameworks... just trying to sort out things...) Now I am trying to enable Xcode's module verifier for FrameworkB and the problem begins... FrameworkB can no longer have #import <FrameworkA/FramworkASomethingSomething.h> in its public headers. The modulemap file for FrameworkB currently looks like framework module FrameworkB { umbrella header "FrameworkB.h" export * module * { export * } } Is it possible still use FrameworkA's public interface in FrameworkB's public interface? And if yes, how is that sorted out in the modulemap? So far I have tried framework module FrameworkB { umbrella header "FrameworkB.h" export * module * { export * } link framework "FrameworkA" module FrameworkA [system] { umbrella header "FrameworkA.h" export * } } But it gives the error Umbrella header 'FrameworkA.h' not found Thanks!

We have a Xcode project consisting of: A mix of Swift and Objective-C code app code ~ 1600 source files. Roughly around 35 {XC}Frameworks. Some of them are binary and some of them are getting built as a dependency to our app, etc. Binary libraries. Most of the frameworks built together with app code are Objective-C or Swift-based, which have their own amount of sources files and framework dependencies. The binary frameworks mostly contain cross-platform C++ code. Our (the poor developers) frustration is that almost all time when we do a insignificant change (or even just tap Cmd-R without any changes) in Swift-file or Objective-C file (.m) and then build again then big sh*t show starts again... For example: Frameworks may get rebuilt even though they are not touched. Tons of app-level files get built again even though no interface changes, etc. was made. Module verifier keeps verifying modules not touched at all, which takes really long time. Xcode 16 didn't seems to improve the situation - on the contrary. Example of an untouched framework that for unknown reason goes trough this every time we build: I know it is hard to come with ideas to solve this for an unknown larger project. But do other people with similar-size projects also experience this or is re-building not an issue for you? Cheers!

In our app we use CoreML. But ever since macOS 15.x was released we started to get a great bunch of crashes like this: Incident Identifier: 424041c3-884b-4e50-bb5a-429a83c3e1c8 CrashReporter Key: B914246B-1291-4D44-984D-EDF84B52310E Hardware Model: Mac14,12 Process: <REMOVED> [1509] Path: /Applications/<REMOVED> Identifier: com.<REMOVED> Version: <REMOVED> Code Type: arm64 Parent Process: launchd [1] Date/Time: 2024-11-13T13:23:06.999Z Launch Time: 2024-11-13T13:22:19Z OS Version: Mac OS X 15.1.0 (24B83) Report Version: 104 Exception Type: SIGABRT Exception Codes: #0 at 0x189042600 Crashed Thread: 36 Thread 36 Crashed: 0 libsystem_kernel.dylib 0x0000000189042600 __pthread_kill + 8 1 libsystem_c.dylib 0x0000000188f87908 abort + 124 2 libsystem_c.dylib 0x0000000188f86c1c __assert_rtn + 280 3 Metal 0x0000000193fdd870 MTLReportFailure.cold.1 + 44 4 Metal 0x0000000193fb9198 MTLReportFailure + 444 5 MetalPerformanceShadersGraph 0x0000000222f78c80 -[MPSGraphExecutable initWithMPSGraphPackageAtURL:compilationDescriptor:] + 296 6 Espresso 0x00000001a290ae3c E5RT::SharedResourceFactory::GetMPSGraphExecutable(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, NSDictionary*) + 932 . . . 43 CoreML 0x0000000192d263bc -[MLModelAsset modelWithConfiguration:error:] + 120 44 CoreML 0x0000000192da96d0 +[MLModel modelWithContentsOfURL:configuration:error:] + 176 45 <REMOVED> 0x000000010497b758 -[<REMOVED> <REMOVED>] (<REMOVED>) No similar crashes on macOS 12-14! MetalPerformanceShadersGraph.log Any clue what is causing this? Thanks! :)

Our app uses Metal for image processing. We have found that if our app (and its possible intensive image processing) is started quickly after user is logged in, then calls to Metal may be hanging/stuck for a good while. Example: it can take 1-2 minutes for something that usually takes 3-5 seconds! Metal threads are just hanging in a memmove... In Activity Monitor we see a lot of things are happening right after log-in. But why Metal calls are blocking for so long is unknown to us... The workaround is to wait a minute before we start our app and start intensive image processing using Metal. But hard to explain this workaround to end-users... It doesn't happen on all computers but fairly easy to reproduce on some computers. We are using macOS 15.3.1. M1/M3 Max. Any good ideas for how to proceed with this problem and possible reach out to Apple engineers? Thanks! :)

We have an old iOS app and an old camera that connects using Wi-Fi either using an access point or Ad Hoc network, e.g., iPhone/iPad connects to the camera's Wi-Fi directly... How it works (old legacy app/system, which cannot be redesigned): Camera is configured to Ad Hoc Wi-Fi network (insecure TCP). iPhone connects to this insecure Wi-Fi. Camera uses Bonjour service to broadcast its IP address. App reads in IP address and begin to send messages to the camera using NSMutableURLRequest, etc. All this works fine for iOS 17. But in iOS 18 step 4 stopped working. App simply doesn't get any responses! We believe we have configured ATS properly (App Store version): In panic we have also tried this in Test Flight version: The latter actually seemed to make a difference when running the app on macOS Apple Silicon. But on iOS it didn't seem to make any difference. Occasionally, I was lucky to get connection on on iPhone 16 Pro with iOS 18. But for the 'many' iPads I have tried I couldn't. I also tried to install CFNetwork profile and look at the logs but I believe I just got timeout on the requests. Questions: Why it iOS 18 different? Bonjour works fine, but NSSURLRequests doesn't Do we configure ATS correctly for this scenario? What should I look for in the Console log when CFNetwork profile is installed? Should I file a TSI? Thanks! :)

We have some rather old code that worked for many years, but recently started to crash sporadically here: The crash looks like this: or Our code is called from many threads concurrently, but as said it worked without any issues until recently. I've found the apparently same crash on iOS at this Reddit post: https://www.reddit.com/r/iOSProgramming/comments/1kle4h4/ios_185_doesnt_fix_cicontext_rendering_crash/ Recap: we believe it started on macOS 18.4 and is still on macOS 18.5. But maybe it was already on macOS 18.3. This matches the observation in the Reddit post well. Should we create a feedback with sysdiagnose? Thanks! :)

I'm implementing the 'new' QLThumbnailProvider for our macOS app... So I just created the skeleton from Xcode, added our QLSupportedContentTypes in Info.plist, and have the skeleton code like below: import QuickLookThumbnailing class ThumbnailProvider: QLThumbnailProvider { override func provideThumbnail(for request: QLFileThumbnailRequest, _ handler: @escaping (QLThumbnailReply?, Error?) -> Void) { // cannot trigger break point here! } I understand I should test the Thumbnail Extension by using: $ qlmanage -t my_file.ext Testing Quick Look thumbnails with files: my_file.ext But I don't know what process to attach to in the Xcode debugger... a bit clueless... I've skimmed relevant parts of https://developer.apple.com/videos/play/wwdc2019/719, but there is no real debug tips... Does anyone know if it is possible to debug with Xcode or not? And if possible, then how? 😅

For a long time our app had this creation of a URLRequest: var urlRequest = URLRequest(url: url, cachePolicy: .reloadIgnoringLocalAndRemoteCacheData, timeoutInterval: timeout) But since iOS 26 was released we started to get crashes in this call. It is created on a background thread. Thread 10 Crashed: 0 libsystem_malloc.dylib 0x00000001920e309c _xzm_xzone_malloc_freelist_outlined + 864 (xzone_malloc.c:1869) 1 libswiftCore.dylib 0x0000000184030360 swift::swift_slowAllocTyped(unsigned long, unsigned long, unsigned long long) + 56 (Heap.cpp:110) 2 libswiftCore.dylib 0x0000000184030754 swift_allocObject + 136 (HeapObject.cpp:245) 3 Foundation 0x00000001845dab9c specialized _ArrayBuffer._consumeAndCreateNew(bufferIsUnique:minimumCapacity:growForAppend:) + 120 4 Foundation 0x00000001845daa58 specialized static _SwiftURL._makeCFURL(from:baseURL:) + 2288 (URL_Swift.swift:1192) 5 Foundation 0x00000001845da118 closure #1 in _SwiftURL._nsurl.getter + 112 (URL_Swift.swift:64) 6 Foundation 0x00000001845da160 partial apply for closure #1 in _SwiftURL._nsurl.getter + 20 (<compiler-generated>:0) 7 Foundation 0x00000001845da0a0 closure #1 in _SwiftURL._nsurl.getterpartial apply + 16 8 Foundation 0x00000001845d9a6c protocol witness for _URLProtocol.bridgeToNSURL() in conformance _SwiftURL + 196 (<compiler-generated>:974) 9 Foundation 0x000000018470f31c URLRequest.init(url:cachePolicy:timeoutInterval:) + 92 (URLRequest.swift:44)# Live For Studio Any idea if this crash is caused by our code or if it is a known problem in iOS 26? I have attached one of the crash reports from Xcode: 2025-10-08_10-13-45.1128_+0200-8acf1536892bf0576f963e1534419cd29e6e10b8.crash