In the Xcode 13 beta, where's the Vary For Traits button?

Views A and B are equal in width (set up via a constraint). The actual width will vary at runtime. What I want to do is arrange view A such that it is horizontally centered on B but offset to the left by 1/10th of the total width. In other words, if views A and B were 100 units in length, I'd want A to be positioned 10 units to the left of B. If the width were 150 units then the A position would be 15 to the left, etc. I thought I could do this with either a leading constraint or a centerX constraint using a multiplier of 0.9, but it isn't working out the way I want. What's the best solution?

Can anyone help me diagnose this crash. It happens in the animation block on the layoutIfNeeded() function call. Full function and. crash report attached.     private func showWarningView() {         DispatchQueue.main.async { [weak self] in             guard let strongSelf = self else { return }             if let safeAreaHeight = strongSelf.superview?.safeAreaLayoutGuide.layoutFrame.size.height {                 let visibleBannerHeight: CGFloat = strongSelf.isBannerVisible ? strongSelf.bannerHeight : 0                 let newConstraintConstant = (safeAreaHeight - strongSelf.externalBottomOffset - visibleBannerHeight) - strongSelf.warningBannerHeight                 strongSelf.addInternalBottomOffset(with: strongSelf.warningBannerHeight)                 strongSelf.warningViewTopConstraint.constant = newConstraintConstant             }             strongSelf.isWarningViewVisible = true             let showWarningView = UIViewPropertyAnimator(duration: 0.25, curve: .easeIn, animations: {                 self?.layoutIfNeeded()             })             showWarningView.startAnimation()         }     } Crash Report

Hello, does anyone experience this issue on the iOS 16 beta? The text wrapping in a simple label seems it is different in the iOS 16 beta. As you can see in the image attached, the "essentially" text goes to the line below in the iOS 16 beta, this is just a dummy example but we have seen a lot of screens where this wrapping happens. For the record: it is the same label with the same leading and trailing constraints values, the only thing that has changed is the IOS version. As our app needs to be "Pixel-perfect" this is a problem because we have a lot of screens to fix and we want to avoid adding iOS version logic in the code.

Xcode version: 13.2.1 (13C100) plateform: iOS Fatal Exception: NSInternalInconsistencyException 0 CoreFoundation 0x99288 __exceptionPreprocess 1 libobjc.A.dylib 0x16744 objc_exception_throw 2 CoreAutoLayout 0x57ac -[NSISEngine withAutomaticOptimizationDisabled:] 3 CoreAutoLayout 0xaa6c -[NSISEngine _optimizeWithoutRebuilding] 4 CoreAutoLayout 0xcb78 -[NSISEngine optimize] 5 CoreAutoLayout 0x50fc -[NSISEngine performPendingChangeNotifications] 6 UIKitCore 0x350710 -[UIView(Hierarchy) layoutSubviews] 7 UIKitCore 0x18bfb4 -[UIView(CALayerDelegate) layoutSublayersOfLayer:] 8 QuartzCore 0x40cd0 CA::Layer::layout_if_needed(CA::Transaction*) 9 QuartzCore 0x33134 CA::Layer::layout_and_display_if_needed(CA::Transaction*) 10 QuartzCore 0x47a7c CA::Context::commit_transaction(CA::Transaction*, double, double*) 11 QuartzCore 0x50970 CA::Transaction::commit() 12 QuartzCore 0xa89a8 CA::Transaction::release_thread(void*) 13 libsystem_pthread.dylib 0x1e58 _pthread_tsd_cleanup 14 libsystem_pthread.dylib 0x48d0 _pthread_exit 15 libsystem_pthread.dylib 0x13b8 pthread_main_np 16 libsystem_pthread.dylib 0x1144 _pthread_wqthread 17 libsystem_pthread.dylib 0xe5c start_wqthread

User case : I am using swiftui with UIHostingController on my app. My entire view is messed up when the keyboard is presented for a text field. This problem happens if - Keyboard is presented in another controller with UIKit text field and then came to this (SwiftUI) screen and the Keyboard is presented for the swiftUI textfield.

