Hello there :) We have a macOS app that has hardened runtime enabled. Furthermore, we have code signing enabled for Debug builds. We were discussing if we disable code signing for our Debug builds (to speed up local building) will this then disable hardened runtime too? Our concern is of course that if our local testing works fine and then in Release builds - if hardened runtime only kicks in here - the app would get into trouble in production... Best regards, Jens Schwarzer

Hello there :) I have a UITableView where I have tableView.allowsMultipleSelection = true. This works just fine on iOS, i.e., I can select/deselect zero, one or more cells... But on Mac Catalyst (macOS 10.15.7) I have the following problems: 1) I cannot select more than one cell. I have tried to Cmd+click and Ctrl+click but it makes no difference. 2) If I iterate over all the cells and programmatically selects them all then tableView.indexPathsForSelectedRows always returns the last selected IndexPath only. In both cases I have checked that tableView.allowsMultipleSelection = true is still true afterwards. This is really frustrating as I wanted to ready my app for Mac Catalyst and kinda assumed that UITableView was fully supported... Any clues why this isn't working for me? Any workarounds? Thanks! Best regards, Jens Schwarzer

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! :)

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!

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

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! :)