Building for iOS Simulator, but the linked and embedded framework ‘XX.framework‘ was built for

(2) Redesign your approach such that you stop actually doing any “long-term running. That's a no-go. Jobs just have to run until they are done. There are dozens if not hundreds of pieces of data that are built and used along the way. Some of them are hogs that will run for 3 hours. How isolated are each of these jobs? For example, is progress being routed back to another thread or is all of the work contained to that thread? All the work for each job is pretty much self-contained in its thread as far as the SBApplication goes. Each job gathers data from the network, generates one of more InDesign documents and saved the resulting files of various types. They all communicate back to other servers by various means (simple I'm still working heartbeats), communicate with main parent app and various objects in the app to show progress, all of which has been heavily stressed and show no signs of causing problems. Swift has wormed its way into this fairly old Cocoa app, mostly in the data access from networ

I sent a Multiplatform set of builds, iOS, and Mac on February 12th to TestFlight. iOS was approved about 24 hours later, but it took 3 days on the Mac...the Mac was rejected (rightly so lol)..I sent a fix that night on the Mac (February 15th) and as of February 17th the Mac is still Waiting for review. Hope that helps.

Last week I sent a Mac and iOS set of builds to TestFlight...they approved the iOS in 24 hours or less, but it took them 3 days on the Mac. They rejected my Mac app (rightly so lol). I sent the fix very late in the evening on the 15th and I have not yet seen a review just yet. I suspect there are less reviewers for Mac.

I am experiencing the same issue described here. If I bring up the AccessorySetupKit picker for ~10 seconds, the BluetoothCentral goes to disconnected. All peripherals also disconnect but I do not get notified (checking peripheral state will show disconnected) There is no recovery without restarting my app. This still reproduces on iOS 26.2 and iOS 26.3. I am ONLY using ASK paired accessories. No bluetooth scanning. With that said, I have a workaround. Disconnect all peripherals AND clear all references to BluetoothCentral before bringing up ASK picker Do not attempt to connect to newly added peripheral while ASK picker is on screen (that is don't use .accessoryAdded as a chance to connect because you don't want to create the central with ASK in use) After ASK is dismissed, recreate BluetoothCentral WITHOUT state restoration Go through all accessories (new and old) and get new references to peripherals + set new delegates etc. This seems to work reliably, but it seems really surprising that

That's interesting about the difference between NSOperation and NSThread as far as Mach ports go. I watched the # ports in Activity Monitor as I ran a job, and it certainly doesn't climb as each job runs. It goes from initially in the 300s to the low 500s right when the job starts, and stays around there, even after the job ends, and then I run the same job 2 or 3 more times without quitting. Well, that's the joy of Mach port leaks... you never REALLY know what you'll get. So, as some broader background here, the actual issue here isn't really about the thread API itself- ultimately, both APIs are using pthreads and the special pthread GCD uses aren't really different than standard pthreads. The real issue here is that you don't actually own the thread and the assumptions AppleEvents/ScriptingBridge were built around. Both of those APIs predate GCD (by many, many years) and are built around the assumption that they'll be used on a long-running thread that's running its own runloop, as that w

Hi, thanks for posting this — I've been hitting the exact same wall. I'm building a screen time management app and spent considerable time trying to persist per-app usage data from the DeviceActivityReportExtension to the App Group container. I exhaustively tested every storage mechanism available: Core Data, JSON files, UserDefaults (App Group suite), Keychain, raw POSIX syscalls, SQLite, iCloud KV, and NSUbiquitousKeyValueStore. All fail with permission errors — the extension is completely write-locked at the kernel level (POSIX errno 1 / EPERM). I also confirmed the DeviceActivityMonitor extension has the same restriction. So I'm very interested in your finding that the host app can reconstruct raw activity data from the report. Could you share more about the technique you used? Specifically: How does your host app access the data from the report extension? Is it through the rendered view hierarchy, some callback mechanism, or something else entirely? Are you able to get per-app bundle identifiers

Thanks for this awesome post. Yes, low power will trigger the device to go night night if possible. This is a great post for other developers to provide tips and ticks how to keep the device awake on a recording session. https://developer.apple.com/documentation/uikit/uiapplication/isidletimerdisabled Your approach of setting is indeed the standard way to achieve this. However, certain power management features, like Adaptive Power Mode, can override these settings, as you've observed. Ensure that you have an active configured while recording. This typically helps in signaling to the system that media capture is in progress, which should naturally prevent the device from sleeping. Unfortunately, iOS doesn't provide public APIs to directly detect Adaptive Power Mode specifically. However, you can check for Low Power Mode . While this doesn't exactly map to Adaptive Power Mode, it can still be useful for alerting users. Since detecting Adaptive Power Mode isn't directly possible, consider displaying a