High Power Mode setting is not applied by powerd (possibly related to migrateenergyprefs) Summary On a MacBook Pro (14-inch, M5 Max), enabling High Power Mode in System Settings has no effect on the actual power governor. The system continues to run at the default (Automatic-equivalent) power ceiling regardless of the High Power Mode setting. The same symptom has been reproduced on a different physical machine, a MacBook Pro (M4 Max), ruling out a single hardware defect. Environment Affected device: MacBook Pro 14-inch (Apple M5 Max, 12P+6S+40GPU, 128GB RAM) macOS version: macOS 26.5.1 (Build 25F80) Migration history: Intel Mac → MacBook Air (M2) → MacBook Pro (M4 Max) → MacBook Pro (M5 Max), using Migration Assistant at each step Same symptom also confirmed on the MacBook Pro (M4 Max), which had the same migration history Symptom Selecting "High Power" under System Settings → Battery → Power Mode has no effect on system_profiler SPPowerDataType, which always reports High Power Mode: No. pmset -g custom correctly shows powermode 2 (the High Power equivalent) for AC Power, confirming the user-facing setting is being written correctly. Low Power Mode in the same system_profiler output correctly toggles between Yes/No depending on the UI selection (Automatic / Low Power / High Power). Only High Power Mode fails to track the UI selection. Benchmarking with 3DMark Steel Nomad Stress Test (Metal API) reproduces the score pattern that third-party reviews report for High Power Mode OFF (stabilized score ~3100–3400), rather than the ON pattern reported for the same model (~3600+). This confirms the issue is not just cosmetic (a wrong status string) but reflects an actual difference in the power ceiling being enforced. Investigation steps taken 1. Preference file inspection Inspected /Library/Preferences/com.apple.PowerManagement.<UUID>.plist. Multiple UUID-keyed files exist, each corresponding to a previously used device (identified by battery serial number in the BatteryWarn key). All of them contained HighPowerMode = 0, including the file matching the current machine's serial number. The MacBook Air (M2) used earlier in this device's migration history does not support High Power Mode at all. It's suspected that HighPowerMode = 0 originated from that device and was carried forward through subsequent Migration Assistant transfers to devices that do support the feature, without ever being correctly re-evaluated. 2. Direct write test Used defaults write to directly set HighPowerMode = 1 in the relevant plist. system_profiler then reported High Power Mode: Yes, and this persisted across a reboot. However, a subsequent benchmark run showed no improvement — powermetrics Combined Power remained in the 27–30W range, and the Steel Nomad Stress Test stabilized score actually dropped slightly (~3134 average over the last 10 loops). This indicates the displayed value is decoupled from the actual power governor state. 3. File deletion / regeneration test Deleted the UUID-keyed plist (after backing it up) and let powerd regenerate it from scratch. The newly generated file still showed HighPowerMode stuck at No and unresponsive to UI changes, while LowPowerMode continued to track UI changes correctly. The same test was repeated with the non-UUID common file (com.apple.PowerManagement.plist), with no change in behavior. This rules out stale/corrupted preference data as the root cause. 4. Binary-level investigation Searched the system for files containing the string "HighPowerMode". Aside from unified logging symbol caches (uuidtext, not relevant), the following were found: /System/Library/CoreServices/powerd.bundle/powerd (Apple-signed, Signed Time: Apr 19, 2026, Platform identifier 26) /System/Library/CoreServices/powerd.bundle/migrateenergyprefs.bundle/ (com.apple.migrateenergyprefs, LSMinimumSystemVersion 26.5, built with Xcode 2630) /System/Library/SystemProfiler/SPPowerReporter.spreporter/ /System/Library/ExtensionKit/Extensions/BatterySettingsIntentsExtension.appex/ The presence of a dedicated com.apple.migrateenergyprefs component strongly suggests this is the code path responsible for carrying power preferences across device migrations. We suspect this migration logic fails to correctly initialize or re-evaluate HighPowerMode when migrating from a device that doesn't support the feature to one that does. Reproducibility Reproduced on two distinct physical machines (M4 Max and M5 Max), making a hardware fault unlikely. Reproduced after deleting and regenerating the preference files, ruling out simple cache corruption. Reproduced after a full reboot, ruling out a transient in-memory state issue alone. Impact Because High Power Mode is not actually engaged, sustained CPU/GPU performance under heavy load is capped at a lower power ceiling than intended, resulting in measurably lower benchmark scores and sustained performance compared to the documented behavior of the same hardware configuration. Questions for Apple Could the com.apple.migrateenergyprefs logic be reviewed for how it handles HighPowerMode when migrating from a device that does not support the feature (e.g., MacBook Air M2) to one that does? Is there a known issue with HighPowerMode specifically (as opposed to LowPowerMode, which behaves correctly) not being written back by powerd in response to UI changes? Are there other users with a similar multi-generation Migration Assistant history reporting the same symptom? Happy to provide a sysdiagnose or additional logs if useful.

