Hi everyone, We're running Xcode/Swift CI builds inside macOS VMs (Tart / Apple Virtualization Framework) on a 32-core Apple Silicon host. While investigating VM build performance, we noticed a consistent pattern: assigning 24 vCPUs to the VM produces faster overall build times than assigning 26-30 vCPUs, despite the host still showing idle CPU capacity. With higher vCPU allocations, the build starts by utilizing the CPUs well, but later stages show a noticeable drop in CPU utilization and overall build throughput. In contrast, the 24-vCPU configuration maintains more stable CPU usage and completes the workload faster. This was observed repeatedly with the same Xcode/Swift workload. The result seems counterintuitive because the VM is not exhausting the available host CPU resources. Our testing identified 24 vCPUs as the current sweet spot, even though the host provides 32 physical cores. Has anyone observed similar behavior? Some questions I have: Do Xcode builds stop scaling efficiently beyond a certain vCPU count? Are there known scheduler or virtualization effects when assigning nearly all host cores to a macOS VM? Is there a commonly recommended practice to leave a number of host cores unassigned, even when the host appears mostly idle?

Hi — I’m trying to understand what customization is currently supported for App Shortcuts as they appear inside the Shortcuts app. From the public App Intents APIs, it looks like an AppShortcut can specify a systemImageName, and an AppShortcutsProvider can specify a shortcutTileColor. I haven’t been able to find documentation for either of the following: Using a custom app-provided icon/image asset instead of an SF Symbol Using custom imagery or a background image for the App Shortcut tile itself However, some Apple apps such as Music and Podcasts appear to use richer/custom artwork in their Shortcuts tiles, which made me wonder whether there is a supported API or approach that I’m missing. Are custom icons or background images currently supported for App Shortcut tiles through public APIs? If not, are the richer treatments used by Apple Music/Podcasts based on system-only capabilities that aren’t currently available to third-party apps? Thanks!

I am seeing a reproducible Apple Pay card provisioning failure on iOS 27 Beta 6 (24A5418b). The card eligibility check succeeds and the Apple Pay provisioning response contains a valid termsID, but provisioning subsequently enters the Secure Element storage-management stage and fails with: SEStorageManagementSheet Code 4 SES.presentationTimedOut The Terms & Conditions screen therefore never appears and provisioning cannot continue. I reproduced the same system-level failure through multiple independent provisioning paths: First-party Apple Wallet provisioning with manual card entry Wallet-initiated provisioning that redirects to the issuer app Issuer-app initiated in-app provisioning The issue affects multiple issuers, including East West Bank and Mercury. The same iPhone successfully provisioned Chase UK and HSBC Hong Kong cards on an earlier iOS 27 beta build, and Apple Pay provisioning worked normally on iOS 26. I have already tested different network conditions, reset network settings, and removed two existing Apple Pay cards before reproduction. The behavior remains unchanged. Two separate sysdiagnoses show the same failure path. During the latest reproduction, SESUIServiceApp was successfully launched, but provisioning ultimately failed during SEStorageManagementSheet presentation with SES.presentationTimedOut. The captured RunningBoard state also showed SESUIServiceApp in a background/suspended state rather than maintaining a successful remote presentation. I have submitted the complete diagnostics and sysdiagnose files through Feedback Assistant: FB24403156 Could an Apple Wallet / Apple Pay engineer please review this Feedback and investigate the SESUIServiceApp / SEStorageManagementSheet remote presentation path on iOS 27? For privacy reasons, I am not attaching the full sysdiagnose publicly here; the diagnostic files are attached to FB24403156

