مهاجرت یک اپلیکیشن موجود به Flutter یکی از موضوعات مهم برای تیم‌هایی است که در گذشته اپلیکیشن خود را به‌صورت Native با Android یا iOS توسعه داده‌اند و اکنون به دنبال کاهش هزینه نگهداری، اشتراک‌گذاری کد و سرعت بیشتر در توسعه هستند.

اما مهاجرت به Flutter به این معنی نیست که همیشه باید پروژه فعلی را کنار بگذارید و همه چیز را از ابتدا بنویسید. در بسیاری از پروژه‌ها می‌توان Flutter را به‌صورت تدریجی وارد اپلیکیشن Native کرد و بخش‌های مختلف را مرحله‌به‌مرحله منتقل کرد. مستندات رسمی Flutter نیز امکان قرار دادن Flutter در اپلیکیشن‌های موجود Android و iOS را به‌صورت تدریجی پشتیبانی می‌کند.

در این مقاله از ناوین، مراحل مهاجرت اپلیکیشن‌های موجود به Flutter، مزایا و معایب، روش‌های Migration، چالش‌های فنی و یک برنامه پیشنهادی برای اجرای پروژه را بررسی می‌کنیم.

مهاجرت به فلاتر چیست؟

مهاجرت به فلاتر به فرآیندی گفته می‌شود که طی آن یک اپلیکیشن موجود Native یا Cross-Platform به Flutter منتقل می‌شود.

برای مثال ممکن است اپلیکیشن فعلی با این فناوری ساخته شده باشد:

Android
↓
Kotlin / Java

یا:

iOS
↓
Swift / Objective-C

و تیم تصمیم بگیرد بخش‌هایی از آن را با Flutter بازنویسی کند:

Existing App
↓
Flutter
↓
Dart
↓
Android + iOS

Flutter امکان استفاده از یک Codebase مشترک برای چند Platform را فراهم می‌کند و در عین حال می‌تواند با APIها و کدهای Native نیز ارتباط برقرار کند.

چرا اپلیکیشن را به فلاتر مهاجرت کنیم؟

دلایل مختلفی می‌توانند باعث تصمیم یک تیم برای Migration شوند.

۱. اشتراک‌گذاری کد

یکی از مهم‌ترین مزایای Flutter امکان استفاده از یک Codebase مشترک برای Android و iOS است.

به‌جای:

Android
↓
Kotlin

iOS
↓
Swift

می‌توان بخش زیادی از منطق و UI را در Flutter پیاده‌سازی کرد:

Flutter
↓
Shared Codebase
↙ ↘
Android iOS

۲. کاهش هزینه نگهداری

در پروژه‌هایی که دو تیم Native جداگانه برای Android و iOS دارند، پیاده‌سازی یک Feature جدید ممکن است نیازمند توسعه و تست جداگانه باشد.

برای مثال:

New Feature
├── Android Development
├── iOS Development
├── Android Testing
└── iOS Testing

با Flutter می‌توان بخش زیادی از این منطق را مشترک کرد.

البته این موضوع به معماری و میزان استفاده پروژه از APIهای اختصاصی هر Platform بستگی دارد.

۳. سرعت بیشتر در توسعه UI

Flutter یک UI Toolkit است که Widgetهای خود را برای ساخت رابط کاربری ارائه می‌کند.

این موضوع باعث می‌شود تیم بتواند بخش بزرگی از UI را در یک Codebase توسعه دهد.

Flutter همچنین از Hot Reload در فرآیند توسعه پشتیبانی می‌کند که برای مشاهده سریع تغییرات UI بسیار مفید است.

۴. یکپارچگی بیشتر UI در اندروید و iOS

اگر هدف این باشد که طراحی UI در Android و iOS تا حد زیادی یکسان باشد، فلاتر می‌تواند گزینه مناسبی باشد.

به‌جای پیاده‌سازی جداگانه:

Android UI
+
iOS UI

