Open Radar

 
Summary:
Working in a mixed-language project where Objective C and Swift implementations reference one another, it can be difficult to quickly navigate to the desired representation of a symbol's definition. Cmd-clicking in a Swift file on a symbol defined in a .h or .m file is liable to jump to a dynamically generated Swift "interface" version of the pertinent file. This is great when you are working against system frameworks for which you don't have source, or if you are only looking to verify an interface. If you want to make changes in the pertinent source file, however, it can be cumbersome to get to that file.

Although the "Show Original Source" menu item is handy, it seems to me that a dynamic Swift interface and its corresponding Objective C implementation and header files should all be considered "Counterparts". That is, for example, pressing Cmd-Opt-Up or Cmd-Opt-Down from a generated Swift header file should cycle through to the Objective C header, and to the Objective C implementation source file, if present.

I think you would only want to include the generated Swift interface in workspaces where Swift is being used, but in those environments, having the generated Swift interface being included among the counterparts would probably suit many workflows.

I don't see any downside when editing a native Swift file, because as far as I know there is never a "Counterpart" for such a file. One downside when focusing on pure Objective C development is the Swift generated interface might get in the way of flipping quickly from header to source file. I think this would be alleviated however by maintaining a predictable ordering such that for example Cmd-Opt-Up always went from header to source, and Cmd-Opt-Down always went from source to header. In this scenario, only pressing the shortcut twice in succession would ever lead you to the generated Swift interface.

Steps to Reproduce:


Expected Results:


Actual Results:


Version:
Version 7.3.1 (7D1012)

Notes:


Configuration:


Attachments: