We are developing GateCall, an iOS application that uses a Call Directory extension to maintain a private, user-selected list of blocked telephone numbers. We are seeking clarification about Call Directory blocking precedence on iOS 27.0.1, particularly when a number exists in Contacts or outgoing Recents. Test environment Physical iPhone 11 Pro Max running iOS 27.0.1. Call Directory extension enabled in Settings. Blocking entry: a valid Canadian telephone number normalized to E.164 and submitted as an Int64. CXCallDirectoryManager.reloadExtension returned successful completion. The application reported synchronization of one blocking entry. Actual extension-loaded entry count has not been independently verified. Observed sequence — November 1, 2026 The target number was initially present in iPhone Contacts. At 2:01 PM, the application reported successful Call Directory synchronization. At 2:06 PM, the iPhone placed an outgoing call to the target number. At 2:16 PM, an incoming cellular call from the same number caused the iPhone to ring. The call subsequently appeared in Phone → Recents as a missed call. We reviewed the September 2025 Apple DTS discussion: https://developer.apple.com/forums/thread/800415 That discussion describes a caller-information priority hierarchy and changes in iOS 26 affecting outgoing Recents. Questions Does iOS 27.0.1 intentionally prioritize Contacts and outgoing Recents over explicit blocking entries supplied by a third-party Call Directory extension? Is there a supported public API or configuration that allows a user-selected Call Directory block to take precedence over those sources? Is this priority behaviour documented or expected to change in future iOS releases? Is there a supported diagnostic mechanism to verify which blocking entries were actually loaded by iOS, beyond successful extension reload completion? We understand that a successful reload does not independently prove that a particular number was loaded or that Call Directory caused the observed behaviour. Our objective is to implement accurate, user-controlled blocking and avoid claiming protection that the operating system cannot guarantee. Any clarification from Apple DTS or developers with recent iOS 27 experience would be appreciated.

Hello, We ship a font provider app that installs fonts system-wide on iOS, delivering the font files through On-Demand Resources. Since iOS 27 shipped, customers have been reporting that their installed fonts vanish from the system font list after every restart. I would like to know whether the restore path for system-wide font registrations changed in iOS 27, and what a font provider app is expected to do after a device reboot. Environment iOS 27.0 and 27.0.0 only. We have no reports on iOS 26 or earlier. iPhone 18 Pro and iPhone 18 Pro Max Fonts delivered through On-Demand Resources and registered for system-wide installation using CoreText Steps to reproduce Activate a font in the app. It appears in Settings > General > Fonts. Reboot the device. Without launching the app, open Settings > General > Fonts. The font is gone. The app still shows the font as active, because it keeps its own activation state. Deactivate and reactivate the font in the app. It comes back. Reboot again. It disappears again. This happens on every reboot. It also happens with a single font activated, and it persists after updating or reinstalling the app. Because the font is missing from the system font list, it is also missing in other apps that use system fonts. What we have ruled out Not low storage. These are new devices with plenty of free space. The documented purge trigger for On-Demand Resources is low storage, which does not explain a result this consistent. Not a crash. Our crash data for the affected app version shows no elevated crash rate on iOS 27 compared to iOS 18. Not specific to one font or one app version. Questions Did the restore path for system-wide font registrations change in iOS 27? Are registrations that reference files inside On-Demand Resources still restored at boot? If a font provider app now has to re-register after a reboot, when and how should it do that? There is no natural launch point, since someone may use the font in another app without opening ours first. Is there a supported way for the app to detect that a font it installed is no longer present in the system font list, so it can repair the registration quietly? Context We deliver several thousand fonts this way, and Apple increased our On-Demand Resources limit for that reason (Case-ID 17273913, December 2025). On-Demand Resources is deprecated as of iOS 27. We have separately confirmed that fonts delivered through Background Assets cannot be registered system-wide: registration fails with CTFontManagerErrorDomain code 306, both from the Background Assets container and after copying the files into the app sandbox, because CoreText requires the file to sit inside the app bundle or On-Demand Resources. We have a separate question open about that migration path, so this post is only about the reboot behavior on iOS 27. Happy to provide a sysdiagnose from an affected device and a sample project. Thank you.

I'm developing an iOS app that uses Apple-hosted Managed Background Assets to deliver regional offline mapping datasets. According to Apple's documentation, the limits are 200 GB of hosted data and 200 asset packs per app. However, I couldn't find a documented maximum size for an individual managed asset pack. Our use case requires automatic, on-demand downloads of geographic datasets, typically between 50 MB and 500 MB, depending on the region. I have a few questions: Is there a maximum compressed or uncompressed size for an individual Apple-hosted Managed Background Assets pack? Are on-demand downloads of 100–500 MB packs supported over Wi-Fi and cellular networks? Are there any additional restrictions on large packs, such as download frequency, storage requirements or background delivery policies? Can these packs be downloaded automatically when a user enters a new geographic region, without requiring the user to select or manually download the pack? I'm specifically asking about Managed Background Assets, not the legacy On-Demand Resources system. Any clarification from an Apple engineer would be greatly appreciated. Thank you!

I’m evaluating an offline profile-card app for iPhone users in the United States. After installation and initial user consent, bringing two iPhones together should automatically display each person’s custom card, containing favorite musicians and their willingness to socialize. Requirements: Neither person needs to open the app before the interaction. The exchange works without internet. No QR codes or external NFC tags are involved. The card appears automatically, rather than requiring a notification tap to open it. Is this supported by any public iOS API or available entitlement? Could NFC & SE Platform support this non-payment use case? If unsupported, which requirement is the blocker? Please distinguish background/suspended apps from apps that the user has force-quit. Thank you.

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

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.