می‌توان ساختار مشترکی داشت:

Flutter UI
↓
Android + iOS

آیا باید کل اپلیکیشن را از ابتدا بازنویسی کنیم؟

خیر.

یکی از مهم‌ترین نکات در Migration این است که همیشه لازم نیست یک پروژه بزرگ را به‌صورت کامل Rewrite کنید.

فلاتر از الگوی Add-to-App پشتیبانی می‌کند؛ یعنی می‌توان Flutter را به یک اپلیکیشن موجود اضافه کرد و بخش‌های فلاتر را در کنار بخش‌های Native اجرا کرد.

برای مثال:

Existing Native App
│
├── Login → Native
├── Home → Flutter
├── Profile → Native
├── Shopping → Flutter
└── Settings → Native

بعد از مدتی می‌توان بخش‌های بیشتری را به Flutter منتقل کرد.

روش‌های مهاجرت به فلاتر

به‌طور کلی چند استراتژی برای Migration وجود دارد.

روش اول: Rewrite کامل

در این روش کل اپلیکیشن از ابتدا با Flutter نوشته می‌شود.

Old App
↓
Analyze
↓
Rewrite
↓
Flutter App

مزایا

• معماری جدید و تمیز
• حذف Legacy Code
• ساختار یکپارچه
• امکان طراحی مجدد UI

معایب

• زمان توسعه زیاد
• هزینه بالا
• ریسک زیاد
• نیاز به تست گسترده
• احتمال از دست رفتن برخی رفتارهای قدیمی

این روش برای اپلیکیشن‌های کوچک‌تر یا پروژه‌هایی که Legacy Code بسیار زیادی دارند ممکن است منطقی باشد.

روش دوم: مهاجرت تدریجی

در این روش Flutter مرحله‌به‌مرحله وارد پروژه می‌شود.

مثلاً:

Version 1
Native 100%

Version 2
Native 80%
Flutter 20%

Version 3
Native 60%
Flutter 40%

Version 4
Native 30%
Flutter 70%

Version 5
Flutter 100%

این روش برای پروژه‌های بزرگ معمولاً ریسک کمتری دارد.

روش سوم: فلاتر برای Featureهای جدید

می‌توانید تصمیم بگیرید که کدهای قدیمی را فعلاً دست‌نخورده نگه دارید و تمام Featureهای جدید را با Flutter توسعه دهید.

مثلاً:

Existing Features
↓
Native

New Features
↓
Flutter

این روش می‌تواند نقطه شروع مناسبی برای تیم‌هایی باشد که هنوز درباره Migration کامل مطمئن نیستند.

معماری Add-to-App چیست؟

در Add-to-App، اپلیکیشن Native نقش Host را دارد و Flutter به آن اضافه می‌شود.

ساختار ساده:

Native Application
│
├── Native Screens
│
├── Native Services
│
└── Flutter Module
│
├── Flutter UI
├── Dart Logic
└── Flutter Plugins

Flutter می‌تواند به‌عنوان یک Module یا بخشی از اپلیکیشن موجود در Android و iOS قرار گیرد.

مهاجرت اندروید به فلاتر

برای یک Android Application موجود می‌توان فلاتر را به‌صورت تدریجی اضافه کرد.

مستندات رسمی فلاتر امکان Integration یک Flutter Module با Android Application موجود را ارائه می‌کند. این Integration می‌تواند از طریق Gradle یا روش‌های دیگر انجام شود.

یک ساختار مفهومی:

Android App
│
├── Kotlin
├── Gradle
├── Android SDK
│
└── Flutter Module
│
├── Dart
├── Widgets
└── Flutter Plugins

حتی می‌توان یک Flutter Screen را در اپلیکیشن Android موجود نمایش داد.

مهاجرت iOS به فلاتر

در iOS نیز می‌توان فلاتر را به اپلیکیشن موجود اضافه کرد.

