Post

Replies

Boosts

Views

Activity

Crash on iOS 14 when using @available(iOS 15.0, *) @FocusState variable in SwiftUI
Adding the following variable declaration is crashing the app when running on iOS 14: @available(iOS 15.0, *) @FocusState var isFocused: Bool This issue was happening in Xcode 13.2 but only for release builds tested on a device. I was hoping this issue will be fixed in Xcode 13.3 but it wasn't. Now it crashes even in Simulator. The crash stack is the following: EXC_BAD_ACCESS (code=1, address=0x0) Thread 2 Queue : com.apple.root.utility-qos (concurrent) #0 0x00000001048e4f98 in swift::ResolveAsSymbolicReference::operator()(swift::Demangle::__runtime::SymbolicReferenceKind, swift::Demangle::__runtime::Directness, int, void const*) () #1 0x000000010490261c in swift::Demangle::__runtime::Demangler::demangleSymbolicReference(unsigned char) () #2 0x00000001048ff880 in swift::Demangle::__runtime::Demangler::demangleType(__swift::__runtime::llvm::StringRef, std::__1::function<swift::Demangle::__runtime::Node* (swift::Demangle::__runtime::SymbolicReferenceKind, swift::Demangle::__runtime::Directness, int, void const*)>) () #3 0x00000001048ea510 in swift_getTypeByMangledNameImpl(swift::MetadataRequest, __swift::__runtime::llvm::StringRef, void const* const*, std::__1::function<swift::TargetMetadata<swift::InProcess> const* (unsigned int, unsigned int)>, std::__1::function<swift::TargetWitnessTable<swift::InProcess> const* (swift::TargetMetadata<swift::InProcess> const*, unsigned int)>) () #4 0x00000001048e7f0c in swift::swift_getTypeByMangledName(swift::MetadataRequest, __swift::__runtime::llvm::StringRef, void const* const*, std::__1::function<swift::TargetMetadata<swift::InProcess> const* (unsigned int, unsigned int)>, std::__1::function<swift::TargetWitnessTable<swift::InProcess> const* (swift::TargetMetadata<swift::InProcess> const*, unsigned int)>) () #5 0x00000001048e8120 in swift_getTypeByMangledNameInContext () #6 0x000000010868eea8 in AG::swift::metadata::mangled_type_name_ref(char const*, AG::swift::metadata::ref_kind*) const () #7 0x000000010868f45c in AG::swift::metadata_visitor::visit_field(AG::swift::metadata const*, AG::swift::field_record const&, unsigned long) () #8 0x000000010868edac in AG::swift::metadata::visit(AG::swift::metadata_visitor&) const () #9 0x000000010869c864 in AG::LayoutDescriptor::Builder::visit_element(AG::swift::metadata const*, AG::swift::metadata::ref_kind, unsigned long) () #10 0x000000010868f47c in AG::swift::metadata_visitor::visit_field(AG::swift::metadata const*, AG::swift::field_record const&, unsigned long) () #11 0x000000010868edac in AG::swift::metadata::visit(AG::swift::metadata_visitor&) const () #12 0x000000010869d3f0 in AG::LayoutDescriptor::make_layout(AG::swift::metadata const*, AGComparisonMode, AG::LayoutDescriptor::HeapMode) () #13 0x000000010869e600 in AG::(anonymous namespace)::LayoutCache::drain_queue(void*) () #14 0x00000001069ad884 in _dispatch_client_callout () #15 0x00000001069bf96c in _dispatch_root_queue_drain () #16 0x00000001069c0188 in _dispatch_worker_thread2 () #17 0x00000001bca3eb04 in _pthread_wqthread () Enqueued from com.apple.main-thread (Thread 1) Queue : com.apple.main-thread (serial) #0 0x00000001069b1570 in _dispatch_async_f_slow () #1 0x000000010869d65c in AG::(anonymous namespace)::LayoutCache::fetch(AG::swift::metadata const*, unsigned int, AG::LayoutDescriptor::HeapMode) () #2 0x0000000108694390 in AG::Graph::intern_type(AG::swift::metadata const*, AG::ClosureFunction<void*>) () #3 0x00000001086a63b0 in AGGraphInternAttributeType () #4 0x00000001086aad1c in Attribute.init<τ_0_0>(body:value:flags:update:) () #5 0x0000000101522610 in GraphHost.Data.init() () #6 0x0000000100ed9cc4 in AppGraph.init<τ_0_0>(app:) () #7 0x0000000100ed9be4 in AppGraph.__allocating_init<τ_0_0>(app:) () #8 0x00000001014bdecc in runApp<τ_0_0>(_:) () #9 0x0000000101093a74 in static App.main() () #10 0x00000001001ab630 in static TestiOS14CrashApp.$main() at /Users/zh/Xcode Projects/TestiOS14Crash/TestiOS14Crash/TestiOS14CrashApp.swift:10 #11 0x00000001001ab6e0 in main () #12 0x00000001004c1088 in start () #13 0x4328800000000000 in 0x4328800000000000 () To reproduce, you can create a new iOS project in Xcode 13.3 using the "App" template, change iOS Deployment Target to 14.5, and edit the ContentView.swift file by adding this line so the code looks just like this: struct ContentView: View { @available(iOS 15.0, *) @FocusState var isFocused: Bool     var body: some View {         Text("Hello, world!")             .padding()     } } Now build and run the app in iOS 14.5 Simulator to see it crashing on launch. Is there a workaround for this?
3
1
1.1k
Mar ’22
Adding a drag gesture to a View inside a ScrollView blocks the scrolling
So I have a ScrollView holding a set of views:ScrollView { ForEach(setOfData) { data in NavigationLink(destination: ...) { CustomView(data: data) } .buttonStyle(BackgroundButtonStyle()) } }In a CustomView I have a drag gesture:let drag = DragGesture() .updating($gestureState) { value, gestureState, _ in // ... } .onEnded { value in // ... }Which I assign to a part of the view:ZStack(alignment: .leading) { HStack { // ... } HStack { // ... } .gesture(drag) // or .simultaneousGesture(drag) }As soon as I attach the gesture, the ScrollView stop scrolling. The only way to make it scroll it to start scrolling from a part of it which has no gesture attached. How can I avoid it and make them both work together. In UIKit is was as simple as specifying true in shouldRecognizeSimultaneouslyWithmethod. How can I have the same in SwiftUI?In SwiftUI I've tried attaching a gesture using .simultaneousGesture(drag) and .highPriorityGesture(drag) – they all work the same as .gesture(drag). I've also tried providing all possible static GestureMask values for including: parameter – I have either scroll working or my drag gesture working. Never both of them.Adding a simultaneousGesture to a ScrollViewdirectly make both of them work simultaneously. Even though I'm not sure it's even possible to get the View my gesture relates to and manipulate its subviews in this case. And even in this case it makes ScrollView behaving weird – it always generates accidental view taps on release when you end scrolling. So in my list you almost can't scroll without triggering a NavigationLink.
2
1
4.3k
Aug ’19