0Pricing
Flutter Mobile Development · Lección

Escritura de plugins de plataforma personalizados para iOS y Android

Cree plugins federados que expongan API nativas de Kotlin y Swift a Dart.

Escritura de plugins de plataforma personalizados para iOS y Android es una lección gratuita de Flutter Mobile Development en CoddyKit. Esta es la lección 3 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de Flutter Mobile Development, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de Flutter Mobile Development incluye 4 lecciones en total.

Partes de esta lección aún no han sido traducidas y se muestran en inglés.

Why Platform Plugins?

Dart cannot call native iOS or Android APIs directly. A platform plugin bridges that gap, exposing Swift/Objective-C and Kotlin/Java capabilities to your Dart code through a typed channel.

  • Package: pure Dart, no native code.
  • Plugin: Dart API plus platform-specific native implementations.

You write a plugin whenever you need hardware (sensors, BLE), OS services (notifications, keychain), or a native SDK that has no Dart equivalent. In this lesson we author a federated plugin that surfaces native Kotlin and Swift APIs to Dart.

Federated Plugin Architecture

A federated plugin splits responsibilities across several packages so different parties can own different platforms:

  • app-facing package (battery): the public Dart API developers import.
  • platform interface (battery_platform_interface): an abstract contract all implementations must satisfy.
  • platform packages (battery_android, battery_ios): concrete native implementations registered via pubspec.yaml.

This decoupling lets a third party add, say, a Windows implementation without touching the app-facing package. The interface package is the linchpin contract.

The Platform Interface Contract

The platform interface uses the plugin_platform_interface package. It declares an abstract base class with a MethodChannel-free contract, plus a default instance other packages override.

The PlatformInterface token-verification prevents implementers from extends-ing and breaking the contract; they must use implements guarded by verifyToken.

import 'package:plugin_platform_interface/plugin_platform_interface.dart';

abstract class BatteryPlatform extends PlatformInterface {
  BatteryPlatform() : super(token: _token);

  static final Object _token = Object();
  static BatteryPlatform _instance = MethodChannelBattery();

  static BatteryPlatform get instance => _instance;

  static set instance(BatteryPlatform value) {
    PlatformInterface.verifyToken(value, _token);
    _instance = value;
  }

  Future<int> getBatteryLevel() {
    throw UnimplementedError('getBatteryLevel() is not implemented.');
  }
}

MethodChannel: The Default Implementation

The default implementation talks to native code over a MethodChannel. Each channel has a unique name shared by Dart and native sides. invokeMethod serializes arguments using the standard message codec and awaits a native reply.

Keep channel names namespaced (reverse-DNS) to avoid collisions across plugins.

import 'package:flutter/services.dart';
import 'battery_platform_interface.dart';

class MethodChannelBattery extends BatteryPlatform {
  final MethodChannel _channel =
      const MethodChannel('com.example.battery/methods');

  @override
  Future<int> getBatteryLevel() async {
    final level = await _channel.invokeMethod<int>('getBatteryLevel');
    if (level == null) {
      throw PlatformException(code: 'NO_LEVEL', message: 'Level unavailable');
    }
    return level;
  }
}

Android: Kotlin Plugin Registration

On Android the native side implements FlutterPlugin and MethodChannel.MethodCallHandler. In onAttachedToEngine you wire a MethodChannel with the same name used in Dart, then route incoming calls in onMethodCall.

  • result.success(value) resolves the Dart Future.
  • result.error(code, msg, details) throws a PlatformException in Dart.
  • result.notImplemented() signals an unknown method.

This is Kotlin, not Dart, so it is illustrative only.

iOS: Swift Plugin Registration

On iOS you conform to FlutterPlugin and register in register(with:), creating a FlutterMethodChannel with the matching name. handle(_:result:) dispatches calls and replies via the FlutterResult callback.

For federated plugins the platform package declares its native entry point under flutter.plugin.platforms.ios in pubspec.yaml, pointing at the Swift class. The Dart registrant is wired automatically.

Declaring the Federated pubspec

The platform implementation packages announce themselves via flutter.plugin.platforms. The dartPluginClass is registered with the platform interface at startup, and pluginClass names the native class.

Crucially the app-facing package lists each platform package under default_package, so adding a platform is a pubspec change, not a code change.

Endorsing Platform Implementations

The app-facing package endorses implementations by depending on them in its pubspec.yaml. Endorsed packages are pulled in transitively, so app developers add one dependency and get every platform.

At runtime, each platform package's registerWith() sets the interface's instance to its own implementation. The Dart API then calls through BatteryPlatform.instance without knowing which platform answered.

