@testable is best understood as a hack because, IMO, the idea of tests being a separate build product fundamentally runs against the nature of a language with access control. Tests ought to be treated as a fundamental part of the code they validate, just like types are. I would like to see the Swift ecosystem eventually evolve support for tests that sit alongside implementation, much like how they do in the D programming language:
In D, a unittest block can appear almost anywhere, and naturally has access to everything in that scope, and the compiler supports conditionally compiling all the unittest blocks so that they can be run in debug builds. This would be a large paradigm shift from what XCTest and Xcode support today in the Swift ecosystem, which is why @testable exists as a stopgap, but I don't think we'll really reach a satisfying testing story by making incremental changes to how @testable works. I believe the D model would fit much more naturally into how Swift as a language is designed.