Use dedicated animator instance per controller

[SplittyDev]

Why

When multiple Bonsplit controllers are used (such as in a macOS multi-window setting), opening new panes doesn't work anymore.

I've tracked this down to the SplitAnimator using a shared instance across multiple controllers.

Changes

• Removed SplitAnimator/shared
• Added SplitViewController/animator property (internal API)
• Modified SplitContainerView to use the animator instance from the SplitViewController, which is obtained from the environment values

[vercel]

@SplittyDev is attempting to deploy a commit to the Replay Team on Vercel.

A member of the Team first needs to authorize it.

[SplittyDev]

This change isn't technically required for the fix, but it's good practice to use structured concurrency instead of GCD nowadays. The Task inherits the MainActor from NSViewRepresentable, so this is perfectly safe to do.

[Copilot]

Pull request overview

This PR addresses a multi-controller issue in Bonsplit (e.g., macOS multi-window) by eliminating the global SplitAnimator singleton and ensuring animations are scoped to each SplitViewController.

Changes:

• Removed SplitAnimator.shared in favor of per-controller animator instances.
• Added an animator property to SplitViewController.
• Updated SplitContainerView to use the controller-provided animator (via environment lookup).

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
Sources/Bonsplit/Internal/Views/SplitContainerView.swift	Switches split-pane animation to use the environment controller’s animator instead of a singleton.
Sources/Bonsplit/Internal/Utilities/SplitAnimator.swift	Removes the shared singleton and allows constructing animator instances.
Sources/Bonsplit/Internal/Controllers/SplitViewController.swift	Introduces a per-controller SplitAnimator instance to avoid cross-controller interference.

Comments suppressed due to low confidence (1)

Sources/Bonsplit/Internal/Views/SplitContainerView.swift:83

• The inner Task { ... } runs from inside a DispatchQueue.main.async @Sendable closure, so it does not guarantee MainActor / main-thread execution, yet it mutates AppKit views (isHidden, setPosition) and calls a @MainActor animator. Consider replacing this with Task { @MainActor in ... } (and/or await Task.yield() if you truly need to wait a runloop for layout) to keep UI work on the main actor and preserve the original “wait for layout” behavior.

                // Wait for layout
                Task {
                    // Show the new pane and animate
                    splitView.arrangedSubviews[newPaneIndex].isHidden = false

                    splitController.animator.animate(
                        splitView: splitView,
                        from: startPosition,
                        to: targetPosition
                    ) {
                        context.coordinator.isAnimating = false
                    }
                }

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

You can also share your feedback on Copilot code review. Take the survey.