Hi Apple Developer Support, I have performed additional experiments to investigate whether AccessoryControlDevice.current(for:) and update(_:) can be used from a custom ExtensionFoundation extension. The results have helped narrow down the issue. 1. Host app registration succeeds The host app successfully obtains the accessory from its AccessorySetupKit session and registers the placement capability: try await AccessoryControlDevice.register( accessory, capabilities: [.placement] )Log: [ASK] AAK 步骤0 ASK配件 id=22E9E2E0-46B4-9435-C0C2-4F16FB6A0568 name=Buds Pro 2 inSession=true sessionCount=1 placement=inEar state=authorized source=session.accessories sessionActivated=true caps=placement [ASK] AAK 步骤1(主App) register 成功 placement=inEar id=22E9E2E0-46B4-9435-C0C2-4F16FB6A0568The registration call completes successfully. 2. Custom ExtensionFoundation extension launches successfully I created a custom extension point using: AppExtensionPoint.Definition AppExtensionPoint.Bind AppExtensionPoint.Monitor AppExtensionProcess The host app successfully discovers the extension and launches it. Logs: [ASK][PLC] 扩展点构造成功 id=com.nothing.smartcenter.placement [ASK][PLC] Monitor 结果 identities=1 stateIdentities=1 unapproved=0 disabled=0 [ASK][PLC] 发现扩展 bundle=com.nothing.smartcenter.placement point=com.nothing.smartcenter.placement [ASK][PLC] AppExtensionProcess 创建成功 [ASK][PLC] XPCSession 创建成功 [ASK][PLC] XPCSession activate 成功 [ASK][PLC] sendSync 成功 —— 扩展已响应，进程确实起来了Therefore, the custom extension is installed, discovered, launched, and able to communicate with the host app through XPC. 3. AccessoryControlDevice.current(for:) still fails inside the extension Inside the running extension, I obtain the accessory from its AccessorySetupKit session. The session contains one accessory. However, calling: let device = try await AccessoryControlDevice.current( for: accessory )consistently fails with: AccessoryControlDevice.Error.invalidated Request invalidatedLogs: [ASK][PLC] 实验3-current 请求已送达 op=probe worn=false [ASK][PLC] e3 扩展回传： ask-session 复用 count=1 [ASK][PLC] e3 扩展回传： current FAIL AccessoryControlDevice.Error.invalidated desc=Request invalidatedThe same result occurs when attempting the placement update experiment: [ASK][PLC] 实验4-offHead 请求已送达 [ASK][PLC] e4off 扩展回传： ask-session 复用 count=1 [ASK][PLC] e4off 扩展回传： current FAIL AccessoryControlDevice.Error.invalidated desc=Request invalidatedBecause current(for:) fails, I have not yet been able to verify whether update(_:) itself works. 4. Questions for Apple I would appreciate clarification on the following points: Does AudioAccessoryKit support custom ExtensionFoundation extensions? Specifically, are extensions created using AppExtensionPoint.Definition and AppExtensionPoint.Bind, and launched through AppExtensionPoint.Monitor and AppExtensionProcess, considered valid app extensions for AudioAccessoryKit? Does AccessoryControlDevice.current(for:) require a specific system-defined extension point or extension type, rather than a custom extension point? Does AudioAccessoryKit require any additional entitlement, capability, extension configuration, or authorization for current(for:) to succeed? Is the ASAccessory instance required by current(for:) expected to be obtained from the same ASK session used by the host app during register(), or can the extension obtain the accessory from its own ASK session? What does AccessoryControlDevice.Error.invalidated / Request invalidated specifically indicate in this situation? Is there a way to obtain more diagnostic information about why the request was invalidated? Is there an official sample project demonstrating the complete integration of AccessorySetupKit, AudioAccessoryKit placement updates, and the required app extension? Environment iOS: 26.4 Accessory: Nothing Ear / Buds Pro 2 (internal model B172) Frameworks: AccessorySetupKit, AudioAccessoryKit, ExtensionFoundation, CoreBluetooth Host app bundle ID: com.nothing.smartcenter Custom extension point: com.nothing.smartcenter.placement At this point, BLE communication, AccessorySetupKit pairing, host-side AudioAccessoryKit registration, extension discovery, extension process launch, and XPC communication are all working. The remaining blocker is that AccessoryControlDevice.current(for:) returns Request invalidated even when called inside the successfully running custom extension. Could you please clarify whether this custom ExtensionFoundation architecture is supported by AudioAccessoryKit, or whether a specific Apple-defined extension type is required? Thank you for your help.

