It's difficult to say for sure what the best solution is from your description alone. But have you investigated using the UITableView lifecycle callbacks when cells display & end displaying for a row? Specifically, you could use the didEndDisplaying callback to know when a cell stops displaying for a given row, and disconnect the observer in that case. Just know that you'd also want to ensure the connection is re-established in the corresponding willDisplay callback, as if the cell is scrolled slightly out of view and then back in, it will remain in the UITableView's internal cache of prepared cells which get displayed again without going through the cellForRowAt callback (i.e. your diffable cell provider).
If necessary, you can disable cell prefetching using this property, however this is not recommended as it will negatively impact scrolling performance (causing user-visible hitches and increased power usage during scrolling).
Set the selfSizingInvalidation property on the UICollectionView to .enabledIncludingConstraints. This will cause the collection view to automatically detect Auto Layout and intrinsic content size changes within the cell, and resize the cell when necessary.
Links to the relevant documentation pages:
https://developer.apple.com/documentation/uikit/uicollectionview/4001100-selfsizinginvalidation
https://developer.apple.com/documentation/uikit/uicollectionview/selfsizinginvalidation/enabledincludingconstraints
There is a known issue with the viewIsAppearing(_:) callback when running on older iOS versions (prior to iOS 16) where it may not be called in certain circumstances when you have nested child view controllers. If you are still supporting those older iOS versions and encounter a situation like this, you will need to implement a workaround in your app when running on those older versions to ensure that the code you would normally run in viewIsAppearing(_:) still executes when you need it to.
Post not yet marked as solved
Please submit a feedback report about this issue so that we can investigate it. At minimum, we need the complete crash report file to better understand the crash. But please also try to attach an Xcode project (preferably a minimal sample) that reproduces this issue as well.
Post not yet marked as solved
UICollectionView will only call resignFirstResponder like this when the first responder view (in this case, the UITextField) is contained within a section or item that has been deleted or reloaded. If the UITextField is contained within a cell in section 0 as you claim, then most likely section 0 is being reloaded as part of the batch updates.
If you don't believe this is what is happening, please distill this into a sample project and submit that as an attachment to a feedback report so that we can take a look and understand the behavior you're seeing.
Post not yet marked as solved
Thanks for bringing this to our attention; this appears to be a bug in iOS 17.
As a temporary workaround until a fix is available in a future update, try adding the following code after you set the configuration of the button:
private lazy var button: UIButton = {
let button = UIButton()
// ...
button.configuration = configuration
// Workaround for stroke color not updating properly in response to userInterfaceStyle changes
button.configurationUpdateHandler = { b in
guard var config = b.configuration else { return }
let strokeColor = config.background.strokeColor
config.background.strokeColor = .clear
b.configuration = config
config.background.strokeColor = strokeColor
b.configuration = config
}
return button
}()
What this workaround does is manually reset the button's background stroke color to .clear and then back to the original color anytime the button's state changes, which includes changes to the button's traits (such as its userInterfaceStyle).
Post not yet marked as solved
Overriding the traitCollection property getter in a UIView or UIViewController subclass has never been supported, and since iOS 13 you would see the following warning logged to the console if you tried to do this:
"Class ... overrides the -traitCollection getter, which is not supported. If you're trying to override traits, you must use the appropriate API."
As the message suggests, you need to use a supported API if you want to override (i.e. modify) trait values. This is critical so that the system knows when you are applying an override, and when the value of the override you're applying has changed.
Fortunately, in iOS 17 and later, this is extremely easy to do using the new traitOverrides property. For example, to set an override for the horizontal size class trait on a view, just do the following:
view.traitOverrides.horizontalSizeClass = .compact
If your app still supports iOS 16 and earlier, you need to use the one of the override trait collection APIs on UIViewController or UIPresentationController.
Post not yet marked as solved
Thanks for bringing this issue to our attention. This appears to be a bug, we'll investigate further.
Post not yet marked as solved
This is probably not a real issue that you need to worry about, and is only a temporary situation where the cell is has its initial default estimated height of 44 before it gets measured and properly sized to fit the content. As a workaround, you can reduce the priority of one of the constraints listed from UILayoutPriority.required (1000) to UILayoutPriority.required - 1 (999), which will allow that constraint to be broken in this temporary situation without causing this unsatisfiable constraints logging.
However, if you can reproduce this in a small sample app, please submit a feedback report containing that sample project so we can investigate and ensure this warning is not emitted in any cases where it shouldn't be.
updateTraitsIfNeeded is safe to call from inside a trait change callback (using the new trait registration methods introduced in iOS 17) or from the deprecated traitCollectionDidChange method. The purpose of doing this would be to immediately update traits (and send any trait change callbacks) for other view controllers and views nested underneath self, so that you could immediately perform other operations that rely on the traitCollection of these descendants being up-to-date. (Remember that traits are updated top-down through the hierarchy, so when you receive trait change callbacks for one view controller or view, any child view controllers or subviews nested deeper haven't been updated yet.)
With that said, it's best to minimize the work you perform directly in the trait change callback, and instead simply invalidate and schedule a future update. For example, in UIView subclasses, if you do your work and updates based on traits inside layoutSubviews, then you can just call setNeedsLayout in response to any trait change.
An example of when you should call updateTraitsIfNeeded is when you have a parent view controller or view that manages the layout of one or more children, and that parent needs to manually measure the size of these children to lay them out (e.g. by calling sizeThatFits or similar on them) — because the preferred size of children may depend on their traits, it's a good idea to call updateTraitsIfNeeded first before sizing those children, so that the measured size is accurate right away.
It's perfectly OK to use updateTraitsIfNeeded when you need to, but try to minimize usage of it in general for best performance.
Post not yet marked as solved
-traitCollectionDidChange: is called any time that the traitCollection of that object has changed. This includes changes to any traits, including built-in system traits, your own custom traits (using the new APIs in iOS 17), or other custom traits from other libraries/frameworks whose code is running in your app. (This is why -traitCollectionDidChange: is deprecated in iOS 17: because it is called for any and all trait changes, it does not scale as more and more traits are added — your code only cares about changes to the small subset of traits it actually uses.)
Often, multiple trait changes will be coalesced into a single -traitCollectionDidChange: call. However, there can also be cases where -traitCollectionDidChange: is called multiple times, because one or more traits are invalidated (e.g. trait overrides are changed), traits are updated and the change notifications are sent, and then more trait(s) are invalidated afterwards.
The best place to start is to use the trait collection change logging that was introduced in iOS 13, which was mentioned during the Implementing Dark Mode on iOS session from WWDC19 starting at this timestamp. Set the launch argument -UITraitCollectionChangeLoggingEnabled YES in your app's scheme to enable it, then filter the logs for category TraitCollectionChange and run your app.
If there is a situation where you are seeing unexpected behavior, please submit a feedback report that includes a sample project that reproduces the issue you're seeing, so we can investigate and understand what is causing the behavior you're observing.
Post not yet marked as solved
As the exception message explains, the system has detected improper use of diffable data source. Please review this documentation and sample project which explains fundamentals about how to properly use diffable data source and identifiers.
UIHostingConfiguration does not support SwiftUI views or features that require a connection to the view controller hierarchy in UIKit. This includes things like navigation, toolbars, keyboard shortcuts, and views that use UIViewControllerRepresentable, as well as popover presentations. See the Use SwiftUI with UIKit video from WWDC22 to learn more. You need to use a UIHostingController in UIKit to be able to use these features in SwiftUI, so that SwiftUI has a connection to the view controller hierarchy in UIKit.
If you want to have a button (or other control) inside a cell using UIHostingConfiguration trigger a popover presentation, consider having the cell issue a callback to your table view controller (by passing a weak reference into the SwiftUI view), and then having that view controller manage the presentation of the popover. Having the view controller coordinate the presentation is often a better architecture in general for UIKit, rather than having a cell directly perform the presentation itself.
Post not yet marked as solved
This looks like a problem with the YYModel library, or perhaps your code using it. If you believe this is an issue with iOS 17, please submit a feedback report and describe the issue, including the complete crash report, as well as a sample project that reproduces the issue.
Post not yet marked as solved
This was a bug introduced in iOS 16.4, but it is fixed as of the latest iOS 16.5 beta, so please test using iOS 16.5 beta 4 or later.
