“show when run”

Bah, again, I’ve just not had time to get back to this. If I were in your shoes I would: Create a minimal test project that illustrates the issue. That’ll ensures that there isn’t some other part of your app that’s causing problems. Run it on two devices connected over infrastructure Wi-Fi. If that doesn’t work, there’s something wrong with your code. Run it again with the devices not on infrastructure Wi-Fi, and thus relying on peer-to-peer Wi-Fi to carry the packets. If that fails, file a bug with your results. Make sure to include: Your test project. Sysdiagnose logs taken on both devices shortly after reproducing the problem… … with additional logging enabled per the Network Diagnostics for iOS/iPadOS instructions on our Bug Reporting > Profiles and Logs. Please post your bug number, just for the record. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I don’t think there’s an actual problem here, largely due to the magic of Objective-C. Consider the small test code at the end of this reply. It declares the requestedMountOptions property without any availability, and I think that’s just fine. Lemme explain… I put this in an Xcode command-line tool project, set the deployment target to macOS 26.0, and compiled it. I then dumped its imports: % otool -L MyTool | grep FSKit % It doesn’t import any symbols from FSKit at all. That’s because FSKit is an Objective-C framework and all the stuff used by the class is either found at runtime by name or is a C-style declaration that has no runtime impact [1]. This doesn’t mean that it isn’t connected to the Objective-C runtime. If you run this command: % otool -o -v MyTool … stuff … you’ll see lots of connection points. However, Objective-C is super dynamic, so that stuff all gets resolved by name when your class is loaded. And the runtime on macOS 26.0 will happily ignore the fact that you’re claiming to imple

+1 AFAIK the ability to put Apps With Screen Time Access behind a Screen Time Passcode is a new thing since iOS 26.4 (?). I'm currently on iOS 26.5 Beta 2 and this particular part works fine (it presents Screen Time passcode when trying to disable an apps Screen Time access). However, the introduction of this introduced a similar bug where if you access the apps settings (not Screen Time settings), you can circumvent the Screen Time Passcode by using the Screen Time Restrictions toggle. FB22463959 is feedback number. The feedback for Apple is actually relatively simple (politics aside): just don't show the Screen Time Restrictions toggle in apps settings. This is how it actually was before. This is just a typical engineering/product issue where introducing new features introduces more bugs. Keeping it simple == less bugs (now and in the future).

In-app purchase is only support for App Store distribution, so Developer ID isn’t a factor here. In general, you can’t run code signed with an Apple Distribution signing identity. See Don’t Run App Store Distribution-Signed Code. [quote='823308021, DexterC, /thread/823308, /profile/DexterC'] Is there any other way to get a properly signed and runnable .app for testing IAP? [/quote] Yes. Use an Apple Development signing identity whose certificate was issued by your paid development team (the same team you used to set up the Apple Distribution signing identity). Apps signed this way will talk the StoreKit sandbox, can use StoreKit Test, and so on. I can’t help you with the third-party tools you’re using, but to do thish in Xcode you: Navigate to Signing & Capabilities. Enable “Automatically manage signing”. Select your paid team is the Team popup. Select Development in the Signing Certificate popup. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = e

Unfortunately I am in this exact same scenario, but with an M4 Pro MacBook Pro. Same exact monitors. I've tried CalDigit TS4 and CalDigit TS5 but I know it's independent of the dock because I can reproduce this directly from the laptop going to the monitors. Using HDMI alongside USB-C doesn't resolve it. The USB-C cords are quality cords, Thunderbolt 4 cords from Apple, as is the HDMI cable (I've tried multiple). The unfortunate workaround is a TWHT emulator: https://www.amazon.com/dp/B0DB7YDFD6 I have tried that before the HDMI cable directly from the laptop, and it works. My hope is that I can get this USB-C to HDMI adapter that is coming today and then put the TWHT on the end of that then the HDMI cable, so I can avoid a clunky scenario with multiple cords coming from the laptop. Here's the kicker: the M4 Pro is through work, but I also have a personal M2 Max MacBook Pro and it works perfectly fine there. I know the Max's have (and I might be saying this wrong) more dedicated graphics cores and maybe that