Help,I have encountered a thorny problem! In systems with iOS 16.5 and above, there is a probability that the keyboard will not disappear after it appears. And once it appears, unless the app is restarted, all places where the keyboard is used cannot be closed. I have tried using the forced shutdown method [UIView endEditing:YES], but it didn't work. When this exception occurs, I notice that there will be two UITextEffectsWindow at the same time. Does anyone know how to solve it?

We're seeing sporadic crashes on devices running iOS 18.1 - both beta and release builds (22B83). The stack trace is always identical, a snippet of it below. As you can tell from the trace, it's happening in places we embed SwiftUI into UIKit via UIHostingController. Anyone else seeing this? 4 libobjc.A.dylib 0xbe2c _objc_fatalv(unsigned long long, unsigned long long, char const*, char*) + 30 5 libobjc.A.dylib 0xb040 weak_register_no_lock + 396 6 libobjc.A.dylib 0xac50 objc_storeWeak + 472 7 libswiftCore.dylib 0x43ac34 swift_unknownObjectWeakAssign + 24 8 SwiftUI 0xeb74c8 _UIHostingView.base.getter + 160 9 SwiftUI 0x92124 _UIHostingView.layoutSubviews() + 112 10 SwiftUI 0x47860 @objc _UIHostingView.layoutSubviews() + 36

since updating from 18.3 to 18.4, both on cellular and WiFi Networks I can’t connect to the internet. Since the phone wont connect to the internet I’m not able to turn off “find my iPhone“ to restore my iPhone to iOS 18.3 this way my iPhone is useless any ideas / thoughts about this?

Dear Apple Customer Support, I’m developing a new Swift iPadOS app and I want the app to run in landscape only (portrait disabled). In Xcode, under Target > General > Deployment Info > Device Orientation, if I select only Landscape Left and Landscape Right, the app builds successfully, but during upload/validation I receive this message and the upload is blocked: “Update the Info.plist: Support for all orientations will soon be required.” Could you please advise what the correct/recommended way is to keep an iPad app locked to landscape only while complying with the current App Store upload requirements? Is there a specific Info.plist configuration (e.g., UISupportedInterfaceOrientations~ipad) or another setting that should be used? Thank you,

I encountered a bug with drag-and-drop sorting in ios 26. I created a UITableView for dragging and dropping to adjust the order of the list. However, when I set the height of the cells to a custom height, some cells were not displayed during the dragging process. The tools I use are the official version of Xcode16.1 and the ios 26 emulator And I can also reproduce the same problem on the real device. class ViewController: UIViewController { private let tableView: UITableView = { let tableView = UITableView.init(frame: .zero, style: .grouped) tableView.backgroundColor = .clear tableView.estimatedSectionHeaderHeight = 50 tableView.isEditing = true tableView.showsVerticalScrollIndicator = false tableView.allowsSelectionDuringEditing = true return tableView }() var content: [Int] = [] override func viewDidLoad() { super.viewDidLoad() tableView.register(FTWatchGroupPageCell.self, forCellReuseIdentifier: "FTWatchGroupPageCell") tableView.delegate = self tableView.dataSource = self view.addSubview(tableView) for i in 1...100 { content.append(i) } tableView.reloadData() } override func viewDidLayoutSubviews() { super.viewDidLayoutSubviews() var frame = view.bounds frame.origin.y = 200 frame.size.height = frame.size.height - 200 tableView.frame = frame } } extension ViewController: UITableViewDelegate, UITableViewDataSource { func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int { return content.count } func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell { let cell = tableView.dequeueReusableCell(withIdentifier: "FTWatchGroupPageCell", for: indexPath) as! FTWatchGroupPageCell cell.label.text = "\(content[indexPath.row])" cell.label.sizeToFit() return cell } func tableView(_ tableView: UITableView, heightForRowAt indexPath: IndexPath) -> CGFloat { return 52.66 } public func tableView(_ tableView: UITableView, heightForHeaderInSection section: Int) -> CGFloat { return 0.01 } public func tableView(_ tableView: UITableView, heightForFooterInSection section: Int) -> CGFloat { return 0.01 } public func tableView(_ tableView: UITableView, canEditRowAt indexPath: IndexPath) -> Bool { return true } public func tableView(_ tableView: UITableView, editingStyleForRowAt indexPath: IndexPath) -> UITableViewCell.EditingStyle { return .none } public func tableView(_ tableView: UITableView, shouldIndentWhileEditingRowAt indexPath: IndexPath) -> Bool { return false } public func tableView(_ tableView: UITableView, canMoveRowAt indexPath: IndexPath) -> Bool { return true } public func tableView(_ tableView: UITableView, moveRowAt sourceIndexPath: IndexPath, to destinationIndexPath: IndexPath) { let item = content.remove(at: sourceIndexPath.row) content.insert(item, at: destinationIndexPath.row) tableView.reloadData() } } class FTWatchGroupPageCell: UITableViewCell { private let contentBackView = UIView() let label = UILabel() override init(style: UITableViewCell.CellStyle, reuseIdentifier: String?) { super.init(style: style, reuseIdentifier: reuseIdentifier) contentView.isHidden = true addSubview(contentBackView) contentBackView.backgroundColor = .red contentBackView.addSubview(label) label.textColor = .black label.font = .systemFont(ofSize: 14) contentBackView.frame = .init(x: 0, y: 0, width: 200, height: 30) } required init?(coder: NSCoder) { fatalError("init(coder:) has not been implemented") } override func layoutSubviews() { super.layoutSubviews() guard let reorderControlClass = NSClassFromString("UITableViewCellReorderControl"), let reorderControl = subviews.first(where: { $0.isKind(of: reorderControlClass) }) else { return } reorderControl.alpha = 0.02 reorderControl.subviews.forEach({ subView in if let imageView = subView as? UIImageView { imageView.image = UIImage() imageView.contentMode = .scaleAspectFit imageView.frame.size = CGSize(width: 20, height: 20) } }) } }

