Capacitor: Plugins, Native Config & Cordova Migration

Using Official Plugins

npm install @capacitor/camera @capacitor/app
npx cap sync   // re-sync after adding a plugin

import { Camera, CameraResultType } from '@capacitor/camera';

async function takePhoto() {
  const photo = await Camera.getPhoto({
    resultType: CameraResultType.Uri,
    quality: 90,
  });
  return photo.webPath;
}
// On web (no native camera), a well-behaved plugin either falls back
// to a browser file picker or rejects predictably -- not a crash.

import { App } from '@capacitor/app';

// App-lifecycle events a pure web app has no visibility into
App.addListener('appStateChange', ({ isActive }) => {
  if (!isActive) pauseBackgroundWork();
});

App.addListener('backButton', () => {
  // handle Android hardware back button
});

Native-Level Configuration Still Required

<!-- ios/App/App/Info.plist -- Capacitor can't configure everything;
     permission usage descriptions must be added directly -->
<key>NSCameraUsageDescription</key>
<string>Used to take profile photos</string>
<key>NSLocationWhenInUseUsageDescription</key>
<string>Used to show nearby stores</string>

<!-- android/app/src/main/AndroidManifest.xml -->
<uses-permission android:name="android.permission.CAMERA" />

Cordova Compatibility & Migration

• Capacitor was designed with Cordova plugin compatibility in mind -- many existing Cordova plugins continue to work.

• A team with an existing Cordova app can migrate the native shell/tooling incrementally, keeping the web codebase largely intact.

• Both are WebView-based (unlike React Native/NativeScript's native-widget rendering) -- Capacitor is a modernized evolution of the same underlying approach.

Web/PWA + Native from One Codebase

• The core app is a normal web app -- deploying it as a website/PWA needs no Capacitor-specific changes.

• cap add ios / cap add android additionally wrap the same build in a native shell.

• Best fit: an existing (or planned) web app wanting maximal code reuse across web + iOS + Android, where WebView rendering's trade-offs (vs. true native-widget frameworks) are an acceptable cost.

• A highly interactive, animation-heavy, native-feel-critical app is where a native-rendering framework more often wins that trade-off instead.