Presenting multiple children from a feature

[ysmaliak]

Description

There is a bug in the modal presentation behavior when replacing child views. Specifically:

1. When a modal is presented.
2. The modal displays a first child.
3. An attempt is made to replace the first child with a second child.

The replacement operation is not working as expected. The behavior is inconsistent and incorrect, resulting in improper display or failure to update the modal's content.

Note: this is a UIKit project.

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

The first child should be dismissed, and the second child should be presented.

Simulator.Screen.Recording.-.iPhone.15.Pro.-.2024-09-09.at.18.00.02.mp4

Actual behavior

Sometimes (randomly), the parent modal is dismissed when trying to present the second child.

Simulator.Screen.Recording.-.iPhone.15.Pro.-.2024-09-09.at.17.59.49.mp4

Steps to reproduce

1. Present Parent as a modal.
2. Present the First Child as a modal from the Parent.
3. Tap a button on the First Child; the Parent should be able to receive this action from the delegate and replace the destination with a Second Child.

Sample project: https://github.com/ysmaliak/tca-navigation-test

The Composable Architecture version information

1.14.0

Destination operating system

iOS 17.5

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: arm64-apple-macosx14.0

[mbrandonw]

Hi @ysmaliak, this is not a bug with the library, but rather just how UIKit (and even SwiftUI) work. You cannot simultaneously dismiss and present controllers, and you can't even simultaneously present two sheets at once. There is even some logs in the console of your app letting you know this wrong:

Attempt to present <tca_navigation_test.SecondChildViewController: 0x13af15120> on <tca_navigation_test.ParentViewController: 0x13ad0a270> (from <tca_navigation_test.ParentViewController: 0x13ad0a270>) whose view is not in the window hierarchy.

The fix is to space out the destination mutations. You can first nil out the destination, wait a small amount of time, and then mutate the destination to the next screen.

However, I also tested this code in iOS 18.1 and things seem to work as intended. So perhaps UIKit has fixed some bugs. I'm not sure it will always work, but at least this simple use case seems to work as expected.

Since this isn't an issue with the library I am going to convert it to a discussion. Please feel free to continue the conversation over there!

[jshier]

@stephencelis I didn't see a specific overload so I didn't think the functionality existed. I guess it just falls out of the existing API. Unfortunately it also doesn't work, even before the presentation occurs. In the example it instead produces a runtime issue:

/Users/user/Library/Developer/Xcode/DerivedData/tca-navigation-test-eqeblkobdrjinigzijcdpomodgqj/SourcePackages/checkouts/swift-composable-architecture/Sources/ComposableArchitecture/Reducer/Reducers/Scope.swift:343 A "Scope" at "tca_navigation_test/ParentViewController.swift:14" received a child action when child state was set to a different case. …

Action:
ParentFeature.Destination.Action.firstChild(.buttonTapped)
State:
ParentFeature.Destination.State.secondChild

This is generally considered an application logic error, and can happen for a few reasons:

• A parent reducer set "ParentFeature.Destination.State" to a different case before the scoped reducer ran. Child reducers must run before any parent reducer sets child state to a different case. This ensures that child reducers can handle their actions while their state is still available. Consider using "Reducer.ifCaseLet" to embed this child reducer in the parent reducer that change its state to ensure the child reducer runs first.

• An in-flight effect emitted this action when child state was unavailable. While it may be perfectly reasonable to ignore this action, consider canceling the associated effect before child state changes to another case, especially if it is a long-living effect.

• This action was sent to the store while state was another case. Make sure that actions for this reducer can only be sent from a view store when state is set to the appropriate case. In SwiftUI applications, use "SwitchStore".

@mbrandonw That's interesting, I didn't realize the order of observations was non deterministic. Explains why changing the order of the presents didn't improve anything.

I'm still pretty sure that if presenting the destination directly worked, the underlying UIKit integration would properly dismiss and present and this issue would be solved, users would just have to make sure to use that form.

[jshier]

Actually, that runtime issue only comes up when you tap the button a second time, as it's sending the action after the destination has changed. The first tap changes the state but doesn't do anything. I'll investigate that part.

[jshier]

When scoped to the destination, present isn't called when the state transitions directly to the second state. Investigating, it looks like the root observe in the parent exits early because the id of the item hasn't changed, despite the underlying state changing. I think this is due the underlying item being the same Store instance, which generates the same id every time since the reference, of course, hasn't changed. Whether this is desirable or correct I can't say yet, but I think it means any reference type used in these tools will have the same problem.

[FredericRuaudel]

Hi !

If it can help, I've also made a project that showcase this kind of navigation in both UIKit and SwiftUI with both usecases: setting the new destination directly and setting destination to nil, waiting then setting the second destination.

In SwiftUI, only the first usecase is working while in UIKit both fail

https://github.com/FredericRuaudel/DoubleModaleShowCase

I also try to run the project with the draft PR that seems related #3464 but with no luck, it behaves exactly the same.

[FredericRuaudel]

As a follow-up, I finally fix my issue by simply increasing the waiting time between the set of the first popover to nil and the set of it to the second destination from 300ms to 1sec. 500ms was not enough but I didn't try to fine-tune more than that so maybe we can find a lesser value between 500ms and 1sec.
The fix is available in the last commit of my project linked above.

To sum it up, it goes like this:

           switch action {
           // …
           case let .destination(.presented(.shareOptions(.delegate(delegateAction)))):
                switch delegateAction {
                case let .dismissThenShare(value):
                    state.destination = nil
                    return .run { [value] send in
                        try await Task.sleep(nanoseconds: 1000 * NSEC_PER_MSEC) // Here we need to wait more than 500ms at least
                        await send(.showShareSheet(value))
                    }
                }

            case .showShareSheet(let value):
                state.destination = .shareSheet(.init(value: value))
                return .none
            }

[FredericRuaudel]

It seems that the issue has worsened in iOS 26. I've opened issue #3836 with sample code to showcase the problem