I have a similar issue, although not using APIGuard and making it slightly further in the [LAContext canEvaluatePolicy:error:] call before receiving a crash event. It's worth noting the crash is rare. I'll attach a crash report as well, but you can see the app has been running for about half a day (my logging tool shows the app crashed pretty quickly after coming back into the foreground). For Authentication, I am using the open source library Auth0.swift Version 2.1.0. The crashing line can be found here on GitHub for context, but I don't see how it could result in a crash at this time. Attached Crash Report 2022-09-10_11-58-02.2444_-0400-e31568fff78e0a76fafed6231bf9dea0a659f5ba.crash Crashed Backtrace Thread 9 name: Thread 9 Crashed: 0 libobjc.A.dylib 0x000000019cff7f40 objc_msgSend + 32 (:-1) 1 libobjc.A.dylib 0x000000019d011b24 objc_object::sidetable_release(bool, bool) + 260 (NSObject.mm:1738) 2 LocalAuthentication 0x00000001bb288ee4 __63-[LAContext _evaluatePolicy:options:log:cid:synchronous:reply:]_block_invoke + 304 (LAContext.m:345) 3 LocalAuthentication 0x00000001bb281ea0 __47-[LAClient _performSynchronous:callId:finally:]_block_invoke.186 + 200 (LAClient.m:449) 4 LocalAuthentication 0x00000001bb281300 -[LAClient _checkIdResultForTCC:synchronous:error:retryBlock:finally:] + 356 (LAClient.m:401) 5 LocalAuthentication 0x00000001bb2827b0 __64-[LAClient evaluatePolicy:options:uiDelegate:synchronous:reply:]_block_invoke_2 + 188 (LAClient.m:542) 6 CoreFoundation 0x0000000184265b24 __invoking___ + 148 (:-1) 7 CoreFoundation 0x0000000184283610 -[NSInvocation invoke] + 468 (NSForwarding.m:3378) 8 Foundation 0x0000000185a71918 __NSXPCCONNECTION_IS_CALLING_OUT_TO_REPLY_BLOCK__ + 24 (NSXPCConnection.m:170) 9 Foundation 0x0000000185a92f54 -[NSXPCConnection _decodeAndInvokeReplyBlockWithEvent:sequence:replyInfo:] + 572 (NSXPCConnection.m:316) 10 Foundation 0x0000000185a6d460 __88-[NSXPCConnection _sendInvocation:orArguments:count:methodSignature:selector:withProxy:]_block_invoke_3 + 212 (NSXPCConnection.m:1630) 11 Foundation 0x0000000185a81d4c -[NSXPCConnection _sendInvocation:orArguments:count:methodSignature:selector:withProxy:] + 2588 (NSXPCConnection.m:1651) 12 CoreFoundation 0x0000000184271c1c ___forwarding___ + 1128 (NSForwarding.m:3618) 13 CoreFoundation 0x0000000184270f70 _CF_forwarding_prep_0 + 96 (:-1) 14 LocalAuthentication 0x00000001bb2826b4 __64-[LAClient evaluatePolicy:options:uiDelegate:synchronous:reply:]_block_invoke + 240 (LAClient.m:541) 15 LocalAuthentication 0x00000001bb281c80 __47-[LAClient _performSynchronous:callId:finally:]_block_invoke + 584 (LAClient.m:441) 16 libdispatch.dylib 0x0000000183f44a30 _dispatch_client_callout + 20 (object.m:560) 17 libdispatch.dylib 0x0000000183f542d4 _dispatch_sync_invoke_and_complete + 56 (queue.c:1028) 18 LocalAuthentication 0x00000001bb2819e8 -[LAClient _performSynchronous:callId:finally:] + 220 (LAClient.m:460) 19 LocalAuthentication 0x00000001bb28257c -[LAClient evaluatePolicy:options:uiDelegate:synchronous:reply:] + 392 (LAClient.m:540) 20 LocalAuthentication 0x00000001bb288d48 -[LAContext _evaluatePolicy:options:log:cid:synchronous:reply:] + 472 (LAContext.m:340) 21 LocalAuthentication 0x00000001bb27e364 -[LAContext _evaluatePolicy:options:log:cid:error:] + 284 (LAContext.m:387) 22 LocalAuthentication 0x00000001bb27e090 -[LAContext canEvaluatePolicy:error:] + 304 (LAContext.m:533) 23 Core 0x0000000103669140 available.get + 24 (BioAuthentication.swift:22) 24 Core 0x0000000103669140 CredentialsManager.credentials(withScope:minTTL:parameters:headers:callback:) + 104 (CredentialsManager.swift:225) 25 Core 0x0000000103631dd4 specialized Auth0AuthProvider.fetchTokens(onCompletion:) + 684 (<compiler-generated>:238) 26 Core 0x000000010362dcdc fetchTokens + 20 (AuthProvider.swift:156) 27 Core 0x000000010362dcdc refreshTokensIfNeeded + 20 (<compiler-generated>:0) 28 Core 0x000000010362dcdc refreshTokensIfNeeded + 20 (AuthInterceptor.swift:17) 29 Core 0x000000010362dcdc AuthInterceptor.interceptAsync<A>(chain:request:response:completion:) + 176 30 Core 0x000000010362dd60 protocol witness for ApolloInterceptor.interceptAsync<A>(chain:request:response:completion:) in conformance AuthInterceptor + 20 (<compiler-generated>:0) 31 Core 0x00000001036cecfc RequestChain.kickoff<A>(request:completion:) + 140 (RequestChain.swift:66) 32 Core 0x00000001036d0ce0 RequestChainNetworkTransport.send<A>(operation:cachePolicy:contextIdentifier:callbackQueue:completionHandler:) + 404 (RequestChainNetworkTransport.swift:99) 33 Core 0x0000000103694be8 ApolloClient.fetch<A>(query:cachePolicy:contextIdentifier:queue:resultHandler:) + 168 (ApolloClient.swift:91) 34 Core 0x00000001035d7c88 specialized APIClient.query<A>(_:cachePolicy:queue:resultHandler:) + 460 35 Core 0x00000001035d77d4 AccountHolderRepositoryImpl.loadAccountHolder(isSilent:) + 552 (AccountHolderRepository.swift:72) 36 Core 0x00000001035d7584 AccountHolderRepositoryImpl.refreshAccountIfNeeded(force:) + 444 (AccountHolderRepository.swift:97)