I'm testing code that uses NSMetadataQuery and I noticed some odd behavior. I run a query where the search scope is set to my Desktop directory. The predicate is set to search for a file name that contains 'we' (display name to be precise: kMDItemDisplayName). And I get no results. So I stop the app from Xcode then I create a new folder on the Desktop and name it we exactly. Then I rerun my app and start the query again - still no results. Unfortunately none of the Spotlight based APIs I'm using report errors. There is no delegate method -queryDidFailWithError: or anything like that. So in another place my app uses the lower level MD prefixed APIs in Core Services to read file metadata and I notice that those APIs are failing as well. Specifically I try to load metadata for a PNG image. I create an MDItemRef via MDItemCreateWithURL (and I do get an MDItemRef). Then I call MDItemCopyAttributes with the MDItemRef and an array of metadata attribute names: CFDictionaryRef fetchedData = MDItemCopyAttributes(mdItem, attributeNames); I step through it in the debugger and fetchedData is NULL. Since there is no error handling APIs available for any of this my app just silently fails. I have Console.app open when I step through MDItemCopyAttributes call in the debugger and this logs out every time: com.apple.spotlightserver Bad checksum on fetch attributes reply from store, 0x123ea456.... FWIW I do not have Spotlight indexing turned off on my system. Also jumping to Finder I'm experiencing the same failures (metadata isn't populating and the Desktop search for we produces no results). Actually on further inspection it looks like all searches are producing no results. Spotlight appears to be in a broken state system wide. I'm pretty sure a system restart will 'fix' it - until it starts occurring again. But for obvious reasons I'd like to avoid releasing a feature in my app that results in this kind of experience. Is there anything I can do on my end to workaround or avoid this issue? And tips or advice would be greatly appreciated.

I applied on the Multicast Networking Entitlement Request site, but I did not receive a response email. How long does a response usually take?

App name: Hold My Bouquet Bundle ID: com.holdmybouquet.app App Store Connect App ID: 6807080553 In-App Purchase Product ID: com.holdmybouquet.app.page_unlock (Non-Consumable, £3.99) Our app was rejected on Guideline 2.1 because the reviewer could not complete this in-app purchase. Since the rejection, we have verified and corrected every configuration item we can control, but the purchase still fails identically in sandbox testing on a physical device. Confirmed correct: Paid Applications Agreement: Active com.holdmybouquet.app.page_unlock: status "Ready to Submit," Cleared for Sale, pricing and availability set Bundle ID matches exactly across Xcode, App Store Connect, and our purchase provider (RevenueCat) Product ID matches exactly, no typos or case mismatches Sandbox tester account verified and signed in on-device (Settings → Developer → Sandbox Account) No local StoreKit Configuration file overriding real data (confirmed "None" in the Xcode scheme) To rule out our purchase provider entirely, we bypassed it and called Apple's native StoreKit 2 API directly from the app: let products = try await Product.products(for: ["com.holdmybouquet.app.page_unlock"]) This also returns zero products, with no error — confirming the issue is not a third-party SDK integration problem. Has anyone seen this before, or can anyone from Apple advise what else to check? We are otherwise ready to resubmit for review.

Hi everyone, I’ve filed a Feedback report (FB20986470) for a serious issue affecting the Call Directory database when add phone numbers for call blocking. When adding blocking numbers to a Call Directory extension, the system’s CallKit database (/private/var/mobile/Library/CallDirectory/CallDirectory.db) becomes corrupted. The reload call (reloadExtensionWithIdentifier) fails with error code 11 when the system tries to insert blocking entries, and the Console app on macOS shows the following errors: database corruption page 2265525 of /private/var/mobile/Library/CallDirectory/CallDirectory.db at line 81343 of [f0ca7bba1c] database corruption at line 79387 of [f0ca7bba1c] Error Domain=com.apple.callkit.database.sqlite Code=11 "sqlite3_step for query 'INSERT INTO PhoneNumberBlockingEntry (extension_id, phone_number_id) VALUES (?, (SELECT id FROM PhoneNumber WHERE (number = ?))), (?, (SELECT id FROM PhoneNumber WHERE (number = ?))),...)'" After this happens, CallKit becomes fully corrupted on the device and no further numbers can be added, even after: Disabling and re-enabling the extension Restarting the device (either force or soft restart) Reinstalling the app Waiting for a couple of minutes after this issue happens (that CallKit could possibly self-recovered) I also tested other call-blocking apps, and they all fail with the same error. The only thing that recovers the system is a full “Reset All Settings.” This issue has been reported by many users of my app, across multiple iOS versions and devices. Similar related issue reported by another developer: https://developer.apple.com/forums/thread/806129 Steps to Reproduce: Enable the Call Directory extension from a call-blocking app. Add and reload blocking numbers (a few thousand entries). Perform multiple reloads between additions. Check the Console, the corruption errors appear. From this point, all insert attempts fail system-wide. Expected Result: Entries should be inserted successfully, or the system should self-recover without persistent corruption. Actual Result: sqlite3_step fails with Code=11, and the Call Directory database remains corrupted until the user resets all settings. Additional Notes: All numbers are sorted and deduplicated before insertion. Happens intermittently after multiple reloads. The system log always shows internal database failure. Environment: Device: iPhone 16 Plus iOS 18.2 Beta (23C5027f) Xcode 16.1 (17B55) Attachments (included in Feedback FB20986470): sysdiagnose captured immediately after the failure (with Phone app General Profile) It seems like a system-level corruption affecting all Call Directory extensions once it occurs.