Hi everyone, I'm developing a third-party Bluetooth audio accessory and investigating AudioAccessoryKit placement updates on iOS 26.4. My goal is to update the accessory's wearing state (for example, .inEar / .offHead) based on BLE notifications from the accessory. Implementation flow Pair the Bluetooth accessory using AccessorySetupKit. Obtain the paired ASAccessory. Register the accessory in the host app: try await AccessoryControlDevice.register( accessory, capabilities: [.audioSwitching, .placement] )Attempt to retrieve the registered device: let device = try await AccessoryControlDevice.current(for: accessory)However, current(for:) consistently fails with: AccessoryControlDevice.Error.invalidated Request invalidatedBLE communication status The BLE communication itself appears to be successful. The following logs show that the command was sent and the accessory returned a response: [ASK] cmd didWrite ok 68745353-1810-4B13-83A2-C1B21B652C9B notifying=false [ASK] cmd toSend mac=2a:e6:e7:eb:be:2c model=B172 bytes=5560014FC000000F status=connected shaking=false [ASK] cmd write direct mac=2a:e6:e7:eb:be:2c bytes=5560014FC000000F chars=10 peripheral=2 delegate=Optional<CBPeripheralDelegate> connected=connected [ASK] cmd reply ok uuid=CA235943-1810-45E6-8326-FC8CA3BC45CE bytes=5560014F4001000F [ASK][PLC] Experiment 4 - inEar request delivered, op=update worn=true [ASK][PLC] Experiment 4 - inEar current baseline: current FAIL AccessoryControlDevice.Error.invalidated desc=Request invalidatedThe BLE command is successfully delivered to the accessory, and the accessory responds. However, the AudioAccessoryKit API still returns invalidated. Questions Does AccessoryControlDevice.current(for:) require a specific app extension context, entitlement, or authorization? Is it expected to call current(for:) from the host app, or must it be called from an app extension? Does registering .placement and .audioSwitching in the host app guarantee that the accessory can subsequently be retrieved using current(for:)? Are there any additional requirements for the accessory, firmware, or system-side registration before current(for:) can succeed? Is there a known issue with AccessoryControlDevice.current(for:) returning Error.invalidated on iOS 26.4? I understand that AccessoryControlDevice.update(_:) is documented as an API that must only be called from an app extension. I'm trying to determine whether the failure of current(for:) in the host app is expected behavior or indicates a registration/configuration problem. Any sample code, implementation guidance, or clarification from Apple engineers would be greatly appreciated. Thanks!

Hi everyone, I'm experiencing an unusually long delay with the App Review process and would appreciate some guidance from the developer community or Apple team. Submission Timeline October 14, 2026 – 1:38 PM: Submitted the app for review for the first time. The submission remained in "Waiting for Review" for nearly two weeks, with no updates or communication from Apple. October 27, 2026 – 1:51 PM: Removed the previous submission and submitted it again. October 30, 2026: The latest submission is still showing "Waiting for Review", with no progress. Concerns and Questions Is it normal for an app to remain in "Waiting for Review" for this long without being assigned to a reviewer? Does removing and resubmitting an app affect its position in the review queue? Is there any way to request manual escalation or have the review expedited? Could this be related to an account-level issue or a problem with the submission? The delay is significantly affecting our planned launch. We understand that Apple handles a large volume of submissions, but waiting for over two weeks without any update is concerning. I've already contacted Apple Developer Support and requested an escalation. However, I'd like to understand whether other developers are experiencing similar delays recently. Has anyone faced this situation recently? Did contacting Apple Developer Support help resolve it, or is there another recommended way to get the review process moving? Any suggestions or insights would be greatly appreciated. Thank you!

Hello Apple Developer Community, We are developing a hardware diagnostic solution consisting of a macOS desktop application and a companion iOS application. Our iOS application is currently distributed through Apple TestFlight for testing purposes. The application installs and functions correctly when users download it manually through TestFlight. However, we are facing an issue when attempting to automatically install the same iOS application onto iPhones connected to our macOS application via USB. Our Intended Workflow A user connects one or multiple iPhones to a Mac using USB cables. Our macOS application automatically detects the connected devices. The macOS application initiates installation of our iOS diagnostic application onto the connected iPhones. The iOS application performs hardware diagnostic tests. Test results are transferred back to the macOS application. Once testing is completed, the iOS application can be removed from the connected devices. Current Issue When installing the iOS application manually through TestFlight, everything works correctly. However, when attempting to install the application programmatically from our macOS application over USB, we encounter a developer recognition or trust-related error. Our objective is to support commercial hardware diagnostic testing on customer-owned iPhones without requiring users to manually install the application, enable Developer Mode, trust developer certificates, or register individual device UDIDs. Questions Is there an officially supported Apple API, framework, or method that allows a macOS application to programmatically install an iOS application onto USB-connected iPhones? Is this functionality available for applications distributed through TestFlight, or does it require an App Store production release? Can installation be initiated on customer-owned, unmanaged iPhones without requiring Developer Mode, manual certificate trust, or device registration? Are there specific code-signing, provisioning profile, or distribution requirements for installing an iOS application through USB? Does Apple provide a supported solution for deploying diagnostic applications to multiple USB-connected iPhones simultaneously? If direct USB installation is restricted, what alternative Apple-supported workflow would be recommended for commercial device diagnostic and refurbishment applications? Additional Information Our iOS diagnostic application and macOS desktop application have already been developed, and the core diagnostic functionality is working. The remaining challenge is determining the correct Apple-supported method for installing the iOS companion application automatically onto connected devices. We would appreciate guidance from Apple engineers or developers who have experience with USB-based iOS application deployment, device management, or commercial diagnostic solutions. Thank you for your assistance.

