I have created this section, dedicated exclusively to keep track of those annoying SwiftUI bugs. I will maintain a list of the bugs I come across. I’ll try to keep them updated, include workarounds when they do exist and stackoverflow.com links if available. When they eventually get squashed, I’ll include the version in which that occurs.
If you have a bug that would like to be included, please send me an email. Don’t forget to include the full code required to replicate the problem. Keep it as minimal as possible, for easier understanding.
To improve chances of these bug getting resolved, I recommend you file a bug report with Apple and mention the number of my report as well, so they can easily link them together and realise they are the same.
The current list is not too long, but we’re just getting started…
Description | Workaround | Checked On |
Contents inside GeometryReader use a different alignment in different iOS versions. Read More | Not Exactly | Xcode 12 beta 4 |
Using the VideoPlayer view in some macOS versions may result in a crash. Read More | Yes | Xcode 12.2 |
The following issues have been resolved:
Description | Fixed On | |
UIViewControllerRepresentable : UIViewControllers created by the UIViewControllerRepresentable are leaked. Read More | Xcode 11 beta 5 | |
SegmentedControl bad behaviour when inside a VStack. Read More | Xcode 11 beta 5 | |
Path is broken and will crash your app. The issue is disclosed in iOS 13, beta 5 release notes | Xcode 11 beta 6 | |
Text().lineLimit(n) is ignored when used inside a ScrollView. Read More | iOS 13.1 | |
The NavigationLink initializers shown below, have a back button erratic behavior. Read MoreNavigationLink(destination:isActive:) NavigationLink(destination:tag:selection:) | iOS 13.1 | |
AnimatableModifier will not animate inside containers, such as VStack. Read More | iOS 13.2 | |
MatchedGeometryEffect: Anchor points in non-source views does not respect the view size. Read More | Xcode 12 beta 4 | |
MatchedGeometryEffect: When two views share id and namespace they are matched, even if none of them is the source. Read More | Xcode 12 beta 4 | |
Using “#if available” inside a ViewBuilder, crashes when selecting the fallback option. Read More | Xcode 12 beta 5 |
I’m having trouble with Beta 5. The basic code in
GeometryReader
is crashing on the.fill(Color.blue)
statement. It doesn’t like the type being returned.Thank you your explanations, when
GeometryReader
starts working again it will be very helpful!Thank you! And by the way,
GeometryReader
works fine with beta 5. The problem is with paths, and because.fill()
will paint a path, that is why you get the crash. However, if you useGeometryReader
in any other way that does not involve paths, you’ll be ok.Cheers,
Javier.-
I came across the following unexpected results.
Text(“email”) gives you “Email”
also
Text(“code”) gives you “Code”
There are probably a number of other words “they” want to control.
The work around is to put a leading blank space.
Great articles BTW
I have not seen that behaviour, but perhaps it depends on device settings. Nevertheless, have you tried:
.autocapitalization(.none)
Try using it on the
Text()
or on in its container.tried
Text("email").autocapitalization(.none)
but it does not work.It is to do with the actual words “email” and “code”, it works for other strings.
Could this “email” business have to do with localization? ie is “email” a key in localized.strings?
wow amazing, it is due to the localization.
It probably means that SwiftUI automatically do the localization, replacing text that it finds in the Localizable.strings files. Thanks for finding out.
The way this works is that various View types which can take a literal string argument resolve that literal string to the type
LocalizedStringKey
. I imagine that if you intended “email” not to be localized, you could instead pass it as avar
String:struct MyView: View { var notLocalized: String = "email" var body: some View { Text(self.notLocalized) } }
would do as you expect.
(dreams of markdown in comments 🙂
A simpler version:
Text(verbatim: "email")
The “Text(…).lineLimit(…) inside a ScrollView” issue was fixed in the iOS 13.1 timeframe. I believe the navigation link issue was fixed around then as well, because I’ve not encountered it when using the isActive: APIs.
Didn’t see the .actionSheet iPad crash listed so, here ’tis…
As of Xcode 11.2.1 (11B53), iPadOS 13.3 it’s still broken (it works on iPhone and MacOS).
Indeed, if the .actionSheet example in “A Companion for SwiftUI” is run on iPad, you’ll get the crash.
https://forums.developer.apple.com/thread/124530
Thanks,
Allen
Thank you! I’m way behind updating the BugWatch section of the blog. Probably because it’s the least fun 😉 Sorry!
Can’t navigate same link twice (when collapsed).
In XCode 11.3.1 (and earlier) NavigationLink has so many bugs:
1. It doesn’t work within buttons;
2. It doesn’t work in gestures
3. In List, even if the row is split into 2 parts via HStack, NavigationLink will capture the whole row’s button click
On macOS Catalina 10.15.4, XCode 11.4, onDrop is not called on views within a ForEach block in a List.
(Sadly) Still not fixed in macOS 11/10.16b2, iOS14/iPadOS14 and Xcode 12b2
This simple Alert that works on ALL other platforms… on Mac OS it causes DUPLICATE BUTTONS.
This is true for both 10.15.6 and the latest 10.16 beta. 🙁
My guess is this is a Catalyst SDK bug in the MacOS libraries…
let send = ActionSheet.Button.default(Text(“Open Settings…”)) {
if let appSettings = URL(string: UIApplication.openSettingsURLString) {
UIApplication.shared.open(appSettings, options: [:], completionHandler: nil)
}
}
let cancel = ActionSheet.Button.cancel(Text(“Cancel”)) {
// game over – nothing else to do
}
return Alert(title: Text(“Network Error”),
message: Text(“Server not connected.”),
primaryButton: send,
secondaryButton: cancel)