فلاتر از Integration تدریجی Flutter UI در پروژه‌های موجود iOS پشتیبانی می‌کند. در نسخه‌های جدید Flutter، Swift Package Manager روش پیش‌فرض برای مدیریت Dependencyهای Flutter در iOS و macOS است و CocoaPods در حالت Maintenance قرار دارد.

ساختار:

Existing iOS App
│
├── Swift
├── UIKit / SwiftUI
│
└── Flutter
├── Dart
└── Flutter UI

مرحله اول: بررسی اپلیکیشن فعلی

قبل از شروع Migration باید پروژه فعلی را به‌طور کامل بررسی کنید.

موارد مهم:

• تعداد Screenها
• Architecture
• APIها
• Database
• Authentication
• Push Notification
• Deep Link
• Payment
• Analytics
• Native SDKها
• Third-party Libraries
• Background Services

یک جدول برای تحلیل پروژه ایجاد کنید:

بخشفناوری فعلیامکان Migration

Login

Native

زیاد

Home

Native

زیاد

Payment

Native SDK

متوسط

Push Notification

Native

زیاد

Camera

Native

زیاد

Bluetooth

Native SDK

بسته به SDK

Background Service

Native

نیازمند بررسی

UI

Native

زیاد

این مرحله جلوی بسیاری از مشکلات آینده را می‌گیرد.

مرحله دوم: پیدا کردن وابستگی‌های Native

همه بخش‌های یک اپلیکیشن به یک اندازه قابل انتقال نیستند.

ممکن است اپلیکیشن از SDKهای خاصی استفاده کند که فقط برای Android یا iOS ارائه شده‌اند.

مثلاً:

Native SDK
↓
Kotlin / Swift

در این شرایط باید بررسی کنید:

1. آیا Flutter Plugin رسمی وجود دارد؟
2. آیا Plugin معتبر Community وجود دارد؟
3. آیا می‌توان Plugin اختصاصی نوشت؟
4. آیا واقعاً لازم است این بخش به Flutter منتقل شود؟

فلاتر امکان ارتباط با کد Native از طریق Platform Channels و سایر روش‌های Integration را فراهم می‌کند.

مرحله سوم: طراحی Architecture جدید

Migration فرصت خوبی برای اصلاح Architecture است.

بهتر است قبل از شروع، ساختار جدید مشخص شود.

برای مثال:

lib/
│
├── core/
│
├── features/
│ ├── auth/
│ ├── home/
│ ├── profile/
│ └── settings/
│
├── data/
├── domain/
└── presentation/

Flutter نیز برای ساخت اپلیکیشن‌های قابل نگهداری و مقیاس‌پذیر، روی Architecture مناسب و Separation of Concerns تأکید دارد.

مرحله چهارم: انتخاب State Management

در پروژه Flutter باید از ابتدا مشخص شود که State Management چگونه انجام می‌شود.

بر اساس اندازه و نیاز پروژه می‌توان از راهکارهایی مانند:

• Provider
• Riverpod
• Bloc
• Cubit
• ValueNotifier

استفاده کرد.

مهم‌تر از انتخاب نام Library، داشتن یک Strategy مشخص برای مدیریت State است.

مرحله پنجم: انتقال مدل‌های داده

یکی از بخش‌های مهم Migration، انتقال Data Modelها است.

فرض کنید در Native مدل زیر وجود دارد:

data class User(
val id: Int,
val name: String,
val email: String
)

در Flutter می‌تواند به مدل Dart تبدیل شود:

class User {
final int id;
final String name;
final String email;

User({
required this.id,
required this.name,
required this.email,
});
}

اگر API ثابت باشد، می‌توانید Data Layer جدید را بر اساس همان API طراحی کنید.

مرحله ششم: انتقال API Layer

معمولاً بهتر است API Contractهای موجود حفظ شوند مگر اینکه دلیل مشخصی برای تغییر آن‌ها وجود داشته باشد.

ساختار:

Flutter
↓
Repository
↓
API Client
↓
REST API
↓
Backend

