Incorrect dismiss behavior after presenting UIAlertController UIKit

[nmalevich]

Description

I use AlertState, @ Presents and present method of UIViewController for showing alerts
If AlertState has ButtonState with action, everything is right. But if AlertState doesn't have ButtonState or has ButtonState with only TextState(without action), after dismissing state of alert doesn't become nil
So I don't have any problems with first show, but after first dismiss property in my state for alerts isn't nil, it is still previous value. So when I try to show next time, it will be nothing, because state isn't change

Checklist

• I have determined whether this bug is also reproducible in a vanilla SwiftUI project.
• If possible, I've reproduced the issue using the main branch of this package.
• This issue hasn't been addressed in an existing GitHub issue or discussion.

Expected behavior

State of alert after dismissing is nil

Actual behavior

State of alert after dismissing isn't nil

Reproducing project

UIKitAlertDismissButtonBugExample.zip

The Composable Architecture version information

1.15.0

Destination operating system

iOS 17.6.1

Xcode version information

15.4

Swift Compiler version information

swift-driver version: 1.90.11.1 Apple Swift version 5.10 (swiftlang-5.10.0.13 clang-1500.3.9.4)
Target: x86_64-apple-macosx14.0

[mbrandonw]

Hi @nmalevich, did you mean to file this issue again?

[nmalevich]

I had made a mistake in previous issues and you found it
I had fixed it but I found another problem
In this issues I have described another problem

[mbrandonw]

This is the problem:

case .view(.testIncorrect):
  state.alert = .init {
    .init("HELLO")
  }

You are showing an alert without any buttons. Our UIAlertController.init helper adds an "OK" button for you, but tapping that can't send any actions because it doesn't have that information. This can't work like it does in SwiftUI. You need to specify a button for dismissing, and you can send the .dismiss action with it.

I am going to again convert this to a discussion because this is not an issue with the library. In the future I think you can open discussions for questions like this instead of filing issues.