This is a question about expected behaviour rather than a bug. Environment iOS 26.x on iPhone 17 Pro Xcode 27. Swift, SwiftUI Declared Age Range capability enabled Context Our app is currently available without age restrictions. Starting in January 2027, we plan to restrict access by age in regulated US jurisdictions using the Declared Age Range API, and treat .declinedSharing as "age unknown." Before rolling this out, we want to understand what existing users will experience. Apple's June 3, 2026 developer news says "new Apple Accounts in Texas are now subject to the law." We couldn't find documentation on how the API behaves for Texas accounts created before that date. Code @Environment(\.requestAgeRange) private var requestAgeRange // ... let response = try await requestAgeRange(ageGates: 16, 18) switch response { case .sharing(let range): // use range.lowerBound / range.upperBound / range.ageRangeDeclaration case .declinedSharing: // treat as age unknown @unknown default: break }Questions For a Texas Apple Account created before June 4, 2026, on iOS 26.x, will requestAgeRange show the age range sheet, as it would in a nonregulated region? If the sheet is shown and the user declines to share: a. Where can they change that decision afterwards? Only under the Apple Account (Settings > [name] > Personal Information > Age Range for Apps), or also on the app's own page (Settings > Apps > [app] > Age Range for Apps)? b. Can the app show the sheet again by calling requestAgeRange, or does it return the cached .declinedSharing without UI until the user changes the setting? c. Is there a supported way to deep-link the user directly to that setting from the app? Thanks!

Since iOS/iPadOS 27.0 (also macOS 27.0), saving a PDF with PDFDocument.dataRepresentation() (or write(to:)) writes every stream whose raw length is 0 as an empty indirect object: 6 0 obj endobjThat object is null, not a stream. When it is referenced from a page's /Contents array, Adobe Acrobat/Reader renders the whole page blank. Browser PDF viewers tolerate it, so the corruption is easy to miss. qpdf --check reports empty object treated as null and ignoring non-stream in an array of streams. No edits are needed to trigger it. Zero-length content streams are legal and fairly common; for example, PDFs generated by TallComponents PDFKit.NET contain a << /Filter /FlateDecode /Length 0 >> content stream on every page. In our case users sign such documents in an iPad app (custom PDFAnnotation) and we upload the result of dataRepresentation(); on iPadOS 27 every one of them opens blank in Acrobat. Minimal repro (builds a 1-page PDF whose /Contents is [text stream, zero-length stream], then re-serializes it): import PDFKit func minimalPDF() -> Data { let objects = [ "<< /Type /Catalog /Pages 2 0 R >>", "<< /Type /Pages /Kids [3 0 R] /Count 1 >>", "<< /Type /Page /Parent 2 0 R /MediaBox [0 0 595 842] /Resources << /Font << /F1 5 0 R >> >> /Contents [4 0 R 6 0 R] >>", "<< /Length 36 >>\nstream\nBT /F1 24 Tf 72 700 Td (Hello) Tj ET\nendstream", "<< /Type /Font /Subtype /Type1 /BaseFont /Helvetica >>", "<< /Length 0 >>\nstream\n\nendstream", // legal zero-length stream ] var pdf = "%PDF-1.7\n", offsets: [Int] = [] for (i, body) in objects.enumerated() { offsets.append(pdf.utf8.count) pdf += "\(i + 1) 0 obj\n\(body)\nendobj\n" } let xref = pdf.utf8.count pdf += "xref\n0 \(objects.count + 1)\n0000000000 65535 f \n" offsets.forEach { pdf += String(format: "%010d 00000 n \n", $0) } pdf += "trailer\n<< /Size \(objects.count + 1) /Root 1 0 R >>\nstartxref\n\(xref)\n%%EOF\n" return Data(pdf.utf8) } let saved = PDFDocument(data: minimalPDF())!.dataRepresentation()! print(String(decoding: saved, as: UTF8.self).contains("obj\nendobj") ? "BROKEN: null object written" : "OK")iOS 18.1: OK (PDFKit re-renders the page through Quartz). iOS 27.0 (24A5370g) / macOS 27.0 (26A428): BROKEN. With CG_PDF_VERBOSE=1 CoreGraphics logs writeStream: Failed to get data from stream. What triggers it: only the raw (encoded) length being 0. It happens with or without /Filter /FlateDecode, for a single /Contents stream, and for a zero-length Form XObject. A FlateDecode stream holding an 8-byte compressed empty payload (decoded length 0) is written correctly, so it is not about the decoded data. Where it seems to come from: iOS 27 introduced a structure-preserving serializer in CoreGraphics (CG::PDFDocumentSerializer). Its writeStream emits N 0 obj, asks for the stream's raw bytes, and when that returns NULL it logs the error above, skips the dictionary/stream/endstream, but still emits endobj. A legal empty stream returns NULL there, so it is treated as a read failure. Workaround we ship: after dataRepresentation(), find the empty objects (N G obj immediately followed by endobj) that are referenced from a page's /Contents, and append an incremental update that redefines them as << /Length 0 >>\nstream\n\nendstream, with a new xref section and a trailer whose /Prev points at the original startxref. The original bytes are untouched, so signatures/annotations written by PDFKit stay as they are, and files from iOS 18 (which contain no such objects) are returned unchanged. Filed as FB25282060. If you hit this too, please file a duplicate referencing that number. Possibly related iOS 27 save-path regressions: https://developer.apple.com/forums/thread/851708 (16-bpc annotation images truncated).