به این ترتیب Migration Mobile App الزاماً نیازمند تغییر Backend نیست.

مرحله هفتم: انتقال UI

بعد از آماده شدن Architecture می‌توانید Screenها را منتقل کنید.

بهتر است از Screenهای کوچک شروع کنید.

مثلاً:

Profile
↓
Flutter

Settings
↓
Flutter

About
↓
Flutter

سپس به سراغ بخش‌های پیچیده‌تر بروید.

مرحله هشتم: برقراری ارتباط فلاتر و Native

در پروژه Hybrid ممکن است فلاتر و Native نیاز داشته باشند با یکدیگر ارتباط برقرار کنند.

مثلاً فلاتر می‌تواند درخواست کند:

Flutter
↓
Get Device Information
↓
Native Android/iOS
↓
Result
↓
Flutter

یکی از روش‌های استاندارد Flutter برای این ارتباط Platform Channels است. Flutter از این مکانیزم برای ارتباط Dart با کدهایی مانند Kotlin و Swift استفاده می‌کند.

Platform Channel چیست؟

یک مثال ساده:

const channel = MethodChannel('native_service');

final result = await channel.invokeMethod('getDeviceInfo');

در Android می‌توان Handler مربوط به Method Channel را در Kotlin پیاده‌سازی کرد.

در iOS نیز می‌توان همین مفهوم را با Swift پیاده‌سازی کرد.

این روش برای قابلیت‌هایی که Plugin آماده ندارند بسیار مفید است.

آیا Native Code باید کاملاً حذف شود؟

خیر.

حتی در یک Flutter Application کامل نیز ممکن است به Native Code نیاز داشته باشید.

Flutter به شما اجازه می‌دهد در کنار Dart از:

Kotlin
Swift
C/C++

و APIهای Platform استفاده کنید.

بنابراین هدف Migration لزوماً حذف 100 درصد Native Code نیست.

هدف اصلی می‌تواند این باشد:

بخش‌هایی که بیشترین ارزش را از Flutter می‌گیرند به Flutter منتقل شوند و بخش‌های Platform-specific همچنان Native باقی بمانند.

انتقال Authentication

Authentication یکی از بخش‌های حساس Migration است.

اگر کاربران قبلی در سیستم فعلی حساب دارند، نباید صرفاً به دلیل Migration حساب‌های آن‌ها را حذف کنید.

باید بررسی شود:

• API فعلی چیست؟
• Token چگونه ذخیره می‌شود؟
• Refresh Token چگونه مدیریت می‌شود؟
• Session چگونه کنترل می‌شود؟
• Secure Storage چگونه انجام می‌شود؟
• Login و Logout چگونه کار می‌کنند؟

هدف باید این باشد:

Existing User
↓
New Flutter App
↓
Same Account
↓
Same Backend

انتقال Local Database

اگر اپلیکیشن فعلی اطلاعات مهمی را روی دستگاه ذخیره می‌کند، Migration Database باید با دقت انجام شود.

برای مثال:

Old Database
↓
Migration Layer
↓
New Database
↓
Flutter

اطلاعاتی مانند:

• User Preferences
• Cached Data
• Offline Data
• Tokens
• Local Settings

باید بررسی شوند.

Push Notification

Notification نیز یکی از بخش‌هایی است که باید در Migration بررسی شود.

باید مطمئن شوید:

• Token دستگاه حفظ یا Refresh می‌شود.
• Notification در Android درست کار می‌کند.
• Notification در iOS درست کار می‌کند.
• Deep Link صحیح است.
• Background Handling درست است.

Deep Link

اگر اپلیکیشن موجود Deep Link دارد، Migration نباید باعث شکستن لینک‌های قبلی شود.

برای مثال:

https://example.com/product/123

باید همچنان کاربر را به صفحه درست هدایت کند.

در Migration:

Deep Link
↓
Router
↓
Flutter Screen

