I have a custom keyboard (UIInputViewController, Full Access). For a dictation feature it opens its containing app to record audio (the keyboard can't use the microphone) and then needs to return the user to the host app they were typing in. That requires knowing the host app. Through iOS 26.3 this worked, because the host bundle id was exposed on the keyboard's input-session connection. On iOS 26.4 / 26.5 it is now nil, and every route I have tried is blocked: UIInputViewController _hostApplicationBundleIdentifier -> nil _hostProcessIdentifier and the host audit token are available, but: RBSProcessHandle handleForAuditToken: / handleForIdentifier: -> "Client not entitled" SecTaskCopySigningIdentifier / SecTaskCopyValueForEntitlement -> nil (sandbox) proc_pidpath -> EPERM UIKeyboardImpl _remoteAppId / _remoteLocalizedAppName -> nil The keyboard arbiter client-change event fires in SpringBoard, not in the extension process However, at least one shipping keyboard still does this on iOS 26.5. I verified in device logs that Yandex Keyboard launches its container app with a URL containing the correct, current host bundle id, and it is live: it reported net.whatsapp.WhatsApp, then net.whatsapp.WhatsAppSMB when the host was WhatsApp Business. So the capability clearly still exists for some apps. Questions: Is there a supported API on iOS 26.4+ for a keyboard extension to identify its host app? If it requires an entitlement, can developers request it, and how? If there is no public path, is the intended approach the system "back to previous app" breadcrumb (manual) plus a containing-app round trip? I have also filed Feedback (FB#######). Thanks.

Hi everyone, I’ve been stuck on an issue with iOS Universal Links for about a week and could really use some help. The problem When tapping a Universal Link on iOS, my Flutter app opens correctly (desired behavior) — but immediately afterward, Safari opens the same link in the browser. So both the app and the browser open. This only happens on iOS. On Android everything works as expected. What works If the link is simply the domain, like: https://mydomain.com …then the app opens without triggering the browser afterward. This is the correct behavior. What doesn’t work If the link includes a path or parameters, like: https://mydomain.com/path https://mydomain.com/path?param=value …then the app opens, and then the browser opens immediately after. What I’ve tried Verified my AASA file using Branch’s validator: https://branch.io/resources/aasa-validator/ → The AASA file is valid. Universal Links do open the correct screen inside the app — the issue is the unwanted second step (Safari opening). Behavior is consistent across different iOS devices. Extra details Using Flutter. Universal Links set up with the standard configuration (associatedDomains, AASA hosted at /.well-known/apple-app-site-association, etc.). Question Has anyone encountered this issue where Universal Links with paths/params open the app and then open Safari? What could cause iOS to trigger the browser fallback even when the AASA file is valid and the app handles the link correctly? Any insights, debugging tips, or known edge cases would be incredibly appreciated!

Hello Apple Developer Support Team, We understand from the Declared Age Range documentation that, in some regulated regions, the system automatically provides the person’s age range and they can’t decline sharing it with the app. We have implemented the API as prescribed in the documentation. For certain users in Texas, the API returns: isEligibleForAgeFeatures == true declaredAgeRangeRequired == true However, in our testing we observe that these Texas users can still decline sharing their age range, either via the system prompt or later via Settings, which results in no age range being provided to the app. This behavior appears inconsistent with the documentation’s statement that, in regulated regions, the person “can’t decline” sharing their age range, and it also raises questions for us about how this aligns with the applicable legal requirements in Texas. Could you please clarify: Whether this behavior (Texas users being able to decline sharing their age range even when declaredAgeRangeRequired is true) is expected, and Under what exact conditions the “they can’t decline sharing” behavior is enforced for Texas accounts (for example, only for new Apple Accounts created in Texas after a certain date, or only for particular age categories)? Any guidance on how we should interpret isEligibleForAgeFeatures and declaredAgeRangeRequired in this scenario would be greatly appreciated. Thank you.

Environment: iOS 26.5, Message Filter app extension (IdentityLookup framework), offline filtering. Setup My Message Filter Extension performs offline string matching on the message body and returns one of: ILMessageFilterAction.allow / .junk / .transaction / .promotion In the Messages app the filtering UI shows these folders: Messages (the main/default folder), Transactions, Promotions, Junk. .allow is expected to surface a message in the main Messages folder. The documented behavior (API docs + WWDC22 "Explore SMS message filters") only describes a static mapping from action → folder. On iOS 26.5 I'm seeing what looks like a stateful, per-sender behavior that I cannot find documented anywhere, and I can't tell whether it is intended or a bug. Test methodology All messages in every sequence are sent from the same single phone number. Before each Case, I fully clear the receive history for that number, so every sequence starts from a clean slate with no prior state for that sender. The notation shows how many conversations/entries appear in each folder after each step. Case A — first message = allow allow → Messages: 1 promotion → Messages: 2 (allow + promotion), Promotions: 1 junk → everything collapses into Junk; Messages & Promotions become empty every subsequent message lands in Junk regardless of the action I return Case B — first message = allow, then transaction allow → Messages: 1 transaction → Messages: 2 (allow + transaction), Transactions: 1 junk → everything collapses into Junk; Messages & Transactions empty every subsequent message lands in Junk regardless of returned action Case C — first message = transaction transaction → Messages: 1, Transactions: 1 ← also appears in Messages allow → Messages: 2, Transactions: 1 promotion → Messages: 3, Transactions: 1, Promotions: 1 junk → Messages: 4, Transactions: 1, Promotions: 1, Junk: 1 (NOTE: here junk does NOT collapse the thread, and there is no "sticky junk") Case D — first message = promotion promotion → Promotions: 1 only (does NOT appear in Messages) allow → Messages: 2 (the earlier promotion now also appears in Messages), Promotions: 1 junk → everything collapses into Junk (sticky, same as Case A/B) every subsequent message lands in Junk regardless of returned action My core question: are the following two behaviors by design, or are they bugs? (1) "Sticky junk" after allow-first / promotion-first. In Cases A, B and D, once .junk is returned the whole sender thread collapses into Junk, and from then on every message is forced into Junk regardless of the action my extension returns. Is this expected/by-design, or a bug? If by design: is it permanent, and what resets it — does the extension have any control, or is it purely user-driven (e.g. the user moving the thread out of Junk)? What concerns me is that the system appears to ignore my returned action entirely once this state is entered. (2) .transaction-first behaving differently from .allow-first. A sender whose first message is .transaction (Case C) behaves differently: the message also appears in the main Messages folder, and a later .junk does not collapse the thread (no sticky junk). Is this .transaction-first behavior expected/by-design, or a bug? If by design, what is the underlying rule that makes .transaction-first confer this state while .allow-first does not? Since the history is cleared before each test, this is determined purely by the first action returned. Additional clarifying questions Is any of this per-sender state behavior documented beyond the static action → folder mapping in the API docs / WWDC22 "Explore SMS message filters"? If so, where? More generally, what determines whether a categorized (.transaction / .promotion) message is also mirrored into the main Messages folder? Thanks — I'd like my extension's return values to produce predictable categorization for users, and right now this first-message-dependent behavior makes that hard to reason about.

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!

With the 27 OSes using UserDefaults.standard.integer(forKey: ) can cause a crash with EXC_BAD_ACCESS (code=1, address=0x0) It has been seen on a Multiplatform app, up to now tested on iOS/iPadOS and visionOS 27 Beta 1. In our code we use UserDefaults.standard.integer(forKey: ) from a singleton called during the SwiftUI app init(), and we don't know yet if this is the only moment there is a crash as we can't go farther. The API should return 0 if it can't get a value. There is no reason the app should crash if the API conforms to its contract. Running the same code from Xcode on iOS 26 runs it without issue. FeedBack FB23310748

Hello, Quick clarification regarding age ratings: If a user is 17 years old and wants to download a 16+ app, is parental approval required? Or is parental consent only needed if the app’s rating does not match (or exceeds) the user’s actual age? Also, is this fully enforced by Apple, or is it up to developers how to implement these checks? Thanks!

Hello there, I am trying to clarify whether iOS 26 changed the expected Phone Recents behavior for CallKit calls reported with CXHandle.generic. On iOS 18 and earlier, CallKit calls reported with: CXHandle(type: .generic, value: <stable custom identifier>) were grouped and displayed in Phone Recents based on the stable handle value. The details/history screen for a Recents entry showed calls for that same handle value. On iOS 26, the same approach no longer appears to work the same way. Observed behavior on iOS 26 I tested multiple stable CXHandle.generic values. The Recents rows are created, but when opening the details/history screen for one Recents entry, the history shows all calls, not only calls for the selected generic handle value. I also tested other handle types: CXHandle(type: .emailAddress, value: <stable email-like identifier>) works as expected: Recents grouping and the details/history screen are isolated to that handle value. CXHandle(type: .phoneNumber, value: <phone number>) also works as expected for real phone-number-style identities: Recents grouping and the details/history screen are isolated to that phone number. CXHandle(type: .generic, value: <stable custom identifier>) does not work the same way on iOS 26: the details/history screen is not isolated to that generic handle value and instead shows all calls. Questions Is CXHandle.generic still intended to be a supported identity for Phone Recents grouping and the details/history screen on iOS 26? Given that .emailAddress and .phoneNumber handles appear to isolate history correctly, is .generic intentionally treated differently by the iOS 26 Phone app, or is this a regression? Did iOS 26 change Phone Recents/details matching so that CXHandle.generic values are no longer used as isolated per-caller identities? If this behavior is intentional, what handle type should be used for stable non-phone CallKit identities? Is using CXHandle(type: .emailAddress, value: "@example.invalid") an acceptable supported approach for stable non-phone identities, if the value is not a real user email address? Is there documentation describing the iOS 26 Phone Recents identity-matching behavior for CallKit calls? Minimal repro Configure a CXProvider with calls included in Recents. Report several CallKit calls using different stable generic handles, for example: CXHandle(type: .generic, value: "app-target-1") CXHandle(type: .generic, value: "app-target-2") End the calls. Open Phone Recents on iOS 26. Open the details/history screen for one of the Recents entries. Expected result: The details/history screen shows only calls for the selected generic handle value. Actual result: The details/history screen shows all calls. Could you clarify whether this is expected behavior on iOS 26, a regression, or an unsupported use of CXHandle.generic? Thank you.

Original discussion pre iOS 26 Our app uses Auth0 with HTTPS callback, we've found the issue where AASA file is not ready immediately when app is initially launched, which is the exact issue from the above link. The issue seems mostly fixed on later versions on iOS 18, however, we are seeing some indications of a regression on iOS 26. Here's some measurement over the last week. | Platform | iOS 18 | iOS 26 | |---------------|----------|--------| | Adoption rate | 55% | 45% | | Issue seen | 1 | 5 | | Recover? | Yes | No | This only 1 iOS 18 instance was able to recover after 1 second after the first try, however, all iOS 26 instances were not able to recover in couple tens of seconds and less than 1 minute, the user eventually gave up. Is there a way to force app to update AASA file? Are there some iOS setting (like using a VPN) that could potentially downgrade the AASA fetch? Related Auth0 discussion: https://community.auth0.com/t/ios-application-not- recognizing-auth0-associated-domain/134847/27

We are seeing a reproducible scenario on iOS 26 where incoming VoIP push notifications are never delivered when the device has been idle and screen-locked for 30+ minutes. The same failure was observed simultaneously on WhatsApp, and Microsoft Teams and our app as well, on the same device during one incident, confirming this is a platform-level issue and not specific to our implementation. We have captured full system logs across three separate incidents. Below are the exact log sequences. Incident — All VoIP apps fail simultaneously (Our app, WhatsApp, Teams) Device: iPhone 17 Pro · iOS: 18.x · Network: 5G NSA (kNRNSA) The device had been idle with the screen locked for approximately 31 minutes. An LTE cell handover caused apsd to begin an APNs reconnection. powerd entered policy 3 before apsd reached channel-flow viable, defuncting the app. 17:45:59.562 symptomsd New RRC 0 when previous 1 from pdp_ip0 ↑ Radio drops to RRC_Idle. Device has been idle since 17:14:56 (31 min). 17:46:01.206 CommCenter #I Mapping the registration state to kRegisteredHome ↑ LTE cell handover triggers RRC reconnect. 17:46:01.330 apsd [C138 IPv4#b71cac13:5223 ready parent-flow (satisfied (Path is satisfied), interface: pdp_ip0[lte], scoped, ipv4, ipv6, dns, expensive, uses cell, LQM: good)] event: path:satisfied_change @594.391s ↑ APNs path re-satisfied. Reconnection begins. channel-flow viable NOT yet reached — TLS handshake still in progress. 17:48:08.057 apsd Powerd has requested assertion activity update ↑ Warning: powerd about to change policy. ── 2 minutes 40 seconds after APNs reconnect started ── 17:48:41.248 powerd Sending com.apple.powerd.assertionpolicy 3 17:48:41.250 apsd Update assertion policy 3 17:48:41.250 powerd Activity changes from 0x1 to 0x0. UseActiveState:0 17:48:41.250 powerd hidActive:0 displayOff:1 assertionActivityValid:0 ↑ Screen off, device locked. OS enters restricted idle. apsd restricted. APNs reconnection abandoned. 17:48:42.669 kernel necp_process_defunct_list: necp_update_client abort nexus error (2) for pid 1518 Comera ↑ Kernel terminates Comera's network stack via NECP. No API available to prevent this. WhatsApp and Teams remain suspended — no DEFUNCT, but apsd in policy 3 means no push delivery for them either. ── Dead zone: VoIP pushes for all 3 apps undeliverable ── 17:50:04.028 powerd Process CommCenter.104 Created SystemIsActive "com.apple.ipTelephony.sipIncoming.cell" ↑ Incoming cellular PSTN call forces system wake. 17:50:04.494 powerd Sending com.apple.powerd.assertionpolicy 0 17:50:04.598 apsd Update assertion policy 0 ↑ Full wake. Queued VoIP pushes from Comera, WhatsApp, and Teams are delivered simultaneously. Gap between channel-flow viable needed and actual delivery: 4 minutes 3 seconds. Recovery trigger: external cellular call from carrier — not any app action. Working case (same test, different conditions) Device: iPhone 17 Pro · iOS: 26.5.1 · Screen unlocked, no hotspot 19:2x:xx apsd policy state {downgradeWhenLocked: NO, isSystemLocked: NO, isConnectedOnUltraConstrainedInterface: NO} ↑ Device unlocked. No policy 3. Comera NOT defuncted. Push delivered. Call rings normally. Our implementation PKPushRegistry is held strongly and re-registered on every applicationWillEnterForeground reportNewIncomingCall(with:update:completion:) is called synchronously within pushRegistry(_:didReceiveIncomingPushWith:) VoIP background mode entitlement is present App has com.apple.developer.pushkit.voip entitlement Questions Is there any entitlement or API to prevent NECP from defuncting a process holding an active PKPushRegistry? The VoIP push entitlement exists for exactly this background delivery scenario. Is pushDisallowed being applied to apps with VoIP push entitlements when InternetSharingActive == 1 intentional? Should VoIP entitlements exempt an app from the Internet Sharing Policy gate in dasd? Is there a documented way to know when apsd has fully completed APNs reconnection (i.e. channel-flow viable) so a server can time push retries more accurately within a call validity window? What is the recommended apns-expiration value for VoIP pushes to survive brief APNs reconnection windows without exceeding a 60-second call validity period? Full log stream captures available for all incidents.

Hello, In my app, I want to create a CSSearchableItem using the initialiser that accepts an appEntity so I can update the item expirationDate when indexing. This initialiser is marked as iOS 18.0+ but as soon as I launch my app, it crashes. I filed a feedback: FB23270394 Can you help? Thank you Axel dyld[62169]: Symbol not found: _$s10AppIntents13IndexedEntityPAAE15hideInSpotlightSbvg Referenced from: <150E43FA-D9F4-3DF3-88C1-86E3DA3B272B> /Users/axel/Library/Developer/CoreSimulator/Devices/2C645A0F-45E5-429E-82EE-0C71D83407E3/data/Containers/Bundle/Application/18F00389-5CE8-49A2-883A-CDA38DDB03C4/Skipper.app/Skipper.debug.dylib Expected in: <F5744EDB-79CF-333C-A49A-8E9C5C3ACD10> /Library/Developer/CoreSimulator/Volumes/iOS_22A3351/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 18.0.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks/AppIntents.framework/AppIntents Symbol not found: _$s10AppIntents13IndexedEntityPAAE15hideInSpotlightSbvg Referenced from: <150E43FA-D9F4-3DF3-88C1-86E3DA3B272B> /Users/axel/Library/Developer/CoreSimulator/Devices/2C645A0F-45E5-429E-82EE-0C71D83407E3/data/Containers/Bundle/Application/18F00389-5CE8-49A2-883A-CDA38DDB03C4/Skipper.app/Skipper.debug.dylib Expected in: <F5744EDB-79CF-333C-A49A-8E9C5C3ACD10> /Library/Developer/CoreSimulator/Volumes/iOS_22A3351/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 18.0.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks/AppIntents.framework/AppIntents dyld config: DYLD_ROOT_PATH=/Library/Developer/CoreSimulator/Volumes/iOS_22A3351/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 18.0.simruntime/Contents/Resources/RuntimeRoot DYLD_LIBRARY_PATH=/Users/axel/Library/Developer/Xcode/DerivedData/Skipper-gayhthkwqznqqkeoqazrmncvolcq/Build/Products/Debug-iphonesimulator DYLD_INSERT_LIBRARIES=/Library/Developer/CoreSimulator/Volumes/iOS_22A3351/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 18.0.simruntime/Contents/Resources/RuntimeRoot/usr/lib/libLogRedirect.dylib:/Library/Developer/CoreSimulator/Volumes/iOS_22A3351/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 18.0.simruntime/Contents/Resources/RuntimeRoot/usr/lib/libMainThreadChecker.dylib:/usr/lib/libRPAC.dylib:/Library/Developer/CoreSimulator/Volumes/iOS_22A3351/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 18.0.simruntime/Contents/Resources/RuntimeRoot/usr/lib/libViewDebuggerSupport.dylib DYLD_FRAMEWORK_PATH=/Users/axel/Library/Developer/Xcode/DerivedData/Skipper-gayhthkwqznqqkeoqazrmncvolcq/Build/Products/Debug-iphonesimulator:/Users/axel/Library/Developer/Xcode/DerivedData/Skipper-gayhthkwqznqqkeoqazrmncvolcq/Build/Products/Debug-iphonesimulator/PackageFrameworks DYLD_FALLBACK_FRAMEWORK_PATH=/Library/Developer/CoreSimulator/Volumes/iOS_22A3351/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 18.0.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks DYLD_FALLBACK_LIBRARY_PATH=/Library/Developer/CoreSimulator/Volumes/iOS_22A3351/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 18.0.simruntime/Contents/Resources/RuntimeRoot/usr/lib Debug session ended with code 9: killed

I enabled the WeatherKit capability on my App ID (com.saimcan.darkweather, Team 6SWSD6V4ZC) about 12 hours ago. The entitlement is embedded in the binary and the provisioning profile authorizes it, but every request fails at the JWT generation step. Error from the logs: Error Domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "(null)" Relevant log excerpt (iOS 26.4 Simulator, same result on a physical device): [AuthService] Calling process is 3rd party process and has the correct entitlement ... accepting the connection [AuthService] Received proxy request for generating a jwt token. url=https://weatherkit.apple.com [WeatherDataService] Starting to generate JWT token request. bundleIdentifier=com.saimcan.darkweather [AuthService] Signed successfully [WeatherDataService] Make new JWT token request. requestIdentifier=... [AuthService] Failed to generate jwt token ... Code=2 What I have verified: Active Apple Developer Program membership (renewed through April 2027) All agreements accepted WeatherKit capability enabled on the App ID codesign -d --entitlements confirms com.apple.developer.weatherkit in the built binary embedded.mobileprovision also includes com.apple.developer.weatherkit App Group (group.com.saimcan.darkweather.shared) correctly bound to both the app and widget App IDs Since "Signed successfully" is logged, the device-side auth plumbing is working. The rejection appears to be server-side. Could someone from the WeatherKit team check whether JWT minting is enabled for this Team ID / Bundle ID? Team ID: 6SWSD6V4ZC Bundle ID: com.saimcan.darkweather

I would like to clarify the expected behavior of a default App Clip link. In my testing, the App Clip card was presented even though the full app was installed. Could you please confirm whether this is the intended behavior of a default App Clip link? Environment: Invocation source: Safari / Notes app Thank you for your assistance.

Hello team, I am trying to develop a solution to intercept a native cellular phone call, process its conversation audio or screen call before it is been answered. Do we have any framework to build such kind of feature.

NSJSONSerialization silently drops U+FEFF from JSON string content — keys merge, characters vanish TL;DR: NSJSONSerialization deletes U+FEFF (ZERO WIDTH NO-BREAK SPACE / BOM) from anywhere inside parsed JSON strings — not just a leading document BOM, and even when written as the \uFEFF escape (it's removed after unescaping). Distinct strings/keys silently collapse onto their U+FEFF-less twins. If you're seeing JSON keys mysteriously merge or a character disappear from a parsed value, this is probably why. It is not your code. Workaround and exhaustive scope below. The workaround Two options, depending on how attached you are to Foundation: A. Stay on NSJSONSerialization — swap U+FEFF for a private-use sentinel before parsing, restore after. You must handle both the raw bytes and the \uFEFF escape (the escape bites too, since deletion happens post-unescape): // 1. Pick a private-use scalar you've verified is absent from the source text. // 2. Replace every in-content U+FEFF (raw char AND \uFEFF escape) with it. // 3. Parse. NSJSONSerialization preserves the sentinel. // 4. Recursively restore the sentinel -> U+FEFF in the parsed tree. static id RestoreSentinel(id o, NSString *s, NSString *bom) { if ([o isKindOfClass:NSString.class]) return [o rangeOfString:s].location == NSNotFound ? o : [o stringByReplacingOccurrencesOfString:s withString:bom]; if ([o isKindOfClass:NSArray.class]) { NSMutableArray *a = [NSMutableArray arrayWithCapacity:[o count]]; for (id e in o) [a addObject:RestoreSentinel(e, s, bom)]; return a; } if ([o isKindOfClass:NSDictionary.class]) { NSMutableDictionary *d = [NSMutableDictionary dictionary]; [o enumerateKeysAndObjectsUsingBlock:^(id k, id v, BOOL *stop) { d[RestoreSentinel(k, s, bom)] = RestoreSentinel(v, s, bom); }]; return d; } return o; } Swap the escape form with a backslash-parity-aware regex so \uFEFF (escaped backslash + literal "uFEFF") is left intact: (?<!\\)((?:\\\\)*)\\u[Ff][Ee][Ff][Ff] -> $1<sentinel> B. Don't use Foundation for this file — a spec-compliant C parser like ++yyjson++ preserves U+FEFF and is faster on large files. (This is the route swift-transformers took for tokenizer.json.) Minimal repro // Object keys collapse: NSData *d1 = [@"{\"\\uFEFF#\":1,\"#\":2}" dataUsingEncoding:NSUTF8StringEncoding]; id o1 = [NSJSONSerialization JSONObjectWithData:d1 options:0 error:nil]; // EXPECTED: 2 keys ("\uFEFF#" and "#"); ACTUAL: 1 key ("#") — \uFEFF stripped, keys merged // String content lost: NSData *d2 = [@"[\"\\uFEFF\"]" dataUsingEncoding:NSUTF8StringEncoding]; id o2 = [NSJSONSerialization JSONObjectWithData:d2 options:0 error:nil]; // EXPECTED: ["\uFEFF"] (one code point); ACTUAL: [""] (empty string) Same outcome whether U+FEFF arrives as raw EF BB BF bytes or the \uFEFF escape. Why this is a bug, not a quirk Per RFC 8259 §7, a JSON string is a sequence of Unicode code points; U+FEFF is ordinary content and doesn't require escaping. Tolerating a leading document BOM is fine — deleting U+FEFF from string content is not. U+FEFF leads a double life (BOM signal vs. ZERO WIDTH NO-BREAK SPACE character); Foundation treats every occurrence as a stray BOM to scrub. Scope — exhaustive, not anecdotal I swept all 1,112,064 valid Unicode scalars (U+0000–U+10FFFF minus surrogates) through a parse round-trip, in both the \uFEFF-escape and raw-UTF-8 forms: U+FEFF is the only scalar altered. Every other scalar round-trips byte-identically — including the other zero-widths (U+200B, U+2060, U+00A0), which all survive. No Unicode normalization occurs (NFD stays decomposed, combining sequences and compatibility characters are preserved). So this is a deliberate BOM-stripping heuristic applied too broadly to string content — narrow and fixable, not general mangling. Why it's nasty in practice U+FEFF is zero-width, so the corruption is invisible — no trace in a diff or editor. Real-world hit: ML tokenizer vocabularies (e.g. Google's Gemma) legitimately contain U+FEFF-bearing tokens; loading tokenizer.json via NSJSONSerialization collapses those keys and assigns wrong token IDs, with zero visible symptom until output is subtly wrong. Filed as FB23271905 — please dupe if this has bitten you. More duplicates is what gets it triaged.

I can reproduce the bug that CallKit doesn't active audiosession after the outgoing call put on hold because of an incoming call. VoIP calling with CallKit Steps to reproduce: Download SpeakerBox example app from the link above and start it with XCode Start a new outgoing call Call your phone from other phone Hold and Accept the call After a few secs finish the call from the other phone The outgoing call will be still on hold Click on the call and click Toggle Hold The call won't be active again because the audiosession is activated. Logs: Received provider(_:didDeactivate:) Received provider(_:didDeactivate:) Received provider(_:didDeactivate:) Received provider(_:didDeactivate:) Received provider(_:didDeactivate:) Requested transaction successfully Starting audio Type: stdio AURemoteIO.cpp:1162 failed: 561017449 (enable 3, outf< 1 ch, 44100 Hz, Float32> inf< 1 ch, 44100 Hz, Float32>) Type: Error | Timestamp: 2024-08-15 12:20:29.949437+02:00 | Process: Speakerbox | Library: libEmbeddedSystemAUs.dylib | Subsystem: com.apple.coreaudio | Category: aurioc | TID: 0x19540d AVAEInternal.h:109 [AVAudioEngineGraph.mm:1344:Initialize: (err = PerformCommand(*outputNode, kAUInitialize, NULL, 0)): error 561017449 Type: Error | Timestamp: 2024-08-15 12:20:29.949619+02:00 | Process: Speakerbox | Library: AVFAudio | Subsystem: com.apple.avfaudio | Category: avae | TID: 0x19540d Couldn't start Apple Voice Processing IO: Error Domain=com.apple.coreaudio.avfaudio Code=561017449 "(null)" UserInfo={failed call=err = PerformCommand(*outputNode, kAUInitialize, NULL, 0)} Type: Notice | Timestamp: 2024-08-15 12:20:29.949730+02:00 | Process: Speakerbox | Library: Speakerbox | TID: 0x19540d Route change: Type: Notice | Timestamp: 2024-08-15 12:20:30.167498+02:00 | Process: Speakerbox | Library: Speakerbox | TID: 0x19540d ReasonUnknown Type: Notice | Timestamp: 2024-08-15 12:20:30.167549+02:00 | Process: Speakerbox | Library: Speakerbox | TID: 0x19540d Previous route: Type: Notice | Timestamp: 2024-08-15 12:20:30.167568+02:00 | Process: Speakerbox | Library: Speakerbox | TID: 0x19540d <AVAudioSessionRouteDescription: 0x302c00bc0, inputs = ( "<AVAudioSessionPortDescription: 0x302c01330, type = MicrophoneBuiltIn; name = iPhone Mikrofon; UID = Built-In Microphone; selectedDataSource = (null)>" ); outputs = ( "<AVAudioSessionPortDescription: 0x302c004d0, type = Receiver; name = Vev\U0151; UID = Built-In Receiver; selectedDataSource = (null)>" )> Type: Notice | Timestamp: 2024-08-15 12:20:30.167626+02:00 | Process: Speakerbox | Library: Speakerbox | TID: 0x19540d

Hello Apple Developer Team, I'm implementing the DeclaredAgeRange framework to support age assurance requirements related to Texas SB 2420. After reading the documentation for: AgeRangeService.shared.isEligibleForAgeFeatures I noticed the discussion states: "Check whether the person using your app is in a region that requires Age Assurance." My understanding is that isEligibleForAgeFeatures uses the user's location and account settings internally to determine whether age assurance requirements apply. However, I am unclear about the expected implementation flow. My questions are: Should developers manually determine whether a user is located in Texas (for example using Core Location, IP-based geolocation, or other methods) before calling requestAgeRange()? Or is Apple recommending that developers simply call: let eligible = try await AgeRangeService.shared.isEligibleForAgeFeatures and rely entirely on the framework to determine whether Texas age assurance requirements apply? If a user is located in Texas and age assurance is required, will isEligibleForAgeFeatures reliably return true without the app needing any location permission? Is there any supported API that allows developers to know which specific region/state triggered the age assurance requirement, or should developers treat isEligibleForAgeFeatures == true as the only signal needed? My goal is to implement the framework according to Apple's intended design while avoiding unnecessary collection of location data. Thank you for any clarification.

Hello, I want to echo the DeviceActivityReport "concurrency" problems flagged in https://developer.apple.com/forums/thread/720549, and ask a related question. (Thanks to Kmart and other Apple dev support folks who have been monitoring these forums and responding diligently.) I would like to display daily and weekly stats in the same view, broken down by specific apps (as in the native Screen Time). However, instantiating multiple DeviceActivityReport objects with different filters and/or different contexts leads to confusion, where the two views will incorrectly and intermittently swap data or duplicate data where it shouldn't (seemingly upon some interval when the extension provides fresh data). There isn't documentation on how to display multiple reports at once. Is the idea that logic for multiple reports should be embedded within the extension itself in the makeConfiguration() function and there should only be a single DeviceActivityReport in the main App, or is this a bug? Even with a single DeviceActivityReport, I run into inconsistencies where the View provided by the extension takes multiple seconds to load or fails to load altogether. The behavior seems random...I will build the application with the same code multiple times and see different behavior each time. Finally, a plug for better support in the Simulator for the entire set of Screen Time APIs. Thanks!

Hi, I have a app group registered in mac os app called gorup.com.company.app and i am saving the key/values in userdefaults to this with suitname. within the mac os app the group userdedaults write/read are working fine. I have a switt cli app with same app group registered in the code signing entitilement for the swit cli app. trying to read the group user default key value registered in mac os app in swift cli app returning no value. this was working fine with macOS 26. Is there some changes have been made in macos 27 in regaard to this?

Hello team, I am trying to develop a solution to intercept a native cellular phone call, process its conversation audio or screen call before it is been answered. Do we have any framework to build such kind of feature.