Hello everyone, I've been chasing a nasty silent data corruption bug in the macOS SMB client (smbfs.kext) and wanted to share what I found, in case someone else has hit it and in the hope that someone from the SMB team sees it. What happens Under concurrent writes with repeated reopens, the client can regress its cached file size (np->n_size) to an earlier, smaller value - behind data it has already written and flushed to the server. The next write then treats the already-written range as a hole, zero-fills it via IO_HEADZEROFILL, and sends the zeros to the server, right on top of the correct bytes it transmitted moments earlier. No write(2) fails and nothing is logged - the file just quietly comes back with a chunk-aligned run of zeros in the middle, at the correct overall length. Environment macOS 26.5 (Darwin 25.5.0), Apple silicon (16 KiB VM pages), SMB 2.1 Sources referenced: SMB client 538.121.1, xnu 12377.121.6 How to reproduce Mount an SMB 2.1(2.0.2 has the same issue as well) share. Have several threads write the same files in 8 KiB chunks, each chunk via its own open/lseek/write/close (so the file is reopened constantly as it fills), while the files are concurrently resolved by name (stat / directory enumeration). Read the files back through a cache-cold path (second mount, or F_NOCACHE) and compare. Roughly 1 file in several hundred came back corrupted for me. The core of the write pattern: CHUNK = 8192 # 2 chunks per 16 KiB page def write_chunk(path, data, offset): fd = os.open(path, os.O_CREAT | os.O_RDWR) # own handle per chunk try: os.lseek(fd, offset, os.SEEK_SET) os.write(fd, data) finally: os.close(fd) # per file: content = os.urandom(random.randint(265000, 300000)); # chunks written in batches of 8 threads, joined between batches; # each file written twice from the same buffer: NAME, then NAME.copy In my runs the corruption always landed on the second (.copy) write. One caveat: I reproduced this against a third-party SMB server, not against macOS File Sharing (smbd), and I don't expect it to reproduce against smbd directly. The stale size arrives via reopen-via-lookup (smbfs_update_size <- smbfs_nget <- smbfs_vnop_lookup) on a freshly instantiated vnode, whose n_sizetime lets the freshness guard pass. smbd instead reopens via vnop_compound_open -> smbfs_attr_cacheenter (warm vnode; the guard rejects it) - the same stale-size candidates occur, they just all get rejected. The server merely steers the client onto the vulnerable path; the bug itself is entirely client-side. What I observed I captured the kernel side with dtrace fbt probes on smbfs_setsize() / smbfs_update_size() (os_log drops events under this load). Timeline for one corrupted file, correlating pcap and dtrace (dtrace has whole-second resolution, marked ".x"): [pcap] = network packet capture of the SMB traffic between client and server [dtrace] = kernel-side trace of the smbfs size-update functions; timestamps only have whole-second resolution, so ".x" marks an unknown sub-second time :39.778 [pcap] — client sends WRITE off=32768 len=32768 with the correct data, covering [40960:65536). :39.777–.860 [pcap] — throughout, the server's CREATE/CLOSE responses report a strictly monotonic EOF: 0, 8192, 40960, 65536, ... 288255. :39.x [dtrace] — on a reopen, smbfs_update_size applies EOF 40960 (a superseded value), regressing n_size from 65536 to 40960. :39.x [dtrace] — the next write starts past the regressed size, so zero_head_off = 40960 and IO_HEADZEROFILL is set. :39.804 [pcap] — client sends WRITE off=32768 len=57344, ALL ZEROS over [40960:65536), on top of the correct data it sent 26 ms earlier. End result: the file is 288255 bytes (correct length) with 24 KiB of zeros at [40960:65536) - three consecutive 8 KiB chunks, i.e. 1.5 x 16 KiB VM pages. Worth stressing: the server's own responses reported a strictly monotonic EOF the whole time, so the regression to 40960 was purely the client applying a superseded value. Expected, obviously: the file reads back byte-for-byte identical to what was written. Where I think the bug is From reading the smbfs and xnu sources, three things combine: np->n_size isn't consistently synchronized - read under the node lock only (smbfs_vnops.c:7329/7387/7391) but written under f_clusterWriteLock (:7411) and by smbfs_vnop_strategy under the cluster lock, so the reader deciding the zero-fill has no ordering guarantee. Possible fix: read it once under f_clusterWriteLock in smbfs_vnop_write so the snapshot, extend, and zero_head_off stay consistent. The freshness guard checks the wrong thing - smbfs_update_size's reqtime <= n_sizetime guard validates the reply's request time, not whether the value is still current, so a superseded (smaller) size applied later still passes and calls smbfs_setsize(smaller). Possible fix: never shrink n_size from fa_size while the vnode has dirty pages or in-flight writes beyond that size. The zero-fill is destructive - zero_head_off = np->n_size (smbfs_vnops.c:7391) feeds IO_HEADZEROFILL, and cluster_write zeros [n_size, uio_offset) without checking whether the UBC already holds those pages as valid/dirty (vfs_cluster.c), then flushes the zeros to the server. A defensive check there would neutralize the corruption regardless of cause. Has anyone else seen silent zero-runs in files written over SMB under concurrent access? Thanks!

