Native ilovani Flutter yoki React Native’ga o‘tkazish

Ikki yo‘l va qanday tanlash kerak

Native ilovani kross-platformaga o‘tkazishning ikki asosiy usuli bor:

• To‘liq qayta yozish — yangi ilova noldan yoziladi va eskisini bitta reliz bilan almashtiradi.
• Bosqichma-bosqich migratsiya (add-to-app, brownfield) — Flutter yoki React Native mavjud native ilovaga joylashtiriladi va ekranlar birma-bir ko‘chiriladi.

Agar ilova kichik, kod esa yomon qo‘llab-quvvatlansa, qayta yozish osonroq bo‘lishi mumkin. Agar mahsulot katta, daromad keltiradi va faol rivojlanayotgan bo‘lsa, deyarli har doim bosqichma-bosqich borish oqilona.

Bosqichma-bosqich migratsiya qanday ishlaydi

• Flutter add-to-app rejimini qo‘llab-quvvatlaydi: Flutter moduli iOS va Android loyihalariga ulanadi, ekranlar FlutterViewController hamda FlutterActivity yoki FlutterFragment orqali ochiladi. Dvigatelni oldindan isitib, qayta ishlatgan ma’qul, aks holda Flutter ekraniga birinchi o‘tish sezilarli darajada sekinroq bo‘ladi.
• React Native mavjud ilovaga native kod oddiy ekranlar kabi ochadigan view’lar to‘plami sifatida joylashtiriladi.

Ishlar tartibi:

1. Chegaralarni belgilang: qaysi ekran va ssenariylar birinchi ko‘chiriladi. Yaxshi nomzodlar — yangi funksiyalar va izolyatsiyalangan bo‘limlar (profil, sozlamalar, katalog).
2. Modul native loyihalar bilan birga yig‘ilishi uchun build va CI ni sozlang.
3. Native va kross-platforma qismlar o‘rtasidagi almashinuv kontraktini aniqlang: navigatsiya, hodisalar, ma’lumotlar.
4. Bo‘limma-bo‘lim ko‘chiring va har bir ko‘chirishdan keyin native kodni o‘chiring.
5. Native’dan faqat qobiq qolganda, to‘liq kross-platforma loyihaga o‘tish-o‘tmaslikni hal qiling.

Relizlarni qanday to‘xtatmaslik kerak

• Har bir ko‘chirilgan ekranni feature flag ortiga yashiring va bosqichma-bosqich yoying.
• Ilovaning o‘sha bundle ID va imzosini saqlang: foydalanuvchilar yangi ilova emas, oddiy yangilanish olishi kerak.
• Yangi versiya crash va mahsulot metrikalari bo‘yicha barqarorligini isbotlamaguncha eski amalga oshirishni saqlab turing.
• Har bir relizda mahsulotning cheklangan qismi o‘zgaradigan qilib rejalashtiring.

Umumiy avtorizatsiya va ma’lumotlar

Eng ko‘p uchraydigan muammo — ilovaning ikki qismi foydalanuvchi kimligini turlicha tushunishi.

• Sessiyaning bitta egasi. Tokenlar bitta joyda (Keychain, Keystore) saqlanadi va ularni bitta qatlam yangilaydi. Ikkinchi qism o‘z refresh mantiqini yuritmasdan, tokenni ko‘prik orqali oladi.
• Aniq kontraktli ko‘prik. Flutter’da — platform channels; tiplangan interfeyslar uchun Pigeon generatori qulay. React Native’da — native modullar. Kontraktni API kabi tavsiflang: metodlar, tiplar, xatolar.
• Bitta ma’lumot manbai. Agar native qism lokal baza bilan ishlasa, kross-platforma qism o‘z nusxasini yaratmasdan, uni ko‘prik yoki umumiy API orqali o‘qishi kerak.
• Hodisalar. Akkauntdan chiqish, tilni o‘zgartirish, profilni yangilash ikkala qismga ham yetib borishi kerak.

// Flutter: native qismdan token so‘rash
const channel = MethodChannel('app/auth');
final token = await channel.invokeMethod<String>('getAccessToken');

Xavflar

• Native va kross-platforma ekranlar orasidagi o‘tishlar tezligi.
• O‘tish davrida build hajmining o‘sishi.
• Jamoada bir vaqtda ikki xil kompetensiya.
• Native bog‘liqliklar: plagini yoki moduli yo‘q SDK larni qo‘lda o‘rashga to‘g‘ri keladi.
• Ilovaning yarmi abadiy ikki stekda qoladigan cho‘zilib ketgan migratsiya.

Migratsiya qachon arzimaydi

• Native jamoalar yaxshi ishlaydi, mahsulot muammolari esa texnologiya bilan bog‘liq emas.
• Ilova platforma funksiyalariga chuqur bog‘langan: kamera bilan murakkab ish, AR, fon servislari, vidjetlar.
• Migratsiyani oxiriga yetkazish uchun resurs yo‘q — yarim migratsiya har ikkala toza variantdan qimmatroq.
• Migratsiya sababi o‘lchanadigan maqsadlar emas, moda: funksiyalarni chiqarish tezligi, yagona jamoa, umumiy kod.