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.

Hi! I'm using AccessorySetupKit with CoreBluetooth state restoration. My understanding is that using AccessorySetupKit is a now pre-requisite to enabling the state restoration/preservation apis, so I went that route — and pairing, handoff, and restoration on search discovery or connection completion seem to be working Where I'm stuck: my accessory is poll-based. I read it by writing a request and reading the response. Then I send a new request. the BLE accessory never pushes data on its own. Since restoration only seems to wake my app on an inbound BLE event, if the app gets terminated mid-session while the connection's still healthy, nothing wakes the app and polling just quietly stops. Is there a recommended way to handle this for a request/response device? Thanks!

Hello, I’m indexing content in my app using Core Spotlight. On iOS, I notice that I can only search using the title or displayName even if I index more content in Spotlight using CSSearchableItem or IndexedEntity. On macOS, I can search for any content or attributes of the CSSearchableItem or IndexedEntity. See attached screenshots (the item id on iOS is 708 and the item id on macOS is 741). On both platforms, the content can be fetched using a CSSearchQuery. I filed a feedback with an attached project: FB23317556 Regards Axel

Hello, I’m using Core Spotlight in my app. I notice that if I use CSSearchableIndex to index the content, it cannot be found in Spotlight on macOS 27. if I use instead an IndexedEntity (from the AppIntents framework), the content can be found on macOS 27. The content seems to correctly be saved because I can fetch the content using a CSSearchQuery in both cases. I filed a feedback with a project attached: FB23317414 Regards, Axel

When a user uses the "Add Name" feature on an unknown number in their Call Logs, the name appears under "Other Known Contacts" in the native iOS Contacts app. The Problem: CNContactStore completely ignores these contacts during a standard fetch/enumeration. When user gives limited permission they can search for that contact and select it, but it won't be visible in my App as it's not technically a contact. Is CNContactStore intentionally blocked from reading "Other Known Contacts" for privacy reasons or are there any future plans to expose API so that third party apps can access it?

Hey, I've been banging my head against this for a few days now and genuinely can't figure out if it's something on my end or an Apple backend issue. My app has WeatherKit integrated and it works fine in the simulator, but on my physical device I consistently get this in the console: Failed to generate jwt token for: com.apple.weatherkit.authservice Error Domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "(null)" Things I've already tried and ruled out: WeatherKit capability is enabled in the App ID on developer.apple.com ✓ com.apple.developer.weatherkit = true is in the entitlements file ✓ Removed and re-added the capability in Xcode Signing & Capabilities ✓ Clean Build Folder, fresh install on device ✓ The location coordinates are valid (hardcoded lat/lon in Bavaria) ✓ The weird part is that it's not a location issue — Error Code 2 from WDSJWTAuthenticatorServiceListener suggests the JWT generation itself is failing before any location lookup even happens. I've had this App ID since early this year, WeatherKit was working at some point, and I'm not sure what changed. My fallback to Open-Meteo works fine so the app isn't broken, but I'd like to actually use the API I'm paying for. I also opened a support ticket but got redirected to the forums, so here I am. Anyone else seen this recently or know if there's something on the provisioning side I'm missing?

Hi Apple Developer Support / WeatherKit team, I’m seeing WeatherKit fail on a physical iPhone with what appears to be a JWT / permission issue, even though the app appears to be correctly configured and signed with the WeatherKit entitlement. App / project context: App name: Signals Platform: iOS Framework: SwiftUI WeatherKit usage: Native WeatherKit framework, using WeatherService.shared.weather(for:) Purpose: Showing a small morning weather summary inside the app What I have already verified: Active Apple Developer Program membership WeatherKit capability enabled for the App ID in Apple Developer Portal WeatherKit capability enabled in the App Capabilities tab WeatherKit capability added in Xcode Signing & Capabilities Automatic signing enabled Built and tested on a physical iPhone device Location permission is requested and granted The app binary appears to include the WeatherKit entitlement The embedded provisioning profile appears to include the WeatherKit entitlement Issue: WeatherKit still fails at runtime with a JWT / permission-related error. Could you please help verify whether: The WeatherKit entitlement is correctly attached to my App ID and provisioning profile My Team ID / App ID has WeatherKit access fully enabled on Apple’s backend There are any backend propagation delays or stuck entitlement states WeatherDaemon has permission to generate JWTs for this app There is anything else I need to reset or regenerate, such as provisioning profiles, certificates, or App ID capabilities I can provide: Team ID Bundle ID provisioning profile UUID entitlement output from codesign device logs / WeatherKit error logs screenshots of App ID capability settings Thank you.

I'm trying to get an NSMetadataQuery to work using an NSPredicate build with: [NSPredicate predicateFromMetadataQueryString:@"InRange(kMDItemFSCreationDate,$time.today,$time.today(+1))"] That string is the one I copied from Finder's Get Info window after saving a search of "Created is Today". It at least parses and runs without exceptions, but the results are totally wrong. It only returns files created on 12/31/2000. I've tried dozens of different attempts at building a predicate that uses these $time functions, but they all fail parsing and throw an exception. What I really need to be able to do is build the predicate with a format string, because the attribute is stored in a property: [NSPredicate predicateWithFormat:@"InRange(%K,$time.today,$time.today(+1))", self.attr]; That throws an exception. [NSPredicate predicateFromMetadataQueryString:[NSString stringWithFormat:@"InRange(%@,$time.today,$time.today(+1))", self.attr]]; That does not throw an exception, but it gives the same 12/31/2000 results.