What is Pigeon and how does it improve platform channels?

WHAT THIS TESTS: The interviewer wants to know if you have moved beyond copy-pasting MethodChannel snippets and understand why maintaining hand-written platform channel glue is risky at scale. They are checking for awareness of interface contracts, type safety across language boundaries, and the practical cost of boilerplate and stringly-typed APIs in production codebases.

A GOOD ANSWER COVERS: First, define Pigeon as a dev-dependency code generator, not a runtime library. Second, explain the workflow: you write an abstract Dart class annotated with HostApi or FlutterApi, plus plain data classes, then run the pigeon CLI to generate Dart, Kotlin, Java, Swift, Objective-C, C++, or GObject implementations. Third, contrast this with manual MethodChannel where you manually match string channel names, serialize arguments with StandardMessageCodec, and cast dynamic results on both sides. Fourth, highlight type safety: the generated code uses real types instead of Map or dynamic, so mismatches are caught at build time rather than runtime. Fifth, mention boilerplate reduction: the tool writes the method channel setup, the codec handling, the callback wrappers, and the error translation into PlatformException for you. Sixth, note advanced features if prompted: synchronous host methods that always reply once, async methods via the async annotation, custom error details with FlutterError or PigeonError, TaskQueue threading control, multi-instance support with message channel suffixes, and event channels for Swift and Kotlin.

COMMON WRONG ANSWERS: Calling Pigeon a plugin or runtime package rather than a code generator. Claiming it replaces MethodChannel entirely at runtime instead of generating typed wrappers over it. Saying it only supports Android and iOS while missing Windows, Linux, and macOS. Asserting that it uses a custom binary codec rather than StandardMessageCodec. Forgetting that the Dart definition file must contain only declarations, no method bodies. Confusing HostApi with FlutterApi directionality.

LIKELY FOLLOW-UPS: How would you handle breaking changes in a Pigeon contract when shipping a plugin to multiple platform teams? When would you still choose raw MethodChannel over Pigeon? How do you test generated host code in CI without a full emulator? What is the difference between a FlutterApi and a HostApi, and how does error propagation differ for synchronous versus asynchronous host methods? How would you support multiple concurrent instances of the same API?

ONE CONCRETE EXAMPLE: Imagine a battery plugin. In the manual approach, you create a MethodChannel with the string battery, call invokeMethod getBatteryLevel, then in Android Kotlin you cast call.arguments as Map and return an Int, hoping the Dart side remembers to cast result as int. With Pigeon, you declare abstract class BatteryApi with int getBatteryLevel annotated HostApi, plus a BatteryResult class if needed. After running pigeon, Dart receives a typed Future of int, Android receives an override fun getBatteryLevel Int, and any rename or type change breaks the build immediately on both sides instead of failing at runtime in production.

Source: pub.dev pigeon package documentation.