Hi , I'm new here, do anyone know how long it takes for Apple to approve my enrollment?

When I tap on one of the buttons in the ShieldAction extension I want to close the shield and open the parent app instead of the shielded app. Is there any way of doing this using the Screen Time API? class ShieldActionExtension: ShieldActionDelegate {      override func handle(action: ShieldAction, for application: ApplicationToken, completionHandler: @escaping (ShieldActionResponse) -> Void) {     // Handle the action as needed.           let store = ManagedSettingsStore()               switch action {     case .primaryButtonPressed:       //TODO - open parent app       completionHandler(.defer)     case .secondaryButtonPressed:       //remove shield       store.shield.applications?.remove(application)       completionHandler(.defer)         @unknown default:       fatalError()     }   }   }

Starting in iOS 27, opening a tel: URL that contains a call-forwarding MMI code from an app shows a system alert and dials nothing: Malicious Link Blocked: This link was blocked because it contains malware that will forward all of your incoming messages and calls to 1 (XXX) XXX-XXXX. Scammers often provide malicious links that look legitimate via email, text, or chat. On iOS 26 the same call showed the normal call confirmation prompt and the carrier applied the forwarding. Repro (in response to a button tap): UIApplication.shared.open(URL(string: "tel:*21*XXXXXXXXXXX%23")!) Typing *21*XXXXXXXXXXX# into the Phone app's keypad by hand still works on iOS 27, so the capability is still there; only the in-app handoff is blocked. This breaks setup for call-screening and visual-voicemail apps whose onboarding depends on carrier forwarding (*21*, *61*, *67*, *71*, *72). It also blocks the disable codes (##21#, ##004#, *73), so users can't turn forwarding off from inside the app, which works against the user's own safety. The anti-hijack intent makes sense for links arriving from Messages, Mail or Safari. For a user tap inside an installed App Store app, a confirmation sheet ("Forward calls to ...? Allow") seems like the right balance, and disable codes should always be allowed. Filed as FB24843805. Questions: Is this block meant to apply to links opened by an installed app in response to a user tap? Is there a supported API, entitlement or URL form to hand a forwarding code to the Phone app with user confirmation? Our current workaround is to copy the code to the clipboard and ask the user to paste it into the keypad, which is a real drop-off point for our (mostly older) users. If you're affected too, please file your own feedback and reference FB24843805.

I'm getting a persistent WeatherKit authentication failure that survives every standard troubleshooting step. Hoping someone from the WeatherKit team can check the backend sync for my Team ID. Team ID: 9CQUMUHB42 Bundle ID: com.martin.MinimalWidgets (app) Bundle ID: com.martin.MinimalWidgets.MinimalWidgetsWidget (widget extension) Error: Failed to generate jwt token for: com.apple.weatherkit.authservice with error: Error Domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "(null)" What I've verified: WeatherKit capability is enabled in Xcode for BOTH the app and widget extension targets WeatherKit is enabled in the App ID configuration for both identifiers in the Developer Portal Confirmed with codesign -d --entitlements :- that com.apple.developer. weatherkit is correctly present and set to true in the signed binaries for both the app and the extension WeatherKit Usage dashboard shows 500,000 calls/month quota, 0 used Cleared the provisioning profile cache at ~/Library/Developer/Xcode/UserData/Provisioning Profiles, ran Download Manual Profiles again Clean Build Folder, deleted the app from device, reinstalled Restarted the test device Waited over 24 hours since first enabling the capability None of the above resolved it — the exact same error persists on every attempt, including today. This looks like a backend entitlement sync issue between the Developer Portal and the WeatherKit auth service rather than a local configuration problem, since the signed entitlements are confirmed correct on my end. Could someone from the WeatherKit team check the sync status for this Team ID / Bundle ID and confirm whether WeatherKit token generation is enabled server-side? Happy to provide any additional diagnostic info (sysdiagnose, device logs, etc.) if needed. Thanks in advance!

Hello all, Looking for guidance for my app. I run a workout studio and the time frames for classes are all in military time. I have tried extensively to have this turned off and I am just unsure what is left to do. Has anyone dealt with something like this?

I’m using the new Preview app on an iPhone running iOS 27 with a multi-page PDF that contains selectable text. Apple’s Preview guide says PDF text search is supported: open the PDF, tap Search, type a word/phrase, and use previous/next match arrows. But I cannot find a Search/Find control anywhere. I checked: • The visible top toolbar • The filename dropdown (it only shows Duplicate, Move, Rename, Export, and Print) • The **- - - ** menu • The bottom toolbar Has anyone found the actual Find in PDF control in the current iPhone Preview interface? If it is missing for you too, please include your iPhone model and exact iOS 27 version/build.

Hi, I’m developing a macOS Finder Sync extension and noticed that NSMenuItem.separator() does not appear to render as a standard separator line when used inside the menu returned from FIFinderSyncController. In a normal AppKit NSMenu, the separator renders as expected. However, when the same kind of menu is returned from the Finder Sync extension, the separator appears as a blank/full-height empty row rather than a thin dividing line. Example: override func menu(for menuKind: FIMenuKind) -> NSMenu { let menu = NSMenu(title: "") menu.addItem(NSMenuItem( title: "First Action", action: #selector(firstAction(_:)), keyEquivalent: "" )) menu.addItem(NSMenuItem.separator()) menu.addItem(NSMenuItem( title: "Second Action", action: #selector(secondAction(_:)), keyEquivalent: "" )) return menu } Expected result: The separator should render as a normal macOS menu separator line between the two menu items. Actual result: In Finder’s context menu, the separator is displayed as blank vertical space / an empty menu row. I understand that Finder Sync menus are rendered by Finder and may not support every NSMenuItem feature. However, NSMenuItem.separator() is a very standard way to visually group menu commands, so I wanted to ask: Is this a known limitation of Finder Sync extension menus? Is there a supported way to display a real separator line in Finder Sync context menus? Should this be filed as a Feedback Assistant issue against Finder Sync / AppKit? I’m trying to avoid fake separators such as disabled menu items with "────" as the title, since that does not feel native and may not behave well with different fonts, accessibility settings, or appearance modes. Thanks!

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 documentation for URLByDeletingLastPathComponent states the following: If the receiver’s URL represents the root path, this property contains a copy of the original URL. Otherwise, if the original URL has only one path component, this property contains the empty string. So maybe this is new in Foundation with the Golden Gate or maybe I just noticed this but the documentation above doesn't seem to be true. This will create an infinite loop: NSURL *fileURL = [NSURL fileURLWithPath:@"/Users/MyUsername/Desktop/AFolder" isDirectory:YES]; NSLog(@"%@",fileURL); NSURL *ancestorURL = fileURL.URLByDeletingLastPathComponent; while (ancestorURL != nil) { NSURL *nextAncestor = ancestorURL.URLByDeletingLastPathComponent; NSLog(@"Next: %@",nextAncestor); if ([nextAncestor isEqual:ancestorURL]) { NSLog(@"Hit the root - got a copy of the same url"); break; } else if ([nextAncestor.absoluteString isEqualToString:@""] || [nextAncestor.path isEqualToString:@""]) { NSLog(@"Empty string means we had only 1 path component."); break; } else if (nextAncestor == nil) { NSLog(@"Got nil"); break; } ancestorURL = nextAncestor; } The infinite loop can be avoided by adding the following condition: else if (nextAncestor.pathComponents.count == 1) { // One path component. NSURL *sneakPeak = nextAncestor.URLByDeletingLastPathComponent; NSLog(@"%lu",sneakPeak.pathComponents.count); // Logs 2. break; } When you get to one path component URLByDeletingLastPathComponent appends a .. path component rather than deleting a path component or returning a copy of the receiver or a url with an empty string.. If this sounds like a bug let me know. When I call URLByDeletingLastPathComponent on a url with only one path component I'd like to get nil. I think that would be a cleaner design.

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.

Description: On iOS 27.0 (24A437) with Apple Intelligence enabled, sharing a Writing Tools result to a share extension fails as soon as the extension shows a keyboard. Steps: Safari (also Chrome, NAVER app): select a paragraph → Writing Tools → Proofread (or Rewrite / Summary). In the result panel tap Share → choose Notes (Apple) or any third-party extension whose sheet focuses a text view. In the extension's sheet, tap the text so the keyboard appears (for SLComposeServiceViewController-based extensions this happens automatically on presentation). Expected: the extension sheet stays open; the user edits and posts. Actual: about 0.3–1.0 s after the keyboard appears, the extension sheet, the share sheet and the Writing Tools panel are all dismissed. Nothing is saved. Apple Notes' own share extension shows the same behaviour when its text is tapped. Impact: no share extension can accept edits from the Writing Tools result panel; developers cannot detect the host or avoid the keyboard when the user wants to type. Device: iPhone 15 Pro (iPhone16,1), iOS 27.0 (24A437)

Hello fellow developers, I’ve been working with the CallKit framework in iOS, specifically handling incoming calls. One issue I’ve encountered is that Siri when "read caller name" is enabled announces the caller name/surname set via localizedCallerName and then reads the generic handle value (usually alphanumeric) too! Has anyone encountered a similar situation or if there’s a solution to prioritize the localizedCallerName over the generic handle value without using CXHandleType.emailAddress? Alternatively, any insights or workarounds you know would be greatly appreciated. TLDR: even when I correctly configure the localizedCallerName property, Siri persists in reading the CXHandleType.generic. The original Implementation with CXHandleType.generic: The issue arises when using CXHandleType.generic for alphanumeric IDs (or even URLs as stated by documentation https://developer.apple.com/documentation/callkit/cxhandle). Despite correctly setting the localizedCallerName, Siri continues to announce the generic handle value. Expected Behavior: Siri should read only the localizedCallerName when set and ignore the generic handle value when announcing incoming calls. Workaround: Currently, the only workaround is to use CXHandleType.emailAddress for alphanumeric IDs. However, this is not ideal since it repurposes an email-related handle type for a different purpose. Steps to Reproduce: Create a CallKit app that handles incoming calls (example app from documentation can be used too). On incoming call create CXCallUpdate object Create a CXHandle with CXHandleType.generic and an alphanumeric value (e.g., “ABC123”). Pass the CXHandle to the CXCallUpdate objects' remoteHandle. Set the localizedCallerName property of the CXCallUpdate object with a custom caller name/surname. Report the call with reportNewIncomingCallWithUUID Observe that Siri reads both the localizedCallerName and the generic handle value during call announcements. While we are here a Feature Request: Developers should be able to provide a user-friendly caller name without resorting to workarounds like using CXHandleType.emailAddress. I kindly request that Apple consider enhancing Siri’s behavior in the following ways: Allow developers to suppress the reading of generic handle values while still using the correct handle type. Introduce additional type options for call announcements that don't read the generic value. Both of the above. Thank you for your help! 🙌

CTFontManagerCreateFontRequestRunLoopSource does not receive any font requests on macOS 27, since beta 5. This API worked fine until macOS 27 beta 4, including previous macOS releases. It looks like this is caused by the App Sandbox. When the com.apple.security.app-sandbox entitlement is disabled the font request source does receive events. Report including sample project: FB24764122 let source = CTFontManagerCreateFontRequestRunLoopSource(0, { (dict, pid) in /* does not receive events when sandboxed */ } CFRunLoopAddSource(CFRunLoopGetCurrent(), source, .defaultMode) Is this a deliberate change or is this a bug in macOS 27? Is there an entitlement that can be set to enable the API in sandboxed apps? My application is distributed on the Mac App Store and as standalone app. Both are properly sandboxed for added security. Disabling the App Sandbox for this specific API would be very undesirable as users will lose all Sandbox benefits.

A macOS app that never reads or writes notes cannot update a contact that has a note property. CNSaveRequest.update() throws NSCocoaErrorDomain 134092 with NSUnderlyingException "Unhandled error (NSCocoaErrorDomain, 134092) occurred during faulting". CNContactNoteKey is never requested. I reduced it to a minimal app whose only action is toggling familyName, and confirmed the cause in both directions: Create a contact programmatically. The update succeeds. Add a note to it in Contacts.app. The identical update now fails with 134092. Set that note to an empty string. Still fails. Remove the note property entirely. The update succeeds again. Contacts imported from a vCard fail from the start, even when the vCard has no NOTE line and Contacts.app shows no note. Clearing the note property on such a contact also makes the update succeed, so I believe the import attaches the property invisibly. Ruled out: mutableObjects instead of mutableCopy, including or omitting CNContactNoteKey, unified versus non-unified fetches, and the app sandbox (an ad-hoc signed build with no sandbox fails the same way). Full Disk Access does not help. I could not test the entitlement itself: an ad-hoc signed build carrying com.apple.developer.contacts.notes is refused at launch (RBSRequestErrorDomain 5, "Launchd job spawn failed"), since it is a restricted entitlement that needs a provisioning profile. Question: is com.apple.developer.contacts.notes required to update any contact that merely has a note, even when the app never reads or writes notes? If so, what is the expected path for an app that only reorders phone numbers and email addresses? The error itself gives no hint that notes are involved. If anyone here already holds the notes entitlement: does saving succeed for you on a contact that has a note? I have a request pending, and confirming this before it is decided would help a great deal. Environment: macOS 26 (Darwin 25.x), Apple Silicon. Filed as FB23452026.

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

I am developing an iOS application with a Location Push Service Extension and am trying to provide managed app configuration to the extension using Apple's ManagedAppConfigurationProvider and Declarative Device Management (DDM). The same managed configuration works correctly in the containing application, but the exact same API fails when called from the Location Push Service Extension. Environment: iOS: 26.2.1 Xcode: 16.4 Extension type: Location Push Service Extension The extension has the following entitlement in both the signed extension and provisioning profile: com.apple.developer.location.push The extension is configured through DDM using ExtensionConfigs: "ExtensionConfigs": { "bundleid (teamid)": { "DataAssetReference": "xxxxxxx" } } The Data Asset is successfully compiled by the MDM server and contains the managed configuration values. The device reports the following DDM status: "config-state": { "app-config-state": { "state": "valid" }, "extension-config-state": { "bundleidofextension": { "state": "unknown" } } } The main application can successfully retrieve the configuration using: let provider = ManagedAppConfigurationProvider() Task { for await configuration in await provider.configurations( ModelManagedAppConfiguration.self ) { print("APP CONFIG = (String(describing: configuration))") } } The same code and the same configuration type are used inside the Location Push Service Extension. Inside the extension, the provider is created successfully: LOCATION EXTENSION: creating ManagedAppConfigurationProvider LOCATION EXTENSION: provider created LOCATION EXTENSION: requesting configurations However, the request fails with: Failed to connect to managedappsd with error Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service named com.apple.devicemanagementclient.managedappsd was invalidated from this process." Failed to fetch managed app configuration. Returning nil. Error: XPC connection failed with error Optional("Couldn’t communicate with a helper application.") Failed to determine managed app configuration changed notification name. Unable to register for notifications. Failed to report configuration error state. Error: XPC connection failed with error Optional("Couldn’t communicate with a helper application.") LOCATION EXTENSION: CONFIG = nil The important observation is that the configuration works from the containing application but fails from the Location Push Service Extension before the configuration reaches the Decodable configuration type. I have also verified: The extension Bundle ID matches the ExtensionConfigs entry. The Team ID matches. com.apple.developer.location.push is present in the signed extension. com.apple.developer.location.push is also present in the provisioning profile. The DDM Data Asset is successfully compiled. The containing application's managed configuration state is valid. The same ManagedAppConfigurationProvider code works in the containing application. According to Apple's documentation, ManagedAppConfigurationProvider provides configurations for a managed app or extension, and ExtensionConfigs is the DDM mechanism for configuring extensions. My question is: Is ManagedAppConfigurationProvider fully supported from a Location Push Service Extension? If it is supported, what could cause managedappsd to reject/invalidate the XPC connection specifically when the request originates from a Location Push Service Extension? Could there be an additional entitlement, extension-specific configuration, or system restriction required for ManagedAppConfigurationProvider to communicate with managedappsd from this type of extension? Any guidance on how to further diagnose the NSCocoaErrorDomain Code=4099 / "Couldn’t communicate with a helper application" error would be appreciated.

On iOS 26.4, I set a Screen Time passcode. However, when I go to Settings > Apps > [Our App] and turn off Screen Time Access for the app, the system asks for Face ID instead of the Screen Time passcode. As a result, Screen Time access can be disabled without entering the Screen Time passcode. Steps to Reproduce 1. Set a Screen Time passcode on iOS 26.4. 2. Open Settings > Apps > [Our App]. 3. Turn off Screen Time Access for the app. Expected Result The system should require the Screen Time passcode before allowing Screen Time access to be disabled. Actual Result The system asks for Face ID instead of the Screen Time passcode, and Screen Time access is disabled.

I'm a font developer. In the development process, I will revise a font and overwrite the OTF file that is currently enabled (registered) with macOS. If I then launch an app, it will immediately use the revised version of the font; while apps that are already loaded will continue to use the old version. This suggests that each app is loading new and separate font data, rather than getting it from some existing cache in memory. Yet macOS does have a "font cache" of some sort. Some apps, like TextEdit, seem to only load the fonts that they need to use. However, other apps, like Pages, load every enabled (registered) font on the OS!! (According to the Open Files list in Activity Monitor.) Given that /System/Library/Fonts/ is 625 Mb, and we can't disable any of it, isn't that a lot of data to be repeating? How many fonts is too many fonts? I can't find much documentation about the process.

Hi everyone, I'm developing an iOS app that uses Apple's Family Controls / Screen Time APIs. I've encountered a strange issue when testing with multiple devices: The app works normally on the first device. When I install the same TestFlight build on a second device, the user completes the Family Controls authorization successfully. Immediately after authorization, an error appears: "Family Controls is only available for one application." After dismissing the error, the app still works normally. Screen Time / Shield functionality also appears to work as expected. The issue seems to occur specifically when authorizing the app on a second device. Has anyone encountered this error before?