We are trying to submit a login form on enter by using onCommit. It works but it seems that it is not a good fit because the onCommit action triggers whenever the field loses focus, so simply clicking between the email/password fields will cause the form to be submitted. Here is a playground showing the issue: import SwiftUI import PlaygroundSupport struct LoginView: View { @State public var email: String @State public var password: String var body: some View { TextField("Email", text: $email) SecureField("Password", text: $password, onCommit: onLoginAction) Button("Login", action: onLoginAction) } } func onLoginAction() { print("submitting login") } PlaygroundPage.current.setLiveView(LoginView(email: "a@b.cc", password: "secret"))

This issue can be recreated by copying the below code into a playground. You will see that in the first example below the publisher is not released when using .flatMap with Fail import Combine import Foundation struct SampleError: Error {} weak var weakPublisher: CurrentValueSubjectSampleError, Never! autoreleasepool {   let publisher = CurrentValueSubjectSampleError, Never(SampleError())   weakPublisher = publisher       publisher     .flatMap(FailVoid, SampleError.init(error:))     .sink(       receiveCompletion: { print("completed \($0)") },       receiveValue: { print("value \($0)") }     )     .cancel() } assert(weakPublisher == nil, "should be nil BUT IS NOT !!!") In this second example, the publisher is released as expected using .tryMap with throw import Combine import Foundation struct SampleError: Error {} weak var weakPublisher2: CurrentValueSubjectSampleError, Never! autoreleasepool {   let publisher = CurrentValueSubjectSampleError, Never(SampleError())   weakPublisher2 = publisher       publisher     .tryMap{ throw $0 }     .sink(       receiveCompletion: { print("completed \($0)") },       receiveValue: { print("value \($0)") }     )     .cancel() } assert(weakPublisher2 == nil, "is nil as expected") Is this the expected behavior?

It looks like having tryCatch + retry will create a retain cycle. Here is the repo demonstrating the issue: - https://github.com/yuri-qualtie/CombineRetryDemo Steps to reproduce: Launch App - CombineRetryDemo Tap - "Load HTML" button Wait for prints in console. For example: completed finished Tap "Back" button Run Debug Memory Graph Expected: HTMLViewController is deallocated and de inited is printed in console subscription is canceled and all the combine publishers are deallocated Actual: HTMLViewController is deallocated and de inited is printed in console Retry and TryCatch are not deallocated and create retain cycle. Memory graph - https://github.com/yuri-qualtie/CombineRetryDemo/issues/1 Context: For our use case we are using a sequence of Combine operators to make a request to a server. In the case where the request fails (server responds with expired token/invalid etc) we want to refresh our token inside the .tryCatch and retry the entire sequence from the beginning. After experimenting we found that replacing retry by having all of our business logic inside the .tryCatch doesn't create a retain cycle but requires us to duplicate our sequence of operators. Is there a better approach we can use?

The goal is to add accessibility identifiers to a VStack where the VStack, View1, and View2 have their own, separate accessibility identifiers set, like so:            VStack { // identifier a              View1 // identifier b              View2 // identifier c           } When trying to use .accessibilityIdentifier(identifier) with any SwiftUI Stack, the identifier is applied to everything inside the VStack and overrides any identifiers that View1 or View2 may have had. The current workaround is to use a GroupBox Container View to wrap the VStack. It achieves the desired result of having different levels of accessibility identifiers but has the drawback of coming with some styling (adds padding). Is there a better way to go about adding accessibility identifier to a container view? See Example playground - https://github.com/sparta-developers/swiftui-accessible-container