Переводимо проєкт з Obj-C на Swift

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті.

Я, Костянтин Білик, Team Lead, Lead iOS Software Engineer у компанії Svitla Systems, більше ніж 10 років у iOS розробці, у цій статті поділюся своїми думками та досвідом у такому, часто просто необхідному питанні, як переведення проекту з однієї мови програмування на іншу. В своїй кар’єрі мені доводилося не раз стикатися з подібними задачами, аргументувати їх необхідність та своєчасність, планувати та втілювати і мінімізувати негативний вплив супутніх проблем на розвиток проекту.

Велика кількість успішних проектів, що була написана на Obj-C досі існує в App Store та використовується мільйонами користувачів для покращення їх життя та бізнесу. Тут ми розглянемо існуючий досвід переводу коду аплікації з однієї мови на іншу:

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

Причини

Перш ніж прийняти рішення про переведення проекту з Obj-C на Swift слід врахувати цілу низку причин і ми розглянемо найголовніші з них у цьому розділі.

Apple

Як зрозуміло із заголовку, головною причиною і спонукачем переходу на Swift є сама компанія Apple. Більше шести років тому стало очевидним, що розробка програмного забезпечення для iOS та macOS матиме велике майбутнє і потребує сучасної мови програмування для пришвидшення процесу та залучення амбітних інженерів-програмістів. Obj-C чудова мова програмування, яка працювала роками, але вона теж мала свої недоліки. Ми не будемо їх детально обговорювати тут, але назвемо деякі: перевантажені синтаксичні конструкції, відсутність гнучкості та вбудованої функціональності для розширення реактивного та функціонального програмування, надсилання повідомлень замість виклику функції та багато іншого. Тож було прийнято рішення не переходити на іншу існуючу мову, а створити нову, яка може бути глибоко використана та модифікована самою Apple разом із open source спільнотою. З найперших версій Swift Apple закликала розробників спробувати та дати свої відгуки. Як приклад, на конференції WWDC спікери одразу перейшли у своїх демонстраційних сесіях коду з Obj-C на Swift, щоб показати можливості нової мови.

Інженери

Ми вже згадували, що однією з причин розробки Swift було те, що нове покоління інженерів програмного забезпечення вже звикло до зручності сучасних мов програмування. Більше того, нові інженери, які бажають працювати над проектом для отримання досвіду та експертизи старших колег, просто взагалі не знають Obj-C. Навіть якщо компанія здатна найняти досвідчену людину, яка готова працювати зі «старшою» мовою, це зазвичай коштує значно дорожче.

Фреймворки

Apple зробила справді хорошу роботу з підтримки функціоналу Obj-C, щоб він був на одному рівні зі Swift, реалізувавши деякі важливі функції для обох мов у iOS та macOS SDK та вивівши Obj-C на новий рівень можливостей. Впровадження дженериків в Obj-C стало великим кроком вперед для його розвитку. Але ми стикаємося з тенденцією, коли мову на основі С стає важче підтримувати в нових фреймворках Apple, і колись, у віддаленому майбутньому, вони все ж збираються обмежити цю підтримку до критичного рівня. Можна стверджувати, що це відбудеться не скоро, але якщо планується перенести проект, щоб він і далі був успішним в майбутньому то такий випадок також треба передбачити і врахувати.

SwiftUI

Нещодавно Apple представила SwiftUI 2.0 — вдосконалену версію їх декларативного UI фреймворку, яка вирішує багаторічні проблеми зі створенням інтерфейсів у iOS, уніфікує підхід до macOS, пришвидшує та спрощує розробку програмного забезпечення загалом. Правду кажучи, версія 1.0 була справді недоробленою, і її можна було лише дуже обмежено використовувати для комерційної розробки. Але сьогодні фреймворк зробив великий крок до застосування в реальних проектах. Найбільшою зміною, окрім покращення control flow, є SwiftUI workflow для проекту, який покликаний замінити App Delegate. Таким чином інженери Apple додали альтернативний спосіб використання та відстеження життєвого циклу програми, який раніше був неможливим. Тому, більше не буде перевантаженого App Delegate, який існував від самого початку і оснований на SwiftUI життєздатний додаток може складатися не більше ніж з 144 символів. Очевидно, що використання Obj-C тут вже особливо немає сенсу.

Архітектура

Багато років інженери програмного забезпечення, що працювали з iOS мали рекомендацію використовувати так званий Apple MVC (Model View Controller) архітектурний паттерн у своїх додатках, що часто призводило до проблеми з Massive View Controller через те, що View та Controller були об’єднані у один файл/клас/сутність самими Apple на рівні SDK. Щоб вирішити цю та ще багато проблем розробники по всьому світу використовували у своїх проектах інші архітектурні патерни, такі як MVP, MVVM, VIPER, Clean Swift та Redux експерементуючи і намагаючись покращити ефективність, а також додаючи нову функціональність до існуючих (MVVM + Coordinator). Сьогодні ми маємо нові рекомендації, що грунтуються на використанні SwiftUI в комбінації з MVVM паттерном та фреймворком реактивного програмування Combine від Apple. І ця комбінація вже не включає в себе Obj-C.