Hello, We are developing a macOS application with many different components that are required for our business features. We distribute the product outside the App Store and sign it with our Developer ID certificate. Rebranding an app is a rare case, but sometimes it happens. My question is: Does Apple have any guide or recommendations on how to rebrand an app properly, other than distributing a completely new product? I am asking because our application has a complex structure: UI app (MyApp1, bundle ID = com.myApp1.osx.app) Helper tool (MyApp1HelperTool, bundle ID = com.myApp1.osx.HelperTool) Privileged daemon (MyApp1Daemon, bundle ID = com.myApp1d) System Extension, Transparent Proxy (MyApp1Proxy, bundle ID = com.myApp1.osx.proxy) As you can see, the brand name is used not only in the bundle and product names, but also in the bundle IDs. At some point, I need to change the product name from MyApp1 to MyApp2. Ideally, I would also like to change the bundle IDs to match the new brand. After rebranding, end users should not see MyApp1 anywhere in the system, only MyApp2. Also, components that are already installed and approved (System Extension, proxy configuration, helper tool, etc.) should stay approved. We would like to avoid showing the approval prompts again to all our end users. I did some research and found that bundle IDs technically cannot be changed. To solve this, I would need to release a new app and implement an in-app update mechanism that updates MyApp1 to MyApp2. However, even with a new app and an in-app update mechanism, I did not find a way to avoid user prompts for approving the new extension, the proxy, and possibly the privileged helper tool. For macOS, these will be new components that require explicit user approval. MDM is not a solution for us: some of our customers use MDM, but many of them do not. We want the update to be as smooth as possible. Thank you!

Hello dear Apple Devs, I have an open feedback which didn't get any attention yet. It is a regression that appeared with iOS27. Simple url schemes like sms:, mailto: and tel: are not getting recognized anymore by iOS with the system NFC reader. The docs still say they are available and supported. Right now this leads to frustration because users reporting this to me and I can't do much more than giving feedback. Can anyone please look into this? FB24975241

The Problem On opening a PDF document in the Preview app, PDF widget annotations appear pixelated/rasterized. This problem exists with button, text, and choice widget subtypes. The pixelation becomes more apparent when zoomed in. Expected Results PDF widgets should appear sharp and smooth, without pixelation. In previous versions of the Preview app, widgets appear vector-based as expected. Impact on User Experience PDF widgets appear pixelated and inconsistent with text content in the same PDF document. Widgets do not look like elements of an interactive form but, instead, resemble low-quality embedded images. Affected Apps/OSs: Preview 11.0 (1147), as well as other apps that use PDFKit, on macOS Golden Gate 27.0 (26A428). A similar problem appears to affect PDFKit on iOS 27.0 and iPadOS 27.0 as well. Feedback/bug report: FB24843022

