Dismiss and present on presenting UIViewController

[v-slobodianiuk]

Description

Hello!
I get incorrect behavior when leaving the screen and opening a new one in a modal window. Sometimes everything works correctly, but other times all my windows just close. I wrote a Unit test and a UI test. The UI test sometimes fails.

Here is a link to the repository with an Example project

Steps:

1. Present AViewController on RootViewController
2. Present BViewController on AViewController
3. Dismiss BViewController and present CViewController on AViewController

Error:

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

Present CViewController

Actual behavior

Dissmis AViewController

Reproducing project

import ComposableArchitecture
import UIKit

@Reducer
struct AFeature {
    @ObservableState
    struct State: Equatable {
        @Presents var destination: Destination.State?
    }

    @Reducer
    enum Destination {
        case bFeature(BFeature)
        case cFeature(CFeature)
    }

    enum Action {
        case showB
        case showC
        case destination(PresentationAction<Destination.Action>)
    }

    var body: some Reducer<State, Action> {
        Reduce { state, action in
            switch action {
            case .showB:
                state.destination = .bFeature(.init())
                return .none

            case .showC:
                state.destination = .cFeature(.init())
                return .none
                
            case .destination(.presented(.bFeature(.delegate(.closeAndShowC)))):
                return .send(.showC)

            default:
                return .none
            }
        }
        .ifLet(\.$destination, action: \.destination)
    }
        
}

extension AFeature.Destination.State: Equatable {}

final class AViewController: UIViewController {
    lazy var button = UIButton(type: .system, primaryAction: .init(handler: { [weak self] _ in
        self?.store.send(.showB)
    }))

    @UIBindable private var store: StoreOf<AFeature>
    
    init(store: StoreOf<AFeature>) {
        self.store = store
        super.init(nibName: nil, bundle: nil)
    }
    
    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
    
    deinit {
        logger.info("✅ Deinit: \(String(describing: Self.self))")
    }

    override func viewDidLoad() {
        super.viewDidLoad()
        
        view.backgroundColor = .systemBackground
        button.configureTintedButton(withTitle: "Show B")
        button.center = view.center
        view.addSubview(button)
        
        present(item: $store.scope(state: \.destination?.bFeature, action: \.destination.bFeature)) { store in
            BViewController(store: store)
        }
        
        present(item: $store.scope(state: \.destination?.cFeature, action: \.destination.cFeature)) { store in
            CViewController(store: store)
        }
    }
}

Example project

The Composable Architecture version information

1.17.1

Destination operating system

iOS 18

Xcode version information

Xcode 16.2

Swift Compiler version information

swift-driver version: 1.115.1 Apple Swift version 6.0.3 (swiftlang-6.0.3.1.10 clang-1600.0.30.1)
Target: arm64-apple-macosx15.0

[BastianKusserow]

Hey @v-slobodianiuk, we currently observe the same issue and I wasn't able to find a fix. Did you by any chance a way around that behaviour?

[v-slobodianiuk]

Hey @v-slobodianiuk, we currently observe the same issue and I wasn't able to find a fix. Did you by any chance a way around that behaviour?

Set current destination to nil. Add delay about 0.5 s to set the new destination.

[stephencelis]

@v-slobodianiuk I believe this is vanilla behavior and reproducible in UIKit if you were to simultaneously dismiss and present a view controller without waiting for it to complete.

One workaround is to introduce a delay, as you've done, and another might be to try to group all sheet presentation into a single present method that switches over the destinations instead of using two separate presents that overlap.

If you do believe this is a bug with our present helper, please reopen the issue on our Swift Navigation library, instead. For now I'm going to convert this to a discussion till it is determined to be a bug with us and not Apple.

[jshier]

Here my final investigation of the issue from six months ago: #3371 (reply in thread)

There was a PR about identified presentations that looked like it would fix this but it was closed recently and I can't find it.

[jshier]

Ah, it was #3451, which has a draft PR to fix, #3464. I think if TCA can provide swift-navigation with the proper information, the chained dismiss into presentation would work automatically.

[jshier]

Another reason you're seeing many reports like this is that, last I tried, attempting to present the whole Destination just didn't work. If that can be made to work you may not need to entirely fix the case of sibling presentations.

[BastianKusserow]

Hey @jshier, nice investigation. Just wondering, you've mentioned that you have a fork solving the issues outlined here. Would be interested in what you've changed?
Also wanted to mention that, while putting all of the presentations into one call to present and switching over it, this solution would break once I need a sheet presentation and eg. a fullscreen cover I believe, so one is stuck with delaying the presentation for an arbitrary amount of time..

[jshier]

Not a fork, we wrote our own presentation and navigation methods in our view controller superclass that track the presented controller and detects when it needs to dismiss and present the next controller. This works for all presentations from the same controller, whether modal, full screen or alert.

[stephencelis]

If you do reproduce the issue in vanilla UIKit, consider filing a Feedback with Apple!

[jshier]

UIKit already has the tools to handle this properly with just a bit of work. SwiftUI does not, but it's a long known issue there.