Шляхи

У загальному випадку існує два шляхи, якими можна піти, щоб перевести вашу аплікацію з Obj-C на Swift: використовувати обидві мови в одному проекті та окремо переписати проект на Swift.

Два в одному

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

Імпортування Objective-C у Swift

Для того, щоб використовувати код, що написаний на Objective-C в Swift проектах, нам потрібно задіяти так званий Bridging Header який має імпортувати всі заголовки «.m» файлів, що будуть потрібні у проекті. Якщо відповідний «.h» файл не буде зазначено у «-Bridging-Header.h» то він не буде видимим для Swift коду. Xcode автоматично пропонує створити файл Bridging Header коли ви додаєте будь-які Obj-C файли до проекту, що базується на Swift: Або це може бути зроблено вручну пізніше вибравши File > New > File > [operating system] > Source > Header File та назвавши новий файл використовуючи назву вашого продуктового модулю з постфіксом «-Bridging-Header.h». Але у цьому випадку ми повинні переконатися, що Objective-C Bridging Header налштування (у конфігурації збірки) містить шлях до bridging header файлу (шлях прописується відносно кореневої папки проекту).

Apple Developer Portal містить окрему статтю з цієї теми, що доступна за посиланням.

Використання Swift у Objective-C

Аналогічно до Bridging Header існує спеціальний файл заголовку який тримає в собі всі Swift типи і може бути використаний шляхом імпортування заголовкового файлу з іменем, що згенероване на базі імені продуктового модуля з постфіксом «-Swift.h», у необхідних «.h» та «.m» файлах. Окрім того, ми маємо врахувати іще одну річ, що згенерований заголовочний файл містить інтерфейси для Swift оголошень позначені public чи open модифікаторами. Якщо target вашого додатку містить Objective-C bridging header, то згенерований файл заголовку також включатиме інтерфейси позначені internal модифікатором. Оголошення позначені private чи fileprivate модифікаторами не з’являться в згенерованому файлі заголовку та не будуть доступні для Objective-C runtime якщо вони явно не позначені @IBAction, @IBOutlet, чи @objc атрибутами. З unit test targets можна отримати доступ до імпортованих внутрішніх (internal) оголошень так, ніби вони публічні (public) через додавання @testable до оголошення імпорту модулю продукта.

Більше деталей по використанню Swift Header в Objective-C проекті можна знайти тут.

Фреймворк

Альтернативно, можна перетворити існуючий проект на фреймворк, який використати всередині нового. Щоб це зробити нам потрібно створити .workspace файл за допомогою Xcode чи використовуючи cocoapods, що створить workspace автоматично.

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

Цей підхід корисний, коли є в наявності дві команди: одна для підтримки існуючої кодової бази та інша для імплементації нових фіч на основі поточної. У цьому випадку можна навіть створити власний pod та включити його як зовнішню залежність, але тоді може не бути можливості переглянути вміст такого фреймворку.

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

Новий

Так може статися, що трансформування одного проекту, який містить дві мови, є занадто ресурсоємким або навіть ризикованим та може призвести до серйозних проблем і відверне користувачів. У такому випадку розробка нового проекту з нуля під Swift буде найкращим рішенням. Очевидно, що новий проект краще за все створювати за допомогою найновішої версії XCode та з використанням останньої версії Swift. Але і це, в свою чергу, може викликати деякі проблеми.

SwiftUI

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

Перш за все, перевикористання існуючих .xib та .storyboard файлів стане складним, якщо взагалі можливим. Як завжди Apple надає можливість зробити і так, але у цьому випадку це вже буде не SwiftUI. Тому, на вас чекає значна кількість роботи зі створення наново всього користувацького інтерфейсу застосовуючи новий фреймворк.

Іще одна річ, зараз рекомендується щоб SwiftUI аплікація базувалася на MVVM архітектурі, тому, якщо ваш проект був написаний з використанням Apple MVC, як це було раніше рекомендовано самими Apple, то це буде іще одна річ, яку потрібно буде врахувати.

І, накінець, SwiftUI додаток написаний з застосуванням MVVM архітектури найкраще працюватиме з використанням якогось фреймворку реактивного програмування для контролю потоку даних та керування станом аплікації. Наприклад, за допомогою Combine від Apple.

SwiftUI Життєвий Цикл Додатку