The Problem When a user toggles radio buttons or checkboxes in a PDF using Preview, the widgets disappear following subsequent interactions after the file is saved and reopened. This renders the form fields unusable. Steps to Reproduce the Problem Open a PDF with radio buttons or checkboxes in Preview. Toggle a radio button or checkbox. Save and close the file. Re-open the PDF in Preview. Toggle the same button again. The button (and any others with the same field name) will disappear. Expected Results Toggling a radio button or checkbox should update the field value without causing the button (or related buttons) to disappear. This behavior is consistent with previous versions of PDFKit. What is Happening In Preview, interacting with radio buttons and checkboxes correctly updates their appearance as expected. Saving the PDF, however, causes the appearance dictionary to reference a new N entry that is a single appearance stream unassociated with any state. The annotation's AS entry is not updated. The original N entry remains but is no longer referenced. Subsequent interactions fail to update the visual presentation because the appearance stream is missing. Impact on User Experience Radio buttons and checkboxes may disappear and become unusable when toggled. PDF documents become irreparably altered after a button is toggled and the file is saved. PDF file size significantly increases when the file is saved. Users may believe they have successfully completed a form, only for the data to become inaccessible or invisible to recipients. Forms may need to be completely restarted or recreated from scratch if the original becomes unusable. The corrupted PDF structure might cause the file to render incorrectly or crash in third-party PDF viewers. Affected Apps/OSs Tested with Preview 11.0 (1147), as well as other apps that use PDFKit, on macOS Golden Gate 27.0 (26A428). This problem also affects PDFKit on iOS 27.0 and iPadOS 27.0. Feedback/bug report: FB24866826 Related Sample Output Original PDF File Checkbox widget annotation (6 0 obj), its appearance dictionary (17 0 obj), and normal appearance dictionary (18 0 obj). Button is not checked. 6 0 obj << /Border [ 0 0 0 ] /Rect [ 90 390 110 410 ] /T (button1) /F 4 /Subtype /Widget /DA (/.AppleSystemUIFont 13 Tf 0 g) /MK 16 0 R /C [ 0 ] /AP 17 0 R /V /Off /M (D:20260919225320Z00'00') /AS /Off /FT /Btn /Type /Annot /Ff 0 >> endobj 17 0 obj << /N 18 0 R >> endobj 18 0 obj << /Yes 20 0 R /Off 22 0 R >> endobj PDF File after Save Checkbox widget annotation object (6 0 obj), its new appearance dictionary object (8 0 obj), a new normal appearance stream object (20 0 obj), and the original appearance stream dictionary (now 21 0 obj). File saved after user checked button. 6 0 obj << /Ff 0 /Type /Annot /AS /Off /AP 8 0 R /MK 9 0 R /C [ 0 ] /FT /Btn /M (D:20260919225320Z00'00') /DA (/.AppleSystemUIFont 13 Tf 0 g) /Subtype /Widget /F 4 /Border [ 0 0 0 ] /Rect [ 90 390 110 410 ] /T (button1) /V (Yes) >> endobj 8 0 obj << /N 20 0 R >> endobj 20 0 obj << /Filter /FlateDecode /Resources << /ColorSpace << /CS1 [ /ICCBased 29 0 R ] /CS2 [ /ICCBased 30 0 R ] >> >> /BBox [ 0 0 20 20 ] /Type /XObject /Subtype /Form /Length 123 >> stream x UéA ¬0 Ô}≈|†≈nà¢úÛÇ* —SA =}Ïr(»ñµ≤w◊€YËà’|ÙÎŒç'óRï∂#SäÏÌü∞¢S‰Ì§ôRÌX }–É•åY Éçˆ BŒ H " *â´8™ˆZø6z⁄ÿ ”ú6ɀ੠"∫t˘‹;'¬ endstream endobj 21 0 obj << /Off 22 0 R /Yes 23 0 R >> endobj Note: No object references 21 0 obj in the PDF.

