Switching activation policy from accessory to regular does not activate the app menu in the menu bar. User have switch to another app and back to make app menu to show in the menu bar. Even the call to activate is successful: assert(NSApp.setActivationPolicy(.regular)) the menu bar shows menu of the previously active app. Filed feedback: FB7743313 Here is the project reproducing the issue with steps: https://github.com/sparta-science/MacSwitchActivation Below is README with step to reproduce to make it searchable in the developer forums: MacSwitchActivation Demo of SetActivationPolicy bug on Mac Expected behaviour When we click Show Window we expect the app to enter "Active State" Actual behaviour When we click Show Window we instead see the app enter "Unexpected State" (See Reproduction Steps) To workaround the user has to switch to another app temporarily and switch back to our app to get menu showing. App States Active State: App name appears in the menu bar App Window is on top App appears in dock Active State is entered by: House Icon -> Show Window which should run NSApp.activate(ignoringOtherApps: true) NSApp.setActivationPolicy(.regular) Accessory State: App name does not appear in the menu bar No App Window is visible App does not appear in dock Accessory State is entered by closing the app window which triggers NSApp.setActivationPolicy(.accessory) Unexpected State: The previous active app name appears in the menu bar App Window is on top App does not appear in dock Steps to reproduce Launch the app to begin in "Active State" Close app window to enter "Accessory State" Restart the app to begin in "Accessory State" Attempt to enter "Active State" by selecting Show Window in the menu dropdown Notice the new "Unexpected State" Cmd-tab to another app and back brings the menu and name in top left corner

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

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?

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?

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"))