Several official plugins, and the web platform itself, cover the same ground. The deciding question is usually whose UI appears and what your code may see:
| Need | Use | Instead of, and why |
|---|---|---|
| Open an external site | Browser | InAppBrowser, unless you must control the page |
| Control or embed a page | InAppBrowser (WebView mode) | Browser, which hides the page from you |
| Open another app | App Launcher | Browser with a custom scheme |
| Remind at a set time | Local Notifications | Push: no server needed |
| Message from your server | Push Notifications | Local, which cannot wake on server events |
| Small settings | Preferences | localStorage, which the OS may evict |
| Secrets and tokens | Secure storage (Secure Storage) | Preferences, which is plain text |
| Files and binary data | Filesystem, File Transfer | Base64 strings in Preferences |
| Alerts in your design | Framework7 572,986 dialogs | Dialog, for the platform's own look |
| Bar style and insets | System Bars (core) | Status Bar colors, ignored at API 36 |
| HTTP without CORS limits | CapacitorHttp (core) | fetch, if your server sends CORS headers |
Three rules generalize. Prefer the web API when it works everywhere you ship, since it stays testable in a browser. Prefer the plugin when the platform owns the behavior (notifications, permissions, the back button) or a web API is missing on one platform, as Vibration is on iOS. And use the system's own UI for sign-in, where users see the real address and the app cannot read their password.