Мова програмування Swift — це сучасне потужне рішення для будь-якого продукту чи обмежений інструмент в закритій екосистемі? Асинхронні оновлення iOS та Swift досі ламають проєкт? Чи вдалося IBM адаптувати цю мову під бекенд, а розробникам Apple — нарешті «допилити» SwiftUI? Та чи дозволить Kotlin Multiplatform Mobile оптимізувати розробку для двох команд? Найпоширеніші міфи про Swift спростовує Роман Кириленко, iOS Developer в Quarks, партнерській компанії Genesis.
МІФ №1
Swift створили, щоби замінити Objective-C, але цієї мети так і не досягли
Поява Swift у 2014 році була органічною потребою, адже Objective-C вже тоді була доволі застарілою мовою програмування. Попри її мачурність та здатність вирішувати багато завдань, вона не відповідала поточним трендам розробки, була недостатньо гнучкою та сучасною.
Мотивація Кріса Латнера, який розробляв Swift, не була націлена на витіснення Objective-C та подальше домінування в iOS-розробці. Але, побачивши результат, Apple почали інвестувати в комʼюніті, чия активність і зробила мову Swift такою, яка вона зараз. Було зрозуміло: якщо Swift «зайде» і проживе декілька версій, надалі ми рухатимемося в бік повної відмови від Objective-C. Це ми спостерігаємо зараз.
Останнім часом нативні фреймворки поступово переписуються на Swift, все менше проєктів запускають на Objective-C, — а ринку вже чимало розробників, які ніколи не стикалися з цією мовою. Іде відмова навіть на рівні Apple, і це гарна тенденція на користь покращення перформансу.
МІФ №2
Swift — мова, якою неможливо писати поганий код
Взагалі iOS-розробка складається з трьох компонентів: власне Swift, iOS SDK та Xcode. На кожному рівні є певні правила, які не допускають помилок. Більшість проблем розробників повʼязані саме з Xcode. Порівняно з іншими програмними середовищами, Xcode має проблеми з перформансом, оновленнями та містить баги.
Щодо Swift — це така ж мова як і всі інші, в яких якість коду цілком залежить від навичок розробників. В останніх версіях мови було розширено інструменти, які дозволяють відслідкувати баги, але водночас додано функціонал, який створює велике плато для нових помилок.
Наприклад, раніше під час програмування вагомим джерелом помилок був менеджмент памʼяті, зараз — на рівному місці можна створити проблеми з перформансом в плані зайвих обчислень чи відмалювань UI, що призводить до інших складнощів. Щоби цього уникати, треба ретельно вивчати інструменти, з якими працюєш.
МІФ №3
Після кожного оновлення Swift, iOS чи Xcode все ламається
Xcode, iOS SDK та Swift справді часто оновлюються асинхронно. Раніше це було проблемою, оновлення часто ламали всю роботу. Зараз це не так.
Проблеми з оновленнями Swift так само були найбільш відчутними на початку. Між першою, другою і третьою версіями різниця була настільки суттєвою, що при кожному оновленні треба було переписувати вагому частину проєкту. Починаючи з четвертої версії, зʼявляються скоріше мінорні зміни, та зберігається зворотна підтримка попередніх версій. Це свідчить про те, що Swift стає більш мачурною і стабільною мовою. Тепер, якщо девелопери хочуть згорнути певну функціональність, вони дають рік або навіть два для перехідного періоду — цього часу достатньо, щоби перейти на нову версію.
Зазвичай розробники не поспішають імплементувати нові фічі в проєкти, адже більшість оновлень можна використовувати тільки на останніх версіях iOS. Наприклад, нативний фреймворк StoreKit. Комʼюніті дуже чекало його оновлення, щоби зробити міграцію з першої версії, яка на той момент була сильно застарілою та містила чимало «бородатих» багів. Анонс другої версії відбувся разом з анонсом iOS 15. На той час актуальною для користувачів була версія iOS 14. Оскільки поширеним правилом є підтримувати хоча б -1 актуальну версію, на той час більшість продуктів підтримували iOS 13 та iOS 14. Проте для повної міграції на нову версію StoreKit потрібно було відмовитись від всіх версій крім 15 або підтримувати обидві реалізації одночасно. Тому для більшості розробників вибір був очевидним — чекати анонсу та переходу користувачів на наступну версію операційної системи, iOS 16.
МІФ №4
Swift повністю адаптований для проєктів за межами iOS
Objective-C — мова, замкнена на операційній системі macOS. Раніше ніхто навіть не пробував використовувати її для іншої розробки. На відміну від неї Swift — open-source проєкт, який можна використовувати для завдань за межами iOS/macOS. Наприклад, на Swift пишуть короткі легкі скрипти для локальних завдань. Також IBM намагалась інвестувати в бекенд на Swift.
Зрештою, з цього так нічого суттєвого не вийшло. Крім локальних невеликих проєктів, Swift залишився технологією, що не виходить за межі екосистеми Apple. Основна перешкода — потреба інвестувати в комʼюніті, яке саме собою зростати не буде. Крім того, з точку зору перформансу є значно цікавіші альтернативи для того ж бекенду. Наприклад, відносно новий Go, який показує гарні результати, в якого вже доволі хороше комʼюніті.
МІФ №5
На Swift можна створювати ігри
Swift — це компільована мова, написана на С++. Вона досить швидка, чудово перформить. При цьому Swift не може існувати в iOS-розробці без набору фреймворків SDK. Туди входять певні інструменти для рендеру графіки, але вони не підходять для розробки ігор, які зазвичай мають високий FPS і потребують рішень, ближчих до хардверу. Ніхто не створює ігри на тих самих фреймворках, що звичайні застосунки. Для цього є спеціальні рішення у вигляді SDK, такі як SceneKit, SpriteKit, Metal. Останній з них був вже написаний під час домінування Swift, і досі розвивається. Проте написані на цих технологіях ігри будуть обмежені платформами iOS та macOS, тому доцільність використання саме Swift для розробки ігор дуже залежить від контексту.
В Unity є опція експортувати проєкт у Swift, щоби надалі мати можливість зарелізитись в App Store. Для рендеру графіки вони використовують кастомний двигун, написаний на С++, який забезпечує пряму комунікацію з хардвером.
МІФ №6
SwiftUI — нове покоління UI-фреймворків
SwiftUI випустили 2019 року дуже «сирим». Якщо перші версії Swift були проблемними, то на SwiftUI в принципі неможливо було створити застосунок, адже цей фреймворк не закривав базових завдань. Певною мірою SwiftUI досі залишається «недопиленим». Ряд питань, які вже відпрацьовані в iOS-розробці протягом років, не можна закрити на SwiftUI, а треба повертатися на рівень UIkit.
Загалом SwiftUI може існувати в певній архітектурі. Але нормально цей функціонал працює лише у версіях, починаючи з iOS 15 (поточна — iOS 16). Тому про нове покоління, вочевидь, говорити ще зарано.
МІФ №7
Єдиний код для Android та iOS неможливий
Десять років тому поширеним упередженням серед розробників було те, що майбутнє — за кросплатформною розробкою. Мається на увазі поява єдиної мови програмування, на якій можна буде створювати продукт та експортувати для різних платформ. Це виглядало дуже логічним: навіщо створювати окремі продукти на двох платформах, якщо все можна зробити на одній? Проте ця ідея не «вистрілює» вже довгий час з багатьох причин.
У кросплатформених рішеннях доволі багато недоліків. Сама розробка може бути складнішою — подекуди розробнику треба орієнтуватись одразу в трьох рішеннях — iOS, Android та тій тулзі, на який він пише. Також кросплатформені рішення з часом застарівають і замінюються новими, через що треба переписувати проєкт. Наприклад, застосунок Airbnb зрештою переписали з кросплатформеної розробки на нативну, вклавши в це чимало часу та грошей.
Натомість зʼявилося інше рішення — кодова мультиплатформа Kotlin Multiplatform Mobile (KMM), яка дозволяє iOS-розробникам ділитися кодовою базою із Kotlin-розробниками. Теоретично у такий спосіб можна буде реалізовувати певні фічі на одній платформі і передавати іншій. Наприклад, одна команда створює якусь бізнес-логіку, ділиться з іншою, яка вже навішує свій нативний UI. Це дозволило б оптимізувати час на розробку і підтримку. В мобільному комʼюніті це одна з найгарячіших тем для обговорення.