We’re attempting to use UICollectionView compositional layout to describe a section layout, but it’s giving us some trouble. What we’d like to achieve: A total of 7 cells 3 cells stacked, each 30% height and 100% width, with orthogonal scrolling to see the next 3 When the user reaches the last cell, it would be 100% height and 100% width of the container. ASCII art and screenshots of the imperfect example are below. Our starting point was Apple’s example code, specifically OrthogonalScrollingViewController, but what we’ve found is if we expand the widths there, the height settings seem to longer be respected. The most basic version of a layout that we tried is this: func createLayout() -> UICollectionViewLayout { let layout = UICollectionViewCompositionalLayout { (sectionIndex: Int, layoutEnvironment: NSCollectionLayoutEnvironment) -> NSCollectionLayoutSection? in // Small items at roughly 30% of the container height. let smallItem = NSCollectionLayoutItem( layoutSize: NSCollectionLayoutSize( widthDimension: .fractionalWidth(1.0), heightDimension: .fractionalHeight(0.3) ) ) // The large item should be 100% of the container width. let largeItem = NSCollectionLayoutItem( layoutSize: NSCollectionLayoutSize( widthDimension: .fractionalWidth(1.0), heightDimension: .fractionalHeight(1.0) ) ) // We want 3 items to appear stacked with orthogonal scrolling. let smallItemGroup = NSCollectionLayoutGroup.vertical( layoutSize: NSCollectionLayoutSize( widthDimension: .fractionalWidth(1.0), heightDimension: .fractionalHeight(1.0) ), subitem: smallItem, count: 3 ) let containerGroup = NSCollectionLayoutGroup.horizontal( layoutSize: NSCollectionLayoutSize( widthDimension: .fractionalWidth(1), heightDimension: .fractionalHeight(0.5) ), subitems: [smallItemGroup, largeItem] ) let section = NSCollectionLayoutSection(group: containerGroup) section.orthogonalScrollingBehavior = .paging return section } return layout } We’ve tried many variations of nested groups and using the .vertical and .horizontal initializers, but each of them has the same result: The last cell is always the same size as all the others. // +------------------------------+ These would be off-screen // | +-------------------------+ | +-------------------------+ +-------------------------+ // | | 1 | | | 4 | | | // | +-------------------------+ | +-------------------------+ | | // | +-------------------------+ | +-------------------------+ | | // | | 2 | | | 5 | | 7 | // | +-------------------------+ | +-------------------------+ | | // | +-------------------------+ | +-------------------------+ | | // | | 3 | | | 6 | | | // | +-------------------------+ | +-------------------------+ +-------------------------+ // | | // | | // | | // | rest of the screen | // | | // | | // | | // | | // +------------------------------+ The last cell in the third screenshot, (0,6), is the one we want 100% height of the section. Is there a way to achieve this layout where the last cell is 100% of the section height?

I recently migrated to macOS Monterey to build my macOS app. After building the app in 12.3, the users have started to experience mysterious crashes related to view layout. The first one was somehow related to NSScrollView endlessly resizing itself between two width values, and I figured it could have something to do with scroll bar sizing, but found no apparent fix. Crashing on exception: The window has been marked as needing another Display Window pass, but it has already had more Display Window passes than there are views in the window. I circumvented the issue with some duct tape, but ended up with another layout exception on other users' systems: Crashing on exception: The window has been marked as needing another Update Constraints in Window pass, but it has already had more Update Constraints in Window passes than there are views in the window. It's very hard to debug this, because the bug seems to be very system-specific. However, by intense googling, I've seen that Safari and Xcode have also suffered from the exact same crash, but I've found no information on how they might have been fixed. I'm starting to suspect that there is something principal that has been changed within view layout routines macOS 11/12 that I'm completely missing. Does anyone have any experience with such issues, and how to start digging deeper?

After upgrading to ios15, there are many crashes. What is the reason？？ -[UIView _layoutEngine_didAddLayoutConstraint:roundingAdjustment:mutuallyExclusiveConstraints:] + 468 -[UIView _tryToAddConstraint:roundingAdjustment:mutuallyExclusiveConstraints:] + 212 -[UIView(UIConstraintBasedLayout) nsli_addConstraint:]  -[UIView(UIConstraintBasedLayout) addConstraints:]_block_invoke + 176 0x000000019b069000 + 34296 -[UIView(UIConstraintBasedLayout) addConstraints:] + 196 -[UIInputWindowControllerHostingItem updateVisibilityConstraintsForPlacement:] + 440 -[UIInputWindowControllerHostingItem updateViewConstraints] + 6888 -[UIInputWindowControllerHosting updateViewConstraints] + -[UIInputWindowController updateViewConstraints] + 92 -[UIInputWindowController changeToInputViewSet:] + 2252 ___43-[UIInputWindowController setInputViewSet:]_block_invoke.1285 + 40 ___77-[UIInputWindowController moveFromPlacement:toPlacement:starting:completion:]_block_invoke.1042 + 1600 -[UIViewAnimationBlockDelegate _didEndBlockAnimation:finished:context:] + 724 -[UIViewAnimationState sendDelegateAnimationDidStop:finished:] + 248 -[UIViewAnimationState animationDidStop:finished:] + 244 0x00000001861eb000 + 821768 libdispatch.dylib __dispatch_client_callout + 20

Hello, I m one of the developers of the My CM app team (Belgian Health Insurance company). While testing on apple devices that have no physical homebutton, but the on-screen "black bar" we notice some strange behaviour. See picture attached. The phone on the left is a iPhone 13 Pro Max, the one on the right is an iPhone XR. Both have ios 15.2. Both phones have the same build of our app. On the Pro Max the black bar is on top of our layout, on the XR our layout seems to be pushed up a bit. The desired behaviour is the behaviour on the XR. Can somebody give us advice on how to handle this issue? Kind regards, Lode

This is a fairly bizarre behavior and I wonder if anyone with deep knowledge of NSView layout internals has a clue. I have a view that hosts a number of toolbar-like buttons, some subclasses of NSButton and other subclasses of NSPopUpButton. The latter are used in pull-down mode and do not display a title (just a pull-down indicator and icon), they are similar in size and appearance to the NSButtons. When the app is switched between light mode and dark mode, some layout action is triggered which always adds 5 pixels of widths to the pull-down buttons. When I override setFrame and set a breakpoint, this is happening below NNAApplication nextEventMatchingMask in an undocumented function called NSViewActuallyUpdateFromLayoutEngine. This method always adds 5 pixels to width for repeated light/dark mode changes. It does so on a pull-down even if it has already done so before, so these controls just keep growing, and this does not seem to be related to any obvious intrinsic content. Some things I would note in trying to track it down: It only happens to the popup buttons, not the regular NSButtons in the same superviews I have some of these in a horizontal stack view and some positioned statically in a regular NSView - both scenarios get this 5-pixel-width-resize I've tried overriding both instrinsicContentSize and fittingSize to return the current frame size, as a way to tell the layout system not to change the size, and that didn't work There are no explicit constraints created for these views; they are created in code not in Interface Builder I've tried using the autolayout mask value NSViewNotSizable with the translates flag set to YES, that does not prevent the issue I've tried setting the superview autoresizesSubviews flag to false and also making sure translates flags were false to not create unwanted constraints, these also do not prevent the issue The only code values I had related to 5 pixels were a spacing setting and a left inset on the horizontal stack view - so I removed those as a check, but as I'd expect that did not change the behavior The only way I've been able to defeat it is to add a .sizeLocked property to my subclass and, if set, replace the incoming frame.size with the current one to prevent the resize while still allowing origin to change. Obviously that's not ideal but as a brute-force workaround it works for this specific issue. However I'm seeing other weird layout creep as well on repeated light/dark change. I wonder why this happens, and what the correct fix might be! Why is dark/light mode switching resizing anything in layout, when the size of windows and views have not changed?

I have an NSTextView inside an NSScrollView with magnification. Zooming in with a pinch-and-zoom gesture works fine, but if I then resize the window while zoomed in, it will eventually crash with the error The window has been marked as needing another Display Window pass, but it has already had more Display Window passes than there are views in the window. It does not always happen immediately, sometimes you have to keep resizing for a while to trigger it. I have made a video illustrating the problem here: youtu.be/M_JRQI2oDaY The original code is here: https://github.com/angstsmurf/spatterlight/tree/helpviewtest (The branch helpviewtest is a cut down test case created for this problem.)

I have a subclass of UIScrollView called MyScrollView. There is a subview called contentViewinside MyScrollView. The width constraint is set to be the contentSize of MyScrollView. private func setupSubviews() { contentView = ContentView() contentView.backgroundColor = UIColor.blue contentView.translatesAutoresizingMaskIntoConstraints = false contentView.isUserInteractionEnabled = true self.addSubview(contentView) contentView.leadingAnchor.constraint(equalTo: self.leadingAnchor).isActive = true contentView.trailingAnchor.constraint(equalTo: self.trailingAnchor).isActive = true contentView.topAnchor.constraint(equalTo: self.topAnchor).isActive = true contentView.bottomAnchor.constraint(equalTo: self.bottomAnchor).isActive = true // create contentView's Width and Height constraints cvWidthConstraint = contentView.widthAnchor.constraint(equalToConstant: 0.0) cvHeightConstraint = contentView.heightAnchor.constraint(equalToConstant: 0.0) // activate them cvWidthConstraint.isActive = true cvHeightConstraint.isActive = true cvWidthConstraint.constant = myWidthConstant //<--- problem here if myWidthConstant is very high, such as 512000 cvHeightConstraint.constant = frame.height contentView.layoutIfNeeded() } The problem is if I set cvWidthConstraint.constant to a very high value such as 521000, I get a warning: This NSLayoutConstraint is being configured with a constant that exceeds internal limits. A smaller value will be substituted, but this problem should be fixed. Break on BOOL _NSLayoutConstraintNumberExceedsLimit(void) to debug. This will be logged only once. This may break in the future. I wonder how does one set UIScrollView content size to be very high values?

Hi everyone, our team was transferred a project that is using a "UICollectionViewCompositionalLayout" for displaying a large amount of data. On iOS 14 and below, we seemed to be having no problems. Now on iOS 15 however, we keep getting this debugger message: APPNAME[47924:507017] [UICollectionViewRecursion] cv == 0x7ff2af9d0200 Disabling recursion trigger logging We are also collecting crashes in our crash tool, solely from iOS 15 devices, saying: NSInternalInconsistencyException: UICollectionView (<UICollectionView 0x1122a6400>) is stuck in its update/layout loop. This can happen for many reasons, including self-sizing views whose preferred attributes are not returning a consistent size. To debug this issue, check the Console app for logs in the "UICollectionViewRecursion" category. We've found that setting all .estimated() sizes we're using in the section provider to .absolute() gets rid of the message, but of course the views aren't sized correctly then. We are using views that size themselves based on the content they display, using UIStackViews. We need them to be dynamic in height. Has something changed moving from iOS 14 to 15 about how the compositional layout has to be configured? Is there something we can do to further debug this issue? I've found some questions about this asked on StackOverflow, but none of them were answered either.

The multitasking control button is getting in the way of my pre-existing button and I would like to alter the position conditionally, right below the multitasking button. Since the status bar is not supported in any of my app's view controllers using Safe Area Guide Insets is not an option. Is there a way to determine whether the Multitasking Control Button is visible besides checking the os version of the device?

Hey I am desperate how I can make my app looks good for all end devices. I have e.g. a completely normal label with the text "Start" and the size UIFont (name: "Arial", size: 35). It also looks good on an Iphone 12 pro max, but the text on an iphone se is simply way too big. How do I get it to look good? And why can't apple adjust the size itself? I would be very happy to hear from you. Best regards

I have iPhone 11 Pro running iOS 14 beta 2. In one of my projects (and only that project perhaps), the view controller doesn't autorotate when connected to XCode (11 or 12) debugger. When not connected to debugger, there is no issue in autorotation. This happens for only one particular project and it's not clear what could be blocking autorotation. None of the autorotation methods are called. I wonder what could be blocking autorotation. And if I connect any iOS 13 device, autorotation works with the debugger. Is this a known issue with iOS 14/XCode?