باید به‌درستی طراحی شود.

Analytics

اگر اپلیکیشن قبلی Analytics داشته است، هنگام Migration نباید اطلاعات مهم Tracking از بین برود.

Eventهای قبلی را مستند کنید:

login
product_view
add_to_cart
purchase
logout

سپس در Flutter همان Eventها را با Strategy مشخص پیاده‌سازی کنید.

تست Migration

Migration بدون Testing می‌تواند بسیار پرریسک باشد.

تست باید در چند سطح انجام شود:

Unit Test

برای منطق برنامه.

Widget Test

برای Widgetها و UI.

Integration Test

برای بررسی Flowهای واقعی.

Manual Test

برای مقایسه نسخه قدیمی و جدید.

مقایسه نسخه Native و فلاتر

یکی از روش‌های خوب این است که یک Feature را در دو نسخه مقایسه کنید.

مثلاً:

Old Native Version
↕
New Flutter Version

و موارد زیر را بررسی کنید:

• UI
• Navigation
• API
• Performance
• Memory
• Animation
• Error Handling
• Analytics

Performance در Migration

یکی از نگرانی‌های رایج این است که آیا Flutter Performance مناسبی خواهد داشت یا خیر.

Flutter در Release به کد Native Machine Code کامپایل می‌شود و برای ساخت اپلیکیشن‌های چندسکویی طراحی شده است.

اما Performance نهایی فقط به Framework بستگی ندارد.

مواردی مانند:

• معماری
• تعداد Widgetها
• Image Loading
• API Calls
• Database
• Animation
• Memory Management

نیز اهمیت زیادی دارند.

توجه به مصرف Memory

در Add-to-App، Flutter Runtime و منابع مربوط به آن باید در اپلیکیشن Host بارگذاری شوند.

مستندات Flutter به هزینه‌های Load، Memory و Performance هنگام نمایش Flutter UI در اپلیکیشن موجود اشاره می‌کند.

بنابراین قبل از Migration کامل باید Memory Usage و Startup Time را روی دستگاه‌های واقعی اندازه‌گیری کنید.

مدیریت Flutter Engine

در Add-to-App، نحوه ایجاد و مدیریت Flutter Engine اهمیت دارد.

ساختار مفهومی:

Native App
↓
FlutterEngine
↓
Flutter UI

در برخی سناریوها می‌توان Engine را از قبل آماده کرد تا زمان نمایش Flutter UI کاهش پیدا کند.

اما Pre-warming نیز هزینه Memory دارد؛ بنابراین باید بر اساس نیاز واقعی پروژه تصمیم‌گیری شود.

Migration و حجم اپلیکیشن

اضافه کردن Flutter به یک اپلیکیشن موجود می‌تواند حجم Application را افزایش دهد، زیرا Flutter Engine و منابع مربوط به آن نیز وارد بسته برنامه می‌شوند. مستندات رسمی Flutter نیز افزایش اندازه اپلیکیشن در Add-to-App را به‌عنوان یکی از ملاحظات این روش ذکر می‌کند.

بنابراین قبل از تصمیم نهایی، حجم:

Old App
vs
Native + Flutter
vs
Full Flutter

را اندازه‌گیری کنید.

برنامه پیشنهادی برای Migration

برای یک پروژه واقعی می‌توان فرآیند را به این شکل تقسیم کرد:

Phase 1 — Analysis

Analyze Existing App
↓
Dependencies
↓
Architecture
↓
Native APIs
↓
Business Logic

Phase 2 — Flutter Setup

Flutter Project
↓
Architecture
↓
Dependencies
↓
CI/CD
↓
Testing

Phase 3 — Pilot Feature

یک Feature نسبتاً ساده را انتخاب کنید.

Profile
↓
Flutter

Phase 4 — Hybrid Integration

Native
+
Flutter

Phase 5 — Feature Migration

20%
↓
40%
↓
60%
↓
80%

Phase 6 — Final Migration

