Only people using iPhone 15 and iPhone 15Pro (don't know about iPhone 15 plus or iPhone 15 pro max) are having problems with my App. All seems fine on 13, 14 and 16 as well as iPad The app is in testflight now. I cannot replicate the issue in MAC via virtual iPhone 15 , 15 plus, pro, or promax. What I see happening - it looks like users are seeing labels disappear, sometimes buttons are disappearing on the 15 pro and 15. I have an ingredient selection page where you can select the ingredients that you have. These are outlined and grouped to make choosing ingredients intuitive. I have a profile selector where you can choose by flavor, strength, body or mood. At the bottom I have three buttons , button one lets you choose if drinks are sorted or strictly matched. The last button allows the user to see the drinks they can make based on ingredients they have.This is done by matching the ingredients with a locally placed drinks list which contains a drink id, drink name, ingredients and profile information. Clicking the last button opens a flatlist. Users on iPhone 15 and iPhone 15Pro iOS 18 sometimes experience the three buttons at the bottom being gone altogether. then returning. After clicking the Drinks Available button the button label should change to hide available drinks, but sometimes that label disappears. The drinks flat list has space for many drinks but the labels for those drinks are not present until halfway down the list where one drink shows up. No other device behaves this way. It might be more common when there are large number of ingredients selected ....e.g., if about 50% of 211 ingredients selected it might be more likely to happen. This needs to be tested to verify,

Using a storyboard, I created a UIView containing an UIImageView and a UILabel, that I dragged into the navigation bar of one of my viewControllers. In my viewDidLoad I transform the view to move it down past the bounds of the navigation bar so its hidden initially navBarMiddleView.transform = .init(translationX: 0, y: 50) Then as the screen scrolls, I slowly move it up so it slides back into the middle of the navigationBar func scrollViewDidScroll(_ scrollView: UIScrollView) { let padding: CGFloat = 70 let adjustedOffset = (scrollView.contentOffset.y - padding) navBarMiddleView.transform = .init(translationX: 0, y: max(0, (50 - adjustedOffset))) } (The content is displayed in a collectionView cell as large content initially, and I want it to remain visible as the user scrolls down. So a mini view of the same data is moved up into the navigationBar) With iOS 26 the navigationBar is applying a blur effect to this view, even when its outside the bounds of the navigationBar, meaning the content its hovering on top of is slightly obscured. I don't know why this blur is being added, how do I remove it? I've tried the following based on recommendations from chatGPT but none have worked self.navigationController?.navigationBar.clipsToBounds = true self.navBarMiddleView.layer.allowsGroupOpacity = false self.navBarMiddleView.backgroundColor = .clear self.navBarMiddleView.isOpaque = true self.navBarMiddleView.layer.isOpaque = true I have my navigation bar setup with this appearence already: let navigationBarAppearance = UINavigationBarAppearance() navigationBarAppearance.configureWithOpaqueBackground() navigationBarAppearance.backgroundEffect = nil navigationBarAppearance.backgroundColor = UIColor.clear navigationBarAppearance.shadowColor = .clear navigationBarAppearance.titleTextAttributes = [ NSAttributedString.Key.foregroundColor: UIColor.colorNamed("Txt2"), NSAttributedString.Key.font: UIFont.custom(ofType: .bold, andSize: 20) ] UINavigationBar.appearance().standardAppearance = navigationBarAppearance UINavigationBar.appearance().compactAppearance = navigationBarAppearance UINavigationBar.appearance().scrollEdgeAppearance = navigationBarAppearance

We have an application WAVE PTT(Push to talk) and Application is in foreground state, When a user receives a cellular call and it is in the "ringing" state and application receives a VoIP APNS(video call) which is reported to CallKit. User rejects the Cellular call from CallKit UI, application Video call is also getting rejected (separate feedback - 19017978) and Here the issue is observed that an Application moved to background(OS26 beta 9). Issue is not observed in iOS 18 and older versions. Frequency : 1 out of 3. Please refer the sysdiagnose logs in below reported feedback ID. Feedback Ticket ID: 20187309 Syslogs Snippet reference: default 2025-09-10 12:30:06.991950 +0530 WAVE PTX 0x10e078100 - ApplicationStateTracker: UISceneDidEnterBackground

After updating to Xcode 26 my XCUITests are now failing as during execution exceptions are being raised and caught by my catch all breakpoint These exceptions are only raised during testing, and seem to be referencing some private internal property. It happens when trying to tap a button based off an accessibilityIdentifier e.g. accessibilityIdentifier = "tertiary-button" ... ... app.buttons["tertiary-button"].tap() The full error is: Thread 1: "[<UIKit.ButtonBarButtonVisualProvider 0x600003b4aa00> valueForUndefinedKey:]: this class is not key value coding-compliant for the key _titleButton." Anyone found any workarounds or solutions? I need to get my tests running on the liquid glass UI

If there is a Notification Service Extension which has the com.apple.developer.usernotifications.filtering entitlement, then does/how having that entitlement affect the preconditions for the NSE to be delivered a push? Specifically, if the app has not prompted for requestAuthorization() is it expected that the push will be delivered to the NSE or not? Thank you

This is really odd. If you setup a UISearchController with a preferredSearchBarPlacement of .stacked and you setup the search bar with scope buttons, then when the view controller is initially displayed, the currently hidden scope buttons block touch events from reaching the main view just below the search bar. But once the search is activated and dismissed, then the freshly hidden scope buttons no longer cause an issue. This is easily demonstrated by putting a UITableViewController in a UINavigationController. Setup the table view to show a few simple rows. Then setup a search controller using the following code: func setupSearch() { // Setup a stacked search bar with scope buttons // Before the search is ever activated, the hidden scope buttons block any touches in the main view controller // in the area just below the search bar. // Once the search is activated and dismissed, the problem goes away. It seems that displaying and hiding the // scope buttons at least once fixes the issue that exists beforehand. // This issue only exists in iOS/iPadOS 26, not iOS/iPadOS 18 or earlier. let search = UISearchController(searchResultsController: UIViewController()) search.hidesNavigationBarDuringPresentation = true search.obscuresBackgroundDuringPresentation = true search.scopeBarActivation = .onSearchActivation // Ensure button appear immediately let searchBar = search.searchBar searchBar.scopeButtonTitles = [ "One", "Two", "Three" ] self.navigationItem.searchController = search self.navigationItem.hidesSearchBarWhenScrolling = false // Issue appears even if this is true self.navigationItem.preferredSearchBarPlacement = .stacked } When first shown, before any attempt is made to activate the search, any attempt to tap on the upper 2/3 of the first row in the table view (which is just below the search bar) fails. If you tap on the lower 1/3 of the first row it works fine. If you then activate the search (now the scope buttons appear) and then dismiss the search (now the scope buttons are hidden again), then there is no issue tapping anywhere on the first row of the table. But if you restart the app, the problem starts over again. This problem happens on any iPhone or iPad, real or simulated, running iOS/iPadOS 26 RC. This is a regression from iOS 18 or earlier.

When trying to use a UISearchController setup with a UISearchBar that has scope buttons, the search controller's scopeBarActivation property is set to .onSearchActivation, the navigation item's preferredSearchBarPlacement property is set to .integrated. or .integratedButton, and the search bar/button appears in the navigation bar, then the scope buttons never appear. But space is made for where they should appear. Some relevant code in a UIViewController shown as the root view controller of a UINavigationController: private func setupSearch() { let sc = UISearchController(searchResultsController: UIViewController()) sc.delegate = self sc.obscuresBackgroundDuringPresentation = true // Setup search bar with scope buttons let bar = sc.searchBar bar.scopeButtonTitles = [ "One", "Two", "Three", "Four" ] bar.selectedScopeButtonIndex = 0 bar.delegate = self // Apply the search controller to the nav bar navigationItem.searchController = sc // BUG - Under iOS/iPadOS 26 RC, using .onSearchActivation results in the scope buttons never appearing at all // when using integrated placement in the nav bar. // Ensure the scope buttons appear immediately upon activating the search controller sc.scopeBarActivation = .onSearchActivation // This works but doesn't show the scope buttons until the user starts typing - that's too late for my needs //sc.scopeBarActivation = .automatic if #available(iOS 26.0, *) { // Under iOS 26 put the search icon in the nav bar - same issue for .integrated and .integratedButton navigationItem.preferredSearchBarPlacement = .integrated // .integratedButton // My toolbar is full so I need the search in the navigation bar navigationItem.searchBarPlacementAllowsToolbarIntegration = false // Ensure it's in the nav bar } else { // Under iOS 18 put the search bar in the nav bar below the title navigationItem.preferredSearchBarPlacement = .stacked } } I need the search bar in the navigation bar since the toolbar is full. And I need the scope buttons to appear immediately upon search activation. This problem happens on any real or simulated iPhone or iPad running iOS/iPadOS 26 RC.

As the title indicates the problem, the large title is shown but the small title in Navitation Bar view is not shown when scrolled up with iOS26 beta7. It works with iOS18 or earlier. Is this iOS26 bug?

Experiencing 100% CPU usage in SwiftUI app using UIHostingController, only on iOS 26 beta and Xcode beta. Issue involves excessive view updates in AttributeGraph propagation. Stack trace (main thread): thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP frame #0: 0x00000001c38b9aa4 AttributeGraph`AG::Graph::propagate_dirty(AG::AttributeID) + 416 frame #1: 0x00000001d9a743ec SwiftUICore`SwiftUI.ObservationGraphMutation.apply() -> () + 656 frame #2: 0x00000001d97c0d4c SwiftUICore`function signature specialization <Arg[2] = [Closure Propagated : closure #1 () -> () in SwiftUI.(AsyncTransaction in _F9F204BD2F8DB167A76F17F3FB1B3335).apply() -> (), Argument Types : [SwiftUI.AsyncTransaction]> of generic specialization <()> of closure #1 () throws -> τ_0_0 in SwiftUI.withTransaction<τ_0_0>(SwiftUI.Transaction, () throws -> τ_0_0) throws -> τ_0_0 + 336 frame #3: 0x00000001d9a6ac80 SwiftUICore`merged function signature specialization <Arg[3] = Owned To Guaranteed> of function signature specialization <Arg[1] = [Closure Propagated : implicit closure #2 () -> () in implicit closure #1 @Sendable (SwiftUI.(AsyncTransaction in _F9F204BD2F8DB167A76F17F3FB1B3335)) -> () -> () in SwiftUI.GraphHost.flushTransactions() -> (), Argument Types : [SwiftUI.AsyncTransaction]> of SwiftUI.GraphHost.runTransaction(_: Swift.Optional<SwiftUI.Transaction>, do: () -> (), id: Swift.Optional<Swift.UInt32>) -> () + 196 frame #4: 0x00000001d9a52ab0 SwiftUICore`SwiftUI.GraphHost.flushTransactions() -> () + 176 frame #5: 0x00000001d8461aac SwiftUI`closure #1 (SwiftUI.GraphHost) -> () in SwiftUI._UIHostingView._renderForTest(interval: Swift.Double) -> () + 20 frame #6: 0x00000001d9bf3b38 SwiftUICore`partial apply forwarder for closure #1 (SwiftUI.ViewGraph) -> τ_1_0 in SwiftUI.ViewGraphRootValueUpdater.updateGraph<τ_0_0>(body: (SwiftUI.GraphHost) -> τ_1_0) -> τ_1_0 + 20 frame #7: 0x00000001d9e16dc4 SwiftUICore`SwiftUI.ViewGraphRootValueUpdater._updateViewGraph<τ_0_0>(body: (SwiftUI.ViewGraph) -> τ_1_0) -> Swift.Optional<τ_1_0> + 200 frame #8: 0x00000001d9e1546c SwiftUICore`SwiftUI.ViewGraphRootValueUpdater.updateGraph<τ_0_0>(body: (SwiftUI.GraphHost) -> τ_1_0) -> τ_1_0 + 136 frame #9: 0x00000001d8461a7c SwiftUI`closure #1 () -> () in closure #1 () -> () in closure #1 () -> () in SwiftUI._UIHostingView.beginTransaction() -> () + 144 frame #10: 0x00000001d846aed0 SwiftUI`partial apply forwarder for closure #1 () -> () in closure #1 () -> () in closure #1 () -> () in SwiftUI._UIHostingView.beginTransaction() -> () + 20 frame #11: 0x00000001d984f814 SwiftUICore`closure #1 () throws -> τ_0_0 in static SwiftUI.Update.ensure<τ_0_0>(() throws -> τ_0_0) throws -> τ_0_0 + 48 frame #12: 0x00000001d984e114 SwiftUICore`static SwiftUI.Update.ensure<τ_0_0>(() throws -> τ_0_0) throws -> τ_0_0 + 96 frame #13: 0x00000001d846aeac SwiftUI`partial apply forwarder for closure #1 () -> () in closure #1 () -> () in SwiftUI._UIHostingView.beginTransaction() -> () + 64 frame #14: 0x00000001851eab1c UIKitCore`___lldb_unnamed_symbol311742 + 20 * frame #15: 0x00000001852b56a8 UIKitCore`___lldb_unnamed_symbol315200 + 44 frame #16: 0x0000000185175120 UIKitCore`___lldb_unnamed_symbol308851 + 20 frame #17: 0x00000001d984e920 SwiftUICore`static SwiftUI.Update.dispatchImmediately<τ_0_0>(reason: Swift.Optional<SwiftUI.CustomEventTrace.ActionEventType.Reason>, _: () -> τ_0_0) -> τ_0_0 + 300 frame #18: 0x00000001d95a7428 SwiftUICore`static SwiftUI.ViewGraphHostUpdate.dispatchImmediately<τ_0_0>(() -> τ_0_0) -> τ_0_0 + 40 frame #19: 0x00000001852b59dc UIKitCore`___lldb_unnamed_symbol315204 + 192 frame #20: 0x00000001852b54a4 UIKitCore`___lldb_unnamed_symbol315199 + 64 frame #21: 0x0000000185745dd4 UIKitCore`_UIUpdateSequenceRunNext + 120 frame #22: 0x0000000186144fac UIKitCore`schedulerStepScheduledMainSectionContinue + 56 frame #23: 0x00000002505ad150 UpdateCycle`UC::DriverCore::continueProcessing() + 36 frame #24: 0x0000000180445b20 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 24 frame #25: 0x0000000180445a68 CoreFoundation`__CFRunLoopDoSource0 + 168 frame #26: 0x00000001804451f4 CoreFoundation`__CFRunLoopDoSources0 + 220 frame #27: 0x00000001804443a8 CoreFoundation`__CFRunLoopRun + 756 frame #28: 0x000000018043f458 CoreFoundation`_CFRunLoopRunSpecificWithOptions + 496 frame #29: 0x00000001928d19bc GraphicsServices`GSEventRunModal + 116 frame #30: 0x0000000186224480 UIKitCore`-[UIApplication _run] + 772 frame #31: 0x0000000186228650 UIKitCore`UIApplicationMain + 124 frame #32: 0x000000010bb1b504 MyApp.debug.dylib`main at main.swift:13:1 frame #33: 0x00000001043813d0 dyld_sim`start_sim + 20 frame #34: 0x000000010468ab98 dyld`start + 6076 Used let _ = Self.printChanges() in my SwiftUI View and got infinite changes of \_UICornerProvider.<computed 0x000000018527ffd8 (Optional<UICoordinateSpace>)> changed. Reproduces only on beta; works on stable iOS. Likely beta-specific bug in SwiftUI rendering.

On iOS, I have a deep link that opens the app directly if it’s already installed. If the app is not installed, the user is first redirected to my website, which then automatically redirects them to the App Store. The deep link contains a parameter that should be passed to the app. On Android, this is possible because the Play Store provides a referrer ID after installation, which allows the app to fetch the parameter on first launch. What options are available on iOS to achieve the same behavior — i.e., preserving and passing the deep link parameter through the App Store install flow? I’m already aware of solutions like Branch.io, other deferred deep linking services, and the clipboard approach, so I’m looking for alternative approaches.

All of these issues appear when the search controller is set on the view controller's navigationItem and the search controller's searchBar has its scopeButtonTitles set. So far the following issues are affecting my app on iOS/iPadOS 26 as of beta 7: When the scopeBarActivation of UISearchController is set to .onSearchActivation, the preferredSearchBarPlacement of the navigationItem is set to .integratedButton, and the searchBarPlacementAllowsToolbarIntegration is set to false (forcing the search icon to appear in the nav bar), on both iPhones and iPads, the scope buttons never appear. They don't appear when the search is activated. They don't appear when any text is entered into the search bar. FB19771313 I attempted to work around that issue by setting the scopeBarActivation to .manual. I then show the scope bar in the didPresentSearchController delegate method and hide the scope bar in the willDismissSearchController. On an iPhone this works though the display is a bit clunky. On an iPad, the scope bar does appear via the code in didPresentSearchController, but when any scope bar button is tapped, the search controller is dismissed. This happens when the app is horizontally regular. When the app on the iPad is horizontally compact, the buttons work but the search bar's text is not correctly aligned within the search bar. Quite the mess really. I still need to post a bug report for this issue. But if issue 1 above is fixed then I don't need this workaround. When the scopeBarActivation of UISearchController is set to .onSearchActivation, the preferredSearchBarPlacement of the navigationItem is set to .stacked, and the hidesSearchBarWhenScrolling property of the navigationItem is set to false (always show the search bar), and this is all used in a UITableViewController, then upon initial display of the view controller on an iPhone or iPad, you are unable to tap on the first row of the table view except on the very bottom of the row. The currently hidden scope bar is stealing the touches. If you activate and then cancel the search (making the scope bar appear and then disappear) then you are able to tap on the first row as expected. The initially hidden scope bar also bleeds through the first row of the table. It's faint but you can tell it's not quite right. Again, this is resolved by activating and then canceling the search once. FB17888632 When the scopeBarActivation of UISearchController is set to .onSearchActivation, the preferredSearchBarPlacement of the navigationItem is set to integrated or .integratedButton, and the toolbar is shown, then on iPhones (where the search bar/icon appears in the toolbar) the scope buttons appear (at the top of the screen) the first time the search is activated. But if you cancel the search and then activate it again, the search bar never appears a second (or later) time. On an iPad the search bar/icon appears in the nav bar and you end up with the same issue as #1 above. FB17890125 Issues 3 and 4 were reported against beta 1 and still haven't been fixed. But if issue 1 is resolved on iPhone, iPad, and Mac (via Mac Catalyst), then I personally won't be affected by issues 2, 3, or 4 any more (but of course all 4 issues need to be fixed). And by resolved, I mean that the scope bar appears and disappears when it is supposed to each and every time the search is activated and cancelled (not just the first time). The scope bar doesn't interfere with touch events upon initial display of the view controller. And there are no visual glitches no matter what the horizontal size class is on an iPad. I really hope the UIKit team can get these resolved before iOS/iPadOS 26 GM.

Hi, I am experiencing a critical issue with my app (dbMobil) in its published state. When the app is installed via TestFlight, it works without any problems and no errors can be detected. However, when downloading the same app from the App Store, it immediately crashes for many users without displaying any error message, directly at app start. This issue also occurs on my own test devices: TestFlight version: works flawlessly App Store version: crashes immediately upon launch It appears that there must be a difference between the version I submitted and published via TestFlight and the one currently available on the App Store. Could you please provide me with feedback on what differences may exist between these two versions and where the cause of this issue might lie? Thank you in advance for your assistance.

Hi. We are writing to report a critical issue we've encountered following the recent release of iOS 26 beta 6. After updating our test devices, we discovered that our application is no longer able to establish HTTPS connections to several of our managed FQDNs. This issue was not present in beta 5 and appears to be a direct result of changes introduced in beta 6. The specific FQDNs that are currently unreachable are: d.socdm.com i.socdm.com tg.scodm.com We have reviewed the official iOS & iPadOS 26 Beta 6 Release Notes, particularly the updates related to TLS. While the notes mention changes, we have confirmed that our servers for all affected FQDNs support TLS 1.2, so we believe they should still be compliant. We have also investigated several of Apple's support documents regarding TLS connection requirements (e.g., HT214774, HT214041), but the information does not seem to apply to our situation, and we are currently unable to identify the root cause of this connection failure. https://support.apple.com/en-us/102028 https://support.apple.com/en-us/103214 Although we hope this issue might be resolved in beta 7 or later, the official release is fast approaching, and this has become a critical concern for us. Could you please provide any advice or insight into what might be causing this issue? Any guidance on potential changes in the networking or security frameworks in beta 6 that could affect TLS connections would be greatly appreciated. We have attached the relevant code snippet that triggers the error, along with the corresponding Xcode logs, for your review. Thank you for your time and assistance. #import "ViewController.h" @interface ViewController () @end @implementation ViewController - (void)viewDidLoad { [super viewDidLoad]; NSURL *url = [NSURL URLWithString:@"https://i.socdm.com/sdk/js/adg-script-loader-b-stg.js"]; NSMutableURLRequest *req = [NSMutableURLRequest requestWithURL:url cachePolicy:NSURLRequestReloadIgnoringLocalCacheData timeoutInterval:30.0]; [self sendWithRequest:req completionHandler:^(NSData *_Nullable data, NSHTTPURLResponse *_Nonnull response, NSError *_Nullable error) { if (error){ NSLog(@"Error occurred: %@", error.localizedDescription); return; }else{ NSLog(@"Success! Status Code: %ld", (long)response.statusCode); } }]; } - (void) sendWithRequest:(NSMutableURLRequest *)request completionHandler:(void (^ _Nullable)(NSData *_Nullable data, NSHTTPURLResponse *response, NSError *_Nullable error))completionHandler { NSURLSessionConfiguration *configuration = [NSURLSessionConfiguration defaultSessionConfiguration]; NSURLSession *session = nil; session = [NSURLSession sessionWithConfiguration:configuration delegate:self delegateQueue:nil]; NSURLSessionTask *task = [session dataTaskWithRequest:request completionHandler:^(NSData *data, NSURLResponse *response, NSError *error) { [session finishTasksAndInvalidate]; NSHTTPURLResponse *httpResponse = (NSHTTPURLResponse *) response; if (error) { if (completionHandler) { completionHandler(nil, httpResponse, error); } } else { if (completionHandler) { completionHandler(data, httpResponse, nil); } } }]; [task resume]; } @end error Connection 1: default TLS Trust evaluation failed(-9807) Connection 1: TLS Trust encountered error 3:-9807 Connection 1: encountered error(3:-9807) Task <C50BB081-E1DA-40FF-A1E5-A03A2C4CB733>.<1> HTTP load failed, 0/0 bytes (error code: -1202 [3:-9807]) Task <C50BB081-E1DA-40FF-A1E5-A03A2C4CB733>.<1> finished with error [-1202] Error Domain=NSURLErrorDomain Code=-1202 "The certificate for this server is invalid. You might be connecting to a server that is pretending to be “i.socdm.com” which could put your confidential information at risk." UserInfo={NSLocalizedRecoverySuggestion=Would you like to connect to the server anyway?, _kCFStreamErrorDomainKey=3, NSErrorPeerCertificateChainKey=( "<cert(0x10621ca00) s: *.socdm.com i: GlobalSign RSA OV SSL CA 2018>", "<cert(0x106324e00) s: GlobalSign RSA OV SSL CA 2018 i: GlobalSign>" ), NSErrorClientCertificateStateKey=0, NSErrorFailingURLKey=https://i.socdm.com/sdk/js/adg-script-loader-b-stg.js, NSErrorFailingURLStringKey=https://i.socdm.com/sdk/js/adg-script-loader-b-stg.js, NSUnderlyingError=0x1062bf960 {Error Domain=kCFErrorDomainCFNetwork Code=-1202 "(null)" UserInfo={_kCFStreamPropertySSLClientCertificateState=0, kCFStreamPropertySSLPeerTrust=<SecTrustRef: 0x10609d140>, _kCFNetworkCFStreamSSLErrorOriginalValue=-9807, _kCFStreamErrorDomainKey=3, _kCFStreamErrorCodeKey=-9807, kCFStreamPropertySSLPeerCertificates=( "<cert(0x10621ca00) s: *.socdm.com i: GlobalSign RSA OV SSL CA 2018>", "<cert(0x106324e00) s: GlobalSign RSA OV SSL CA 2018 i: GlobalSign>" )}}, _NSURLErrorRelatedURLSessionTaskErrorKey=( "LocalDataTask <C50BB081-E1DA-40FF-A1E5-A03A2C4CB733>.<1>" ), _kCFStreamErrorCodeKey=-9807, _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <C50BB081-E1DA-40FF-A1E5-A03A2C4CB733>.<1>, NSURLErrorFailingURLPeerTrustErrorKey=<SecTrustRef: 0x10609d140>, NSLocalizedDescription=The certificate for this server is invalid. You might be connecting to a server that is pretending to be “i.socdm.com” which could put your confidential information at risk.} Error occurred: The certificate for this server is invalid. You might be connecting to a server that is pretending to be “i.socdm.com” which could put your confidential information at risk. 折りたたむ

Environment iOS 26.0 (device), Xcode 26 beta 7 SwiftUI TabView using the new Tab("…", value:) API iPhone only (aware that minimize is iPhone-only) Issue .tabBarMinimizeBehavior(.onScrollDown) only works reliably in my Settings tab. In my other tabs (Dashboard / Games / Help), the tab bar does not minimize when scrolling, even though the content is scrollable. The main difference: those tabs are wrapped in a NavigationStack(path:) with a bound NavigationPath. Settings has no path binding. Repro (minimal) import SwiftUI enum TabSel: Hashable { case dashboard, games, settings } struct Root: View { @State private var selection: TabSel = .dashboard // Per-tab paths @State private var dashPath = NavigationPath() @State private var gamesPath = NavigationPath() var body: some View { if #available(iOS 26, *) { TabView(selection: $selection) { // ❌ Does NOT minimize when scrolling SwiftUI.Tab("Dashboard", systemImage: "square.grid.2x2.fill", value: .dashboard) { NavigationStack(path: $dashPath) { ScrollView { // ... } } } // ❌ Same here SwiftUI.Tab("Games", systemImage: "sportscourt.fill", value: .games) { NavigationStack(path: $gamesPath) { ScrollView { // ... } } } // ✅ Minimizes as expected on scroll SwiftUI.Tab("Settings", systemImage: "gear", value: .settings) { // Note: also inside a NavigationStack, but no `path` binding NavigationStack { ScrollView { // ... } } } } .tabBarMinimizeBehavior(.onScrollDown) } } } What I tried Removing nested stacks in child views → no change Ensured no .tabViewStyle(.page) / PageTabViewStyle() anywhere No toolbar(.hidden, for: .tabBar) on the tab roots Confirmed the content is scrollable and tested on device Expected All tabs should minimize the tab bar on downward scroll. Actual Only the Settings tab (no path binding) minimizes; tabs with NavigationStack(path:) do not. Questions Is this a known issue with NavigationStack(path:) and .tabBarMinimizeBehavior in iOS 26 betas? Any recommended workaround that keeps a bound NavigationPath per tab?

Has anyone encountered a situation like mine below? I’ve submitted feedback, but it seems like I’ll have to wait for a while. ContactProviderManager Fails with Custom domainIdentifier, Works Only with "defaultDomain" Category: Developer Tools / Frameworks Subcategory: ContactProvider Framework Reproducibility: Always iOS Version: iOS 18.0 (and later) Xcode Version: Xcode 16.0 (or later)  Description: When initializing a ContactProviderManager with a custom ContactProviderDomain using any identifier other than "defaultDomain", the initializer throws a ContactProviderError.domainNotRegistered error. The documentation for ContactProviderDomain (https://developer.apple.com/documentation/contactprovider/contactproviderdomain) does not provide any method to register custom identifiers, making it impossible to use ContactProviderManager with a desired custom identifier. The only successful case is when the identifier is "defaultDomain". print("Error: (error)") // No error, initialization succeeds Steps to Reproduce: Create a Contact Provider Extension in an iOS app targeting iOS 18.0. In host app, Attempt to initialize a ContactProviderManager with a custom ContactProviderDomain identifier: ​import ContactProvider func enableExtensionExample() async {    do {        // The app creates a contact provider manager with custom domain.        let manager =  try ContactProviderManager(domainIdentifier: "com.mycompany.customdomain")               // May prompt the person to enable the custom domain.        try await manager.enable()    } catch {       print("Error: \(error)") // Prints ContactProviderError.domainNotRegistered    } } Try the same with the default identifier: ​import ContactProvider func enableExtensionExample() async {    do {        // The app creates a contact provider manager with a default domain.        let manager =  try ContactProviderManager(domainIdentifier: "defaultDomain")               // May prompt the person to enable the default domain.        try await manager.enable()    } catch {       print("Error: \(error)") // No error, initialization succeeds    } } Build and run the app on a device or simulator running iOS 18.0 or later. Observe that the initializer fails with domainNotRegistered for any identifier other than "defaultDomain". Expected Behavior: The ContactProviderManager should initialize successfully with any valid ContactProviderDomain identifier, provided the domain is properly configured or registered, allowing developers to use custom identifiers for organizing contacts (e.g., for different categories or sources). Actual Behavior: The ContactProviderManager initializer throws ContactProviderError.domainNotRegistered for any ContactProviderDomain identifier other than "defaultDomain". Only the "defaultDomain" identifier succeeds, limiting the ability to use custom domains. Impact: Developers cannot use custom identifiers to categorize or manage contacts in separate domains, restricting the ContactProvider framework’s flexibility. This forces reliance on the "defaultDomain" identifier, which may not suit use cases requiring distinct contact groups (e.g., personal vs. business contacts). Suggested Fix: Provide an API to register custom ContactProviderDomain identifiers, such as a ContactProviderManager.register(domain:) method. Update the ContactProviderDomain and ContactProviderManager documentation to clarify how to use custom identifiers or explicitly state if only "defaultDomain" is supported. If custom identifiers are not intended to be supported, document this limitation clearly to avoid developer confusion. Feedback : FB20104001 (ContactProviderManager Fails with Custom domainIdentifier, Works Only with "defaultDomain")

Observed few times that providerDidBegin(_:) delegate never called for the complete app session after app init(as part of this CXProvider registered) which was built with SDK 26 and running on iOS 26. This issue observed multiple times with our testing. Since there is no providerDidBegin:, client is marking CallKit as not ready and never report any calls for VoIP APNS and ended up in app crash due to "[PKPushRegistry _terminateAppIfThereAreUnhandledVoIPPushes]" Please refer for sysdiagnose logs : FB19778306

Hi there, I'm using WCSession to communicate watchOS companion with its iOS app. Every time watch app becomes "active", it needs to fetch data from iOS app, which works e.g. turning my hand back and forth. But only when the app is opened after it was minimised by pressing digital crown, it didn't fetch data. My assumption is that scenePhase doesn't emit a change on reopen. Here is the ContentView of watch app: import SwiftUI struct ContentView: View { @EnvironmentObject private var iOSAppConnector: IOSAppConnector @Environment(\.scenePhase) private var scenePhase @State private var showOpenCategories = true var body: some View { NavigationStack { VStack { if iOSAppConnector.items.isEmpty { WelcomeView() } else { ScrollView { VStack(spacing: 10) { ForEach(iOSAppConnector.items, id: \.self.name) { item in ItemView(item: item) } } } .task { DispatchQueue.main.asyncAfter(deadline: .now() + 0.5) { loadItems() } } .onChange(of: scenePhase, initial: true) { newPhase, _ in if newPhase == .active { loadItems() } } } fileprivate func loadItems() -> Void { if iOSAppConnector.items.isEmpty { iOSAppConnector.loadItems() } } } What could be the issue? Thanks. Best regards Sanjeev

When my Intents extension resolves an INStartCallIntent and returns .continueInApp while the device is locked, the call does not proceed unless the user unlocks the device. After unlocking, the app receives the NSUserActivity and CallKit proceeds normally. My expectation is that the native CallKit outgoing UI should appear and the call should start without requiring unlock — especially when using AirPods, where attention is not available. Steps to Reproduce Pair and connect AirPods. Lock the iPhone. Start music playback (e.g. Apple Music). Place the phone face down (or cover Face ID sensors so attention isn’t available). Say: “Hey Siri, call Tommy with DiscoMonday(My app name).” Observed Behavior Music mutes briefly. Siri says “Calling Tommy with DiscoMonday.” Lock screen shows “Require Face ID / passcode.” After several seconds, music resumes. The app is not launched, no NSUserActivity is delivered, and no CXStartCallAction occurs. With the phone face up, the same phrase launches the app, triggers CXStartCallAction, and the call proceeds via CallKit after faceID. Expected Behavior From the lock screen, Siri should hand off INStartCallIntent to the app, which immediately requests CXStartCallAction and drives the CallKit UI (reportOutgoingCall(...startedConnectingAt:) → ...connectedAt:), without requiring device unlock, regardless of orientation or attention availability when AirPods are connected.

Hi There We are looking to download the iOS 18.4 Simulator Runtime but due to restrictions on internet access in our company we are unable to use XCode to download the required file. Is there an alternative location we can browse to and download the iOS 18.4 Simulator Runtime file? We checked the downloads sections of the Apple Developer site but can only find 18.2 version of the iOS Simulator Runtime. Thanks

Hello, I'm developing a feature for my app, that allows users to challenge their friends. The friend request functionality is built using Universal Links, but I've run into a significant issue. The Universal Links are correctly deep-linking into the app. However, once the app opens, nothing happens—the friend request acceptance or rejection flow does not occur. This prevents users from completing friend requests and building their friend list. Here are examples of the Universal Links I'm generating: https://www.strike-force.app/invite?type=invite&amp;amp;userID=... https://www.strike-force.app/invite?type=invite&amp;amp;friendRequestID=... https://www.strike-force.app/profile?userID=... I've recently updated my cloudflare-worker.js to serve a paths array of ["*"] in the AASA file, so I believe the links themselves should be valid. Technical Details &amp;amp; Error Logs In the console, I am consistently seeing the following error message: Cannot issue sandbox extension for URL:https://www.strike-force.app/invite?token=7EF1E439-090B-4DF2-BE64-9904F50A3F8B Received port for identifier response: &amp;lt;(null)&amp;gt; with error:Error Domain=RBSServiceErrorDomain Code=1 "Client not entitled" UserInfo={RBSEntitlement=com.apple.runningboard.process-state, NSLocalizedFailureReason=Client not entitled, RBSPermanent=false} elapsedCPUTimeForFrontBoard couldn't generate a task port This error appears to be related to entitlements and process state, but I am not sure if it's the root cause of the Universal Link issue or a separate problem. The 'Client not entitled' error on line 3 has had me chasing down entitlements issues. But, I've added the Associated Domains entitlement with the proper applink URLs and verified this in my Developer Portal. I've regenerated my provisioning profile, manually installed it, and selected/de-selected Automatically Manage Signing. As well I've verified my AASA file and it's correctly being served via HTTPS and returning a 200. curl -i https://strike-force.app/.well-known/apple-app-site-association curl -i https://www.strike-force.app/.well-known/apple-app-site-association I am looking for guidance on why the friend request flow is not being triggered after a successful deep-link and how I can fix the related error. Any insights or suggestions would be greatly appreciated.