У iOS 14, як нову фічу, Apple презентували змінений підхід до Життєвого Циклу додатку, який більше не використовує AppDelegate і, навіть, не працює через SceneDelegate, а повністю покладається на новий App протокол, що заснований на SwiftUI. Тепер додатки можуть бути значно меншими і матимуть зовсім інший спосіб контролю їх життєвого циклу. Одна з можливих проблем тут, полягає у відсутності методів делегату для відслідковування подій життєвого циклу, що було вирішено Apple через представлення нового, більш потужного оператора switch для SwiftUI: Інша ймовірна проблема може бути викликана відсутністю спільної точки ініціалізації якою, вже багато років, був метод «appDidFinishLaunching:WithOptions». Але і цей нюанс було враховано зв допомогою новоствореного UIApplicationDelegateAdaptor, який дозволяє отримати доступ до втрачених методів AppDelegate.

Більше подробиць та прикладів нового Життєвого Циклу SwiftUI можна прочитати тут.

Зовнішні фреймворки

Більшість проектів покладається на існуючі фреймворки та використовує cocoapods, як менеджер залежностей. Може статися так, що якась бібліотека, яку було використано у Objective-C проекті іще не підтримується на Swift. Це було частим випадком для ранніх версій Swift.

Зараз, більшість популярних фреймворков має Swift версію, але такий нюанс слід враховувати під час прийняття рішення про перехід з однієї мови на іншу. В найгіршому випадку можливо включити фреймворки, що базуються на Objective-C у Swift проект, особливо, використовуючи cocoapods. У певних рідкісних випадках вам, можливо, доведеться зробити відгалуження від оригінального репозиторія, щоб змінити код бібліотеки для використання у Swift.

«За» та «Проти»

Bridging

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

Ця функціональність дозволяє імплементувати частковий перехід та включення коду однієї мови у проект написаний іншою мовою.

З негативного боку, як зазначалося раніше, такий перетин може викликати проблеми збірки, а також ускладнити інтеграцію залежностей через cocoapods. В ранніх версіях Swift та із недостатньою кількістю бібліотек, що підтримують Swift зазначені проблеми були дуже частими, але сьогодні, у більшості випадків, ускладнення можуть бути вирішені використанням команди «use_frameworks!» у pod файлі, щоб уникнути недоліків використання Static Libraries.

Архітектура

Найпростіший спосіб переходу з Obj-C на Swift з використанням обох мов у коді паралельно — це перехід на модульну архітектуру, коли назовні надаються тільки API, щоб мати можливість викликати код кожного модуля, що є дуже схожим на мікросервісну архітектуру у Web, але тільки всеседині iOS/macOS додатку.

Позитивним аспектом такого підходу є розділення коду, зменшення зв’язаності та можливість проведення рефакторингу помодульно. Загалом, така архітектура — це хороший спосіб розвитку для складних проектів з кількома командами розробки, що відповідають кожна за свою частину функціональності.

З іншого боку, керування багатопроектним робочим простором може бути складним та потребуватиме певного навчання і передачі знань новим членам команди.

Рефакторинг

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

Це також чудова можливість покращити свій код, зробити його більш орієнтованим на протоколи та покрити юніт тестами. Більше того, однією з найефективніших стратегій буде рефакторинг у TDD стилі, коли ви покриваєте існуючий код тестами і потім переводите його з Objective-C на Swift переконуючись, що всі тести проходять успішно.

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

Ресурси

Коли ми працюємо у agile оточенні, то створюється відчуття, що ми маємо гарний контроль над роботою команди та здатністю оцінювати роботи у певний період часу, але у випадку переходу з Obj-c на Swift це може виявитися найбільш складною частиною роботи, адже тут нам не тільки не вистачатиме досвіду в оцінці такого роду завдань але й може з’явитися потреба у додаткових ресурсах та експертизі.

Почати виділяти ресурси на таку діяльність — це гарний досвід для команди. З відповідним плануванням та затвердженням ви можете зробити постійний рефакторинг природною частиною процесу розробки.

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

Помилки

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

Використання Swift має свої переваги у процесі ідентифікації існуючих помилок в Objective-C коді. Як мінімум сувора типізованість мови змушує нас використовувати перевірки змінних чи констант на nil та не дозволяє відправляти повідомлення nil-об’єктам як це дозволено в Objective-C. Більше того, переписування методів у функції дозволяє переглянути їх тіло та знайти можливі логічні помилки які так складно впіймати.

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

Документація

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

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

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

Синтаксис

Кожна з мов має свої переваги та обмеження. Для прикладу, swizzling методів, який використовується в Objective-C коді буде не так просто замінити використовуючи можливості Swift, але це тільки одна сторона проблеми.

Однією з причин створення Swift було те, що він мав мати кращий синтаксис ніж Objective-C і цього було досягнуто досить успішно. Багато звичайних конструкцій є набагато коротшитими у Swift та роблять його більш подібним до інших сучасних мов програмування.

