Beike's Flutter Integration Scheme for iOS and Android: Hybrid, Source and Binary Modes

Google released Flutter 1.0 in 2018, offering two development modes: pure Flutter (Dart only) and hybrid integration with existing native projects. Because many of Beike's legacy apps cannot replace all native code, the hybrid approach is required, though the official support is limited.

1. Official Flutter templates

Flutter provides four project templates: app , module , package , and plugin . The app template is a pure Flutter project that still generates iOS and Android host projects. The module template is designed for integrating Flutter into existing iOS/Android apps and includes scripts for Pod and Gradle integration. package and plugin are for reusable Dart components, with plugin also containing native code.

2. Official iOS integration process

Using the module template, the project structure includes key directories such as .ios , .android , and the pubspec.yaml file. Integration requires adding lines to the Podfile, for example:

flutter_application_path = '../my_flutter'
load File.join(flutter_application_path, '.ios', 'Flutter', 'podhelper.rb')

target 'MyApp' do
  install_all_flutter_pods(flutter_application_path)
end

The install_all_flutter_pods function performs three steps: integrating the Flutter engine, the Flutter plugins, and the compiled Dart code/resources via a custom Xcode build phase.

Problems with the official solution include:

Podfile modifications are intrusive.

Flutter code must reside in a local directory, causing repository pollution.

All developers need a configured Flutter SDK, increasing setup cost.

3. Beike's iOS integration scheme

To address the issues, two modes are introduced:

Source mode : Flutter developers reference the module via a podspec with a build phase that copies App.framework into the IPA.

Binary mode : Non‑Flutter developers use a pre‑built binary pod (e.g., pod 'demo', '0.0.1' ) that contains the compiled framework, avoiding source code exposure.

Both modes share a single pod that bundles the Flutter artifacts and auxiliary files using the s.source attribute, preventing multiple imports and keeping the host project clean.

3.1 Plugin handling

In source mode, plugin information is read from .flutter-plugins and .flutter-plugins-dependencies . In binary mode, a custom isFlutter => true flag in the pod declaration enables pre‑download of the Flutter binary and extraction of plugin metadata.

3.2 Engine integration

For source mode, the build script always copies Flutter.framework into the module's iOS/Flutter directory. In binary mode, a custom build phase merges debug and release slices and copies the appropriate framework based on the $ACTION variable.

3.3 Flutter SDK automation

A deployment tool adds a configuration file to the Flutter project specifying the SDK channel and version. Build machines read this file to automatically install the correct SDK, eliminating manual setup. The tool also supports Git‑based pod specifications, e.g.:

pod 'demo', :git => 'http://xxx.git', :isFlutter => true

Environment variables ( FLUTTER_COMPONENT , FLUTTER_COMPONENT_SOURCE_URL , FLUTTER_COMPONENT_BRANCH ) can be used to inject Git information during pod install .

3.4 Flavor support

iOS flavors are handled via CocoaPods subspecs, each with its own configuration.

4. Android integration scheme

For Android, Beike prefers the AAR approach over Gradle sub‑module source inclusion. The AAR contains both the Flutter engine and plugin code. Custom Gradle files modify the standard Flutter plugin:

///FILE:android/settings.gradle
include ':app_flutter'
project(':app_flutter').projectDir = new File(rootProject.projectDir, 'app')

///FILE:android/build.gradle
buildscript {
  repositories { google(); maven { url "http://your.artifactory/url" } }
  dependencies { classpath 'com.android.tools.build:gradle:3.5.3'; classpath 'com.lianjia.common.android:flutter-gradle:1.0' }
}

The module's android/app/build.gradle applies the custom flutter-plugin and defines the Flutter source, package name, and launcher activity.

Additional customizations include:

Merge Flutter plugin classes into the final AAR.

Optionally upload the AAR to a Maven repository.

Modify flutter_tools to support flavor‑specific asset filtering and to translate IDE run commands into flutter build apk invocations.

Build commands remain similar to standard Flutter, e.g., flutter build apk --flavor flavor_name --release , with an extra --upload flag to publish the AAR.

5. Summary

Beike's integration solution reduces host project pollution, provides clean podfile usage, supports both source and binary workflows, automates Flutter SDK provisioning, and improves build efficiency, ultimately enabling seamless collaboration between Flutter and non‑Flutter developers.