Since iOS 27.0, domain-bound SMS one-time codes are no longer offered above the keyboard in our app, where the code is entered on a web page in a WKWebView, although the app is associated with the domain through webcredentials. The same SMS is offered in Safari on the same device, and it is offered in our app on iOS 26.6 and iOS 18. SMS format (last line per the domain-bound code format): Your verification code is: 123456 @app.example.com #123456Setup Several builds of the same app with different bundle IDs (App Store, internal, development), all under one team Entitlement com.apple.developer.associated-domains: webcredentials:app.example.com (plus two more environments of the same domain) AASA at https://app.example.com/.well-known/apple-app-site-association: 200, application/json, no redirect, same content on app-site-association.cdn-apple.com: {"webcredentials":{"apps":["TEAMID.com.example.app","TEAMID.com.example.app.internal","TEAMID.com.example.app.dev"]}} The code field is an <input type="tel" autocomplete="one-time-code"> in a WKWebView showing a page on that domain. We also tested a native field with the one-time-code content type (the app is built with Flutter; the field is a Flutter TextField with the one-time-code autofill hint). Steps Open the verification page in the app and focus the code field. Receive the SMS above. Expected: the code is offered in the QuickType bar, as it is in Safari on the same domain and as it is in our app on iOS 26.6 and iOS 18. Actual: nothing is offered. The keyboard log: kbd Received verification code from Messages kbd One Time Code field has been entered. kbd Retrieving Current One-Time Codes for App kbd Current verification code is domain-bound to <mask.hash: '…'>. kbd Domain-bound verification code is NOT valid for app <mask.hash: 'X'>. E kbd Could not fetch application record for application identifier: <mask.hash: 'X'>. kbd Returning 0 available one-time codesWhat we checked swcd downloads the AASA for all domains without errors after a reinstall. The installed app's entitlements (read from the device) contain the expected application-identifier and associated domains; the profile is validated. The failure is the same in the WKWebView field and in a native one-time-code field, in the App Store build, a distribution-signed internal build and a development build, and in an older app version that used to work. The masked application identifier in the log (X above) is the same for two builds with different bundle IDs, so the lookup does not seem to use the app's bundle ID. All our builds share CFBundleExecutable = Runner (the Flutter default) and the same CFBundleName. The same app build and the same SMS work on iOS 26.6 and iOS 18.x, so the change happened between iOS 26.6 and 27.0. An SMS without the @domain #code line is offered in the app on iOS 27 (Returning 1 available one-time code), although Could not fetch application record is still logged. Questions Is this a known iOS 27 regression, or is there a new requirement for apps to receive domain-bound codes? What application identifier does the keyboard use for this lookup, and can anything in the app's configuration (for example the executable name) affect it? Device: iPhone 17 Pro Max, iOS 27.0

Since iPadOS 27, Apple Pencil strokes that were drawn and saved through the system markup UI in QLPreviewController can no longer be erased with the pixel eraser once the PDF is saved and reopened. They can only be selected and deleted as whole annotations. On iPadOS 26 the same flow kept saved strokes erasable. Reproduction (no custom code needed — Files app shows it too): Files app → long-press a PDF → Quick Look → Markup Draw a few strokes with Apple Pencil, tap Done/save Reopen the same PDF in Quick Look → Markup Eraser (Erase Strokes mode) does nothing on the saved strokes The same happens in our app, which presents PDFs via QLPreviewController with editingModeFor = .createCopy. Newly drawn strokes in the current session erase fine; only saved-and-reloaded ones are affected. The new Preview app is NOT affected — the same PDF edited there stays fully re-editable. Digging into the saved files: Quick Look writes each stroke as a /Stamp annotation whose /AAPL:AKExtras contains only legacy AnnotationKit data (AKAnnotationObject with a flattened AKImageAnnotation, or AKAnnotationV2/AKInkAnnotation2) — and no /PPK entry. The Preview app embeds the PencilKit drawing data (/PPKType = "draw", /PPK with a "crdt" stream, plus page-level /AAPL:PPK + /AAPL:PPKHash), which is what makes its output re-editable. It looks like the iPadOS 27 markup editor only restores erasable strokes from /PPK, while the Quick Look save path still writes the old format — so Quick Look can no longer round-trip its own output. Questions: Is this an intentional behavior change or a regression? I couldn't find anything in the iPadOS 27 release notes about Quick Look / markup persistence. Is there any way for a host app to opt QLPreviewController's markup into the new PencilKit-based persistence?

We are seeing a reproducible behavior change with ManagedSettingsStore.application.blockedApplications on iOS 27.0 (24A437), iPhone 17 Pro, under .individual Family Controls authorization. On iOS 26, hiding an app and later removing the block restored it to its original Dock, Home Screen, or folder position. On iOS 27, the app may reappear elsewhere on the Home Screen, outside its original folder, or only in App Library, requiring manual "Add to Home Screen." We tested setting blockedApplications to nil and [], clearAllSettings(), and deactivating a named store; none reliably preserved placement. Notably, the same symptom reproduces with no third-party API involved at all using iOS's own built-in "Hide" feature (long-press an app -> Require Face ID -> Hide, then later un-hide it) also fails to restore the app to its original Dock, Home Screen, or folder position. This suggests a more general placement-restoration regression in iOS 27, not something specific to ManagedSettings. Has anyone else reproduced either of these? Is this an expected iOS 27 behavior change, or a SpringBoard regression? Filed as FB25044883.

