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

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.

Hello, I am developing an iPhone application to help users avoid missing important phone calls. The intended behavior is: A user receives a regular cellular call through the built-in iPhone Phone app. The user does not answer the call. Our application automatically detects the missed call. The application schedules repeated local notifications until the user acknowledges the missed call. The critical requirement is that detection must work while our application is in the background, without the user reopening it. Implementation We currently use CXCallObserver to observe cellular call events. When an incoming call ends without being connected, we classify it as a missed call and schedule notifications using UNUserNotificationCenter. Test environment Device: iPhone 17 iOS: 26.7.1 Distribution target: Standard App Store, Japan Testing: Physical device without an attached Xcode debugger Observed behavior Scenario A: Our application is visible immediately before the iPhone is locked. Missed calls have been detected and notifications scheduled after more than 30 to 60 minutes of device lock. Scenario B: Our application is moved to the background before the iPhone is locked, for example by returning to the Home Screen or opening Safari. Missed calls are not detected promptly, even after only a short period in the background. When the user subsequently opens our application, CXCallObserver callbacks may arrive and the earlier missed call is then detected. This defeats the purpose of the application because the user must reopen it to receive alerts. Questions Is CXCallObserver expected to deliver callbacks while its application is suspended, or only when the process is executing? Is there any supported public iOS API, extension, or background execution mechanism that allows a third-party application to detect missed calls from the built-in Phone app while the application is suspended or terminated? Can a regular cellular missed-call event wake or relaunch a third-party application? If CXCallObserver cannot support this use case, is there another Apple-supported solution available to ordinary App Store applications distributed in Japan? We are looking for an approach that does not require external hardware, carrier integration, private APIs, or unsupported background execution techniques. If this use case is not supported by the public iOS SDK, confirmation of that limitation would be very helpful. Thank you for your guidance.

When i use the MFMailComposeViewController in visionOS, there is no cancel button for the controller. The button at the bottom closes the app. Is anyone else experiencing this? if([MFMailComposeViewController canSendMail]) { MFMailComposeViewController* controller = [[MFMailComposeViewController alloc] init]; controller.mailComposeDelegate = (id <MFMailComposeViewControllerDelegate>)view; [controller setToRecipients:toAddresses]; [controller setSubject:subject]; [controller setMessageBody:body isHTML:isHtml]; [view presentViewController:controller animated:YES completion:nil]; }

