Вічна дилема iOS чи Android? Чи варто вчити Flutter або можливо краще обрати КММ? XML або Compose? Грати за правилами бізнесу або просувати нові технології? Поговоримо далі.
Телефони вже давно перестали бути просто способом примітивної комунікації. Сьогодні люди мають можливість тримати все своє життя на долоні. Там зберігається все — робота, друзі, ціла бібліотека, галерея або показник здоров’я.
Це результати роботи розробників та цілих команд, що створюють нові застосунки та підтримують старі. Розберемося, що потрібно знати, щоб стати частиною цього, а допоможе нам в цьому Паронікян Папін Арменович, техлид «Андроїд» відділу в CHI Software.
— Що таке нативна розробка?
Базою для будь-яких розробників в цій галузі будуть знання про життєвий цикл, компоненти та взаємодію елементів у певній системі.
«iOS розробнику з мов треба знати Objective–C і Swift та вміти підтримувати дуже невелику кількість девайсів — розмірів екрана та версій.
Android розробнику потрібні Java і Kotlin, до того ж набагато більший перелік девайсів і розмірів екранів, а також знати особливості роботи з китайськими девайсами такими, як Xiaomi й Huawei», — зазначає Папін Арменович.
Вам може здатися, що стати iOS розробником легше. Але якщо у вас немає девайса на Mac OS X, на вас чекає захопливий процес встановлення ПО.
Що таке кросплатформена розробка?
Кросплатформеність — здатність програмного забезпечення працювати більш ніж на одній апаратній платформі та (або) операційній системі.
Для даного виду розробки наразі використовують здебільшого Flutter, рідше React-Native або KMM (Kotlin Multiplatform Mobile). На мою думку, це зумовлено тим, що розробка на React є достатньо незручною, а KMM доволі сира технологія, оскільки її активний розвиток припав на 2021-2022 роки, а це вже наслідок пізньої появи Compose (бета вийшла у 2021 році). До появи Compose розробка для iOS все одно потребувала SwiftUI, а даний факт був не на користь KMM.
Наразі, щоб писати якісні та стабільні додатки треба володіти навичками нативної розробки та кросплатформної.
Apple та кросплатформеність?
Компанія Apple завжди вирізнялася своєю «особливістю», отож і мову програмування вони створили для себе окрему. Як вже відомо — це Swift. Ніяких нарікань до цієї пташки, проте чи є тоді шанс в умовного Flutter підкорити IOS ринок?
Папін Арменович має думку, що «Flutter зробив великий стрибок у цьому, тепер справа часу, коли бізнес зрозуміє, що для їх MVP/POC швидше і дешевше буде кросплатформеність, тоді вони займуть левову частку ринку. Особливо програми, в яких треба просто піти в інтернет, зберегти й відобразити щось».
— Так чи треба переходити з нативної розробки на кросплатформену?
— Тут залежить від бажання кожного. Кросплатформова технологія існує давно і ті, хто хотів — вже перейшли або в процесі. Маємо інтернату (в CHI) на iOS, Android і ось уже 2-й рік повноцінну на Flutter, де спеціалісти спочатку отримують знання з нейтива і потім вже вивчають Flutter. Процес довгий, але результати того варті.
Створили Flutter відділ близько 3-х років тому, в більшості зі своїх Android розробників, пізніше приєдналися з iOS. Загалом вже 12 розробників.
Маємо ще React Native, але з нейтива туди важче перейти, тому якщо і переходять, то на Flutter.
— KMM чи Flutter?
— На мою думку, KMM експериментальна річ, що має потенціал у майбутньому, але поки що все дуже сире і частину роботи треба все одно писати нативно. На проєкті де я працюю його використовують, проте інших застосувань я б не придумав. У нас два нативні додатки, а доповнення для певних користувачів написане на КММ. Проєкт з багатомільйонним прибутком і для замовників це експеримент, UI повторюється, тому ми на нейтів стороні створюємо Compose і SwiftUI, який вони вже використовують, що скорочує час розробки.
Писати з нуля програми поки не бачу сенсу. Для бізнесу — дорого, довго і не зрозуміло, чи довго воно буде підтримуватися. Якщо бізнес не просить цього, то й розробники масово не вивчатимуть цієї технології. Для розширення кругозору – супер. Тому Flutter поки що на гребені хвилі.
— Compose витісняє XML? Чому?
— Compose використовуємо не дуже, але напевно кожен 5-й проєкт так чи інакше використовує його. У когось проєкт вже повністю на Compose, є ті, хто нові екрани створює на ньому, якщо архітектура дозволяє. На проєктах ставлять завдання переписувати екран на Compose. Бізнес просить розробників мати його в арсеналі, тому він з'являється в матриці розвитку команди.
Його просуває сам Google й ігнорувати це не можна, він вже в релізі, активно використовується, досить зручний, якщо звикнути, легкий для системи та декларативний, що найважливіше.
Дякую Вам, Папін Арменович, за цікавий діалог. Від себе додам, що важливо не зупинятися на тому, що популярно зараз, а аналізувати, чи буде це потрібно завтра.
Чекаю на вас в коментарях.
Цехмістренко Катерина