در صورت موفقیت مراحل قبلی:

Flutter
↓
Main Application

چه Featureهایی را اول مهاجرت دهیم؟

بهتر است Migration را با بخش‌هایی شروع کنید که:

• وابستگی Native کمی دارند.
• Business Logic پیچیده‌ای ندارند.
• قابل تست هستند.
• ارزش مناسبی برای پروژه دارند.

برای مثال:

About
Settings
Profile
Home

ممکن است گزینه‌های خوبی باشند.

در مقابل، بهتر است Featureهایی که وابستگی سنگین به Native SDK دارند در مراحل اولیه منتقل نشوند.

چه بخش‌هایی را بهتر است Native نگه داریم؟

بسته به پروژه، برخی قابلیت‌ها ممکن است بهتر باشد Native باقی بمانند.

برای مثال:

• قابلیت‌های بسیار اختصاصی Platform
• SDKهای خاص
• بعضی Background Serviceها
• Integrationهای سطح پایین
• قابلیت‌های اختصاصی سخت‌افزاری

در چنین شرایطی می‌توانید:

Flutter UI
↓
Platform Channel
↓
Native Service

داشته باشید.

CI/CD در Migration

وقتی پروژه Hybrid می‌شود، CI/CD اهمیت بیشتری پیدا می‌کند.

Pipeline باید بتواند:

Checkout
↓
Flutter Dependencies
↓
Native Dependencies
↓
Build
↓
Test
↓
Android Release
↓
iOS Release

را مدیریت کند.

همچنین بهتر است Buildهای Android و iOS در محیط CI به‌صورت مستقل تست شوند.

اشتباهات رایج در Migration به فلاتر

۱. Rewrite کردن کل پروژه از روز اول

در پروژه‌های بزرگ این کار می‌تواند ریسک زیادی داشته باشد.

۲. انتقال UI بدون بررسی Architecture

اگر فقط UI را منتقل کنید اما مشکلات Architecture را حل نکنید، ممکن است مشکلات قبلی در Flutter نیز تکرار شوند.

۳. نادیده گرفتن Native Dependencyها

قبل از Migration باید تمام SDKهای Native بررسی شوند.

۴. انتقال هم‌زمان چند Feature بزرگ

بهتر است Migration مرحله‌ای باشد.

۵. تست نکردن Performance

قبل و بعد از Migration باید Performance اندازه‌گیری شود.

۶. حذف سریع کدهای Native

تا زمانی که Feature جدید به‌طور کامل تست نشده است، بهتر است کد قبلی حذف نشود.

۷. نداشتن Rollback Strategy

برای هر مرحله باید مشخص باشد که اگر مشکلی ایجاد شد چگونه به نسخه قبلی برمی‌گردیم.

فلاتر Migration برای چه پروژه‌هایی مناسب است؟

فلاتر می‌تواند گزینه مناسبی باشد اگر:

• Android و iOS هر دو برای شما مهم هستند.
• بخش زیادی از UI مشترک است.
• هزینه نگهداری دو Codebase بالاست.
• تیم قصد توسعه Cross-Platform دارد.
• پروژه Native قدیمی شده است.
• نیاز به توسعه سریع Featureهای جدید دارید.

اما اگر پروژه شدیداً به APIهای اختصاصی Platform وابسته است، باید قبل از Migration تحلیل فنی دقیق‌تری انجام شود.

آیا Migration همیشه تصمیم درستی است؟

خیر.

گاهی هزینه Migration بیشتر از مزایای آن است.

برای تصمیم‌گیری می‌توانید این موارد را بررسی کنید:

معیارسؤال

Codebase

چقدر Legacy Code داریم؟

Team

تیم Flutter داریم؟

Native SDK

چند SDK اختصاصی داریم؟

UI

چقدر UI بین Android و iOS مشترک است؟

Backend

آیا APIها قابل استفاده مجدد هستند؟

Performance

محدودیت Performance داریم؟