I'm trying to understand how UIDevice.current.identifierForVendor behaves when an iOS app is restored via iCloud onto a different physical device. Context I'm building an app that needs to detect whether it’s running on a newly restored device (for example, after the user transfers their iPhone via iCloud setup). To do this, I save the value of UIDevice.current.identifierForVendor?.uuidString in persistent storage (e.g., UserDefaults). The question If I install my app on Device A, store the identifierForVendor value, back up the device to iCloud, and then restore that backup onto Device B, will the restored app see the same identifierForVendor value, or a new one? More specifically: Does iCloud backup/restore preserve the underlying “vendor” ID across devices? Is the identifierForVendor tied only to the bundle identifier and vendor prefix, or also to the physical device hardware? If the user deletes all apps from the same vendor, then restores them from iCloud, is the ID reset? What I’ve found so far Apple’s docs say: “The value of this property is the same for apps that come from the same vendor running on the same device. If the user deletes all of that vendor’s apps from the device and then reinstalls one or more of them, the value may change.” However, it doesn’t explicitly mention what happens after iCloud restore onto a new device. Goal I want to know if it’s safe to use identifierForVendor to detect a new device context (e.g., trigger a refresh of a Firebase token when the user’s device changes). Environment iOS 17+ (latest) Swift / Capacitor app bridge Testing between iPhone 14 Pro → iPhone 15 Pro (iCloud restore)

Navigation Title no longer showing for first Tab in iOS/iPadOS 26 (Directives) in my app Starship SE Corps when running is Xcode 26 simulator and on iPad device itself running iPadOS 26 beta. Launch app Notice Navigation Title “Directives” is missing from top tab in Sidebar and Floating Tab View (iPad) and TabView (iOS). Navigate to other tabs and Navigation Titles appear as expected. Worked fine (as expected) in iOS/iPadOS 18.5, but broken in iOS/iPadOS 26. Reference Feedback: FB17987650