Hello, I’m developing a native macOS application intended for Mac App Store distribution, with App Sandbox enabled. The intended feature is to let users connect their personal iPhone or iPad via USB, read the existing Home Screen layout, rearrange app icons and folders on the Mac, and apply the user-approved layout back to the device. The target devices are ordinary, non-supervised consumer devices, without MDM enrollment. Our current prototype detects the connected iPhone through public IOKit registry APIs. It does not access the Home Screen layout or modify the device. I have reviewed USB access entitlements and the device-management HomeScreenLayout payload, but have not identified a public API for this consumer-device workflow. Is there a public, supported API or documented integration mechanism for reading and updating these Home Screen layouts from a sandboxed macOS app? If supported, which framework and entitlements should we use? We would also need to understand any limitations around preserving folders, Dock contents, widgets, and empty icon positions. If this capability is not available through public APIs, could you clarify that limitation and the appropriate channel for submitting an enhancement request? This is a question about technical API availability, rather than a request for advance App Review approval. Thank you.

Our app uses the Family Controls framework for individual (self) device management. Separately, it estimates how much a user scrolls from CoreMotion accelerometer data (CMSensorRecorder) with an on-device Core ML model. Today, no Screen Time data leaves the device. We'd like to add an opt-in feature where a user compares results with friends they explicitly invite, and we want to stay within DPLA section 3.3.3(P) ("You and Your Application may not share device or usage data received through the Family Controls Framework or otherwise, beyond … the individual and their device"). Is it acceptable to share, only with invited friends (opt-in), a daily scroll-distance estimate that is computed solely from accelerometer data and never uses DeviceActivity or other Family Controls data? On the device only, we could use DeviceActivityMonitor threshold events to calibrate our accelerometer-based estimate against that user's screen time (the calibration and the threshold data never leave the device). Would sharing the resulting estimate (for example, "estimated minutes") with invited friends count as sharing usage data received through Family Controls, and therefore not be allowed? Would sharing only an outcome derived on device from DeviceActivity threshold events (for example, win/lose or goal met/not met) count as sharing device or usage data under 3.3.3(P)? We understand App Review can't pre-approve features. We're looking for guidance on how to interpret this section.

Hi everyone, I’m the developer of one sec, an app used by a large number of users globally to reduce time spent on social media and to build healthier digital habits. Because of this, we rely heavily on Apple’s Screen Time / DeviceActivity / FamilyControls, ManagedSettings APIs – and unfortunately, we’re seeing increasingly severe issues in production that directly impact hundreds of thousands of real iOS users. During the past years, we have been busy filing dozens of feedback requests for different Screen Time issues – and there has been no response from Apple at all. Developer Relations might be able to "confirm" that the bugs are present and that they ended up with the right team – but they are never addressed, neither are workarounds provided. Instead, the situation gets worse and worse. iOS 26 introduced a series of heavy regressions (which have been reported via Apple’s official bug report tool "Feedback Assistant" on iOS 26 beta 1 in June 2025 – and have not been addressed 10 Months later). This is very frustrating for us as developers, but also for our end-users who run into these issues every day. In the end this impacts our ability to build an amazing product and hurts revenue (which affects both us and Apple). 1. DeviceActivity thresholds are not firing at all This affects both: our app’s usage of the API and Apple’s own Screen Time limits Radars: FB22304617, FB20526837, FB15491936, FB12195437, FB15663329, FB18198691, FB18289475, FB19827144 2. Screen Time usage data is clearly corrupted Websites showing hundreds of hours per week Up to ~20 hours per day of usage reported for a single domain Radars: FB22304617, FB17777429, FB18464235 3. DeviceActivity thresholds reaching threshold immediately Newly introduced with iOS 26 Reported on iOS 26 beta 1 in June No response so far / no workaround DeviceActivity calls didReachThreshold immediately after creating the DeviceActivityEvent – instead of waiting till the defined threshold is actually reached. Radars: FB13696022, FB18351583, FB21320644, FB18927456, FB18061981 4. Randomly Randomizing ApplicationTokens From time to time, and without consistency, Screen Time suddenly provides new, random, unknown tokens to my app in the ShieldConfigurationDataSource and ShieldActionDelegate. This has been reported on many times before here on the dev forms, many many years back already: https://forums.developer.apple.com/forums/thread/756440 https://forums.developer.apple.com/forums/thread/758325 https://forums.developer.apple.com/forums/thread/758325?answerId=793267022#793267022 Radars: FB14082790 and FB18764644 5. Moving Tokens from one ManagedSettingsStore to Another Removing an ApplicationToken from one SettingsStore and then adding it to another while the target app remains in foreground leads to the re-use of the ShieldConfiguration. Which can be wrong in many scenarios. It is not possible to request a re-request of the ShieldConfiguration in that scenario. Radar: FB14237883 6. Unable to Open Parent App (one sec) from Shield Many times, when a target app is blocked by a shield, the user wants to perform some action (e.g. to unlock more time for the target app via an intervention). That means, that somehow I have to forward the user from a ShieldActionDelegate back into my target app. Unfortunately, there’s no API for that. Many apps on the App Store rely on private API to achieve that, but that’s too risky for a popular app like one sec. Radar: FB15079668 7. Unable to Open Target App from an ApplicationToken When a user has completed an intervention within one sec, and they indend to to continue to the target app, there is no way that one sec can open the target app just from the token alone. Sure, there are URL schemes, but that means the user has to manually assign URL schemes to each ApplicationToken. That is not a very user friendly process (and in many cases impossible, because not every app registers URL schemes). It would be better if there was a way that my app could open a target app directly from an ApplicationToken, e.g. via an AppIntent that can be run on a button press. This way, the selected apps would remain fully private while still offering advanced functionality: struct OpenTargetAppIntent: AppIntent, OpenAppFromApplicationTokenIntent { func perform() { return .result(openAppFromApplicationToken: applicationToken) } } Radar: FB15500695 Summary Thanks a lot for taking the time to read my feedback. If you have any questions, please feel free to reach out to me any time. I’m always happy to provide more details, logs, and steps to reproduce in my radars / feedback requests or in-person in Cupertino. It would be extremely helpful if someone from the Screen Time / DeviceActivity engineering team could: Take a look at the listed radars. Work on bug fixes and be transparent about when fixes will be shipped. Provide workarounds in the meantime. We genuinely want to build great, reliable experiences on top of Screen Time – but in its current state, it’s becoming very difficult to depend on. – Frederik