Cost

هزینه نگهداری فعلی چقدر است؟

Timeline

چه مدت برای Migration داریم؟

اگر پاسخ بیشتر این موارد به نفع Flutter باشد، Migration می‌تواند ارزش بررسی جدی داشته باشد.

جمع‌بندی

مهاجرت یک اپلیکیشن موجود به فلاتر می‌تواند راهکاری مناسب برای تیم‌هایی باشد که می‌خواهند Code Sharing، سرعت توسعه و قابلیت نگهداری اپلیکیشن‌های اندروید و iOS را بهبود دهند.

اما بهترین روش این نیست که همیشه پروژه فعلی را کنار بگذاریم و همه چیز را از ابتدا بنویسیم.

در پروژه‌های بزرگ، Incremental Migration معمولاً رویکرد منطقی‌تری است:

Existing Native App
↓
Flutter Integration
↓
Pilot Feature
↓
More Features
↓
Hybrid App
↓
Flutter-based App

Flutter امکان Integration با اپلیکیشن‌های موجود Android و iOS را فراهم می‌کند و حتی می‌توان یک Flutter Screen را در کنار Screenهای Native اجرا کرد.

از طرف دیگر، نباید چالش‌هایی مانند Native SDKها، Memory، حجم Application، Authentication، Database، Deep Link، Push Notification و Performance را نادیده گرفت.

بنابراین قبل از شروع Migration، ابتدا پروژه فعلی را تحلیل کنید، یک Feature مناسب برای Pilot انتخاب کنید، Architecture جدید را مشخص کنید و سپس Migration را مرحله‌به‌مرحله پیش ببرید.

مهاجرت موفق به Flutter بیشتر از اینکه یک Rewrite ساده باشد، یک پروژه مهندسی و معماری است.

سوالات متداول

آیا می‌توان یک اپلیکیشن Android موجود را به فلاتر منتقل کرد؟

بله. فلاتر از Integration با اپلیکیشن‌های موجود Android پشتیبانی می‌کند و می‌توان فلاتر را به‌صورت تدریجی وارد پروژه کرد.

آیا برای مهاجرت باید کل اپلیکیشن را از ابتدا بنویسیم؟

خیر. می‌توان از روش Add-to-App استفاده کرد و Featureها یا Screenهای فلاتر را به‌تدریج در اپلیکیشن Native قرار داد.

آیا می‌توان Flutter و Kotlin را در یک اپلیکیشن استفاده کرد؟

بله. فلاتر می‌تواند در کنار کد Native Android اجرا شود و از طریق Integrationهایی مانند Platform Channels با Kotlin ارتباط برقرار کند.

آیا می‌توان Flutter و Swift را در یک اپلیکیشن iOS استفاده کرد؟

بله. فلاتر می‌تواند در یک اپلیکیشن موجود iOS قرار گیرد و با کد Swift ارتباط برقرار کند.

آیا بعد از Migration دیگر به Native Code نیاز نداریم؟

نه لزوماً. برخی قابلیت‌های Platform-specific ممکن است همچنان به Kotlin یا Swift نیاز داشته باشند. فلاتر برای چنین شرایطی مکانیزم‌های Integration و Platform Channels ارائه می‌کند.

آیا Migration به Flutter باعث افزایش حجم اپلیکیشن می‌شود؟

در روش Add-to-App ممکن است حجم اپلیکیشن افزایش پیدا کند، زیرا Flutter Runtime و منابع مربوط به آن نیز باید در Application قرار بگیرند.

بهترین روش برای مهاجرت یک اپلیکیشن بزرگ چیست؟

در بسیاری از پروژه‌های بزرگ، Migration تدریجی و Feature-by-Feature نسبت به Rewrite کامل ریسک کمتری دارد؛ ابتدا یک Feature مناسب را به‌عنوان Pilot منتقل کنید و پس از ارزیابی Performance و Stability، مهاجرت را ادامه دهید.