Thanks, Quinn! I’ll look into these resources you provided soon.

However, I think there's a better solution, which is to always display the tabbed view when your app starts, regardless of the login status. In general, tabbed views are expected to be the permanent "root" of an app.  I may need to experiment with this specifically for the Login View and the rest of the app. Regarding the NavigationView/Stack having a similar issue, though, we have a flow that may be a bit wonky if we tried to treat it similarly. We have a modifier view responsible for gating functionality behind a condition. To avoid the issue documented above for this, I see two approaches: Present a modal over whatever you want to be locked with an opportunity for the user to see the sensitive content. Require handling this by the referring View and ViewModel and only present the intended destination once the condition is met. (less easy to share handling in various parts of the application) From a code structure, shared handling, and modeling perspective, it seems much easier to have a ViewModifier conditionally present the Navigation flow (which uses a Nav View) when needed and show the intended destination when authenticated, regardless of presentation context. For this case, I don't see much of a workaround to guarantee unnecessary work isn't performed without more work on the referring views, potentially showing sensitive content before gating with a shared modifier, or using the debounce + cancellable behavior described above to work within the constraints of this bug.

I am able to reproduce this problem on iOS 14.0.1, but not on iOS 14.5. Perhaps your issue was addressed. Using the code provided, there are other appearance-related issues, but if I comment out the getPeople(num:) calls on the tabItem's onAppear - leaving the one within SimpleView - it appears to work as I expect (on iOS 14.5).