Write a plugin only when the catalog (Device, UI and System Plugins-Notifications and Sharing) and the community (Community Plugins) come up empty, or the only candidate fails the health check of Vetting Community Plugins. Typical reasons are a niche API, a vendor SDK, and heavy native work such as image processing. BookNest's case is the first: before it downloads a 25 MB audiobook sample, it should ask Android how much space is left, which no official plugin reports.
You have three places to put native code:
| Approach | Where the code lives | Best for |
|---|---|---|
| Local plugin class (Plugin Registry) | The app's android/ and ios/ folders | One app, quick glue code |
| Plugin package | Its own npm 2,036 package and repository | Reuse across apps, sharing |
| Direct native edits (MainActivity and AppDelegate) | MainActivity, AppDelegate | Startup work with no JavaScript API |
A local class is fastest but serves one app, with no web fallback or typed API. A package has both. Keep it "reasonably small", as the Capacitor documentation asks: one capability, a few methods.