We shipped Apple-Hosted Background Assets in our App Store app (iOS 26.0+, released September 12, 2026): 14 managed asset packs named ea-<system>-s1 (about 955 MB in total, all in “Ready for Distribution” in App Store Connect), on-demand download policy. The app downloads them sequentially with AssetPackManager.shared.ensureLocalAvailability(of:) (on iOS 26.4+ with requireLatestVersion:), observes statusUpdates, and runs a BGContinuedProcessingTask for foreground progress. In production the managed downloads fail for a large share of devices. Our analytics for the first three days (7,384 devices started the download): 68% completed; 6% ended in a hard failure that retries do not fix; about 25% never completed (many runs were cancelled because the BGContinuedProcessingTask expired). Failure classes (unique devices): NSURLErrorDomain -3007 “Download decoding failed” (NSURLErrorDownloadDecodingFailedToComplete), thrown by ensureLocalAvailability: 186 devices. Only on iOS 26.4+ (26.4/26.5: about 7% of devices that started; 26.6.x: about 1.3%; none on iOS 26.0–26.3). Free disk space is not a factor (median 74 GB free on failing devices). Users also see “The operation couldn’t be completed. (ManagedBackgroundAssetsProcessingPipeline.ProcessingPipelineError error 1.)”. The daily rate jumped 5x on September 14 (34 to 166 devices per day). ensureLocalAvailability returns successfully, but the pack’s files are not in the app-group namespace: AssetPackManager.shared.contents(at:searchingInAssetPackWithID:) fails for a file that is definitely inside the pack: 178 devices. Calling ensureLocalAvailability again returns immediately with the same result. Deleting and reinstalling the app fixes it. NSXPCConnectionInterrupted (4097) “Couldn’t communicate with a helper application”, XPC.XPCRichError error 1, ManagedBackgroundAssetsXPC.XPCInvocationError error 1: 74 devices. Rebooting the device fixes it. Downloads that never deliver a single progress event (stuck at 0% for minutes on Wi-Fi and cellular): about 100 devices. “The asset pack <Asset Pack | ID: ea-skeletal-s1 download size: 161205935 version: 1> is unavailable” (25 devices) and AMSErrorDomain error 203 (12 devices). Affected devices range from iPhone 11 to iPhone 17 Pro Max and several iPad models, in Russia, the US, Brazil and Kazakhstan alike, so this is not a regional network issue. The same packs work fine on the majority of devices, and they were uploaded with xcrun altool --upload-asset-pack and processed without errors. Questions: Is there a known issue with pack decoding/extraction in the managed pipeline on iOS 26.4–26.6, or on the Apple-hosted CDN side? The September 14 spike looks like a server-side change. What is the recommended recovery when the daemon reports a pack as available while its files are missing on disk: remove(assetPackWithID:) and ensureLocalAvailability again? Is there any way for developers to see per-download server-side errors for their asset packs? We had to ship a hotfix that bundles the 3D content inside the app again. We can provide a sysdiagnose from an affected device (a Feedback Assistant report will follow), the bundle ID and pack IDs privately, and exact timestamps of failed downloads.

