I have following code and made it invoke every time when a UIViewController presents another UIViewController through method swizzling. When I try to access the Password management app while input password, these code will be invoked and the presenting VC is instance of UITrackingElementWindowController. It will crash [presentingVC beginAppearanceTransition:NO animated:NO]; [presentingVC endAppearanceTransition];

From what I understand, you’re meant to pass information like a view model to a content view through its configuration state. What about callbacks (e.g. something like didClickButton)? They aren’t “inputs” into the content configuration like a view model would be, but it feels odd to create and apply a content configuration only to specify callbacks and nothing else.

Scenario: Typing Chinese Zhuyin “ㄨㄤ” and then selecting the candidate word “王”. On iOS 18, the delegate (textField:shouldChangeCharactersInRange:replacementString:) is called with: range: {0, 2} replacementString: "王" On iOS 26, the delegate (textField:shouldChangeCharactersInRanges:replacementString:) instead provides: ranges: [{2, 0}] replacementString: "王" This results in inconsistent text input handling compared to earlier system versions. Implement: Limit user input to a maximum of 100 Chinese characters. - (BOOL)textField:(UITextField *)textField shouldChangeCharactersInRange:(NSRange)range replacementString:(NSString *)string { if ([textField markedTextRange]) { return YES; } NSString *changedString = [textField.text stringByReplacingCharactersInRange:range withString:string]; if (changedString.length > 100) { return NO; } return YES; } Questions: Is this an intentional change in iOS 26? If intentional, what is the recommended way to handle such cases in order to support both iOS 18 and iOS 26 consistently?

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.

In our app, there is a UIWindow makeKeyAndVisible crash, and for now, it appears once, crash stack: the crash detail: crash.txt in the RCWindowSceneManager class's makeWindowKeyAndVisible method, we check and set a window's windowScene and makeKeyAndVisible: public func makeWindowKeyAndVisible(_ window: UIWindow?) { guard let window else { return } if let currentWindowScene { if window.windowScene == nil || window.windowScene != currentWindowScene { window.windowScene = currentWindowScene } window.makeKeyAndVisible() } } and I set a break point at a normal no crash flow, the stack is: why it crash? and how we avoid this, 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.

I have an iPad app that supports multiple scenes. I discovered some issues with my app's user interface that I would like to tweak based on whether the user has setup multitasking (in iPadOS 26) as "Full Screen Apps" or "Windowed Apps". Is there any API or way to determine the current iPadOS 26 multitasking setting? I've looked at UIDevice.current.isMultitaskingSupported and UIApplication.shared.supportsMultipleScenes. Both always return true no matter the user's chosen multitasking choice. I also looked at UIWindowScene isFullScreen which was always false. I tried to look at UIWindowScene windowingBehaviors but that was always nil.

Starting with iOS 18, UITabBarController no longer updates tab bar item titles when localized strings are changed or reassigned at runtime. This behavior worked correctly in iOS 17 and earlier, but in iOS 18 the tab bar titles remain unchanged until the app restarts or the view controller hierarchy is reset. This regression appears to be caused by internal UITabBarController optimizations introduced in iOS 18. Steps to Reproduce Create a UITabBarController with two or more tabs, each having a UITabBarItem with a title. Localize the tab titles using NSLocalizedString(): tabBar.items?[0].title = NSLocalizedString("home_tab", comment: "") tabBar.items?[1].title = NSLocalizedString("settings_tab", comment: "") Run the app. Change the app’s language at runtime (without restarting), or manually reassign the localized titles again: tabBar.items?[0].title = NSLocalizedString("home_tab", comment: "") tabBar.items?[1].title = NSLocalizedString("settings_tab", comment: "") Observe that the tab bar titles do not update visually.