A screen time app I'm making has started telling users that their limit was reached even when they're far below their limit for the day (sometimes even at 0 minutes for the day). This issue only started happening after upgrading my software to iOS 26.2. Is this happening to anyone else? If so how have you found any solutions or does anyone know of any changes that could be causing this? Any help would be appreciated.

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.

We're bringing our CallKit-based VoIP app to the Mac with Mac Catalyst. Incoming calls work fine. For outgoing calls we request a CXStartCallAction (audio only, isVideo = false), the provider fulfills it and the call connects. But at the moment the call starts dialing, macOS launches FaceTime.app, which turns on the camera preview and shows its own call screen for our call ("no video"). When the call ends, FaceTime stays open and the camera stays on until FaceTime is quit manually. The system log shows callservicesd deciding to launch the in-call application for our call: callservicesd _shouldLaunchInCallApplicationForCall: 1 callservicesd Opening URL: <private> for call <private> CoreServicesUIAgent LAUNCH: ... com.apple.FaceTime starting stopped process.Reported as FB25284357 (macOS 27.0.1, Xcode 27.1). Is this expected for third-party CallKit providers on macOS? Is there a supported way to keep the call in our own app without dropping CallKit for outgoing calls?

Setup Parent device: FamilyActivityPicker with a selection created as FamilyActivitySelection(includeEntireCategory: true). The parent selects apps for an always-on block list. The selection is encoded with PropertyListEncoder and sent to our server. Child device: authorized with AuthorizationCenter.shared.requestAuthorization(for: .child). It receives the selection, decodes it, and immediately applies its application tokens. The shield stays on all day, with no schedule: let selection = try PropertyListDecoder().decode(FamilyActivitySelection.self, from: data) ManagedSettingsStore(named: .appBlock).shield.applications = selection.applicationTokensObserved Cases A and B use the same two physical devices with the parent and child roles swapped. In all cases, the Family Sharing group uses legacy Screen Time, because not every device is on iOS 27 and the redesigned Screen Time is not available. CaseParentChildOur app's shieldSystem Screen Time (set by parent)AiOS 27.0.1iOS 18.7.1BlocksBlocksBiOS 18.7.1iOS 27.0.1Does not blockBlocksCiOS 18.7.1iOS 18.7.1BlocksBlocksQuestions Is this a known issue in iOS 27.0.x? Could it be related to issue number 175437403 ("Screen Time restrictions might not apply to child accounts despite being configured"), which the iOS 27 release notes list as fixed? Should tokens selected on an iOS 18 parent device be enforced on an iOS 27 child device? Is there a workaround, or a way to detect that a shield was applied but is not being enforced?