// battery_android registers itself at startup
import 'battery_platform_interface.dart';

class BatteryAndroid extends BatteryPlatform {
  /// Registered via dartPluginClass in pubspec.yaml.
  static void registerWith() {
    BatteryPlatform.instance = BatteryAndroid();
  }

  @override
  Future<int> getBatteryLevel() {
    // Delegates to the MethodChannel under the hood.
    return MethodChannelBattery().getBatteryLevel();
  }
}

The App-Facing Dart API

The public package wraps the interface in an ergonomic, well-documented API. App developers never touch channels or platform classes — they call clean Dart methods.

Keep this layer thin: validation, convenience overloads, and documentation. All real work lives behind BatteryPlatform.instance.

import 'battery_platform_interface.dart';

class Battery {
  /// Returns the current battery level as a percentage (0-100).
  Future<int> get batteryLevel => BatteryPlatform.instance.getBatteryLevel();

  /// Convenience: true when the device is critically low.
  Future<bool> get isCritical async => (await batteryLevel) <= 15;
}

Streaming Native Events with EventChannel

For continuous data (charging state, sensor streams) a single method call is not enough. Use an EventChannel: the native side pushes events through a StreamHandler/FlutterEventSink, and Dart exposes them as a Stream.

receiveBroadcastStream lazily starts the native listener on first subscription and tears it down on cancel.

import 'package:flutter/services.dart';

class BatteryStream {
  final EventChannel _events =
      const EventChannel('com.example.battery/charging');

  Stream<bool> get onChargingChanged => _events
      .receiveBroadcastStream()
      .map((event) => event == 'charging');
}

Type-Safe Channels with Pigeon

Hand-written channels are stringly-typed and error-prone. Pigeon generates type-safe Dart, Kotlin, and Swift bindings from a single Dart definition file, eliminating method-name typos and codec mismatches.

You annotate an abstract class with @HostApi() (Dart calls native) or @FlutterApi() (native calls Dart), run the Pigeon generator, and wire the generated classes — no manual invokeMethod strings.

import 'package:pigeon/pigeon.dart';

class BatteryInfo {
  int? level;
  bool? isCharging;
}

@HostApi()
abstract class BatteryHostApi {
  BatteryInfo getBatteryInfo();
}

@FlutterApi()
abstract class BatteryFlutterApi {
  void onLevelChanged(int level);
}

Quick Check

You are publishing a Flutter plugin and want third parties to add new platform implementations (e.g. Windows) without modifying or forking your app-facing package. Which architecture and mechanism makes that possible?

Recap

You learned to author a federated platform plugin exposing native Kotlin and Swift APIs to Dart:

  • Architecture: app-facing package, platform interface, and per-platform implementations.
  • Contract: an abstract PlatformInterface with token verification and a swappable instance.
  • Channels: MethodChannel for request/response, EventChannel for native event streams, with matching names on both sides.
  • Native sides: Kotlin onMethodCall and Swift handle(_:result:) resolving via success/error.
  • Endorsement: pubspec wires dartPluginClass and pluginClass so platforms register themselves.
  • Pigeon: generates type-safe bindings to replace fragile string-based channels.

With this you can wrap any native SDK behind a clean, testable Dart API.

Preguntas frecuentes

¿La lección «Escritura de plugins de plataforma personalizados para iOS y Android» es gratis?

Sí — el texto completo de «Escritura de plugins de plataforma personalizados para iOS y Android» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de Flutter Mobile Development, actualiza a CoddyKit PRO. El curso de Flutter Mobile Development incluye 4 lecciones en total.

¿Qué aprenderé en «Escritura de plugins de plataforma personalizados para iOS y Android»?

Cree plugins federados que expongan API nativas de Kotlin y Swift a Dart. Practicas Flutter Mobile Development con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.

¿Necesito experiencia previa para empezar Flutter Mobile Development?

No se requiere experiencia previa. Flutter Mobile Development en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 3 de 4.

¿Cuánto tiempo toma la lección «Escritura de plugins de plataforma personalizados para iOS y Android»?

La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.

¿Puedo escribir y ejecutar código en esta lección de Flutter Mobile Development?

Sí. Cada lección de Flutter Mobile Development incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.

Todas las lecciones de este curso

  1. Llamadas a bibliotecas C con dart:ffi
  2. Canales de plataforma con seguridad de tipos mediante Pigeon
  3. Escritura de plugins de plataforma personalizados para iOS y Android
  4. Isolates en segundo plano y gestión de memoria nativa
← Volver a Flutter Mobile Development