Post not yet marked as solved
Unfortunately, you cannot use an "if" statement like that / in the middle of a chain of modifiers.
In Swift 5.5 #if can be used like that (see #if for postfix member expressions ) - but that is a compile time check so you cannot use this to check for an iOS version at runtime.
I think the only way is to build your own modifier that's compatible with the old iOS version. I had the same problem with the new badge() modifier, so here is an example:
struct WithBadgeModifier: ViewModifier {
var count: Int
func body(content: Content) -> some View {
if #available(iOS 15.0, *) {
content
.badge(count)
} else {
content
}
}
}
extension View {
func withBadge(count: Int) -> some View {
modifier(WithBadgeModifier(count: count))
}
}
Another way to structure is to build a .backport modifier so you can use the same name for the modifier (.backport.badge(10)) and can find all those places where a new modifier was used conditionally (thanks Dave deLong):
struct Backport<Content: View> {
let content: Content
}
extension View {
var backport: Backport<Self> { Backport(content: self) }
}
extension Backport {
@ViewBuilder func badge(_ count: Int) -> some View {
if #available(iOS 15, *) {
content.badge(count)
} else {
self.content
}
}
}
Post not yet marked as solved
@Developer Tools Engineer: I double checked, it's FB7760343 and it's shown as sent in the feedback assistant. I filed it for the XCTest project, is this the correct place?
Post not yet marked as solved
If you only use API that was already available with iOS 13, yes. You'll have to be careful about not using API that was newly introduced with iOS 14, like f.e. the newly added TextEditor would be forbidden / you'd have to write the code in way that the newly added APIs are only used on iOS 14 using code like 'if #available(iOS 14, *) { ... }' . Xcode will warn about these if you set iOS 13 as development target, you can also look it up using the documentation under 'Availablility' (f.e. for https://developer.apple.com/documentation/swiftui/texteditor ). Also you'll have to spend some effort to properly test the app both on iOS 13 and iOS 14 because you might encounter bugs that are only visible on one of the versions.
Greetings,
Ralf
I am tending to use the ObservableObject approach nowaways because it allows elegant setup in the PreviewProvider.I extracted a full example here:Using URLSession to load JSON data for SwiftUI Viewshttps://stackoverflow.com/a/61858358/128083
"Hardware » Erase all Content and Settings" in the simulator fixed the problem.Probably some leftover from the Betas.
Cross-posted here:https://stackoverflow.com/questions/58648283/xcuielementtypetext-fails-for-two-text-fields
It seems:subscribing via View#onReceive + copying the new value to a @State to trigger the refreshor subscribing to the Publisher in an ObservableObject + copying the new value to a @Published value to trigger the refreshseems to be the way to go.
Catalina Beta 9 fixed this for me.
Post not yet marked as solved
This is now fixed in Beta 5, the __title initializers are not necessary anymore. For example:private func createContextMenu() -> UIContextMenuConfiguration {
let actionProvider: UIContextMenuActionProvider = { _ in
let showMap = UIAction(title: "Show map", image: UIImage(systemName: "mappin.and.ellipse")) { _ in
// ...
}
return UIMenu(title: "Example menu", children: [showMap])
}
return UIContextMenuConfiguration(identifier: nil, previewProvider: nil, actionProvider: actionProvider)
}
Post not yet marked as solved
I submitted a bug report about the problem (FB6902557):The example project for NSPersistentCloudKitContainerhttps://developer.apple.com/documentation/coredata/synchronizing_a_local_store_to_the_clouddoesn't work out of the box on Beta 5.Just downlading and running it causes an runtime error:CloudKit integration requires does not support ordered relationships. The following relationships are marked ordered:
Post: attachments
Post: tagsAlso, the iCloud container ID is currently dependent on the bundle ID and the project has Catalyst enabled which leads to a Automatic signing error because of the different ids.I worked around these issues to make the project work, see:https://github.com/ralfebert/SynchronizingALocalStoreToTheCloudhttps://github.com/ralfebert/SynchronizingALocalStoreToTheCloud/commit/e836893f5a669390090638d89a4f19021e1d2b11https://github.com/ralfebert/SynchronizingALocalStoreToTheCloud/commit/c6306c30864422c2f6cb0cecb56c2b2374e5e6e0The issue is also discussed here:https://stackoverflow.com/questions/57089435/is-there-a-way-to-resolve-this-error-cloudkit-integration-requires-does-not-su
Post not yet marked as solved
It works in the simulator but syncs only on app startup when you set the automaticallyMergesChangesFromParent-option on the viewContext. See https://stackoverflow.com/questions/56601716/how-to-get-default-project-with-nspersistentcloudkitcontainer-up-and-runningThe actual sync via push notification only works on real devices.
Post not yet marked as solved
Hi,Xcode 9.2 should be the last version compatible with 10.12.6.If the Mac App Store doesn't install that version, you could get and install it manually from here:https://developer.apple.com/download/more/ (Apple ID required).Greetings,Ralf
Post not yet marked as solved
Good point, this makes this more tricky.Although my suggestion was not so much about accidentially missing a call to super but the convenience of not having to type it manually, so a warning wouldn't help in that regard (I assume).Maybe the <#code#> insertion marker could be left out to not imply any order.The other cases could be handled by some way to document must-(not)-call-super cases as part of the method signature so the tooling could react accordingly.
