Just checked new Xcode 26.2 with iOS 26.2 and the debug builds startup time indeed improved significantly. We still have ~7 seconds of initial sluggishness (difference between debug executable on/off), but it's way better than it was before! 👍 While I appreciate the movement in the right direction, this still represents a substantial regression from the prior baseline, ~1s in Xcode 16. A reduction in severity isn’t a resolution. If Xcode is to remain viable for professional workflows, startup and initial responsiveness need to return to the Xcode 16 baseline.

Just checked new Xcode 26.2 with iOS 26.2 and the debug builds startup time indeed improved significantly. We still have ~7 seconds of initial sluggishness (difference between debug executable on/off), but it's way better than it was before! 👍 That’s not an improvement, that's a partial rollback of a huge regression. On Xcode 16 it was ~1s. That was the baseline. Seven seconds of launch + long initial sluggishness in debug is still absurd. Stop celebrating “less bad.” This shouldn’t be acceptable and Xcode 26 is still unusable for any serious work.

I faced a similar issue recently. First you have to set the z-index of the SquareView to be higher if it is selected. That is not enough though, as it will only be in front of SquareViews in the same GridRow. That is because the z-index of nested views in SwiftUI does not propagate to parent views. So we must also set the z-index of that GridRow to be higher if it contains the piece being dragged. Store the piece being dragged's id and use that for the comparison!