I am using SwiftData to model my data. For that i created a model called OrganizationData that contains various relationships to other entities. My data set is quite large and i am having a big performance issue when fetching all OrganizationData entities. I started debugging and looking at the sql debug log i noticed that when fetching my entities i run into faults for all relationships even when not accessing them. Fetching my entities: let fetchDescriptor = FetchDescriptor<OrganizationData>() let context = MapperContext(dataManager: self) let organizations = (try modelContainer.mainContext.fetch(fetchDescriptor)) Doing this fetch, also fetches all relationships. Each in a single query, for every OrganizationData entity. CoreData: annotation: to-many relationship fault "relationship1" for objectID 0x8aa5249772916e00 <x-coredata://B891FCEB-DF16-4E11-98E6-0AFB5D171A81/OrganizationData/p3869> fulfilled from database. Got 9 rows CoreData: annotation: to-many relationship fault "relationship2" for objectID 0x8aa5249772916e00 <x-coredata://B891FCEB-DF16-4E11-98E6-0AFB5D171A81/OrganizationData/p3869> fulfilled from database. Got 0 rows CoreData: annotation: to-many relationship fault "relationship3" for objectID 0x8aa5249772916e00 <x-coredata://B891FCEB-DF16-4E11-98E6-0AFB5D171A81/OrganizationData/p3869> fulfilled from database. Got 0 rows CoreData: annotation: to-many relationship fault "relationship4" for objectID 0x8aa5249772916e00 <x-coredata://B891FCEB-DF16-4E11-98E6-0AFB5D171A81/OrganizationData/p3869> fulfilled from database. Got 0 rows CoreData: annotation: to-many relationship fault "relationship5" for objectID 0x8aa5249772916e00 <x-coredata://B891FCEB-DF16-4E11-98E6-0AFB5D171A81/OrganizationData/p3869> fulfilled from database. Got 0 rows CoreData: annotation: to-many relationship fault "relationship6" for objectID 0x8aa5249772916e00 <x-coredata://B891FCEB-DF16-4E11-98E6-0AFB5D171A81/OrganizationData/p3869> fulfilled from database. Got 0 rows CoreData: annotation: to-many relationship fault "relationship7" for objectID 0x8aa5249772916e00 <x-coredata://B891FCEB-DF16-4E11-98E6-0AFB5D171A81/OrganizationData/p3869> fulfilled from database. Got 1 rows CoreData: annotation: to-many relationship fault "relationship8" for objectID 0x8aa5249772916e00 <x-coredata://B891FCEB-DF16-4E11-98E6-0AFB5D171A81/OrganizationData/p3869> fulfilled from database. Got 0 rows CoreData: annotation: to-many relationship fault "relationship9" for objectID 0x8aa5249772916e00 <x-coredata://B891FCEB-DF16-4E11-98E6-0AFB5D171A81/OrganizationData/p3869> fulfilled from database. Got 0 rows The relationships are all defined the same @Relationship(deleteRule: .cascade, inverse: \EntityData1.organization) var relationship1: [EntityData1] = [] Am i missing something? As far as i understood relationships are lazy and should only be faulted when accessing the property. But doing the fetch as described above already causes a query to happen, making the fetch take very long when using a large data set.

Dear Apple Developer Relations Team, We are currently reviewing the documentation for the UIDesignRequiresCompatibility Info.plist key. In the documentation, there is a warning that states: "Temporarily use this key while reviewing and refining your app’s UI for the design in the latest SDKs." However, in the adoption guide for Liquid Glass: Adopting Liquid Glass, we did not see any explicit requirement to force adoption of the Liquid Glass design. We have the Gojek app, which currently uses the UIDesignRequiresCompatibility key. To ensure long-term stability, we would like clarification on the following points: Future Support of the Key: Is it safe to continue using the UIDesignRequiresCompatibility key? Can you confirm whether this key will remain supported or if there are plans for it to be deprecated/removed in future iOS versions? Liquid Glass Adoption: Our app’s design guidelines do not align with the Liquid Glass style. Can you confirm that adoption of Liquid Glass is not mandatory, and that apps can continue to use their existing custom design guidelines without any restrictions? Compatibility with iOS 26: Are there any required changes we need to make to our existing views to ensure that the UI will continue to render as it does today on iOS 26 and beyond? We want to make sure we provide the best user experience while remaining compliant with Apple’s guidelines. Your clarification would help us plan our design and development roadmap accordingly. Thank you for your support and guidance.

