SwiftUI is amazing. It's functional, it's consistent and it upgrades the layout paradigm for Apple platforms to a modern and much more up-to-date approach. But it isn't without flaws.
This project aims to shed a light on some of it's bugs that you should be aware of before start developing your application. It currently consist of a list of mostly macOS issues because that seems to be in a worst shape, overall, than SwiftUI for iOS or iPadOS, however, feel free to append any known SwiftUI issues to this repository regardless its platform. Pull-requests are more than welcome.
All the issues described here have been observed and are reproducible in the latest major iOS version: 15.2
Radar: FB9939086
When nesting Buttons with styles, the outer ButtonStyle.Configuration.isPressed
is modified even when pressing the inner button. This incorrectly applies pressed button styles.
Preview: NestedButtonStyle
All the issues described here have been observed and are reproducible in the latest major macOS version: 12.1 (Monterey)
Radar: FB9045245
The cursor system simply does not work with SwiftUI, specially when relying on onHover
to modify the cursor.
Preview: CursorUnreliableView
Radar: 9010301
When rendering a ZStack, if any Views with a lower zIndex
than its siblings applies an onHover
modifier, that closure gets called even if the View is overlaid (and potentially hidden) by other Views.
Preview: NestedHoverView
Radar: FB9047229
TextFields on macOS ignores .textCase
modifiers. The given case is applied only to the placeholder, but not to the typed content.
Preview: UppercasedTextFieldView
Radar: FB9047243
TextField formatter is applied only on commit, not as the user types into the field.
Preview: TextFieldFormatterView
Radar: FB9071516
List-specific modifiers applied to a List view are not applied. Even the generic "background" modifier is ignored.
Preview: ListStyleView
The following issues have been closed for various reasons.
Status: Fixed ✅
Radar: 9038728
When updating the content of a ScrollView, if the new content requires the indicators to be visible (i.e. expanding the content size) the content will be improperly rendered with the full ScrollView width disregarding the ScrollView's indicators which will cover some of the content.
A workaround is manually forcing the ScrollView to be re-updated either by changing a state or an observed object.
Preview: ScrollViewIndicatorsView