Posts

Post not yet marked as solved
54 Replies
What's sad is the navigation workarounds don't work some scenarios so my plan C in those cases has been to use a .sheet instead of navigating, which takes SwiftUI mediocrity to a whole new level
Post not yet marked as solved
54 Replies
Another approach to the navigation link workaround collection is placing a hidden NavigationLink in the background that is shared across a few buttons, instead of each button being a NavigationLink: swift extension View {     func navigateDestination: View(         isActive: BindingBool,         destination: Destination?     ) - some View {         background(             NavigationLink(                 destination: destination,                 isActive: isActive,                 label: EmptyView.init             )             .hidden()         )     } } extension View {     func navigateItem, Destination: View(         item: BindingItem?,         destination: (Item) - Destination     ) - some View {         navigate(             isActive: Binding(                 get: { item.wrappedValue != nil },                 set: { if !$0 { item.wrappedValue = nil } }             ),             destination: Group {                 if let item = item.wrappedValue {                     destination(item)                 }             }         )     } } Then you can use it like this: swift struct ShowMoreView: View {     @State private var isLinkActive = false     var body: some View {         List {             Button(action: { isLinkActive = true })                 Text("Start navigation 1")             }             Button(action: { isLinkActive = true })                 Text("Start navigation 2")             }             Button(action: { isLinkActive = true })                 Text("Start navigation 3")             }         }         .navigate(isActive: $isLinkActive, destination: makeDestination())     } } struct ShowMoreView: View {     @State private var date: Date?     var body: some View {         List {             Button(action: { date = Date() })                 Text("Start navigation 1")             }             Button(action: { date = Date() + 100 })                 Text("Start navigation 2")             }             Button(action: { date = Date() + 1000 })                 Text("Start navigation 3")             }         }         .navigate(item: $date, destination: makeDestination)     }     func makeDestination(for date: Date) - some View {         ...     } } This source is from SwiftWithMajid's blog (for some reason the forums is not allowing me to link to it, but search for "swiftui majid lazy navigation" and you'll find it).
Post not yet marked as solved
54 Replies
I think this all stems from the original SwiftUI design decision that navigation link destinations are not lazy loaded. What a pain navigation has been from the beginning and getting more and more messier.
Post not yet marked as solved
36 Replies
On Xcode 12.3 / iOS 14.3 and onAppear is still very flaky. I'm actively avoiding it at all costs everywhere and calling functions manually while constructing the view instead.
Post marked as solved
5 Replies
Turns out you don't even need to use UIViewControllerRepresentable, or UIKit at all in SwiftUI! The trick is to use PKPaymentAuthorizationController - https://developer.apple.com/documentation/passkit/pkpaymentauthorizationcontroller, NOT the view controller version - https://developer.apple.com/documentation/passkit/pkpaymentauthorizationviewcontroller. From the docs: The PKPaymentAuthorizationController class performs the same role as the PKPaymentAuthorizationViewController class, but it does not depend on the UIKit framework. This means that the authorization controller can be used in places where a view controller cannot (for example, in watchOS apps or in SiriKit extensions). Apply Pay integration on SwiftUI should be approached more like a watchOS or Siri integration than a UIKit app. Below is a sample of the implementation: let request = PKPaymentRequest() request.paymentSummaryItems = ... let controller = PKPaymentAuthorizationController(paymentRequest: request) controller.delegate = self controller.present { [weak self] presented in 	 // Apple Pay presented from scene window } The controller automatically finds the scene window to present from. No more porting to UIKit or dismissal memory leaks!
Post not yet marked as solved
3 Replies
Did you ever find a solution for this? I even tried subscribing to UIWindow.didBecomeVisibleNotification and UIApplication.willResignActiveNotification but they don't trigger when the password dialog pops up.
Post marked as solved
27 Replies
https://forums.swift.org/t/migrating-to-spm-from-mix-of-embedded-frameworks-and-static-libraries/34253/4
Post marked as solved
27 Replies
This is still happening with the official release of Xcode 11.4. Obviously we don't have control over 3rd party packages to change static to dynamic, and of course many libraies are shared across targets and extensions. Please don't say this is a feature 😟
Post marked as solved
94 Replies
Xcode 11.2 crashes for me too but not for anything storyboard or UIKit related. Finding many are having bad access crashes on Xcode 11.2, including pure Swift Packages. See here for further details and temporary workaround: https://github.com/onevcat/Kingfisher/issues/1330 Xcode 11.2 needs a hot fix! Why would you ship this if this was in beta too?!!?!