(Filing to track and centralize discussion, since this has come up in several discussions.)
The number of generators in Pigeon is an issue for ongoing development (e.g., event channel support), and we are currently maintaining two generators—Objective-C and Swift—for the use case of iOS/macOS plugin development. Ideally we would only maintain one, which given the direction of iOS and macOS development would be Swift.
Swift/Obj-C interop is non-trivial; in particular, it doesn't seem to be possible to implement a Swift interface in Obj-C, so at least the top level code (the plugin class, or code factored out of it in cases where that's the whole implementation) would need to be converted to Swift as part of switching to the Swift Pigeon generator. That's work we want to do eventually, but isn't currently a priority.
This would apply to third parties as well; very crude GitHub search (e.g., no fork de-duping) suggests a majority of iOS Pigeon clients are using Obj-C rather than Swift, but not an overwhelming majority. Of course, they could always keep using older versions of Pigeon until they had time to transition.
Clients would be forced to write/maintain non-generated Swift code, which is not ideal for plugin maintainers who want to use Obj-C based on their own experience.
(Filing to track and centralize discussion, since this has come up in several discussions.)
The number of generators in Pigeon is an issue for ongoing development (e.g., event channel support), and we are currently maintaining two generators—Objective-C and Swift—for the use case of iOS/macOS plugin development. Ideally we would only maintain one, which given the direction of iOS and macOS development would be Swift.
In favor of turning it down:
Impediments to turning it down: