Мультиплатформна Розробка — ТАК/НІ?

НАПИШИ ОДИН РАЗ — ЗАПУСКАЙ ГДЕ УГОДНО

Основна ідея — розробка одночасно під кілька платформ, тобто пишемо код один раз замість двох для iOS та Android. Те саме стосується і фіксу багів, розширення функціоналу, підтримки проекту.

При розгляді мультиплатформного рішення зазвичай звертають увагу на наступні критерії:

• Об’єм шарингу кодової бази. Бувають кейси, коли універсальне рішення не працює або працює не так, як потрібно і тоді доводиться його кастомізувати під конкретну платформу. Цю властивість можна виражати через відсотки, наприклад, у додатку 50% загального коду. Можна висловлювати через абстракції — наприклад, мережевий шар (тобто робота з API) загальний, а UI частина на кожній платформі своя.
• Продуктивність. Тут начебто все очевидно.
• Поріг входження: перш ніж працювати з новою технологією, її потрібно вивчити/освоїти.
  Легасі. Існує природна необхідність у переході на нову технологію, коли стара об’єктивно програє, але буває і так, що перехід обумовлений лише тим, що в нових умовах просто інша екосистема, інший технологічний стек. Що більше знань стають неактуальними, то гірше.
• Перспективи: ймовірність того, що технологія вистрілить, її не перестануть розвивати та підтримувати, наявність активного ком’юніті. Для команди це ще й актуальність знань та досвіду, на вивчення яких було витрачено зусилля та ресурси.

Розглянемо рішення від JetBrains: Kotlin Mobile Multiplatform для iOS та Android.

ШАРИНГ КОДОВОЇ БАЗИ.

На сайті JetBrains є розділ з кейсами, де різні компанії діляться досвідом використання цієї технологіх. Деякі кажуть, що їм вдалося винести до загального коду приблизно дві третини проекту. Тут, звісно, багато залежить від конкретного проекту.

Зазвичай до загального коду потрапляють такі штуки, як робота з мережею, бізнес-логіка. У нативі реалізують UI та якісь специфічні для платформи API, наприклад, робота з камерою, біометрія, Google/Apple сервіси тощо.

Чисто теоретично, можна зашарити й набагато більше — все залежить від того:

• на якому етапі розвитку знаходиться технологія
• чи сподобалася вона спільноті, що впливає на кількість бібліотек від сторонніх розробників.

Варто зазначити, що у разі відсутності відповідного рішення не кожна компанія чи клієнт може знайти ресурси та бажання на розробку своїх кастомних рішень.

Якщо технологія популярна, поява бібліотек це лише питання часу, на гітхабі вже є добірки з рішеннями для популярних кейсів.

Їм, звичайно, ще доведеться пройти перевірку часом. Цілком можливо, що вони містять баги або покривають не всі юзкейси, або просто виконані неякісно.

З продуктивністю все має бути гаразд.

Якщо грубо і без подробиць, то загальний код компілюється у нативний і підключається як бібліотека.

ПОРІГ ВХОДЖЕННЯ/ЛЕГАСІ/ПЕРСПЕКТИВИ

1. Нові бібліотеки для розробників.

Якщо йдеться про шарений код, то бібліотеки там свої, їх треба освоювати: деякі можуть бути схожі на «старі» і даватися легко, а інші можуть відрізнятися, зокрема концептуально.

2.  Можлива нова (додаткова) мова для iOS розробника (Kotlin).

Як вказано вище, шарений код компілюється в бібліотеку і підключається до Android або iOS проекту. Якщо в шареному коді потрібна інтеграція з кастомними для платформи рішеннями, тоді в рамках цієї шареної бібліотеки готуються різні шматочки коду, які будуть взаємодіяти з різними платформами.

Приклад.

Те, що  у схемі на зображенні, є шарений код, що написаний на Kotlin. При цьому в частині iOS (помаранчева зліва) вже є доступ до iOS SDK (різні NS обджекти).

Таким чином, або розробник iOS вивчає Kotlin, або розробник Android, що знає Kotlin, вивчає iOS SDK.

3. Архітектура

Залежно від того, скільки та який код потрапить у шаренний, це може сильно вплинути на архітектуру, яка в iOS та Android проектах може надто відрізнятися. Можливо, комусь доведеться підлаштовуватися або шукати компроміси. Загалом це потрібно враховувати.

4. Два IDE (середовища розробки)

Часом знадобиться працювати в обох IDE (Android студія і XCode). Тобто йдеться про додатковий час, щоб освоїтись.

5. Рекомендації по залізу від iOS розробника (для Mac)

• 512 GB SSD
• 16 GB RAM
• Пристрій (iphone) – необов’язково (є simulator)

Можливо вистачило б і 350-400 ГБ диску, але вибір полягає між 256 та 512, а чогось посередині немає. 256 дуже мало, ризиковано для двох екосистем розробки.

Варто згадати, що на Windows зібрати бінарник для MacOS не можна.

Пристрій (iphone) – необов’язковий (є simulator, який хоч і покриває не всі кейси, але для базового функціоналу годиться).

ПЕРСПЕКТИВИ

Чисто субъективно, з огляду на інфоприводи і те, як це виглядає зі сторони: технологія начебто сподобалася ком’юніті. Активно розвивається, “помирати” не збирається.

Список деяких компаній, які використовують КММ. Напевно, всім зрозуміло, що вони використовують це в рамках експериментів, а не як основну технологію для флагманських продуктів.

Автор: Арсен, наш Android розробник 😎