missing package product

Once again I get rejected. I removed all references to dating. They just come back and hit me with a 4.3 rating and give me no guidance on what I need to do. I am filing a second appeal, but I haven't received a response from anyone. Here's my new appeal message: My app is not a dating app. It’s a real-world social discovery tool designed to help people meet others while they are out in public spaces. Users can create events, connect with others nearby, and explore Hot Zones, which show where activity is happening in a specific area. I have removed all references to dating to make that distinction clear. I continue to receive Guideline 4.3 rejections, but I have not been given any specific feedback or direction on what changes are required. Without actionable guidance, it is impossible to understand what the review team believes is duplicative or how I can bring the app into compliance. I respectfully request that someone contact me or provide more detailed clarification. I have invested significant time and

So I guess I'm wondering: is it... fine to now use fdatasync on APFS? Because if it is now fine (as per sqlite's understanding via the Hacker News comment...), then I think there's a bunch of software might be relying on outdated documentation/advice, since: So, the first thing to understand is that what led to F_FULLFSYNC wasn't really the kernel itself's handling of data. The basic issue was that the kernel itself would send the data all the way to disk... and which point the drive itself would stick the data in a write cache and leave it there for an indeterminate but long time. Even worse: Some of these drives were intentionally ignoring the existing commands (and more performant) that were supposed to flush the specific data. These issue were widespread enough across product and vendors that blaming hardware wasn't really feasible. The only solution we found viable was what F_FULLFSYNC does, which is to flush the data and the force the drive to commit the data. I'll also note that issue above wa

Hi Quinn, Thank you for the detailed analysis — especially the breakdown of the crashing thread and explanation about the Swift concurrency actor expectation. That was extremely helpful. I tested your suggestion: CTFontManagerRegisterFontURLs(cfArray, scope, true) { @Sendable _, _ in true } Result This does prevent the crash. The system “Install Fonts” sheet appears, and tapping Install no longer triggers a trap. Remaining Issue Although the crash is fixed, the fonts still do not install system-wide when using the .persistent scope with fonts delivered via Apple-Hosted Background Assets. After tapping Install, nothing appears under: Settings → General → Fonts → My Fonts So the concurrency crash is resolved, but the underlying issue remains: .process registration works .persistent registration does not install fonts No errors are returned by CTFontManagerRegisterFontURLs Next Steps As you suggested, I am happy to have FB21109320 repurposed to track the missing concurrency annotation on CTFontManagerRe

SharedModelContainer.txt Folks who filed their feedback report may have gotten responses from the feedback system. For people who see the same issue but haven't yet filed any feedback report, I'd like to share our investigation here to hopefully help. To give you more context, SwiftData (with DefaultStore) uses Core Data as its underlying storage mechanism. At runtime, SwiftData converts the schema to an in-memory Core Data model (NSManagedObjectModel), and uses the model to load and persist the data store. Before system 26.1, when handling an attribute of an array type, SwiftData converts the array type to Binary Data. On system 26.1, it instead converts the type to Transformable. This change leads to a difference between the in-memory model and the model used in the persisted data store, triggering a migration error with the following message: Error Domain=NSCocoaErrorDomain Code=134140 Persistent store migration failed, missing mapping model.” To work around the issue, you might consider the follo

Does anyone know why a CPU (and Neural Engine)-intensive job like this would slow down so dramatically when using BGContinuedProcessingTask in the background on iOS 26+, despite apparent similar resource-usage metrics? I'm not entirely certain of this, but if I had to guess, it could be happening because you lost GPU access when you entered the background. Try testing with the Metal System Trace, as I suspect that will show you a resource shift that wouldn't necessarily be visible in Activity Monitor. Are there internal iOS scheduling/hardware-allocation behaviors (e.g., falling back to lower-performing cores when backgrounded) that might explain this? Priority certainly does shift when you enter the background; however, the shift you’re describing is larger than I'd expect from that, especially since BGContinuedProcessingTask is involved. I'll also note that in your list here: ...the measured system resource metrics (process CPU usage, system CPU usage, memory, QoS class, thermal state) showed no me

Ok, I found this in dmesg/syslog: [46147.634755]: DriverKitSampleA[6170] triggered unnest of range 0x1fc000000->0x1fe000000 of DYLD shared region in VM map 0x853f7106fc70fc7d. While not abnormal for debuggers, this increases system memory footprint until the target exits. [46147.634762]: DriverKitSampleA[6170] triggered unnest of range 0x1fe000000->0x200000000 of DYLD shared region in VM map 0x853f7106fc70fc7d. While not abnormal for debuggers, this increases system memory footprint until the target exits. [46148.219526]: Sandbox: ContextStoreAgent(448) allow file-read-data /Users/daniel/Library/Developer/Xcode/DerivedData/DriverKitUserClientSample-haxyygamobxzqybcidlsjqhbccev/Build/Products/Debug/DriverKitSampleApp.appSandbox: ContextStoreAgent(448) allow file-read-data /Users/daniel/Library/Developer/Xcode/DerivedData/DriverKitUserClientSample-haxyygamobxzqybcidlsjqhbccev/Build/Products/Debug/DriverKitSampleApp.app/ContentsSandbox: ContextStoreAgent(448) allow file-read-data /Users/d