Flutter: Building Truly Native Cross-platform Apps

Flutter allows engineering teams to maintain a single Dart codebase that comprehensively compiles into highly optimized, native ARM machine code for wildly fast performance across iOS and Android. It achieved this by doing the impossible: completely ignoring the native OEM widgets provided by Apple and Google. Instead, Flutter paints its own extremely performant widgets directly onto the screen using a customized C++ rendering engine.

However, you aren't just building a UI—you are building mobile applications that require deep OS telemetry. While the package ecosystem (pub.dev) is vast, inevitably, your startup will require integration with a hyper-specific Native SDK that simply does not have a Flutter plugin. Rather than abandoning the framework, your solution lies in writing customized, asynchronous Platform Channels.

1. The Asynchronous Messaging Architecture

Flutter’s platform channels operate heavily like a basic network API. Messages are serialized and passed asynchronously between the client (your Dart UI code) and the host (the actual iPhone or Android operating system context). Because communication is strictly asynchronous, your UI never drops frames or blocks the thread while waiting for a heavy Kotlin process to fetch Bluetooth telemetry.

2. Calling the Channel from Dart

First, we establish the caller side natively in Dart. We must define a unique channel namespace (traditionally reverse-DNS notation is utilized to prevent global namespace collisions).

        // lib/services/battery_service.dart
import 'package:flutter/services.dart';

class NativeBatteryService {
  // Define the channel name uniquely matching the native side later
  static const platform = MethodChannel('com.exploremybrain.hardware/battery');

  Future<String> fetchAccurateBatteryLevel() async {
    try {
      // Invoke the specific method across the bridge
      final int result = await platform.invokeMethod('getBatteryLevel');
      return 'Hardware Battery Context: $result%';
    } on PlatformException catch (e) {
      // Catch exceptions explicitly thrown by Swift or Kotlin
      return "Native Hardware Execution Failed: '\${e.message}'.";
    } catch (e) {
      return "Unknown Bridge Serialization Error occurred.";
    }
  }
}
      

3. Creating the iOS Host Implementation (Swift)

Now we must open Xcode (specifically opening the ios/Runner.xcworkspace file, NOT the project file). Inside our AppDelegate, we intercept the exact string channel and execute standard, optimized iOS Swift instructions.

        import UIKit
import Flutter

@UIApplicationMain
@objc class AppDelegate: FlutterAppDelegate {
  override func application(
    _ application: UIApplication,
    didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
  ) -> Bool {
  
    // Retrieve the active Flutter view controller
    let controller : FlutterViewController = window?.rootViewController as! FlutterViewController
    
    // Bind the exact same channel string defined in the Dart codebase
    let batteryChannel = FlutterMethodChannel(name: "com.exploremybrain.hardware/battery",
                                              binaryMessenger: controller.binaryMessenger)
                                              
    // Listen for method invocations from the UI thread
    batteryChannel.setMethodCallHandler({
      (call: FlutterMethodCall, result: @escaping FlutterResult) -> Void in
      
      // Route the string command
      if call.method == "getBatteryLevel" {
        self.receiveBatteryLevel(result: result)
      } else {
        // Return fallback if Dart asks for a non-existent method
        result(FlutterMethodNotImplemented)
      }
    })

    return super.application(application, didFinishLaunchingWithOptions: launchOptions)
  }
  
  // The actual low-level native code implementation isolating Apple's exact APIs
  private func receiveBatteryLevel(result: FlutterResult) {
    let device = UIDevice.current
    device.isBatteryMonitoringEnabled = true
    
    if device.batteryState == UIDevice.BatteryState.unknown {
      // Throw exception back across bridge to Dart
      result(FlutterError(code: "UNAVAILABLE", 
                          message: "Hardware battery info cannot be resolved by iOS.", 
                          details: nil))
    } else {
      // Send successful integer back back across bridge
      result(Int(device.batteryLevel * 100))
    }
  }
}
      

Conclusion: The Ultimate Leverage

With MethodChannels, you possess the ultimate developmental leverage. You preserve incredibly high velocity by keeping 95% of your application's UI logic, routing, and HTTP layers encapsulated inside an agile, single-source Dart repository. Simultaneously, you guarantee that the 5% requiring raw, unrelenting OS hardware integrations can still be handled beautifully and deterministically in Swift and Kotlin. The framework ceases to be a limitation and becomes a unified command center.