We are currently implementing App Clips in our app. While we have carefully optimized the App Clip size to keep it lightweight (~3.69MB), we have noticed that on the first load, displaying the App Clip Card and activating the “Open” button takes a surprisingly long time (approximately 2–3 seconds). Subsequent loads appear to perform normally. We understand that this behavior may not be directly controllable from the app development side, but we would like to know if there are any possible ways to improve it. Minimizing the time it takes for users to access the content is extremely important, as delays on the first interaction can negatively impact the user experience. Any guidance or best practices to make the App Clip Card and its “Open” button respond faster on first load would be greatly appreciated.

Hi, Upon reviewing our app, we got feedback that our app icon within the Wallet app is not behaving as expected when the home screen is set to "light mode" only. In that case, on the home screen, the app icon remains its default color (e.g., red), regardless of the device's appearance settings (light or dark), which is expected. However, in the apple Wallet, e.g., under the From Apps from your device, app icons change their color (e.g., red in light mode, black in dark mode) when iOS appearance is changed - which is reported as an app issue. I've noticed that all apps in that section are changing the color, not just ours, so it seems to me like a bug in iOS or a behavior that was not clearly defined in the app store guidelines. If there is an API we must use to cover that case, which one would that be? Is this a bug that Apple should resolve, or is this the intended behaviour?

I'm a web developer of WebRTC based web app for video and audio calls. After updating to iOS 26.1 beta I noticed, that my app can't use microphone anymore. When I'm calling to getUserMedia with audio set to true, Safari returns error "No AVAudioSessionCaptureDevice device". Other WebRTC demo apps also can't access microphone on this firmware. And maybe it's connected somehow, but safari can't detect connected AirPods Pro 2 as an input device. So, this bug brakes any WebRTC app, that uses microphones.

I am encountering a critical issue where a custom background image on a UIToolbar fails to display when the app is built with Xcode 26 and run on iOS 26 beta. The exact same implementation works perfectly on iOS 18 and earlier versions. We first attempted to use the legacy setBackgroundImage method, which fails to render the image on iOS 26: // 1. Get Navigation Bar and set basic properties UINavigationBar* navBar = self.navigationBar; navBar.hidden = NO; navBar.translucent = NO; // 2. Setup the UIToolbar instance UIToolbar *toolBar = [[UIToolbar alloc] initWithFrame:navBar.bounds]; toolBar.autoresizingMask = UIViewAutoresizingFlexibleHeight | UIViewAutoresizingFlexibleWidth; // 3. Set the resizable image (This image does not appear on iOS 26) UIImage* imagePortrait = [UIImage imageNamed:@"nav_bg"]; UIEdgeInsets insets = UIEdgeInsetsMake(0.f, 6.f, 0.f, 6.f); [toolBar setBackgroundImage:[imagePortrait resizableImageWithCapInsets:insets] forToolbarPosition:UIToolbarPositionAny barMetrics:UIBarMetricsDefault]; We then migrated to the recommended modern UIToolbarAppearance to solve this, but the issue persists: // 1. Prepare Image UIImage* imagePortrait = [UIImage imageNamed:@"nav_bg"]; // Insets are applied via resizableImageWithCapInsets: (not shown in this snippet but implied) // 2. Configure UIToolbarAppearance UIToolbarAppearance *appearance = [[UIToolbarAppearance alloc] init]; appearance.backgroundImage = imagePortrait; // The image is correctly loaded (not nil) // 3. Apply the Appearance toolBar.standardAppearance = appearance; // We also applied to scrollEdgeAppearance and compactAppearance. Any information or recommended workarounds for displaying a custom background image on UIToolbar in the latest iOS 26 would be highly appreciated.