After upgrading my M1 MacBook Pro from macOS 26 to macOS 27, my NuPhy Kick75 Bluetooth keyboard started randomly disconnecting during normal use. This issue did not occur on macOS 26 with exactly the same Mac, keyboard, physical location, and usage environment. The problem started immediately after upgrading to macOS 27. The keyboard disconnects approximately 2–3 times per hour. When the interruption occurs, the Bluetooth connection indicator on the keyboard also shows that the Bluetooth link has been lost. This is therefore an actual Bluetooth disconnection rather than only input lag or delayed keyboard events. The keyboard automatically reconnects shortly afterward. macOS bluetoothd logs captured at the exact time of an occurrence confirm that the Bluetooth LE HID link is being disconnected. Hardware Mac: MacBook Pro with Apple M1 Keyboard: NuPhy Kick75 Bluetooth device name: Kick75 IO-2 Connection type: Bluetooth LE HID Regression macOS 26: No Bluetooth disconnections observed during long-term normal use. macOS 27: Random Bluetooth disconnect/reconnect events occur approximately 2–3 times per hour. No keyboard, firmware, physical location, or other hardware/environmental changes were made when the issue started. The behavioral change occurred immediately after upgrading the Mac from macOS 26 to macOS 27. Steps to Reproduce Connect a NuPhy Kick75 keyboard to an M1 MacBook Pro using Bluetooth. Use the keyboard normally for typing. Continue normal use for approximately one hour. At seemingly random intervals, keyboard input suddenly stops. At the same time, the keyboard's Bluetooth connection indicator shows that the Bluetooth link has been lost. macOS automatically reconnects to the keyboard shortly afterward. The same event can be observed in bluetoothd logs as an LE HID link disconnection. Frequency Intermittent but frequent. Approximately 2–3 occurrences per hour after upgrading to macOS 27. Expected Result The Bluetooth LE HID connection should remain stable during normal use, as it did on macOS 26. Actual Result The Bluetooth LE HID connection is unexpectedly terminated. macOS subsequently reconnects to the keyboard automatically. Relevant bluetoothd Log The following was captured during an actual disconnection at: 2026-09-15 17:47:44 Disconnect OI_HCI_LM_HANDLE: 0x55 (85) wakeUp: No RSSI: -37 -37 -37 -37 ... _GATT_LE_DisconnectedCB ... reason STATUS 708 LE Link disconnected ... reason 708 LE ConnManager disconnection complete reason 708 localRole=Central encrypted:1 linkReady:1 disconnectDevice:0 localRole:0 reason:708 result:307 Device disconnected - { devicename: Kick75 IO-2, result: 307 } App disconnected - { bundle: com.apple.BTLEServer, reconnecting: Y } macLeDeviceDisconnected: LE Connection disconnected. Device is a LE HID. BLE Disconnected Unspecified reason 708 Setting LeDevice to Compatible HID from Compatible HID The RSSI values immediately before the disconnection remained consistently around -37 dBm, indicating a very strong Bluetooth signal at the time the link was lost. The following fields appear consistently relevant to this event: reason:708 result:307 disconnectDevice:0 reconnecting:Y macOS also classified the keyboard as a Compatible HID. Related Community Reports This may not be isolated to the Kick75. There is an independent community report involving a NuPhy Air75 V3 on macOS 27 that describes very similar Bluetooth LE HID disconnections. That report has several notable similarities: The Air75 V3 disconnects repeatedly on macOS 27. The same keyboard reportedly operates normally on Windows and iOS 27. Other Bluetooth devices connected to the affected Mac reportedly remain stable. The reporter's macOS Bluetooth logs contain: Incompatible LE HID HID latency issue detected LE Link disconnected (reason 708) Another user reported the same problem with a NuPhy Air65 V3. NuPhy Support responded that they had adjusted Bluetooth parameters and optimized the Bluetooth connection interval, and offered a test firmware for further investigation. The original reporter later tested the same Air75 V3 over Bluetooth on a Mac running macOS 26 at an Apple Store and reported that it did not disconnect. The reporter also observed that having certain Apple Bluetooth HID devices connected at the same time could affect the frequency of the NuPhy disconnections. The community report is titled: “Air75 V3 randomly disconnects on macOS 27 Developer Beta (works perfectly on Windows & iOS 27)” I am including the link to that report with this feedback as supporting information. Importantly, that report involves different NuPhy hardware and a different Mac, but its LE Link disconnected (reason 708) log message closely matches the reason 708 observed independently on my Kick75. This suggests the issue may affect more than one NuPhy Bluetooth LE HID keyboard model under macOS 27. Summary My own reproducible observations are: Same M1 MacBook Pro Same NuPhy Kick75 Same physical environment Stable Bluetooth operation on macOS 26 Frequent disconnections immediately after upgrading to macOS 27 Approximately 2–3 disconnections per hour Keyboard Bluetooth indicator confirms actual link loss bluetoothd confirms an LE HID disconnection RSSI was approximately -37 dBm immediately before the disconnection macOS records reason 708, result 307, and subsequently attempts to reconnect An independent NuPhy Air75 V3 report on macOS 27 also contains LE Link disconnected (reason 708) Taken together, these observations suggest a possible Bluetooth LE HID compatibility regression introduced in macOS 27. I can provide additional Bluetooth diagnostics, a sysdiagnose, and reproduce the issue with Apple's Bluetooth debug logging profile enabled if required.

