Filed as FB_______. Related to thread 841386 ("iOS 27: Malicious link blocked") and FB25102183, but this case involves no link at all. The user pastes the code into the Phone keypad themselves. Setup: iPhone 17 Pro Max, iOS 27.2, Verizon (forwarding code *72 + 10-digit number; GSM carriers use **21* + number + #). What our app does: our customers forward their own cell to their own business number on our service. The app never opens a tel: link, never dials and never uses Shortcuts. It shows the carrier's forwarding code, copies it to the pasteboard only when the user taps "Copy code", and guides them to paste it into Phone > Keypad and tap call themselves. That normally works. Steps to reproduce: Copy a forwarding code (e.g. *72 + a 10-digit number). It can come from any app; Notes reproduces it. Open Phone > Keypad and paste it. Don't tap call. Leave the Phone app. Come back. The keypad is empty, so tap the green call button. Redial fills the code back in. Tap call. Result: "Call Forwarding Link Blocked", with only OK and Learn More. From then on, clearing the field and pasting the same code again is also blocked, every time, until the Phone app is force-quit from the app switcher. After a force-quit, paste + call works again. To be clear: a normal paste works every time. Paste the code and tap call right away, without leaving the Phone app, and it dials and the carrier confirms forwarding. Typing the code by hand also always works. Only the leave-and-redial path triggers the block, and it then sticks until force-quit. Expected: consistent behavior. A code the user pastes or types into the keypad and dials themselves should not be treated as a "link" depending on whether redial filled the field, and the block should not persist across fresh pastes. Questions for DTS: Is a user pasting a forwarding code into the keypad and dialing it themselves a supported flow going forward, or should apps tell iPhone users to type these codes by hand? Is there, or is there planned, a supported way for an app to ask iOS to set up call forwarding to a given number, with the user approving it in system UI? Legitimate services where customers forward their own number to their own account currently have no path that doesn't look like the scam pattern this protection targets. Happy to provide a sysdiagnose or a screen recording.

We run a live App Clip used by cafes in Saudi Arabia. Customers scan a QR code at the counter to follow their order. Some customers stay on the blurred loading screen for about a minute, then get App Clip Unavailable. One cafe reported more than five cases in its first days, and I watched another happen at a cafe today, on an iPhone showing 5G with Low Power Mode on. Try Again did nothing when we tested it, and a new scan opened the clip at once. I reproduced it in 1 of 6 fresh downloads on an iPhone 17 Pro Max (build 23F84) on mobile data. The log shows: appstored starts the download from iosapps.itunes.apple.com over HTTP/1.1 on IPv6, with timeouts(60.0, 604800.0). TCP and TLS succeed and the request is sent. 71 ms later a TCP RST arrives with a stale sequence number, and the stack drops it as out of window. Retransmits go unanswered. response_bytes=0, then NSURLErrorDomain -1001 after 60.4 s. The install is cancelled, with no second attempt. A parallel HTTP/3 request finished in 414 ms, so the network was up. The clip is about 0.7 MB, and both App Clip experiences are published. Today I got the same stall without an iPhone. A Mac on an iPhone hotspot on STC mobile (AS39386) ran curl, opening a fresh HTTP/1.1 connection each time: iosapps.itunes.apple.com: IPv6 17 of 231 stalled, IPv4 0 of 89 stalled updates.cdn-apple.com: IPv6 5 of 60 stalled, IPv4 0 of 60 stalled www.apple.com, on a different CDN: IPv6 0 of 115 stalled, IPv4 0 of 85 stalled Each stall looks the same: TCP and TLS finish, the request goes out, and no response byte comes back. The stalls hit many edge addresses. One edge, frmrs1-vip-bx-005, answers on both 2a01:b740:a11:f000::203 and 17.253.122.203, and it stalled on IPv6 only, so this looks like the IPv6 path rather than a bad node. This is one SIM over 17 minutes, and I haven't tested other carriers yet. Repro from a Mac on an STC mobile hotspot: for i in {1..60}; do curl -6 --http1.1 -s -o /dev/null -m 10 -I -w '%{http_code} %{time_starttransfer}\n' https://iosapps.itunes.apple.com/; sleep 4; doneMy questions: Is there anything a developer can do to avoid this or recover from it? Is this a known issue with IPv6 to Apple's edge from Saudi mobile networks? Could someone from the App Clips or edge network team look at FB25380604? It stops real customers at the counter, so it's urgent for us.

PLEASE ADDRESS ASAP: Muse is #1 on the App Store and Facebook is one of the most blocked apps for Screen Time. This is affecting a vast number of people. Description: When a user blocks the Facebook app in any screen time app, iOS automatically blocks Meta's Muse app too. Every single time. There is no way for the user or the developer to prevent it, allowlist it, or even detect that it happened. Muse shows Apple's generic blocked-app "Restricted" screen instead of the screen time app's own design, so the user cannot tell who blocked it or why. This is the worst possible combination of apps: Facebook is one of the most-blocked app across screen time apps. Muse ("Muse from Meta") is currently the #1 app on the App Store. A huge and fast-growing number of users block Facebook and silently lose the world's most popular new app. Muse launched Sept 8, 2026 and adoption is still climbing -- the affected population grows every day. There is NO workaround whatsoever: Users cannot allowlist Muse: it does not appear in Settings > Screen Time > Always Allowed. Developers cannot prevent it: the Screen Time API offers no opt-out; the extra block is applied by iOS itself. Developers cannot detect it: Muse's token (listed separately in FamilyActivityPicker) corresponds to no real identity anywhere else. Developers cannot customize it: their ShieldConfiguration is never consulted -- Muse gets Apple's generic shield UI. Users cannot even block Muse on purpose: shielding Muse's own token is a silent no-op. Screen Time usage statistics are also wrong -- Muse usage is recorded as "Facebook." This Screen Time bug renders screen time apps effectively unusable if users want to block Facebook and use Muse, which is extremely common. How can we get this addressed as soon as possible? Feedback Assistant ticket: https://feedbackassistant.apple.com/feedback/25019832

Hi there! My claim is that ManagedSettingsStore.TokenExpiryMessage API family doesn't work properly. I'm curious if that's only me, or others have also found it confusing, or non-working? I haven't found much public discussion about it, so this is the start of it. There are multiple confusing scenarios from my playing with it, but the simplest example is that ~30% of my apps NEW users get the ".tokensDidExpire" as soon as they approve Screen Time Permissions. Note that they haven't even seen the FamilyActivityPicker! FB23391495 is the feedback. Apple dev responded, but it didn't give confidence that my bug report was deemed correct (which can be fair!). However, it's current status is "Potential fix identified - For a future OS update," so maybe there is something to it. The API is likely quite difficult to get right, so I am happy to provide feedback on potential implementation so it's 100% solid.

Family Controls: Can Screen Time performance determine StoreKit promotional-offer eligibility? I'm developing an iOS app that helps individuals reduce recreational screen time. The app would use DeviceActivityMonitor to evaluate whether users meet their own screen-time goals. Users who succeed could redeem a discounted one-month subscription through StoreKit promotional offers. The calculation would occur locally on the user's device. No raw usage data, app names, or browsing history would be transmitted. Two questions: Is it permissible under the Family Controls framework's data-use restrictions to use on-device activity outcomes to determine eligibility for a discount on the same app's subscription? Can the resulting discount tier or promotional-offer identifier be sent to our server solely to authorize the StoreKit offer, without violating those restrictions? I'd appreciate clarification from Apple staff about this specific use case before implementing it.

Two physical iPhones on public iOS 27.2 (24B119), using separate adult US Apple Accounts, produce different results from the Declared Age Range framework under a BR country classification. Device A displays the mandatory Brazil-sharing notice, does not accept Never in the native selector, and returns an 18+ range to a real request with ageGates:18. Device B accepts Never after the update. The same local checker receives declinedSharing with no age bounds. Never remains checked afterward. The checker invokes requestAgeRange even when regulatory eligibility is false; it does not synthesize a refusal locally. Device logs indicate normal flow, without a sandbox override. Selected diagnostics show US billing countries for App Store, Music and iCloud on both devices and BR detected on both. Their separate age-assurance classifications differ: BR with account eligibility true on A, versus unset with account eligibility false on B. Unset is not being treated as US. The captures were made on different dates, and identical account histories and management payloads have not been established. Both devices are supervised. No location simulation or network filter was active during B's test. For developers handling these API results, what documented account or device criterion explains this difference? What supported diagnostic and correction path is available when the native sharing control is unavailable on one device but effective on another under the same detected country? The detailed comparison has been supplied privately through Feedback Assistant. This question concerns the public framework's behavior and supported remediation; it does not assume US billing country alone creates an exemption.

In Core Spotlight, one can only index content by using title or displayName, and it requires four consecutive characters for indexing. These situations occurred in iOS 17 and 18. In iOS 16, I could not only index content by title or displayName, but also by keyword. Moreover, there was no restriction of requiring four consecutive characters. I could index my app content by simply inputting one character. Here is my code.https://github.com/kritto1/corespotlight-bug-test/tree/main @available(iOS 14, *) func addItemToIndex(_ item: QSpotlightItem) { let attributeSet = CSSearchableItemAttributeSet(contentType: .item) attributeSet.title = item.title attributeSet.displayName = item.title attributeSet.contentDescription = item.contentDescription attributeSet.keywords = item.keywords attributeSet.thumbnailData = item.thumbnailImage attributeSet.contactKeywords = item.keywords attributeSet.supportsNavigation = true let searchableItem = CSSearchableItem(uniqueIdentifier: item.id, domainIdentifier: "com.qunar.iphone.spotlight", attributeSet: attributeSet) searchableItem.expirationDate = .distantFuture CSSearchableIndex.default().indexSearchableItems([searchableItem]) { error in if let error = error { } else { } } } @available(iOS 14, *) func addToSpotlightIndex() { let spotlightHotel = QSpotlightItem( id: "corespotlight_1", title: "查询酒店住宿", contentDescription: "", thumbnailImage: UIImage(named: "img2")?.pngData(), keywords: ["酒店", "住宿"] ) addItemToIndex(spotlightHotel) let spotlightFlight = QSpotlightItem( id: "corespotlight_2", title: "查询和预订机票", contentDescription: "", thumbnailImage: UIImage(named: "img2")?.pngData(), keywords: ["查询", "预订", "机票"] ) addItemToIndex(spotlightFlight) let spotlightSight = QSpotlightItem( id: "corespotlight_3", title: "查询预订门票", contentDescription: "", thumbnailImage: UIImage(named: "img2")?.pngData(), keywords: ["查询", "预订", "门票"] ) addItemToIndex(spotlightSight) }

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 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.