I wrote a python script MXSymbolicate to symbolicate crash reports produced by MetricKit. To symbolicate a given frame, it needs the symbol file for that frame's library. For system libraries, my system only has the requisite files on disk if I've plugged an iOS device of that type at that iOS version into my computer at some point (I assume these symbol files from the device are generated by Xcode when it's preparing to debug on a new device). All these different versions of the symbol files take up a fair bit of space on my machine over time, and it means the symbolication process isn't very portable. Is there a better way to get ahold of symbol files for system libraries? Or is the expectation that we (as third party developers) only symbolicate the frames from our own apps?

I am developing a watch-only bedside clock for an Apple Watch running watchOS 27.0.1. The user needs to remove the watch in hot weather and still see the time without having a charger available. The requirements are: wrist detection remains enabled; the watch is off wrist and unplugged; the app is opened manually on the watch; the clock remains visible without periodic touches or any Mac/developer connection. Covering the screen should turn it off. The UI contains only the time, date, and battery level. It does not need protected data, HealthKit access, or programmatic unlocking. Independent physical testing still ends in the app transitioning to the background and the display turning off. Always On configuration and background runtime are not sufficient in the tested off-wrist state. Experimental idle-display requests either have no visible effect or extend the visible period to approximately 60 seconds. Updating the native scene's requested idle duration every 20 seconds does not renew the observed display deadline, despite the local readback showing the requested values. Is there a supported public API or system-owned presentation surface that can keep a nonsensitive clock visible in this situation while preserving wrist detection and authentication? If this requires an approved entitlement or a platform capability, is one available to third-party developers for this use case? Please distinguish keeping the process alive, retaining the frontmost app, and keeping the physical display visible after removal from the wrist. I have not claimed additional entitlements or changed the watch's authentication settings. I would appreciate clarification of the supported platform boundary before undertaking further device experiments.

Dear Screen Time Team! The current 6 MB memory limit for the DeviceActivityMonitor extension no longer reflects the reality of modern iOS devices or the complexity of apps built on top of the Screen Time framework. When Screen Time APIs were introduced with iOS 15, hardware constraints were very different. Since then, iPhone performance and available RAM have increased significantly…but the extension memory limit has remained unchanged. My name is Frederik Riedel, and I’m the developer of the screen time app “one sec.” Our app relies heavily on FamilyControls, ManagedSettings, and DeviceActivity to provide real-time interventions that help users reduce social media usage. In practice, the 6 MB limit has become a critical bottleneck: The DeviceActivityMonitor extension frequently crashes due to memory pressure, often unpredictably. Even highly optimized implementations struggle to stay within this constraint when using Swift and multiple ManagedSettings stores. The limit makes it disproportionately difficult to build stable, maintainable, and scalable architectures on top of these frameworks. This is not just an edge case…it directly impacts reliability in production apps that depend on Screen Time APIs for core functionality. Modern system integrations like Screen Time are incredibly powerful, but they also require a reasonable amount of memory headroom to function reliably. The current limit forces developers into fragile workarounds and undermines the robustness of apps that aim to improve users’ digital wellbeing. We would greatly appreciate if you could revisit and update this restriction to better align with today’s device capabilities and developer needs. Thank you for your continued work on Screen Time and for supporting developers building meaningful experiences on top of it. Feedback: FB22279215 Best regards, Frederik Riedel (one sec app)

Hi there, I'm planning to develop a simple underwater compass app for Apple Watch Ultra 2, intended for recreational scuba diving down to 40 meters. The app itself does not need depth or pressure measurements beyond 6 meters. Its primary function is compass navigation using heading data. During a dive, however, I would like the app to: remain frontmost and visible throughout the dive; use Water Lock; use an underwater-depth WKExtendedRuntimeSession; continue receiving compass heading updates; allow interaction through physical controls such as the Digital Crown and Action Button; remain operational below 6 meters, potentially down to 40 meters. I understand that the Shallow Depth and Pressure capability limits CMWaterSubmersionManager depth/pressure data to approximately 6 meters, while access to depth/pressure data down to 40 meters requires the full Submerged Depth and Pressure entitlement. My question is: If my app does not require depth/pressure measurements beyond 6 meters, is the full Submerged Depth and Pressure entitlement still required simply to keep the underwater extended runtime session, UI, compass heading updates, and physical-control interaction working below 6 meters? In other words, does the 6-meter entitlement limit apply only to depth/pressure data, or does it also limit the ability of an underwater compass app to remain operational during a scuba dive below 6 meters? Target hardware: Apple Watch Ultra 2. Thanks in advance!

Hello, We are developing a macOS app using Apple-Hosted Managed Background Assets (MBA). Our resources are strictly coupled to specific app binary versions (e.g., App v1.0 is incompatible with Asset Pack v2.0 due to data schema and data format changes). We plan to use Essential asset packs, but also plan to provide an in-app fallback using ensureLocalAvailability during initial launch to handle cases where background downloads fail or are delayed. We have questions regarding the version-resolution behavior and Apple's recommended architecture for version-coupled assets. Scenario A user installs App v1.0 (which targets Asset v1.0). The initial Essential download fails (e.g., network disconnect). The user opens the app without local assets. Later, Asset v2.0 is released to the App Store alongside App v2.0. The user on App v1.0 launches the app and calls ensureLocalAvailability. Questions [1] Version Resolution & Fallback Behavior When an app has no local asset pack installed and calls: try await AssetPackManager.shared.ensureLocalAvailability( of: appResources01, requireLatestVersion: false // or the legacy ensureLocalAvailability(of:) ) Does the system always fetch the latest live version in the App Store (v2.0), or is there any mechanism to retrieve the historical version compatible with App v1.0? Is it possible for an app to explicitly request a specific Asset Pack version rather than the currently active App Store version? [2] Scope of shouldDownload(_:) Does ManagedDownloaderExtension.shouldDownload(_:) get invoked during an explicit in-app call to ensureLocalAvailability? Or is shouldDownload(_:) exclusively called for system-initiated background download cycles? [3] Recommended Architecture for Version-Coupled Resources If an application cannot maintain backward compatibility within a single continuously versioned Asset Pack (v1 → v2 → v3), what is Apple's recommended design pattern? Option A (Separate Identifiers): Define distinct Asset Pack identifiers for each incompatible app generation (e.g., AppResources-v1, AppResources-v2)? Option B (Forced App Update): Use a single Asset Pack identifier and require older app versions to prompt a forced app update via the Mac App Store if assets are missing and incompatible? Option C: Is there another recommended mechanism within Background Assets for managing strict asset-binary version coupling? Thank you for your guidance!

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?

iOS 27, See image below. From top to bottom I'm using: displayName containerDisplayName contentDescription I haven't found a way to remove the transaction amount from my containerDisplayName and display it in the top right with some other CSSearchableItemAttributeSet value. Is it even possible?

I'm developing a digital wellbeing app using FamilyControls and DeviceActivity. The core functionality of the app is to show the user their per-application Screen Time usage, including the application identity and duration (for example, Instagram — 1h 30m, YouTube — 45m). I understand that on iOS 26.4+, AuthorizationStatus.approvedWithDataAccess and DeviceActivityData.activityData(filteredBy:using:) provide access to non-tokenized application usage data. I also understand the current Apple documentation states that customer installations can only obtain approvedWithDataAccess on devices located in the EU with an Apple Account configured to an EU country or region, and that outside the EU the authorization status never becomes approvedWithDataAccess. My app and test device are based in Kazakhstan. My question is not about bypassing Apple's privacy model or implementing an undocumented workaround. I would like to know whether there is any official path for a legitimate third-party Screen Time / digital wellbeing app to obtain this data outside the EU, for example: an additional entitlement; a developer approval or application process; a regional exception; an alternative Apple-supported API; or any other official mechanism. We already have the Family Controls distribution entitlement approved and have enabled the Family Controls App and Website Usage capability. If no such mechanism exists, I would appreciate confirmation that the EU restriction is currently absolute for customer installations and that there is no additional entitlement or approval process available for developers outside the EU. The reason I am asking is that per-application usage is a core part of the application's functionality, so I want to make sure I am not missing an official Apple-supported option before designing around this limitation.

We are implementing regional age-assurance checks for an iPhone app that supports iOS 17 and later. It is a paid toddler app with no backend, app accounts, ads, in-app purchases, messaging or shared user content. All content is suitable for young children. Optional family voice recordings remain on the device. We plan to request Declared Age Range when Apple's regulatory signals require it, process the response locally, and avoid logging, storing or transmitting age data. We are seeking supported technical behavior, rather than legal advice or preapproval: What supported API or platform guarantee establishes that initial download/purchase parental consent was obtained? The age-range response does not appear to expose a separate initial-consent status. Apple's age-assurance Q&A says the platform prevents launching an app after a parent revokes consent. The implementation guidance also describes RESCIND_CONSENT through App Store Server Notifications. For an app with no backend or remotely accessible service, can local access rely on the platform's launch blocking, or is a notification server still required? If a server is required, what local enforcement behavior should it drive? What is the supported behavior for offline reopening and unavailable or network-error results, particularly on older supported iOS versions where the regulatory APIs are unavailable? Does platform enforcement also cover an app already running when consent is revoked, and how should an offline app handle that transition? Documentation or a sample showing this entirely local case would be helpful.

After transferring the App ownership to a different account, if you update the app on iOS, two identical apps will show up in Settings > Screen Time. Users can't control the blocking settings from before the update - the only fix is to restart the phone. After the next execution of manageStore.shield.applications, users still can't manually disable the restrictions - their only option is to uninstall and reinstall the app. I believe this is related to how Screen Time API's authentication works - it's not just tied to the app's bundle ID, but also linked to the developer account's organization ID. Any suggestions for a clean solution that would allow smooth app updates after the transfer without running into these issues?

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.

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

I’m looking for clarification on how Apple retrieves the apple-app-site-association (AASA) file for Universal Links / Associated Domains. Assume a domain exposes the AASA file at: https://example.com/.well-known/apple-app-site-association The domain is protected by Geo-Blocking, where access from certain countries/regions is restricted. I would like to understand the expected network behavior for AASA retrieval: Can requests to retrieve the AASA file originate from Apple infrastructure in different countries or regions globally? Does Apple publish a list of source countries, IP addresses, IP ranges, or network ranges specifically used for AASA retrieval? Can the source country or IP address change over time due to Apple's infrastructure, CDN, or routing? Is there any supported way to force AASA retrieval through a particular region, such as the US? If certain countries are blocked, is there any way to determine whether Apple may use infrastructure from those countries for AASA retrieval? Is the recommended approach to allow the following endpoint to be publicly reachable regardless of source geography? The objective is to restrict access as much as possible while ensuring that Universal Links continue to work reliably. If there is any official Apple documentation covering the source network, IP ranges, geographic locations, or accessibility requirements for AASA retrieval, a reference would be greatly appreciated.

I’m evaluating an iOS app that uses Family Controls / DeviceActivity for an adult user’s voluntary personal device-management and digital-wellbeing goals. The app would also have an optional social competition feature where friends participate in fantasy-style leagues based on completion of their individual digital-wellbeing goals. I’m trying to understand the restrictions in Apple Developer Program License Agreement Section 3.3.3(P), specifically whether a privacy-preserving result derived locally from Family Controls / DeviceActivity can leave the device when the underlying usage data never does. I’m considering three architectures: A — Locally derived fantasy score DeviceActivity information is evaluated entirely on-device and converted locally into an abstract score. The server receives only: fantasy_points = 82 No Screen Time duration, app identity, website activity, bundle identifier, or underlying usage information leaves the device. B — Binary goal completion A user creates a private usage goal, such as remaining below their chosen daily device-usage threshold. The goal is evaluated entirely on-device. The server receives only: goal_completed = true The server then awards predetermined fantasy points. It never receives the underlying Screen Time value. C — Opaque challenge completion A user privately selects an app/activity goal. DeviceActivity evaluates the threshold locally. The server receives only: challenge_id = C928 completed = true The server knows C928 is worth a predetermined number of points, but does not receive the selected app identity, usage duration, Screen Time quantity, or other underlying DeviceActivity information. In all three approaches, raw Screen Time duration, per-app usage duration, application/bundle identity, website activity, DeviceActivity reports, and underlying historical usage records would remain on-device. Friends would only see fantasy points, matchup results, standings, and/or achievements. My question: Under Section 3.3.3(P) and the Family Controls requirements, are any of A, B, or C permitted? More specifically, does Apple consider an abstract score, boolean goal-completion result, or opaque challenge-completion result to itself be “device or usage data” when it was derived from Family Controls / DeviceActivity? If none of these architectures are permitted, is there a supported privacy-preserving architecture that allows an on-device DeviceActivity evaluation to affect a server-side social or multiplayer feature without transmitting the underlying device/usage information? I’m trying to establish the compliant architecture before development rather than build around an incorrect interpretation of the Family Controls requirements.

I'm developing an iOS parent-child app that uses FamilyControls and DeviceActivity. Before distribution, I need to test AuthorizationCenter.shared.requestAuthorization(for: .child), including the guardian approval flow. So far I have tested .individual, which authenticates the device owner and does not exercise the child flow. Apple Developer Program Support directed me to this forum. What is the Apple-supported way to test this flow in this situation? Is there an Apple-supported test-only account or setup for this flow without using a child's personal Apple Account? If so, where are its requirements documented? If not, what is the recommended alternative? Can Sandbox Apple Accounts used for StoreKit Family Sharing tests be used to sign in to iCloud and test FamilyControls .child, or are they limited to purchase testing? Is there a supported simulator or other test method for guardian approval, or must this be verified using a child Apple Account in a real Family Sharing group on physical devices? I want to follow Apple's account rules and test the actual parental authorization path before distribution. References to official guidance would be appreciated.

(lldb) p [@"ΗΙzzz" caseInsensitiveCompare:@"ᾚabc"] (long long) -1 (lldb) p [@"ᾚabc" caseInsensitiveCompare:@"ΗΙzzz"] (long long) -1 Note the unicode char in the second string. The results can't be both -1, afaik, if one is -1 the other one should be +1. This causes inconsistent indexing in a sorted array resulting in obscure crashes of my app. Am I doing something wrong? Tested on iOS 27 and macOS 26.6.