Hi everyone, I have the following issue that I have tried to tweak every possible modifier of ScrollView and still got the same result in iOS 26. Description: Create a SwiftUI ScrollView with scrollTargetBehavior of paging, also create a bottom UI view below the ScrollView. If the starting index is not 0, the position of current page will be off with part of previous page shown above it. It only happens on iOS 26, not on iOS 18. Also if bottom UI view (text view in this case) is removed, it also works fine. I want to see if there is a solution for it or it's an iOS 26 bug. Thanks! import SwiftUI struct ContentView: View { @State private var currentPageIndex: Int? = 3 var body: some View { VStack { scrollView Text("Bottom Bar") .frame(maxWidth: .infinity) .frame(height: 80) .background(.red) } .background(.black) } @ViewBuilder var scrollView: some View { VerticalPagerView( currentPageIndex: $currentPageIndex, itemCount: 10, content: Array(0...9).map { index in content(for: index) } ) } @ViewBuilder private func content(for index: Int) -> some View { // Empty view with random background color Color( red: Double((index * 25 + 0) % 255) / 255.0, green: Double((index * 25 + 80) % 255) / 255.0, blue: Double((index * 25 + 160) % 255) / 255.0 ) } } struct VerticalPagerView<Content: View>: View { @Binding private var currentPageIndex: Int? private let itemCount: Int private let content: [Content] init( currentPageIndex: Binding<Int?>, itemCount: Int, content: [Content] ) { self._currentPageIndex = currentPageIndex self.itemCount = itemCount self.content = content } var body: some View { GeometryReader { geometryReader in ScrollViewReader { reader in ScrollView(.vertical) { LazyVStack(spacing: 0) { ForEach(0 ..< itemCount, id: \.self) { index in content[index] .id(index) .containerRelativeFrame(.vertical, alignment: .center) .clipped() } } .frame(minHeight: geometryReader.size.height) .scrollTargetLayout() } .scrollIndicators(.hidden) .onAppear { guard let currentPageIndex = currentPageIndex else { return } reader.scrollTo(currentPageIndex, anchor: .center) } } .scrollPosition(id: $currentPageIndex, anchor: .center) .ignoresSafeArea() .scrollTargetBehavior(.paging) .onChange(of: currentPageIndex) { oldIndex, newIndex in } } } }

We’ve recently updated our app to adopt the native iOS 26 tab bar. Since then, we’ve started seeing crashes on iOS 26 devices with swift_getObjectType appearing in the stack. I’ve reviewed the logs in Organizer but couldn’t find anything conclusive. The issue seems isolated to iOS 26 and doesn’t reproduce on earlier versions. com.grofers.consumer_issue_2cc3a4a209ab2b47bfbdab919a320fa7_crash_session_68148be54ef5441fac56d3138d055bac_DNE_5_v2_stacktrace.txt

Getting this error in iPhone Portrait Mode with notch. Currrently using AVQueuePlayer to play more than 30 mp3 files one by one. All constraint properties are correct but error occures only in Apple iPhone Portrait Mode with notch series. But same code works on same iPhone in Landscape mode. **But I get this error: ** LoudnessManager.mm:709 unable to open stream for LoudnessManager plist Type: Error | Timestamp: 2025-02-07 | Process: | Library: AudioToolbox | Subsystem: com.apple.coreaudio | Category: aqme | TID: 0x42754 LoudnessManager.mm:709 unable to open stream for LoudnessManager plist LoudnessManager.mm:709 unable to open stream for LoudnessManager plist Timestamp: 2025-02-07 | Library: AudioToolbox | Subsystem: com.apple.coreaudio | Category: aqme

Device: iPhone 15pro, ios26.0 (23A 341) IOS version: 26.0 (23A 341) When using position: sticky; bottom: 0, the div is expected to stick to the bottom of the viewport when the browser toolbar hides while scrolling. However, it stops at the height where the toolbar was, instead of moving down with the disappearing toolbar. In the image below, the red-bordered navigation shows the situation where it does not stick to the bottom. i

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.

Is the Cancel button intentionally removed from UISearchBar (right side)? Even when using searchController with navigationItem also. showsCancelButton = true doesn’t display the cancel button. Also: When tapping the clear ("x") button inside the search field, the search is getting canceled, and searchBarCancelButtonClicked(_:) is triggered (Generally it should only clear text, not cancel search). If the search text is empty and I tap outside the search bar, the search is canceled. Also when I have tableview in my controller(like recent searches) below search bar and if I try to tap when editing started, action is not triggered(verified in sample too). Just cancellation is happening. In a split view controller, if the search is on the right side and I try to open the side panel, the search also gets canceled. Are these behaviors intentional changes, beta issues, or are we missing something in implementation?

Hi, I'm looking for the best way to use MLX models, particularly those I've fine-tuned, within a React Native application on iOS devices. Is there a recommended integration path or specific API for bridging MLX's capabilities to React Native for deployment on iPhones and iPads?