This problem occurs only when using the Japanese keyboard. After typing ""あい"" into a text field and pressing Enter, insert ""う"" between ""あ"" and ""い"". As a result, the displayed text becomes ""あううい"". Text field: ""あい"" → ""あううい"" The range values at this point: range.location = 2 range.length = 2 ・Behavior in iOS versions before 26 After typing ""あい"" into a text field and pressing Enter, insert ""う"" between ""あ"" and ""い"". As a result, the displayed text becomes ""あうい"". Text field: ""あい"" → ""あうい"" The range values at this point: range.location = 1 range.length = 1 The following source code can be used to reproduce the issue. mainApp (displaying a UIKit ViewController from SwiftUI) import SwiftUI import UIKit struct ViewControllerWrapper: UIViewControllerRepresentable { func makeUIViewController(context: Context) -> ViewController { return ViewController() } func updateUIViewController(_ uiViewController: ViewController, context: Context) {} } @main struct konnitihaApp: App { var body: some Scene { WindowGroup { ViewControllerWrapper() // UIKitのViewControllerを表示 } } } ViewController import UIKit class ViewController: UIViewController, UITextFieldDelegate { let textField = UITextField() let displayLabel = UILabel() // 追加で管理するプロパティ var replacementText: String = "" var textInsertLocation: Int = 0 var textSelectedLength: Int = 0 override func viewDidLoad() { super.viewDidLoad() view.backgroundColor = .white // UITextFieldの設定 textField.borderStyle = .roundedRect textField.placeholder = "" textField.delegate = self textField.translatesAutoresizingMaskIntoConstraints = false view.addSubview(textField) // UILabelの設定 displayLabel.text = "" displayLabel.layer.borderWidth = 2 displayLabel.layer.borderColor = UIColor.blue.cgColor displayLabel.translatesAutoresizingMaskIntoConstraints = false view.addSubview(displayLabel) // レイアウト NSLayoutConstraint.activate([ textField.topAnchor.constraint(equalTo: view.safeAreaLayoutGuide.topAnchor, constant: 40), textField.leadingAnchor.constraint(equalTo: view.leadingAnchor, constant: 20), textField.trailingAnchor.constraint(equalTo: view.trailingAnchor, constant: -20), textField.heightAnchor.constraint(equalToConstant: 40), //label displayLabel.topAnchor.constraint(equalTo: textField.bottomAnchor, constant: 500), displayLabel.leadingAnchor.constraint(equalTo: view.leadingAnchor, constant: 20), displayLabel.trailingAnchor.constraint(equalTo: view.trailingAnchor, constant: -20), displayLabel.heightAnchor.constraint(equalToConstant: 40), ]) } // UITextFieldDelegate func textField(_ textField: UITextField, shouldChangeCharactersIn range: NSRange, replacementString string: String) -> Bool { self.replacementText = string self.textInsertLocation = range.location self.textSelectedLength = range.length print("rangeは",range) // ラベルに最新の文字列を反映 if let text = textField.text, let textRange = Range(range, in: text) { let updatedText = text.replacingCharacters(in: textRange, with: string) if textField == self.textField { displayLabel.text = updatedText } } return true } }

Before iOS 26.1 our app work fine. but, when some users update to iOS 26.1 our app has very strange issues. Our app has a feature to upload pictures to server, before update pictures we will popup a UIAlertController to let user choose, there are 3 options, album, take a photo, cloud, or cancel. when click option button UIAlertController is hangup here not any response, and Xcode has no useful logs. How can I fix it? This app is work online for 8 years!!

I open this post to bring attention to overlooked UIManagedDocument. It still marked with @MainActor despite the fact that UIDocument is gonna be nonisolated in iOS 26.1. Here is what we will have with iOS 26.1 (the fix was there since, at least, beta 2): UIDocument was incorrectly annotated to be main actor only. This has been corrected. As a result you might see new warnings or errors show up in your Swift code using UIDocument. (149990945) Seems that UIManagedDocument should also have to be corrected the same way. Otherwise, in Swift 6 we will have crashes. Feedback report for this issue is FB20555456.

Hello, I'm experiencing a navigation bar positioning issue with my UIKit iPad app on iPadOS 26 (23A340) using Xcode 26 (17A321). The navigation bar positions under the status bar initially, and after orientation changes to landscape, it positions incorrectly below its expected location. This occurs on both real device (iPad mini A17 Pro) and simulator. My app uses UIKit + Storyboard with a Root Navigation Controller. A stack overflow post has reproduce the bug event if it's not in the same configuration: https://stackoverflow.com/questions/79752945/xcode-26-beta-6-ipados-26-statusbar-overlaps-with-navigationbar-after-presen I have checked all safe areas and tried changing some constraints, but nothing works. Have you encountered this bug before, or do you need additional information to investigate this issue?

I’m building a custom input field using UITextField. When the user taps to focus the field and the text is long, the entire text becomes selected by default. This is the same behavior you can see in iOS Safari’s search field or the Messages app search field. What I want: when the field becomes first responder, the caret should be placed at the end of the text (latest word), without selecting all the text. Here’s the code that builds my text field: public func makeTextField() -> UITextField { let textField = UITextField() textField.autocorrectionType = .no textField.setContentCompressionResistancePriority(.required, for: .horizontal) textField.setContentCompressionResistancePriority(.required, for: .vertical) if #available(iOS 13.0, *) { textField.smartInsertDeleteType = .no } textField.smartQuotesType = .no textField.smartDashesType = .no textField.autocapitalizationType = .none textField.contentMode = .scaleToFill if let font = attributes[.font] as? UIFont { textField.font = font } if let color = attributes[.foregroundColor] as? UIColor { textField.textColor = color } // Truncate long text at the head let paragraphStyle = NSMutableParagraphStyle() paragraphStyle.lineBreakMode = .byTruncatingHead textField.defaultTextAttributes[.paragraphStyle] = paragraphStyle textField.delegate = self textField.backgroundColor = .clear textField.addTarget(self, action: #selector(textFieldDidChange(_:)), for: .editingChanged) return textField } Entire text is selected when focusing the field if the text is long. What I’ve tried Forcing the caret to the end in textFieldDidBeginEditing: func textFieldDidBeginEditing(_ textField: UITextField) { let end = textField.endOfDocument textField.selectedTextRange = textField.textRange(from: end, to: end) } Doing the same asynchronously (next runloop) to avoid the system overriding selection: func textFieldDidBeginEditing(_ textField: UITextField) { DispatchQueue.main.async { let end = textField.endOfDocument textField.selectedTextRange = textField.textRange(from: end, to: end) } } Despite these, the system still selects all text on focus when the string is long/truncated at the head.

On iPad OS 26, the custom keyboard works correctly with a full keyboard, but with a floating keyboard, there is only one line and the console displays a constraint error. Unable to simultaneously satisfy constraints. Probably at least one of the constraints in the following list is one you don't want. Try this: (1) look at each constraint and try to figure out which you don't expect; (2) find the code that added the unwanted constraint or constraints and fix it. ( "<NSLayoutConstraint:0x600002172c10 V:|-(10)-[TUIKeyboardContentView:0x1039c5410] (active, names: '|':TUIKeyplaneView:0x1039c3e20 )>", "<NSLayoutConstraint:0x600002172c60 V:[TUIKeyboardContentView:0x1039c5410]-(-11)-| (active, names: '|':TUIKeyplaneView:0x1039c3e20 )>", "<NSLayoutConstraint:0x6000021721c0 V:|-(0)-[TUIKeyplaneView:0x1039c3e20] (active, names: UIKeyboardLayoutStar Prev...:0x105160e00, '|':UIKeyboardLayoutStar Prev...:0x105160e00 )>", "<NSLayoutConstraint:0x600002172210 V:[TUIKeyplaneView:0x1039c3e20]-(0)-| (active, names: UIKeyboardLayoutStar Prev...:0x105160e00, '|':UIKeyboardLayoutStar Prev...:0x105160e00 )>", "<NSLayoutConstraint:0x6000021728a0 V:|-(0)-[UIKeyboardLayoutStar Prev...] (active, names: UIKeyboardLayoutStar Prev...:0x105160e00, '|':UIKeyboardImpl:0x109905fa0 )>", "<NSLayoutConstraint:0x6000021728f0 V:[UIKeyboardLayoutStar Prev...]-(0)-| (active, names: UIKeyboardLayoutStar Prev...:0x105160e00, '|':UIKeyboardImpl:0x109905fa0 )>", "<NSLayoutConstraint:0x600002177980 '_UITemporaryLayoutHeight' UIKeyboardImpl:0x109905fa0.height == 0 (active)>", "<NSLayoutConstraint:0x600002172df0 'TUIKeyplane.height' TUIKeyboardContentView:0x1039c5410.height == 217 (active)>" ) Will attempt to recover by breaking constraint <NSLayoutConstraint:0x600002172df0 'TUIKeyplane.height' TUIKeyboardContentView:0x1039c5410.height == 217 (active)> Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to catch this in the debugger. The methods in the UIConstraintBasedLayoutDebugging category on UIView listed in <UIKitCore/UIView.h> may also be helpful. iPad OS 26 custom keyboard, full keyboard mode is working normally.

Summary In iOS 18, the UICollectionViewDelegate method collectionView(_:targetIndexPathForMoveOfItemFromOriginalIndexPath:atCurrentIndexPath:toProposedIndexPath:) is not being called when moving items in a UICollectionView. This method works as expected in iOS 17.5 and earlier versions. Steps to Reproduce Create a UICollectionView with drag and drop enabled. Implement the UICollectionViewDelegate method: func collectionView(_ collectionView: UICollectionView, targetIndexPathForMoveOfItemFromOriginalIndexPath originalIndexPath: IndexPath, atCurrentIndexPath currentIndexPath: IndexPath, toProposedIndexPath proposedIndexPath: IndexPath) -> IndexPath { print("🐸 Move") return proposedIndexPath } Run the app on iOS 18. Attempt to drag and drop items within the collection view. Expected Behavior The method should be called during the drag and drop operation, and "🐸 Move" should be printed to the console. Actual Behavior The method is not called, and nothing is printed to the console. The drag and drop operation still occurs, but without invoking this delegate method. Configuration iOS Version: 18 Xcode Version: Xcode 16.0.0

I have a few view controllers in a large UIKit application that previously started showing content right below the bottom of the top navigation toolbar. When testing the same code on iOS 26, these same views have their content extend under the navigation bar and toolbar. I was able to fix it with: if #available(iOS 26, *, *) { self.edgesForExtendedLayout = [.bottom] } when running on iOS 26. I also fixed one or two places where the main view was anchored to self.view.topAnchor instead of self.view.safeAreaLayoutGuide.topAnchor. Although this seems to work, I wonder if this was an intended change in iOS 26 or just a temporary bug in the beta that will be resolved. Were changes made to the safe area and edgesForExtendedLayout logic in iOS 26? If so, is there a place I can see what the specific changes were, so I know my code is handling it properly? Thanks!

I have a tab bar with 4 tabs. Since iOS 26, I’m facing an issue with the tab alignment — the text automatically shrinks, and the tab icon shifts upward for some tabs. I am using UITab property for creating Tabs from os Version above 18 and UITabBar for os version below 18.

I’m running the interactive reordering sample from this repo and hitting an odd behavior on newer simulators: the delegate method that lets you steer the drop: func collectionView(_:targetIndexPathForMoveOfItemFromOriginalIndexPath:atCurrentIndexPath:toProposedIndexPath:) works fine on iOS 16, but on iOS 18 and iOS 26 simulators it never fires, so the item always lands at the proposed index path and I can’t constrain moves or adjust the compositional view layout to accommodate the cell of different size. Is this a new behavior in modern iOS? If so, what’s the recommended way to control the final index path for the UICollectionViewDropDelegate now?

For anyone interested, I put together a simple SwiftUI proof-of-concept wrapper around PaperKit: https://blog.objectivepixel.com/posts/using-paperkit-papermarkerview-in-swiftui Gist on Github: PaperKit SwiftUI

Hi, We began to get this new crash in codes that exist years ago from our recent released version, it crashed after a view removed itself from superview. We tried to look at the assembly code of NSISSparseVectorAddTermWithPlaceValueCoefficientStartingIndex, find out that d0 <= 0 would branch to NSISSparseVectorAddTermWithPlaceValueCoefficientStartingIndex.cold.1. We believe that it's related with Autolayout, but setting a negative value for width or height constraints can't reproduce this crash. Here is the crash log Exception Type: NSInternalInconsistencyException Invalid parameter not satisfying: placeValue > 0 Exception Codes: fault addr: (null) Crashed Thread: 0 0 CoreFoundation ___exceptionPreprocess + 164 1 libobjc.A.dylib _objc_exception_throw + 88 2 Foundation -[NSMutableDictionary(NSMutableDictionary) initWithContentsOfFile:] + 0 3 CoreAutoLayout NSISSparseVectorAddTermWithPlaceValueCoefficientStartingIndex.cold.1 + 100 4 CoreAutoLayout _NSISSparseVectorAddTermWithPlaceValueCoefficientStartingIndex + 848 5 CoreAutoLayout _NSISSparseVectorAddVectorTimesScalar + 72 6 CoreAutoLayout -[NSISObjectiveLinearExpression replaceVar:withExpression:processVarNewToReceiver:processVarDroppedFromReceiver:] + 200 7 CoreAutoLayout ____substituteOutAllOccurencesOfBodyVar_block_invoke + 504 8 CoreAutoLayout __substituteOutAllOccurencesOfBodyVar + 340 9 CoreAutoLayout __pivotToMakeColNewHeadOfRow + 960 10 CoreAutoLayout -[NSISEngine removeConstraintWithMarker:] + 748 11 CoreAutoLayout -[NSLayoutConstraint _removeFromEngine:] + 140 12 UIKitCore ___57-[UIView(AdditionalLayoutSupport) _switchToLayoutEngine:]_block_invoke + 164 13 CoreAutoLayout -[NSISEngine withBehaviors:performModifications:] + 84 14 UIKitCore -[UIView(AdditionalLayoutSupport) _switchToLayoutEngine:] + 212 15 UIKitCore ___57-[UIView(AdditionalLayoutSupport) _switchToLayoutEngine:]_block_invoke_2 + 148 16 UIKitCore ___57-[UIView(AdditionalLayoutSupport) _switchToLayoutEngine:]_block_invoke + 544 17 CoreAutoLayout -[NSISEngine withBehaviors:performModifications:] + 84 18 UIKitCore -[UIView(AdditionalLayoutSupport) _switchToLayoutEngine:] + 212 19 UIKitCore ___45-[UIView(Hierarchy) _postMovedFromSuperview:]_block_invoke + 84 20 CoreAutoLayout -[NSISEngine withBehaviors:performModifications:] + 84 21 UIKitCore -[UIView _postMovedFromSuperview:] + 512 22 UIKitCore ___UIViewWasRemovedFromSuperview + 136 23 UIKitCore -[UIView(Hierarchy) removeFromSuperview] + 244 Assembly of NSISSparseVectorAddTermWithPlaceValueCoefficientStartingIndex CoreAutoLayout`NSISSparseVectorAddTermWithPlaceValueCoefficientStartingIndex: -> 0x1ec1a2124 <+0>: pacibsp 0x1ec1a2128 <+4>: stp d11, d10, [sp, #-0x60]! 0x1ec1a212c <+8>: stp d9, d8, [sp, #0x10] 0x1ec1a2130 <+12>: stp x24, x23, [sp, #0x20] 0x1ec1a2134 <+16>: stp x22, x21, [sp, #0x30] 0x1ec1a2138 <+20>: stp x20, x19, [sp, #0x40] 0x1ec1a213c <+24>: stp x29, x30, [sp, #0x50] 0x1ec1a2140 <+28>: add x29, sp, #0x50 0x1ec1a2144 <+32>: mov x19, x1 0x1ec1a2148 <+36>: fmov d9, d2 0x1ec1a214c <+40>: fmov d10, d1 0x1ec1a2150 <+44>: fmov d8, d0 0x1ec1a2154 <+48>: mov x20, x0 0x1ec1a2158 <+52>: fcmp d0, #0.0 0x1ec1a215c <+56>: b.le 0x1ec1a2470 ; <+844> 0x1ec1a2160 <+60>: fcmp d10, #0.0 0x1ec1a2164 <+64>: adrp x8, 112778 .... 0x1ec1a2468 <+836>: ldp d11, d10, [sp], #0x60 0x1ec1a246c <+840>: retab 0x1ec1a2470 <+844>: bl 0x1ec1cac18 ; NSISSparseVectorAddTermWithPlaceValueCoefficientStartingIndex.cold.1 0x1ec1a2474 <+848>: b 0x1ec1a2160 ; <+60>