Post

Replies

Boosts

Views

Activity

iOS 26 Phone Recents: CXHandle.generic no longer groups CallKit VoIP calls/history by handle value
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.
1
0
371
Jun ’26
iOS 26 UISearchController always appears at the bottom instead of top with preferredSearchBarPlacement = .stacked
Hi everyone, I’m running into a strange issue with UISearchController placement with iOS 26 SDK. In one of my view controllers, I was able to move the search bar to the top of the navigation bar by setting: navigationItem.searchController = searchController navigationItem.hidesSearchBarWhenScrolling = false navigationItem.preferredSearchBarPlacement = .stacked This works as expected — the search bar is placed at the top. However, in another view controller with almost identical configuration, the search bar always shows up at the bottom. If I delay the setup with DispatchQueue.main.async, it appears at the bottom; if I don’t, it doesn’t appear at all. Both VCs are wrapped in their own UINavigationController. So my questions are: Has anyone faced this issue where preferredSearchBarPlacement = .stacked is ignored? Are there hidden requirements or limitations for placing the search bar at the top? Why could the same setup behave differently in two controllers? Any help or ideas would be appreciated!
Topic: UI Frameworks SubTopic: UIKit Tags:
3
0
829
Feb ’26
iOS 26 Phone Recents: CXHandle.generic no longer groups CallKit VoIP calls/history by handle value
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.
Replies
1
Boosts
0
Views
371
Activity
Jun ’26
iOS 26 UISearchController always appears at the bottom instead of top with preferredSearchBarPlacement = .stacked
Hi everyone, I’m running into a strange issue with UISearchController placement with iOS 26 SDK. In one of my view controllers, I was able to move the search bar to the top of the navigation bar by setting: navigationItem.searchController = searchController navigationItem.hidesSearchBarWhenScrolling = false navigationItem.preferredSearchBarPlacement = .stacked This works as expected — the search bar is placed at the top. However, in another view controller with almost identical configuration, the search bar always shows up at the bottom. If I delay the setup with DispatchQueue.main.async, it appears at the bottom; if I don’t, it doesn’t appear at all. Both VCs are wrapped in their own UINavigationController. So my questions are: Has anyone faced this issue where preferredSearchBarPlacement = .stacked is ignored? Are there hidden requirements or limitations for placing the search bar at the top? Why could the same setup behave differently in two controllers? Any help or ideas would be appreciated!
Topic: UI Frameworks SubTopic: UIKit Tags:
Replies
3
Boosts
0
Views
829
Activity
Feb ’26