Hi there, I am working on a little application which processes cursor and graphics tablet data and adds some extra control to the output. So far it makes use of... if let eventTap = CGEvent.tapCreate(tap: .cgSessionEventTap, //.cghidEventTap place: .headInsertEventTap, options: .defaultTap, eventsOfInterest: eventMask, callback: handleTapEvent, userInfo: userInfo) ... to modify existing events. The issue that in some cases arises (it's a globally working app) - that some other applications pull and process pointer-data aside the event stream and therefor create conflicting values. Would creating and posting events to a 'virtual pointing device' on a lower system level (kext) help? Let's discuss. BR, E

Hello, I’m currently working on a project that implements Bluetooth Low Energy (BLE) 5 Extended Advertising. We are experiencing an issue specifically on iOS 18.6.2. The device is visible/scannable, but we are unable to establish a connection with it. Initially, our advertising interval was set to 2 seconds. We suspected that this interval might be too long for reliable discovery on iOS, so we reduced it to 100 ms. With the same firmware and advertising configuration: iOS 26.5.2: the device is discovered and a connection can be established successfully. iOS 18.6.2: the device can be detected/scanned, but the connection cannot be established. Could you please clarify whether there are any known limitations, restrictions, or differences in the handling of Bluetooth 5 Extended Advertising between iOS 18.6.2 and newer iOS versions? In particular, we would like to know whether iOS 18.6.2 has any specific requirements regarding: BLE Extended Advertising / LE Extended Advertising Primary and secondary advertising channels Advertising intervals PHY configuration (1M / 2M / Coded PHY) Connectable Extended Advertising We would also appreciate any documentation or known issues related to Extended Advertising on iOS that could explain why the same device and configuration works correctly on iOS 26.5.2. Thank you in advance for your help.

Hi, I am developing a Screen Time App and I am having issues with the ShieldConfigurationExtension (ShieldConfigurationDataSource). I know this extensions is sandboxed but I should be able to read data from the main app. I am using SwiftData as my database, but I am unable to initialize it in the extensions with an error indicating insufficient file permissions. I have App Group set up and I am able to share data using UserDefaults but that is just inconvenient. Is there any way I could just open the SwiftData in read only mode so that I could display the user some info on the shield? SwiftData Init: private func setupContainer() throws { let schema = Schema([ DogEntity.self, HouseEntity.self ]) // Use app group container if available let config: ModelConfiguration if let containerURL = FileManager.default.containerURL( forSecurityApplicationGroupIdentifier: "group.\(Bundle.app.bundleIdentifier ?? "")" ) { config = ModelConfiguration(schema: schema, url: containerURL.appendingPathComponent("default.sqlite")) } else { config = ModelConfiguration(schema: schema) } self.container = try ModelContainer(for: schema, configurations: [config]) } Error in extension: fault: Attempt to add read-only file at path file:///private/var/mobile/Containers/Shared/AppGroup/51431199-5919-4AE6-940C-6FE3C53EEB46/default.sqlite read/write. Adding it read-only instead. This will be a hard error in the future; you must specify the NSReadOnlyPersistentStoreOption. error: (3) access permission denied error: Encountered exception error during prepareSQL for SQL string 'SELECT TBL_NAME FROM SQLITE_MASTER WHERE TBL_NAME = 'Z_METADATA'' : access permission denied with userInfo { NSFilePath = "/private/var/mobile/Containers/Shared/AppGroup/51431199-5919-4AE6-940C-6FE3C53EEB46/default.sqlite"; NSSQLiteErrorDomain = 3; } while checking table name from store: <NSSQLiteConnection: 0x154100300> error: Store failed to load. <NSPersistentStoreDescription: 0x15402d590> (type: SQLite, url: file:///private/var/mobile/Containers/Shared/AppGroup/51431199-5919-4AE6-940C-6FE3C53EEB46/default.sqlite) with error = Error Domain=NSCocoaErrorDomain Code=256 "The file “default.sqlite” couldn’t be opened." UserInfo={NSFilePath=/private/var/mobile/Containers/Shared/AppGroup/51431199-5919-4AE6-940C-6FE3C53EEB46/default.sqlite, NSSQLiteErrorDomain=3} with userInfo { NSFilePath = "/private/var/mobile/Containers/Shared/AppGroup/51431199-5919-4AE6-940C-6FE3C53EEB46/default.sqlite"; NSSQLiteErrorDomain = 3; } Any help appreciated 🙂

Hello, I am investigating a roaming network selection use case on iPhone and would like to know whether Apple provides any supported API, entitlement, carrier capability, or carrier-specific integration that allows an application or a mobile network operator to access or control PLMN selection while roaming. My specific use case is: Device: iPhone 17 iOS: 26.6.1 Home operator: Orange France Roaming country: Switzerland Automatically selected roaming network: Salt Preferred roaming network: Swisscom At this location, Salt has very poor cellular coverage while Swisscom has excellent coverage. The user can manually select Swisscom through: Settings → Cellular → Network Selection → Swisscom I would like to determine whether there is any supported mechanism for a carrier or a carrier-authorized application to: Read the currently selected roaming PLMN. Obtain the available roaming PLMNs. Programmatically select a specific PLMN. Configure a preferred roaming PLMN. Ask the modem to prefer one roaming partner over another. Access any carrier-only/private entitlement that provides such functionality. For example, could an authorized Orange carrier application or carrier integration request that Swisscom (MCC 228 / MNC 01) be preferred over Salt (MCC 228 / MNC 03) while roaming in Switzerland? I understand that Core Telephony provides access to some carrier information and that certain capabilities require Apple-granted entitlements. If this functionality is not available to third-party applications, is there a carrier integration, carrier configuration, SIM/eSIM profile mechanism, or other Apple-supported mechanism that can influence the preferred roaming PLMN? I am specifically looking for a supported solution and not a jailbreak or other unsupported/private API. Thank you.

Hi, I’m developing a native macOS music app intended for the Mac App Store. We already support Audio Units and are investigating VST3 instrument and effect hosting on Apple Silicon. Users would install plugins themselves, typically in: /Library/Audio/Plug-Ins/VST3 ~/Library/Audio/Plug-Ins/VST3 The app would load these third-party plugin bundles using public APIs, such as CFBundleLoadExecutableAndReturnError. Plugins may be signed by developers with different Team IDs. Our app would not download or install them. Is there a supported way to load and execute these bundles while the hosting process remains sandboxed throughout? If so, which APIs and entitlements should we use? Specifically, I’m trying to distinguish permission to read a plugin bundle from permission to load its executable code. Would user selected folder access and security scoped bookmarks cover the sandbox access requirements, or is another mechanism needed? I understand that com.apple.security.cs.disable-library-validation addresses loading code signed by other developers, but does not itself grant sandbox file access. We cannot rely on an Audio Unit compatibility exception that disables the host’s sandbox. App Review Guideline 3.1.1 (https://developer.apple.com/app-store/review/guidelines/#in-app-purchase) explicitly allows Mac App Store apps to host plugins enabled outside the App Store. I’m looking for the supported technical approach under App Sandbox, rather than preapproval for our app. We’re checking this before implementation, so we don’t yet have a failing reproducer. Any relevant documentation, sample code or existing discussion would be appreciated. Thanks, Ben

I am developing an iOS application for carrier network testing and diagnostics, and I need to access the following cellular, carrier, subscriber, and device information: RSRP RSRQ SINR RSSI PCI Cell ID LTE/5G Band EARFCN / NRARFCN Carrier name Country code MCC MNC Mobile/subscriber number IMEI Enable/Disable/connect wifi Enable/Disable hotspot Insert/update/delete e-sim I understand that some or all of this information is not available through Apple’s public iOS APIs. My question is: If I request Apple’s Interoperability Access or a carrier-related entitlement for an application developed specifically for carrier network testing and diagnostics, can these APIs/data become available? If yes, could someone please clarify: Which of the above data points can be accessed with carrier-related entitlements? Which specific entitlements or APIs are required? Are RSRP, RSRQ, SINR, RSSI, PCI, Cell ID, Band, and EARFCN/NRARFCN available through any Apple-approved entitlement? Can carrier information such as carrier name, MCC, MNC, and country code be accessed? Is mobile/subscriber number accessible? Is IMEI accessible with a carrier entitlement? Is there a specific Apple WWDR/Interoperability request process for these requirements? This is for a legitimate carrier testing/diagnostics application. I would appreciate any clear guidance on what is technically possible on current iOS versions and which Apple approval/entitlement process I should follow.

I am not sure if it's from Xcode or macOS 27, but here is what I get after running df: /dev/disk3s3 228Gi 1.5Gi 15Gi 9% 112 161M 0% /Volumes/Recovery devices -- file:///Users/USER/Library/Containers/com.apple.CoreDevice.CoreDeviceService/Data/ 1.0Ti 0Bi 1.0Ti 0% 0 9.2E 0% /Users/USER/Library/Developer/CoreDevice/DeviceFS It's really annoying. Is there any way to remove this?

I'm seeing a recurring issue on macOS 26.5.2 (build 25F84) where the kernel's Sandbox/System Policy layer intermittently denies file access on NFS mount points from local network servers. Posting here in case anyone recognizes this pattern or has a workaround, and flagging it since I've also filed a Feedback Assistant report (with a live-captured sysdiagnose) for the same issue. WHAT HAPPENS Two independent NFS mounts to two separate, unrelated servers on my LAN start failing simultaneously with "Operation not permitted." The kernel log shows: kernel: (Sandbox) System Policy: mount_nfs(PID) deny(1) file-mount /path/to/mount Critically, it's not limited to the mount syscall - within the same few-second window, System Policy also denies ls, perl, diskutil, and even umount -f on the exact same path, for otherwise unrelated processes. So it looks like a transient, path-scoped kernel decision rather than something specific to NFS or the mount syscall. It self-heals anywhere from seconds to ~30 minutes later, then recurs - documented 30-80+ occurrences/day via a background watchdog script. WHAT I'VE RULED OUT Server-side cause: two independent servers on different hardware fail identically at the same instant. Network issue: checked network logs in the same window, no correlated connectivity event. Third-party kext conflict: kextstat shows zero third-party kexts loaded. syspolicyd database corruption: no "ASP: Validation category" signature present. TCC/Full Disk Access: already granted; the denying layer is kernel Sandbox "System Policy," not TCC. QUESTION Has anyone else run into System Policy denying file-mount/file-read-data/file-unmount on network volume paths intermittently like this? Is there any userland way to inspect or reset whatever internal state drives this decision (I haven't found one - no spctl/tccutil/sysctl lever that touches it)? Happy to share more log excerpts if useful.

Hello, We are testing Wallet passes with iBeacons in iOS 26 Beta. In earlier iOS releases, when a device was in proximity to a registered beacon, the corresponding pass would surface automatically. In iOS 26 Beta, this behavior no longer occurs, even if the pass is already present in Wallet. I have not found documentation of this change in the iOS 26 release notes. Could you please confirm whether this is expected in iOS 26, or if it may be a Beta-specific issue? Any pointers to updated documentation would be appreciated. Thank you.

I'm developing an iPad app where I want to annotate things on a pdf. I subclassed PDFAnnotation to drag text on a pdf. When I use Xcode 26 everything is working fine and everything is rendered perfect. But when I run the same code with Xcode 27 on iOS27 I get a pixelated annotation. iOS26 iOS27 The code: import UIKit final class ManualPlacementPreviewAnnotation: PDFAnnotation, DraggablePreviewAnnotation { private let text: String private let textFont: UIFont private let textColor: UIColor var isGrabbed = false init(bounds: CGRect, text: String, font: UIFont, color: UIColor) { self.text = text self.textFont = font self.textColor = color super.init( bounds: bounds.insetBy(dx: -PreviewAnnotationChrome.padding, dy: -PreviewAnnotationChrome.padding), forType: .freeText, withProperties: nil ) } required init?(coder: NSCoder) { text = "" textFont = .systemFont(ofSize: 12) textColor = .black super.init(coder: coder) } override func draw(with box: PDFDisplayBox, in context: CGContext) { context.saveGState() context.translateBy(x: 0, y: bounds.minY + bounds.maxY) context.scaleBy(x: 1, y: -1) let content = contentBounds UIGraphicsPushContext(context) NSAttributedString(string: text, attributes: [ .font: textFont, .foregroundColor: textColor, ]).draw(in: content) UIGraphicsPopContext() PreviewAnnotationChrome.draw(context, around: content, grabbed: isGrabbed) context.restoreGState() } } Is this a bug in iOS27 or am I doing something wrong?

I have a macOS app using NSPersistentCloudKitContainer with separate private and shared persistent stores and zone-wide CloudKit Sharing. The same Core Data model and sharing implementation work correctly in Development: the complete object graph is shared and bidirectional owner/participant synchronization works. In Production, however, sharing is stuck in a partially exported state. The owner has a complete and internally consistent Core Data object graph. fetchShares(matching:) reports the expected managed objects as belonging to the Production share. However, inspection of the Production shared CloudKit zone shows that many of the corresponding CKRecords were never exported. For example, the participant successfully imports records that actually exist in the shared zone, but entire expected record types such as CD_Missionary and CD_Area are absent from that zone. The Production owner's private persistent store repeatedly reports failed setup/export events. The relevant Core Data + CloudKit log pattern is: Never successfully initialized and cannot execute request due to error: CKErrorDomain Code=2 with an underlying: CKInternalErrorDomain Code=1011 I also correlated multiple failed Core Data export events with CloudKit server logs. Within seconds of the failed exports, CloudKit reports: Database: PRIVATE Operation: RecordDelete Overall Status: USER_ERROR Error: BAD_REQUEST Returned Record Type: _pcs_data The failure is reproducible across multiple export attempts. The Production shared zone itself exists and has zone-wide sharing enabled. The expected cloudkit.share record type is present in Production. I compared the visible Production and Development schemas, including cloudkit.share, and found no obvious record-type/field discrepancy. The important comparison is that Development sharing with the same model/implementation works correctly, while the existing Production mirroring/share state repeatedly fails. I have filed Feedback Assistant report FB24739413, including a sysdiagnose captured while the failure was active, Core Data/CloudKit event diagnostics, CloudKit server-log request IDs, store identifiers, zone information, and reproduction details. My main question is about recovery rather than diagnosis: What is the supported way to recover an existing Production NSPersistentCloudKitContainer share/mirroring state like this and cause the missing managed objects to be exported, without deleting or purging the owner's managed objects? I have deliberately not reset the Production environment, deleted/recreated the share, purged the shared zone, reset the owner's persistent store, or mass-modified the managed objects to try to force re-export. In particular, I understand that purgeObjectsAndRecordsInZone can delete the corresponding managed objects, so I do not want to use destructive recovery techniques without guidance. Is there a supported mechanism for rebuilding/reinitializing the Production mirroring/share state while preserving the owner's existing Core Data object graph, or is this a situation that requires intervention/instructions from Apple? Environment macOS 26.6.2 Core Data + NSPersistentCloudKitContainer CloudKit private + shared persistent stores zone-wide sharing Production failure only Development sharing works correctly Feedback: FB24739413

I had strange experience few days ago. After sending VoIP push notification request properly to APNs it took nearly 10 minutes to actually receive the Push notification. Could this be cause by other than network issues? (i.e. APNs issue or iOS issue)