Привіт! Мене звати Володимир, я iOS Team Lead у компанії RIA.com, працюю із продуктом AUTO.RIA. Мабуть, однією з найбільш помітних змін у світі мобільних застосунків та розробки продуктів останніх років став SwiftUI. Наша команда iOS-розробників вирішила прийняти цей виклик і перейти на SwiftUI для покращення продуктивності та забезпечення кращого користувацького досвіду. Тож у цьому матеріалі я розповім про нашу подорож у світ SwiftUI та про те, чи варто вже зараз переписувати весь флоу, які переваги та недоліки в імплементації SwiftUI.
Чому саме SwiftUI?
Станом на зараз у застосунку AUTO.RIA понад 13 млн завантажень, із них 4 млн — це iOS. Перед тим, як розпочати імплементацію SwiftUI, ми провели дослідження та вивчили переваги цієї технології.
Авжеж, інтеграція SwiftUI в UIKit уповільнює розробку на перехідному етапі. Проте дає більше переваг при повному переході на SwiftUI. Також важливо розуміти, що не можна тримати кодову базу на старих технологіях потрібно бути в тренді. Багато нових розробників вже починають з вивчення Swift оминаючи попередній тренд написання додатків на Objective-C. Це дає велику користь для підтримки продукту.
Почати треба з мови програмування, яку ми використовували. Багато всесвітньо відомих застосунків працюють на iOS завдяки стеку 80-х. Проте Swift є мовою програмування, за допомогою якої можна створити сучасні застосунки для Apple. До речі, цього року Swift виповнюється 10 років.
SwiftUI вважається найновішою технологією на ринку. Його анонсували у 2019 році і наразі відбувається перехідний етап, коли і UIKit все ще використовується, але й SwiftUI уже став знайомий багатьом компаніям. Хоча багато колег все ще з підозрою ставляться до нього через періодичні оновлення, наша команда розробників була готова до експериментів. SwiftUI розроблено для роботи разом з UIKit. Враховуючи, що попередній код застосунку був на UIKit, ми зрозуміли, що можна поступово застосовувати цю технологію. Стояла задача повністю створити нову частину інтерфейсу на iOS, не змінюючи докорінно поточну.
Зараз SwiftUI є повноцінним робочим інструментом, який дав нам багато якісних і швидких рішень «з коробки». Більшість візуальних компонентів можна описати більш лаконічно використовуючи менше коду.
SwiftUI — це сучасна та декларативна платформа для створення інтерфейсів, яка дає змогу легко та швидко створювати складні UI-елементи з мінімальними зусиллями.
Для чого нам переходити з UIKit на SwiftUI?
Відповідь на це запитання проста і складна водночас. Усім зрозуміло, що у нашу розробницьку буденність постукає SwiftUI. Він є простим для розуміння, якщо лише починати вивчати mobile-розробку. По продуктивності SwiftUI в цілому є ефективніший, ніж UIKit. Це завдяки тому, що ієрархія представлень знаходиться у структурах типів значень, які зберігаються у стеку. Відсутність дорогого виділення пам’яті призводить до кращої продуктивності в деяких сценаріях розробки.
На користь переходу на SwiftUI також свідчать наступні недоліки UIKit:
- З появою нових платформ або додаткових функцій може виникнути необхідність адаптації UIKit до нових умов. Це вимагає значних зусиль і витрат часу;
- Для створення простих інтерфейсів в UIKit часто потрібно написати більше коду порівняно з SwiftUI. Це може призвести до збільшення часу розробки та збільшення кількості можливих помилок;
- UIKit, базується на імперативному підході, що може зробити код менш зрозумілим та більш складним. SwiftUI, натомість, використовує декларативний синтаксис, який значно полегшує створення інтерфейсів;
- UIKit може вимагати більше коду та обробки, щоб керувати станом застосунку та взаємодією між компонентами. Це може призвести до більшої складності у підтримці та розвитку додатків.
У нас була задача по редизайну застосунку та зміні підходу взаємодії з бекендом. І саме в ході цих великих змін було прийняте рішення використати SwiftUI. Важливо було вибрати одну технологію і одну платформу, щоб сконценцентрувати всі сили.
Наш перехід на SwiftUI
Перехід на SwiftUI у застосунку розпочався ще задовго до ідеї створити нову версію AUTO.RIA. Переписувати окремі прості сторінки ми почали ще у ковідні часи. Тоді ми вже бачили, що є нові технології і потихеньку їх вчили. Це було задовго до розмов про новий інтерфейс.
Після ухвалення рішення про зміну інтерфейсу у команди не стояв вибір, які фреймворки використовувати. Ми вибрали SwiftUI для того, щоб наша кодова база була сучасною та більш гнучкою. Для того, щоб швидше втілювати фічі в життя. Ця робота на перспективу. Також зараз триває редизайн застосунку і більш вдалого моменту для переходу на нову технологію тяжко знайти. Якби не редизайн, ми би почекали з переходом на SwiftUI та дочекались більш комфортної версії iOS 17.
Утім, SwiftUI є досить робочим інструментом зі своїми підводними каменями. Враховуючи те, що ми вже мали деякі переписані сторінки, то всі слабкі сторони цього фреймворку були нам відомі. Для початку переходу на SwiftUI ми обрали певні розділи, розпочали створювати з нуля нові екрани та рефакторинг існуючого коду.
Першим кроком був вибір версій iOS, з якими будемо працювати. Ми одразу зрозуміли, що технології SwiftUI менше 14 iOS будуть неефективні. Кількість багів та витрати часу на роботу з ними не корелювалися із нашим головним завданням — створити для користувачів новий інтерфейс, який буде допомагати у вирішенні бізнес-завдань. Тому зосередилися на 15, 16 і 17 версії iOS. Наразі на останній версії iOS близько 70% користувачів мобільного застосунку AUTO.RIA.
Наступним етапом була архітектура. Вона не залежить від UI-складової, але цей етап був одним із найголовніших. У процесі редизайну ми спробували різні підходи, сучасні рішення, але перевірена на UIKit MVVM показала себе досить ефективною та зрозумілою і на SwiftUI.
Потім — навігація. З рефакторингу коду менше ресурсів займало лишити навігацію UIKit і поступово реалізовувати на її основі SwiftUI екрани, щоб можна було вже викатувати на юзерів. Тут ми зіткнулися з іншою стороною SwiftUI: на деяких версіях іOS знайшли купу багів і у якийсь момент не було зрозуміло, як із ними працювати. Після дослідження варіантів у нас було 2 шляхи: викинути все на UIKit і переписати на SwiftUI, або використати навігацію UIKit, а сам UI писати на SwiftUI. Для інтерфейсу екранів вживаних авто ми вибрали другий шлях. Це зумовлено самою архітектурою коду та моделлю роботи бекенду та фронтенду.
Значно полегшило розробку створення Design System. Визначені шрифти, конкретні кольори додатку та градуси заокруглення кнопок пришвидшили розроблення нового інтерфейсу майже вдвічі. Ті сторінки, переписування яких на UIKit займало повний робочий день, зі SwiftUI та Design System займають 2 години кодингу у помірному темпі.
Які очікування були від переходу на SwiftUI? Чи виправдовує він їх?
Ми хотіли взяти від SwiftUI усе зручне і корисне: готові рішення, робота з актуальною технологією, досвід «яблучної» новинки у коді. Хоч SwiftUI про сучасний стек, але він все ще сирий. Із досвіду роботи з цим фреймворком помітно, що він дуже добре працює в iOS 17. Якби мені сказали: «Напиши додаток лише для iOS 17», — це було була б найкраща задача. Бо у крайній версії від Apple з кодом на SwiftUI все «літає»: баги виправлені, все красиво і працює ідеально. Але ми живемо у реальному світі, де застосунок повинен допомагати певним бізнес-процесам. Тому треба створювати стек, який підтримуватиме мінімум 2-3 версії iOS.
Переваги, які ми відчули:
- Швидкість розробки: SwiftUI дозволяє створювати UI-елементи за допомогою простого коду, що значно спрощує процес розробки;
- Інтерактивність: SwiftUI надає потужні інструменти для створення взаємодії та анімацій, які можуть покращити користувацький досвід;
- Єдність між платформами: SwiftUI дозволяє створювати додатки для iOS, macOS, watchOS та tvOS з використанням одного коду.
Чи жорстока реальність із SwiftUI?
Перехід на SwiftUI був успішним, але не без перешкод. Ми зіткнулись з деякими викликами, які потребували часу та уваги. Однією з основних перепон була несумісність з попередніми версіями iOS, що вимагала від нас ретельно протестувати імплементацію на різних пристроях і версіях операційної системи.
Основні труднощі під час рефакторингу:
- Відмінності в підходах до навігації: SwiftUI використовує NavigationLink та NavigationView для забезпечення навігації між екранами. У той час як UIKit використовує UINavigationController та UIViewController. Це може викликати неспівпадіння при спробі інтеграції. Вихід - використовуємо обгортки UIHostingController або UIViewController Representable, які дозволить нам вбудовувати SwiftUI в контейнери UIKit або навпаки.
- Передача даних між SwiftUI та UIKit: Передача даних між SwiftUI та UIKit може виявитися складною, оскільки ці дві технології можуть використовувати різні підходи до обміну даними між екранами. Вихід — використовуємо спільний об'єкт моделі даних або спеціальний механізм передачі даних (наприклад, замикання) для обміну даними між SwiftUI та UIKit.
- Динамічне приховування Tab Bar не доступна в iOS версіях нижчих за 16. Вихід — використовуємо статичний.
Які все ж таки недоліки SwiftUI?
- SwiftUI введений у iOS 13, тому якщо ваша цільова аудиторія включає користувачів, які використовують попередні версії iOS, вам доведеться здійснювати додаткові зусилля для підтримки старіших версій або використовувати альтернативні методи розробки інтерфейсів.
- Деякі бібліотеки та функціонал, доступні в UIKit, наразі не мають повноцінної підтримки в SwiftUI. Таким чином, є ймовірність, що розробникам доведеться використовувати обидві технології (SwiftUI та UIKit) в одному проєкті.
- Обмежена кількість готових компонентів: на цей момент SwiftUI може виглядати менш гнучким у порівнянні з UIKit в термінах доступних готових компонентів. Деякі стандартні елементи інтерфейсу можуть вимагати додаткової роботи для досягнення певного ефекту.
- Менша кількість ресурсів та матеріалів для вивчення порівняно з UIKit.
- SwiftUI порівняно з UIKit дає мало можливостей для кастомізації елементів.
Ми дослідили, як краще керувати станом додатка та спілкуватися між Swift UI та іншими частинами додатка, що залишились на UIKit. Деякі старі бібліотеки і плагіни вимагали адаптації та оновлення.
Майбутнє зі SwiftUI
Після успішної імплементації SwiftUI, ми помітили покращення продуктивності нашої команди та забезпечили більш приємний досвід для наших користувачів. Тепер нові функції можна легко додавати та тестувати.
У майбутньому ми плануємо продовжити роботу з SwiftUI, вдосконалювати наші додатки та розробляти нові функції, використовуючи цей потужний інструмент.
SwiftUI так само регулярно оновлюється, що потребує постійного спостереження за кодом. Традиційно перед вереснем, коли виходить новий iOS, потрібно спостерігати за тим, щоб весь метод не став червоним. Проте на цьому етапі ми можемо впевнено говорити про підвищення швидкодії екранів, зменшення кількостості коду, менше часу потрібно на імплементацію нових розділів та на зміни в написаних.