Both iOS native testing and Objective-C are admittedly out of my familiarity zone, so please let me know if there's a better way to test the plugin. I'm also pretty sure these tests can be made more thorough using POP and a mock class or two, during the Swift migration.

I'm also pretty sure these tests can be made more thorough using POP and a mock class or two, during the Swift migration.

It is important to get full coverage BEFORE the migration, so that the contributors/reviewers are fully aware of what the existing behavior is (and with bonus point to discover new bugs).

You can follow this to get a test coverage report in Xcode. To be clear, this coverage report is just a tool, not a metric - we need to actually read the test and decide whether we have full coverage.

If we can get good coverage without using OCMock, then just writing Swift test is fine. But if we need OCMock, then we may have to do the backfill in ObjC first due to OCMock limitation discussed here.

Code coverage before this PR:

And on this PR:

We've just completed the migration of the plugin code to the flutter/packages repository, as described in https://flutter.dev/go/flutter-plugins-repo-migration, and this repository is now being archived. Unfortunately that means that all in-progress PRs here must be moved to flutter/packages.

Please see our instructions for an explanation of how to move your PR, and if you have any issues moving your PR please don't hesitate to reach out in the #hackers-ecosystem channel in Discord.

Our apologies that your PR was caught in this one-time transition. We're aware that it's disruptive in the short term, and appreciate your help in getting us to a better long-term state!