Для інженерів, що звикли до Objective-C перехід на Swift буде доадтковим викликом до необхідності знайти нові способи реалізації вже знайомих та звичних речей. Swift є вже досить дорослою мовою та більшість проблем мають свої стандартні рішення.

Швидкість

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

Згідно з Apple Swift є до 2.6 разів швидшим з Objective-C і тільки це одне твердження маю бути гарним приводом для негайного початку рефакторингу.

Але в процесі переходу аплікація буде працювати зі швидкістю найповільнішої мови і це Objective-C. На додачу, час компіляції може зрости через менеджмент взаємодій між двома мовами.

Автоматизація

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

Ми можемо вважати за перевагу те, що навіть один з найпопулярніших інструментів для автоматизації мобільної розробки fastlane тепер дозволяє конфігурувати процеси за допомогою Swift. Також, як тільки проект, що містить дві мови, зконфігуровано на локальній машині, то його можна запускати на віддалених машинах для збірки.

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

Залежність

Вже існуючий код може залежати не тільки від використаних бібліотек, що не підтримують (на даний момент чи взагалі) інтеграцію зі Swift, але також може викликати проблеми з використанням менеджерів залежностей, таких як cocoapods.

Гарні новини полягають у тому, що з моменту впровадження Swift пройшло вже досить багато часу і самі cocoapods та й більшість популярних бібліотек вже впровадили повну підтримку Swift. На додачу тепер існує і Swift Package Manager, що набуває все більшої і більшої популярності.

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

Міграція

Кожен тип, що написаний на Swift навіть якщо він повністю дублює Objective-C аналог вважається новим для таких речей як кодування та декодування і нам доведеться потурбуватися про те, як існуючі засоби збереження даних на диску будуть працювати з новими типами та сутностями

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

З негативного, усі об’єкти закодовані у файл будуть вважатися відмінними від Swift аналогів і потрібно буде вигадати якусь стратегію міграції та деякий час тримати Objective-C версії для сутностей в кодовій базі з тим, щоб мати можливість здійснювати ці міграції для збереження даних користувачів.

І багато іншого

Існує іще багато інших менших речей, які можуть піти не так або надати не такі очевидні переваги в процесі переведення проекту з Objective-C на Swift.

Головне, що потрібно тримати в голові — це те, що загалом вам доведеться мати справу з ускладненнями витрачаючи більше часу команди інженерів але це однозначно окупиться у довгостроковій перспективі (іноді не такій довгостроковій).

Як то кажуть — ніколи не пізно почати робити правильні речі і це чудове місце щоб почати!

План

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

1. Перегляд

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

2. Стратегія

Наступний підготовчий крок — визначення стратегії чи способу впровадження змін. Можемо ми відокремити новий проект чи нам варто працювати з існуючим? Якщо останнє, то чи дійсно варто його розбивати на модулі? Чи потрібен нам SwiftUI з новим життєвим циклом, чи він занадто незрілий?

3. Ресурси

Цей крок значною мірою поєднаний з попереднім. Чи можемо ми використати існуючу команду для втілення переходу з Objective-C на Swift? Чи має вона достатньо досвіду та знань у нових технологіях щоб зробити це без зовнішньої експертизи? Чи можливо мати окрему під-пкоманду, що буде повністю присвячена саме задачі переходу?

4. Планування

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

5. Найм

Дуже ймовірно, що нам знадобляться додаткові інженери і їх найм має бути здійснений після ретельного виконання попередніх пунктів. Які будуть вимоги до кандидатів? Чи варто нам найняти не тільки розробників але й QA інженерів? Чи буде потреба у керівнику для окремої команди?

6. Втілення

Очевидно, що цей крок завершує всю підготовчу роботу і потребуватиме прийняття нових рішень. Чи варто розглядати процес переходу як окремий проект з точки зору менеджменту? Чи будемо ми використовувати той самий робочий процес (якийсь agile фреймворк, вотерфол, щось інше), як і для головного проекту? Як передати знання про проект між новими членами команди та інженерами, що вже працюють на проекті певний час?

7. Перегляд

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

Висновок

Виглядає так, що ми майже не маємо вибору хотіти чи не хотіти переводити проект з Obj-C на Swift і єдине що ми можемо вирішити — як це зробити. Саме тому так важливо врахувати всі згадані «за» та «проти» та створити план переходу обравши один із шляхів: поєднати дві мови в єдиному проекті чи створити окремий для Swift з нуля.

Звичайно, може бути іще більше аспектів, які варто врахувати для конкретного проекту та команди. Але, якщо ви будете слідувати рекомендаціям та триматимете в голові основні аспекти цієї статті, то процес заміни Objective-C на Swift буде настільки ідеальним, наскільки це можливо.