We are building an iPadOS app that requires a DriverKit USB transport dext, and we have been waiting on the restricted entitlement for over three weeks with no movement on any of our requests. Team ID: AKFY9W27HB Entitlements requested: com.apple.developer.driverkit and com.apple.developer.driverkit.transport.usb ┌────────────┬───────────────┬───────────┐ │ Request ID │ Requested │ Status │ ├────────────┼───────────────┼───────────┤ │ 633LBK79JF │ 25 July 2026 │ Submitted │ ├────────────┼───────────────┼───────────┤ │ 6N8PP3G6BA │ 6 August 2026 │ Submitted │ ├────────────┼───────────────┼───────────┤ │ Y8T72G8YJS │ 6 August 2026 │ Submitted │ └────────────┴───────────────┴───────────┘ All three are still showing "Submitted" with no response, the oldest for over three weeks. What we actually need is one configuration, not three grants. The three requests cover three vendor IDs, but a single dext has to match all of them simultaneously: 0x1452 (5202) 0x1343 (4931) 0x0D16 (3350) I believe this is the same situation as thread 826658 (https://developer.apple.com/forums/thread/826658), where multiple vendor ID requests were consolidated into a single entitlement configuration. If our three can be merged the same way, that is exactly what we need. Any guidance on the status of these three requests, or on consolidating them, would be much appreciated.

iOS 27 adds a second stage to HealthKit read authorization. After picking data types, the user chooses "Past 30 Days and Future Data" or "All Recorded Data and Future Data", with Allow disabled until one is selected. Every user of every health app now makes this call, in the first seconds of onboarding, with no real context about what the app needs. I don't think the scale of this has landed yet. A meaningful share of users will pick 30 days. multi-year health trends, month to month comparisons, all-time records: with 30 days these features don't get worse, they stop existing. And it breaks silently. The user sees empty charts and a app that doesn't do what the screenshots promised. They won't connect that to a sheet they tapped through on day one — they'll connect it to the app. That's the reckoning: a wave of one-star reviews and support mail for a decision the developer never saw and can't inspect. Because we can't inspect it .authorizationStatus(for:) deliberately hides read authorization and getRequestStatusForAuthorization only says whether prompting would show UI, so a 30-day grant and a genuinely new Apple Watch user look identical from the query layer. A callback when Health permissions change for a type — even without disclosing the new state — would go a long way here. And we can't route users to the fix. UIApplication.openSettingsURLString opens the app's own Settings page, which has no Health section. The real control sits at Settings › Privacy & Security › Health › — four levels deep, unreachable from any public API. My suggestion is a URL constant scoped to the calling app, the way openNotificationSettingsURLString (iOS 15.4+) and openDefaultApplicationsSettingsURLString (iOS 18.3+) already work. But that's just my idea; if there's a better mitigation, or something already planned, I'd like to hear it. Worth saying the privacy gain looks thin either way: the app keeps all future data indefinitely, so a 30-day grant becomes a full-history grant in thirty days for anyone who keeps the app. The window limits what's readable today, not what accumulates. iOS 27 release is approaching... I think this will cause problems 😞 Filed as FB24398048 and FB24398031

Please take a look at: FB22280049

TL;DR: looking for FileProvider Extension debugging suggestions... I am attempting to develop NSFileProviderReplicatedExtension. Against a real backing repository (~4TB), I've seen fileproviderd become heavily loaded, non-responsive (i.e. fileproviderctl dump has failed to complete within 60s on 8 tries) and (maybe?) re-enumerate the contents of the repository. The profiler says that it's spending most of its time doing sqlite work against the table for the domain from my extension. I hypothesize that my extension has telling fileproviderd occasionally inconsistent things and it is now making sure that the world is the way that it should be. So: is there a way to get it to log when it has received invalid info? (I did read its (terse 😊) man page. I'm running out of ideas of what more to check with responses from the extension.

We have an auto-renewable subscription in our app that we want to stop offering. However, we want to make sure that people who have already purchased the subscription remain subscribed until the end of their current subscription period (and are subsequently unsubscribed and not charged further). What is the right way to do this?We tried submitting the app with the subscription still enabled in App Store Connect but hidden in the app, and our update was rejected because the reviewer couldn't find a way to subscribe.Thanks,Frank

Hi all, we are building a custom controller for ATDECC, which is a layer 2 protocol standardized by IEEE in 1722.1. Our controller can work on multiple network interfaces at the same time . It uses the interface's MAC address to identify, on which interface a certain AVB / ATDECC device was discovered. It then sends replies for this device only to this interface. This controller worked fine up to and including macOS 26, but when running the same code on macOS 27, we cannot get the MAC addresses for the local interfaces anymore, but we receive 02:00:00:00:00:00 for each of them. This seems to indicate that the MAC address was redacted (looks like the same MAC address, that is being returned since iOS 11 due to privacy reason). Is this a bug or is macOS going to redact the MAC addresses also in the final release? If MAC addresses are being redacted, would it help to request access to the new entitlement called com.apple.developer.networking.topology-observation? I attached a little code snippet, that returns actual MAC addresses on macOS 26, but redacted ones on macOS 27. Build with clang++ -std=c++23 -o ifprobe ifprobe.cpp and then run it with ./ifprobe. ifprobe.cpp

We are seeing a low-volume but persistent crash on iOS 26 that surfaces inside Foundation's base64 encoder, and we would like to see if and how we could prevent that crash 2026-08-14_10-47-14.9181_-0500-5b74aa117551b30ab7696e1d90c129b97ab1e42f.crash - (nonnull NSString *)pnd_UTF8Base64 { NSData *encodedData = [self dataUsingEncoding:NSUTF8StringEncoding]; if (encodedData == nil || encodedData.length == 0) { return @""; } NSData *safeData = [NSData dataWithBytes:encodedData.bytes length:encodedData.length]; return [safeData base64EncodedStringWithOptions:0]; } Questions: Is our reading correct that _xzm_xzone_malloc_freelist_outlined indicates the freelist was ALREADY corrupted before this allocation (double-free / use-after-free / buffer overflow somewhere else), and that this base64 malloc is merely the first allocation to detect it (a 'canary'), not the cause? Did the iOS 26 xzone allocator add/strengthen freelist integrity checks such that latent corruption that previously went unnoticed now traps here? What is the recommended way to pin down the real corruptor in a shipping app where this reproduces only occasionally on end-user devices (MallocStackLogging, Guard Malloc / libgmalloc, MallocScribble, Address Sanitizer, MallocNanoZone settings)? Are any of these usable/meaningful against the xzone allocator? Is there any process-level or per-allocation API to validate heap integrity that is safe on the xzone allocator (e.g. malloc_zone_check behavior on iOS 26)? Any guidance on interpreting this signature and isolating the root cause would be appreciated. Thanks.

I have a persistent WeatherKit authentication failure that could be server-side JWT minting not being enabled for my App ID. Every WeatherService.shared.weather(for:) call fails with: Failed to generate jwt token for: com.apple.weatherkit.authservice Error Domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "(null)" The console shows the request reaching Apple's auth service and failing only at the JWT generation step. Account / app: Team ID: 634Q7K5DN8 Bundle ID: com.davidfrauenhofer.TripVault App: shipping on the App Store (this is an update adding a WeatherKit forecast) Device: iPhone 13 Pro, physical device (not simulator) Signing: Xcode automatic Everything I've verified locally: codesign -d --entitlements - on the installed binary confirms com.apple.developer.weatherkit = true, with application-identifier = 634Q7K5DN8.com.davidfrauenhofer.TripVault and matching com.apple.developer.team-identifier. WeatherKit is enabled on the App ID under both the Capabilities and App Services tabs, saved and confirmed. App ID Prefix equals my Team ID (634Q7K5DN8) — no legacy prefix mismatch. Fresh provisioning profiles downloaded; clean build folder; app deleted and reinstalled. Active Apple Developer Program membership; no pending agreements in App Store Connect. Valid coordinates passed (confirmed in logs). This has persisted for several weeks across many rebuilds and reinstalls so i should have cleared any propagation windows. Request to the WeatherKit team: Could someone verify whether JWT minting is enabled server-side for this Team ID / Bundle ID, and whether there is a stuck or incomplete WeatherKit registration for this App ID? Given the entitlement is confirmed present in the signed binary and all client-side configuration is correct, I believe this requires inspection of the auth-service registration on Apple's side. Happy to provide any additional logs or identifiers.

Our production container has hit the record type ceiling. Any schema change that adds a new type is rejected with: The request was not allowed: max user record types limit exceeded A schema export taken from production with cktool shows exactly 250 record types: 148 our active schema, CKSyncEngine based 98 CD_* types, auto-generated by NSPersistentCloudKitContainer years ago, before we migrated to CKSyncEngine. The current binary does not use that mirroring path at all (every ModelConfiguration is created with .cloudKitDatabase: .none, and there is not a single CD_ literal in our source). They are never read and never written. 4 system and pre-migration legacy types So 39% of the budget belongs to a framework we no longer use, and because the production schema is append-only we cannot reclaim any of it. Our effective ceiling is 152 types, and we have used 148. The user-visible symptom is CKError 12, "Cannot create new type in production schema". The record is created locally, the client uploads it, the server correctly rejects it, and the data never reaches the user's other Mac or iPad. It fails silently from the user's point of view. Eight shipped features are affected. One of them carries allergen availability, which our restaurant customers print on recipes and communicate to guests, so this is not cosmetic for us. The wall is exactly 250 and it is deterministic: a batch of 13 new types was rejected (245 + 13), and a batch of 5 succeeded, landing the container on 250 precisely. What I have already done: Filed FB24239614 with the full schema export attached. Opened Developer Support case 20000130013570, which came back with general information about what CloudKit is and did not address the quota. Adopted an internal rule that new synchronised data lives as a field or blob on an existing record type wherever the data model allows. Adding fields to existing types works fine and does not consume the budget — that part is not the problem. Some of the eight genuinely need to be their own type. My questions: Is there any supported way to reclaim record type slots left behind by NSPersistentCloudKitContainer after migrating off it? Everything I have found says the production schema is append-only with no exceptions, but these types were generated by the framework rather than authored by us, so I wanted to ask before assuming. If slots cannot be reclaimed, is a per-container record type limit increase something that can be requested through a channel that reaches the CloudKit team? The Developer Support case did not get there. Has anyone migrated a container that uses CKShare-based sharing to a new container? Our model gives each customer a shared zone that their staff accept through a CKShare. My understanding is that shares cannot be migrated, which would force every one of those users to re-accept access. I would like to know if that understanding is correct before treating it as an option. Happy to share the container identifier with an Apple engineer, and the Feedback report has the full export.

I want to prompt users when their iCloud storage quota is full. My test device's iCloud space is full, and when subscribing to the NSPersistentCloudKitContainer-eventChangedNotification event, events exceeding the quota will not be passed to the application at runtime. When I tried to add data to Core data using NSPersistentCloudKitContainer, I got an error: <CKError 0x600000c15890: "Quota Exceeded" (25/2035); server message = "Quota exceeded"; op = 1ECF73B9554DF79F; uuid = 34D12DF0-A307-49EB-AD3A-BB646FF66F54; Retry after 316.0 seconds>}> My iCloud storage space is full, but I am unable to retrieve the 'Quota exceeded' error.I have written a demo, please help me fix the issue. github: CloudKit Sync Demo

Transaction.finish() doesn't clear a transaction on iOS 27 beta 5 — worked correctly through beta 4 — every repeat purchase after the first replays the same transaction with no confirmation sheet and no charge. StoreKit.Transaction.finish() does not clear a transaction on iOS 27 beta 5. The transaction remains in Transaction.unfinished indefinitely, and every subsequent Product.purchase() call for that product returns the same stale transaction instead of starting a new purchase — with no confirmation sheet, no charge, and no way for the app to tell it apart from a genuine purchase. Because the replayed result is .success carrying a VerificationResult that verifies normally, an app has no supported signal that nothing was bought. The only distinguishing traits are that the id and purchaseDate are unchanged and the call returns in ~10ms instead of making a server round-trip. Consequence: a consumable product can be purchased exactly once per device. Every later attempt silently no-ops while appearing to succeed. Steps to Reproduce On a device running iOS 27 beta 5, sign in to a newly created Sandbox Apple Account (Settings → Apps → App Store → Sandbox Account) with no prior purchase history. Install and launch a development build of an app offering a consumable IAP. Confirm Transaction.unfinished is empty. Purchase the consumable. The confirmation sheet appears and the purchase completes normally. await transaction.finish() on the returned transaction. Enumerate Transaction.unfinished again. Purchase the same consumable a second time. Expected Results Step 6: Transaction.unfinished is empty — the transaction was finished. Step 7: a confirmation sheet appears and a new transaction is created, with a new id and a current purchaseDate. Actual Results Step 6: the just-finished transaction is still listed in Transaction.unfinished. Step 7: no confirmation sheet appears. purchase() returns .success in ~0.01s carrying the same transaction — identical id and identical purchaseDate — and nothing is charged. This repeats indefinitely. Re-fetching the transaction from Transaction.unfinished and calling finish() on that instance does not clear it either, so there is no app-side way to drain the queue. Diagnostic Log Virgin sandbox account, empty queue, three consecutive taps on one product: unfinished before tip.small: [] purchase() returned after 18.10s tip.small: id=2000001221113013 purchaseDate=2026-08-13 22:36:26 +0000 --- await transaction.finish() --- unfinished after finishing 2000001221113013: [small#2000001221113013] unfinished before tip.small: [small#2000001221113013] purchase() returned after 0.01s tip.small: id=2000001221113013 purchaseDate=2026-08-13 22:36:26 +0000 unfinished before tip.small: [small#2000001221113013] purchase() returned after 0.01s tip.small: id=2000001221113013 purchaseDate=2026-08-13 22:36:26 +0000 The first call is a genuine purchase (18s round-trip, sheet shown). The transaction survives its own finish(). Calls two and three are replays of it. Notes Not reproducible against a local .storekit configuration in the Simulator, which always presents the confirmation sheet. Requires Apple's sandbox. Also reproduces on a TestFlight build billed to a real Apple ID, where it is worse: TestFlight purchase history cannot be reset, so the affected products stay permanently stuck for that account. It survives deleting and reinstalling the app, and a device reboot. Possibly the same underlying issue as the unanswered report at https://developer.apple.com/forums/thread/808648 (iOS 26/18, Nov 2025). Configuration Device: iPhone 16 Pro Max OS: iOS 27 beta 5 Products: consumable in-app purchases API: StoreKit 2 (Product.purchase(), Transaction.finish(), Transaction.unfinished)

Filing this as a public thread to try to get DTS attention, similar to how thread 821372 (skmem_slab_free_locked double-free) got resolved - accumulated cross-referenced reports there are what got that one fixed in 26.5/26.6. Panic signature (identical every time): panic(cpu N caller 0x...): m_copym_with_hdrs n 0x... copy overflow @uipc_mbuf.c:3268 My own occurrences: 5 panics over 2 days on a MacBook Pro (Mac16,7 / M4 Pro), macOS 26.5.2 build 25F84, kernel Darwin 25.5.0 (xnu-12377.121.10~1/RELEASE_ARM64_T6041). Filed as Feedback Assistant report FB24343421 (5 panic logs + a full sysdiagnose attached). Why this looks like a generic kernel bug, not app-specific: I initially suspected a third-party VPN NetworkExtension (Tailscale) since it appeared in the full stackshot of every one of my panics. Ruled that out: That NE is a userspace-only component - cannot execute kernel code. Two other reporters have hit the identical panic string via completely different, unrelated paths: One reproduced it with no VPN/tunnel software running at all (engine stopped, sysext idle) - see FB24333740, cross-referenced at https://github.com/tailscale/tailscale/issues/20864 Another hit the same panic string on an Intel Mac via a third-party Ethernet kext, no VPN/utun involved at all - https://github.com/SongXiaoXi/AppleIGC/issues/34 So this reproduces through at least 3 independent producer paths (a NetworkExtension, no tunnel software at all, and a third-party Ethernet driver), which points to something generic in the TCP send path (tcp_output -> m_copym_with_hdrs) rather than anything specific to one app or extension. Known non-workarounds: net.inet.tcp.tso=0 does not avoid the code path (checked against the last public xnu source drop). No sysctl or config change has stopped recurrence for anyone who's tried. Related public reports: https://github.com/tailscale/tailscale/issues/20864 https://github.com/tailscale/tailscale/issues/20612 https://github.com/SongXiaoXi/AppleIGC/issues/34 FB24333740 (independent Feedback Assistant report, same signature) FB24343421 (mine, this thread) Still reproducing on the latest public release (26.6.1 / 25G76) per the other reporters. Happy to provide more diagnostics - this is easy to reproduce on my end, roughly every few hours to once a day under normal use.

Hi, We've implemented age assurance logic in our app using the DeclaredAgeRange framework to comply with regulations in Brazil (Digital ECA, effective March 17, 2026) and Utah (App Store Accountability Act, effective May 6, 2026). Our implementation calls AgeRangeService.shared.isEligibleForAgeFeatures on app launch to determine whether the current user is subject to age assurance requirements, and proceeds to call requestAgeRange(ageGates:) accordingly. However, after monitoring in production since the Brazil enforcement date, we've consistently observed isEligibleForAgeFeatures returning false for users in regulated regions, with no age range data being returned. What we'd like to clarify: Is isEligibleForAgeFeatures currently returning true for users in Brazil in production (not sandbox)? For Utah — given that HB 498 pushed the developer compliance deadline to May 6, 2027, will isEligibleForAgeFeatures reflect the original May 6, 2026 activation date or the revised 2027 date? Is there a known rollout schedule or gradual activation plan for these regions that would explain why the flag remains false even after the legal enforcement dates have passed? We've seen similar reports from other developers on these forums, so it seems this may be a widespread issue rather than an implementation problem on our end. Any official guidance on the current status of the API in regulated regions would be greatly appreciated. Thanks.

We have developed an IOPCIFamily based custom KEXT to communicate with Thunderbolt interface storage device. This KEXT is working fine with Apple machines with Intel CPUs in all types of machines (iMac, iMac Pro and MacBooks). We tested this KEXT with Apple Silicon M1 machine where we are observing crash for the very first command we send to the Thunderbolt device. We observed that there is difference in number of bits in Physical Address we use for preparing command PRPs. In Intel machines we get 28-Bit Physical Address whereas in M1 we are getting 36-Bit address used for PRPs. We use inTaskWithPhysicalMask api to allocate memory buffer we use for preparing command PRPs. Below are the options we have used for this: options: kIOMemoryPhysicallyContiguous | kIODirectionInOut capacity: 16kb physicalMask: 0xFFFFF000UL (We want 4kb aligned memory) According to below documentation, we have to use inTaskWithPhysicalMask api to get memory below 4gb. https://developer.apple.com/library/archive/documentation/Darwin/Conceptual/64bitPorting/KernelExtensionsandDrivers/KernelExtensionsandDrivers.html#//apple_ref/doc/uid/TP40001064-CH227-SW1 Some devices can only handle physical addresses that fit into 32 bits. To the extent that it is possible to use 64-bit addresses you should do so, but for these devices, you can either use IODMACommand or the initWithPhysicalMask method of IOBufferMemoryDescriptor to allocate a bounce buffer within the bottom 4 GB of physical memory. So just want to know what's the difference between Intel and ARM64 architecture with respect to physical memory access. Is there any difference between byte order for physical memory address..?? Crash log is given below: panic(cpu 0 caller 0xfffffe0016e08cd8): "apciec[0:pcic0-bridge]::handleInterrupt: Request address is greater than 32 bits linksts=0x99000001 pcielint=0x00020000 linkcdmsts=0x00000800 (ltssm 0x11=L0)\n" Debugger message: panic Memory ID: 0x6 OS release type: User OS version: 20C69 Kernel version: Darwin Kernel Version 20.2.0: Wed Dec 2 20:40:21 PST 2020; root:xnu-7195.60.75~1/RELEASEARM64T8101 Fileset Kernelcache UUID: 3E6AA74DF723BCB886499A5AAB34FA34 Kernel UUID: 48F71DB3-6C91-3E62-9576-3A1DCEF2B536 iBoot version: iBoot-6723.61.3 secure boot?: YES Paniclog version: 13 KernelCache slide: 0x000000000dbfc000 KernelCache base: 0xfffffe0014c00000 Kernel slide: 0x000000000e73c000 Kernel text base: 0xfffffe0015740000 Kernel text exec base: 0xfffffe0015808000 machabsolutetime: 0x12643a9c5 Epoch Time: sec usec Boot : 0x5fe06736 0x0009afbc Sleep : 0x00000000 0x00000000 Wake : 0x00000000 0x00000000 Calendar: 0x5fe067fd 0x0006569d CORE 0 recently retired instr at 0xfffffe0015971798 CORE 1 recently retired instr at 0xfffffe0015972c5c CORE 2 recently retired instr at 0xfffffe0015972c5c CORE 3 recently retired instr at 0xfffffe0015972c5c CORE 4 recently retired instr at 0xfffffe0015972c60 CORE 5 recently retired instr at 0xfffffe0015972c60 CORE 6 recently retired instr at 0xfffffe0015972c60 CORE 7 recently retired instr at 0xfffffe0015972c60 Panicked task 0xfffffe166ce9e550: 75145 pages, 462 threads: pid 0: kernel_task Panicked thread: 0xfffffe166d053918, backtrace: 0xfffffe306cb4b6d0, tid: 141 lr: 0xfffffe0015855f8c fp: 0xfffffe306cb4b740 lr: 0xfffffe0015855d58 fp: 0xfffffe306cb4b7b0 lr: 0xfffffe0015977f5c fp: 0xfffffe306cb4b7d0 lr: 0xfffffe0015969914 fp: 0xfffffe306cb4b880 lr: 0xfffffe001580f7e8 fp: 0xfffffe306cb4b890 lr: 0xfffffe00158559e8 fp: 0xfffffe306cb4bc20 lr: 0xfffffe00158559e8 fp: 0xfffffe306cb4bc90 lr: 0xfffffe0015ff03f8 fp: 0xfffffe306cb4bcb0 lr: 0xfffffe0016e08cd8 fp: 0xfffffe306cb4bd60 lr: 0xfffffe00166bc778 fp: 0xfffffe306cb4be30 lr: 0xfffffe0015f2226c fp: 0xfffffe306cb4be80 lr: 0xfffffe0015f1e2f4 fp: 0xfffffe306cb4bec0 lr: 0xfffffe0015f1f050 fp: 0xfffffe306cb4bf00 lr: 0xfffffe0015818c14 fp: 0x0000000000000000 Kernel Extensions in backtrace: com.apple.driver.AppleEmbeddedPCIE(1.0)[4F37F34B-EE1B-3282-BD8B-00009B954483]@0xfffffe00166b4000->0xfffffe00166c7fff dependency: com.apple.driver.AppleARMPlatform(1.0.2)[5CBA9CD0-E248-38E3-94E5-4CC5EAB96DE1]@0xfffffe0016148000->0xfffffe0016193fff dependency: com.apple.driver.IODARTFamily(1)[88B19766-4B19-3106-8ACE-EC29201F00A3]@0xfffffe0017890000->0xfffffe00178a3fff dependency: com.apple.iokit.IOPCIFamily(2.9)[5187699D-1DDC-3763-934C-1C4896310225]@0xfffffe0017c48000->0xfffffe0017c63fff dependency: com.apple.iokit.IOReportFamily(47)[93EC9828-1413-3458-A6B2-DBB3E24540AE]@0xfffffe0017c64000->0xfffffe0017c67fff com.apple.driver.AppleT8103PCIeC(1.0)[35AEB73B-D51E-3339-AB5B-50AC78740FB8]@0xfffffe0016e04000->0xfffffe0016e13fff dependency: com.apple.driver.AppleARMPlatform(1.0.2)[5CBA9CD0-E248-38E3-94E5-4CC5EAB96DE1]@0xfffffe0016148000->0xfffffe0016193fff dependency: com.apple.driver.AppleEmbeddedPCIE(1)[4F37F34B-EE1B-3282-BD8B-00009B954483]@0xfffffe00166b4000->0xfffffe00166c7fff dependency: com.apple.driver.ApplePIODMA(1)[A8EFA5BD-B11D-3A84-ACBD-6DB25DBCD817]@0xfffffe0016b0c000->0xfffffe0016b13fff dependency: com.apple.iokit.IOPCIFamily(2.9)[5187699D-1DDC-3763-934C-1C4896310225]@0xfffffe0017c48000->0xfffffe0017c63fff dependency: com.apple.iokit.IOReportFamily(47)[93EC9828-1413-3458-A6B2-DBB3E24540AE]@0xfffffe0017c64000->0xfffffe0017c67fff dependency: com.apple.iokit.IOThunderboltFamily(9.3.2)[11617399-2987-322D-85B6-EF2F1AD4A794]@0xfffffe0017d80000->0xfffffe0017e93fff Stackshot Succeeded Bytes Traced 277390 (Uncompressed 703968) ** System Information: Apple Silicon M1 BigSur 11.1 Model: Macmini9,1 Any help or suggestion is really appreciated. Thanks

Using VisionKit, there's two main ways to get text from images. ImageAnalyzer VNRecognizeRequest Based on some OCR tests, I'm seeing that the outputs from these two methods are different. Initially, I thought ImageAnalyzer was running VNRequestTextRecognitionLevel.fast because it's for Live Text, but the outputs from ImageAnalyzer are sometimes better than VNRequestTextRecognitionLevel.accurate. Is ImageAnalyzer running VNRequestTextRecognition in the background? Or if it isn't, what pipeline is it using to detect text?

Hello Apple Developer Community, I am reaching out to see if anyone has experienced a similar administrative roadblock with the Apple MFi Portal (WPC Certification Program) and how it was successfully resolved, given that our official support channel tickets have been stalled for over two months. Background & Timeline of Events May 29 : Applied to join the WPC Certification Program. June 3 : Received an email stating the enrollment form was declined. June 17 : Replied via email providing additional clarification and context, as email was the only available communication channel. (with no alternative contact options accessible on the portal). Note: Due to an inactive or incorrect contact email provided in their system, my initial message was misdirected, causing two-weeks delay. June 25 : The WPC Cert team replied stating that we could enroll in the program. However, the portal status remained "Enrollment form declined" with no interactive options available. June 25 : Requested that they either approve our previous application or reset the account status so we could submit a fresh form. July 14 : Followed up due to a lack of response. July 16 : Support advised that we need to "create and fill out a new application." July 20 : Asked for instructions on how to create a new application or requested an account reset to enable a new submission. July 29 : Followed up once again to check on the progress. Present : No reply received, even after two weeks of waiting. The core Technical & Administrative Issue Portal UI Block : The portal page (https://mfi.apple.com/wpc-login) remains locked on the "Enrollment form declined" status screen. There are no buttons, menus, or interactive elements to reapply, submit a new form, or update the existing application. Troubleshooting Steps Taken: Cleared browser caches and tested using Safari's Private Browsing mode. Installed alternative browsers and attempted access via Incognito mode. The screen layout remains identical with no mechanism to clear the status or start fresh. Support Feedback Limitation : Support simply advised to "create and fill out a new application.", but provided no technical path or portal interface to actually do so under our current account. Help / Advice Requested Since our support ticket has been unresponsive for over two months despite multiple follow-ups: Has anyone encountered a UI lock like this on the MFi portal after a declined status? Is there a specific backend account reset procedure or alternate escalation path to clear an existing profile's status without forcing the creation of a new account? Any guidance, insights, or advice on how to escalate this efficiently would be greatly appreciated. Thank you for your time!