💡Підтримка OpenRouter у Xcode

OpenRouter — це платформа, яка надає доступ до більшості великих мовних моделей (LLM) через єдиний API і спільну систему токенів.
Завдяки цьому немає потреби окремо налаштовувати підключення до кожної моделі — все працює через один інтерфейс.

Тепер ви можете викликати API OpenRouter прямо з Xcode, що спрощує інтеграцію AI-асистентів у процес розробки. Це означає, що будь-яку підтримувану модель можна підключити до вашого робочого середовища без додаткових конфігурацій та зайвих ключів для кожного провайдера.

🇺🇦 iOSDevUA

💡Реалізація мема: @escaping @Sendable @MainActor @autoclosure () async -> Void
📖 Стаття Джейкоба Бартлетта

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

У своєму дописі Джейкоб розбирає кожен атрибут по черзі — від @escaping до @MainActor — і врешті доходить до такої реалізації:

Task {
    await allTheAttributes(await helloWorld())
}

func allTheAttributes(
    _ then: @escaping @Sendable @MainActor @autoclosure () async -> Void
) async {
    Task {
        await then()
    }
}

@MainActor func helloWorld() {
    print("Hello, world!")
}

Тут він демонструє, як усі ці атрибути можуть поєднуватися в одному параметрі, навіть якщо це виглядає надто перевантажено.

😅 Як каже сам автор: “Не пробуйте це вдома” (а тим паче у продакшні, якщо не впевнені у своїх навичках).
Це радше навчальний приклад, ніж рекомендація для реального коду.

🇺🇦 iOSDevUA

💡Global actor у Swift Concurrency на практичних прикладах

ℹ️ У Swift Concurrency з’явилась концепція глобального актора, яка використовується разом із async/await та задачами.

Найвідоміший приклад — @MainActor, який забезпечує виконання коду в головному потоці. Докладніше про нього можна почитати тут.

Але Swift також дозволяє створювати власні глобальні актори.

Що таке глобальний актор?

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

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

Де це корисно?
• Централізоване керування доступом до спільних ресурсів
• Ізоляція важливих операцій (наприклад, доступу до бази даних або файлів)
• Побудова потокобезпечних API без необхідності вручну синхронізувати доступ

📖 У статті Avanderlee розглядається:
• як правильно створювати глобальні актори;
• як використовувати їх у коді;
• типові помилки та як їх уникати.

🇺🇦 iOSDevUA

💡Великий огляд усіх змін у UIKit в iOS 26

Кілька місяців тому багато великих iOS-ресурсів поширювали чутки про те, що UIKit (і зокрема UIApplicationDelegate) збираються депрекейтити. Як це часто буває — жодних підтверджень не було.
Після WWDC стало зрозуміло, що на практиці все інакше: UIKit нікуди не зникає, і найближчим часом ми ще активно ним користуватимемось.

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

📖 У своєму пості він розглядає:
• UIBackgroundExtensionView — новий API для роботи з розширенням фону.
• UICornerConfiguration — нарешті офіційне рішення для скруглень, яке замінить кастомні реалізації з UIBezierPath.
• Зміни в UIResponder — нові можливості для роботи з відповідями на події.
• Оновлення в UIScrollView — покращення поведінки скролу та візуальних ефектів.
• Та інші дрібні, але важливі зміни, які вплинуть на розробку.

🔗 Раджу зберегти пост «What’s new in UIKit 26» у закладки, адже реліз iOS 26 вже зовсім скоро.

🇺🇦 iOSDevUA

💡@isolated(any) у Swift — детальний розбір від NSHipster

У Swift 6.0 з’явився модифікатор @isolated(any), який допомагає гнучкіше працювати з асинхронністю та керуванням потоками.

Що це таке?

@isolated використовується для позначення того, що певний параметр функції або властивість ізольований в контексті актора чи іншого concurrency-домену.
Ключове слово any у цьому випадку означає, що параметр може належати будь-якому ізольованому контексту — не обов’язково конкретному актору.

Для чого це потрібно?
• Гнучкість — можна викликати метод, який працює з ізольованими даними, без жорсткої прив’язки до конкретного актора.
• Сумісність — спрощує передачу даних між різними контекстами Swift Concurrency.
• Продуктивність — зменшує кількість непотрібних перемикань потоків і await.

Приклад використання

func processData(_ handler: @isolated(any) () -> Void) {
    handler()
}

Тут handler може бути ізольованим у будь-якому контексті — наприклад, у MainActor або кастомному акторі.

Ключові висновки зі статті
• @isolated(any) особливо корисний у універсальних API, які повинні працювати з різними акторами.
• Це потужний інструмент для оптимізації асинхронних викликів у складних багатопотокових застосунках.
• Не варто плутати його з nonisolated — вони вирішують різні задачі.

🇺🇦 iOSDevUA

💡Як працювати зі SwiftData у фоновому режимі в Swift 6

Це може стати в пригоді у багатьох сценаріях — наприклад, при інтеграції з новими LLM API, коли потрібно зберігати відповіді чи проміжні результати у вже наявні моделі SwiftData.

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

Ключові моменти:
• Використання background context для уникнення блокування UI.
• Робота з асинхронними операціями збереження, щоб дані записувались без шкоди для продуктивності.
• Інтеграція з Task та async/await для зручного керування операціями у фонових потоках.

Таким чином можна створювати застосунки, які залишаються відзивчивими, навіть коли відбувається масове збереження або оновлення даних у SwiftData.

🇺🇦 iOSDevUA

💡Переходимо з Xcode у Zed

Zed — відносно новий редактор коду, який на відміну від більшості конкурентів не є форком VS Code. Він написаний повністю на Rust і його головна перевага — швидкість і легковажність: Zed працює блискавично навіть на великих проєктах.

Що можна робити в Zed для iOS/macOS-розробки

У статті розглядається, як замінити Xcode в більшості щоденних задач:
• Редагування Swift-коду з підсвічуванням синтаксису та автодоповненням.
• Дебаг застосунків через інтеграцію з LLDB.
• Запуск і складання iOS/macOS-проєктів.
• Використання Bazel та інших тулів для керування збірками.

Чому це цікаво
• Zed дозволяє працювати у знайомому середовищі, але з відчутно більшою продуктивністю.
• Він не перевантажений зайвими функціями, як Xcode, і більше нагадує «чистий редактор» із можливістю тонкої кастомізації.
• Спільнота активно додає плагіни й інтеграції, у тому числі для Swift.

🚀 Якщо ви шукали легкий і сучасний редактор для роботи зі Swift поза Xcode, Zed може стати гарною альтернативою.

🇺🇦 iOSDevUA

💡Додаток від творців SwiftUI, який дозволяє писати код прямо на iPhone та публікувати його у TestFlight

Bitrig — це новий застосунок, який створює нативні Swift-апки за допомогою AI-асистента.

Як це працює
• Ви описуєте, яке застосунок хочете отримати.
• AI генерує код і збирає апку.
• У результаті — можна одразу залити проєкт у TestFlight без складних налаштувань.

🛠 Спробувати можна вже зараз: Bitrig у App Store
(доступно 5 запитів без підписки).

Чому це особливо цікаво

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

Моє бачення

Хайп, ймовірно, спаде, особливо якщо великі AI-гравці додадуть подібні можливості у свої IDE. Але сама ідея створювати й тестувати апки прямо на iPhone виглядає захопливою й відкриває нові сценарії для експериментів.

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

🇺🇦 iOSDevUA

💡Чим поганий TextKit 2 — досвід Марціна Кшижановскі

Marcin Krzyzanowski — один із найвідоміших експертів із роботи з текстом в iOS, а також мейнтейнер бібліотеки STTextView. За роки використання TextKit 2 він зібрав велику кількість проблем і поділився ними у своєму блозі.

Основні проблеми TextKit 2
• Нестабільність: багато методів працюють непослідовно, а іноді й зовсім ламаються в різних сценаріях.
• Документація: відчутний брак зрозумілих прикладів і пояснень, через що розробникам доводиться здогадуватись, як правильно використовувати API.
• Зворотна сумісність: перехід із TextKit 1 виявляється складним і не завжди виправданим.
• Обмеженість функціоналу: чимало можливостей, які здавалися очевидними, доводиться реалізовувати вручну.

Висновки

За словами Марціна, хоча TextKit 2 і був представлений як “нова обітована земля” для роботи з текстом у iOS, на практиці він виявився сирим і проблемним інструментом. Багатьом командам доводиться шукати обхідні рішення або навіть залишатися на старому TextKit 1.

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

🇺🇦 iOSDevUA

💡Як писати якісні дизайн-документи

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

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

✍️ Хороший дизайн-док — це не формальність, а робочий інструмент, який підвищує ефективність команди та якість продукту.

🇺🇦 iOSDevUA

💡UDF у SwiftUI без додаткових бібліотек

Unidirectional Data Flow (UDF) — простий і зрозумілий архітектурний патерн, для реалізації якого зовсім не обов’язково підтягувати важкі фреймворки на кшталт TCA.

Чому це важливо

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

Ключова ідея

Навіть без додаткових бібліотек можна побудувати просту UDF-логіку у SwiftUI. Це особливо зручно для окремих фіч, де важлива прозора обробка стану, але цілий фреймворк був би зайвим.

Приклад підходу:
• створюємо стан у вигляді структури;
• описуємо дії (events), які змінюють цей стан;
• використовуємо редʼюсер (функцію, що приймає стан і дію та повертає новий стан);
• підключаємо це до SwiftUI-в’юшок.

Висновок

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

🇺🇦 iOSDevUA

💡Реліз SwiftMCP 1.0 — перша стабільна версія MCP для Swift
🛠 GitHub — SwiftMCP

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

Чому це важливо
• SwiftMCP став feature complete і отримав перший стабільний реліз (1.0).
• Це означає, що бібліотека готова для продакшн-використання.
• Вона дає змогу створювати MCP-сумісні інструменти на Swift, без потреби переходити на інші мови.

Для кого
• Для розробників, які хочуть автоматизувати рутинні робочі процеси.
• Для тих, хто хоче експериментувати з AI-асистентами та MCP-інтеграціями.
• Для Swift-комʼюніті, яке прагне єдиних стандартів і кросплатформеної сумісності.

🚀 SwiftMCP 1.0 відкриває шлях до створення власних серверів та інструментів на MCP, залишаючись у екосистемі Swift.

🇺🇦 iOSDevUA

💡Контроль та оптимізація процесу декодування зображень в iOS

Робота з графікою в iOS часто стає викликом для розробників. Хтось покладається на сторонні бібліотеки, але багато хто намагається оптимізувати процес власноруч — використовуючи доступні API й експериментуючи з підходами.

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

Три стовпи ефективності

Оптимальна робота зображень у iOS базується на балансі:
1. CPU — скільки обчислювальних ресурсів ми витрачаємо.
2. RAM — наскільки ефективно використовуємо оперативну пам’ять.
3. I/O — наскільки правильно організоване кешування й робота із записами на диск.

Основні поради зі статті
• Переносьте важкі обчислення з головного потоку, щоб уникати фризів і лагів.
• Використовуйте попередньо згенеровані прев’ю, коли це можливо.
• Зверніть увагу на CVPixelBuffer для оптимізації відео-кадрів.
• Використовуйте профілювання, щоб зрозуміти, на якому етапі рендерингу відбувається декодування і в якому потоці.

Висновок

Робота з декодуванням зображень — це не лише про відображення картинки, а й про баланс продуктивності та плавності UX.
Навіть кілька невеликих оптимізацій можуть помітно знизити навантаження на CPU і пам’ять, покращивши роботу застосунку.

🇺🇦 iOSDevUA

💡Як перевірити, скільки пам’яті доступно застосунку (і як підняти цей ліміт)

Більшість розробників звикли оптимізовувати споживання пам’яті, шліфуючи алгоритми чи прибираючи зайві дані. Але починаючи з iOS 15, Apple додала спеціальний entitlement, який дозволяє підняти стандартний ліміт пам’яті для застосунку на підтримуваних пристроях.

🔧 Entitlement для збільшення ліміту

Apple представила entitlement com.apple.developer.kernel.increased-memory-limit.
Його можна додати в проєкт, якщо деякі ключові функції застосунку критично залежать від більшого обсягу пам’яті. Наприклад, для роботи з великими обсягами медіа чи складними ML-моделями.

Цей entitlement дозволяє перевищувати стандартний ліміт пам’яті, але варто пам’ятати: він діє не на всіх пристроях, а лише на тих, які підтримують таке підвищення.

📊 Як перевірити, скільки пам’яті реально доступно

Щоб дізнатися доступний обсяг пам’яті на конкретному пристрої, можна використати метод
os_proc_available_memory
(попередньо потрібно імпортувати фреймворк os).

Приклад:

import os

let availableMemory = os_proc_available_memory()
print("Available memory: \(availableMemory / 1024 / 1024) MB")

⚠️ Важливі зауваження
• Використовуйте entitlement лише тоді, коли справді є сценарій, який неможливо оптимізувати іншим способом.
• Apple може звернути увагу на його використання під час рев’ю в App Store, тож у описі функцій застосунку варто аргументувати необхідність.
• Це не «чарівна пігулка» — оптимізація споживання пам’яті все одно залишається важливим завданням.

🇺🇦 iOSDevUA

💡Як зробити «піратський» PassKit-застосунок для власного спортзалу

Кумедна історія про те, як автор, трохи занурившись у реверс-інжиніринг, розібрав механізм генерації одноразових QR-кодів для входу в тренажерку.

Замість того щоб щоразу відкривати офіційний застосунок і чекати на завантаження, він:
• написав власний бекенд на Swift, який генерує валідні коди;
• створив PassKit-картку для Apple Wallet, що автоматично підтягує QR-код;
• зекономив собі приблизно 8 секунд щодня на вході до спортзалу.

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

🇺🇦 iOSDevUA

💡Як мігрувати UIKit-застосунок на сценовий життєвий цикл в iOS

Починаючи з iOS 18.4, у консолі для старих проєктів без підтримки сцен можна побачити повідомлення:

This process does not adopt UIScene lifecycle.
This will become an assert in a future version.

А якщо спробувати зібрати застосунок під iOS 26 у бета-версії Xcode, там уже з’являється ще суворіше попередження:

UIScene lifecycle will soon be required.
Failure to adopt will result in an assert in the future.

У наступному мажорному релізі після iOS 26 програми, що не використовують UIScene, більше взагалі не запустяться.

Чому це важливо

Apple переходить на scene-based lifecycle. Це означає:
• жодного запуску без сцени;
• повна підтримка CarPlay, iPad мультивіконності, macCatalyst і майбутніх API лише через UIScene;
• старі AppDelegate-проєкти потрібно адаптувати.

Як перейти на сцени — покроково

1. Додаємо конфіг у Info.plist

<key>UIApplicationSceneManifest</key>
<dict>
    <key>UIApplicationSupportsMultipleScenes</key>
    <false/> 
    <key>UISceneConfigurations</key>
    <dict>
        <key>UIWindowSceneSessionRoleApplication</key>
        <array>
            <dict>
                <key>UISceneConfigurationName</key>
                <string>Default Configuration</string>
                <key>UISceneDelegateClassName</key>
                <string>$(PRODUCT_MODULE_NAME).SceneDelegate</string>
                <key>UISceneStoryboardFile</key>
                <string>Main</string> 
            </dict>
        </array>
    </dict>
</dict>

👉 Для невеликих проєктів зазвичай достатньо однієї сцени. Але для macCatalyst або iPad мультивіконності мультисцени вже must-have.

2. Додаємо конфігурацію сцен у AppDelegate

@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate {
    func application(
        _ application: UIApplication,
        configurationForConnecting connectingSceneSession: UISceneSession,
        options: UIScene.ConnectionOptions
    ) -> UISceneConfiguration {
        
        var configurationName: String!
    
        switch options.userActivities.first?.activityType {
        case UserActivity.GalleryOpenInspectorActivityType:
            configurationName = "Inspector Configuration"
        default:
            configurationName = "Default Configuration"
        }
        
        return UISceneConfiguration(
            name: configurationName,
            sessionRole: connectingSceneSession.role
        )
    }
}

3. Реалізуємо SceneDelegate

import UIKit

class SceneDelegate: UIResponder, UIWindowSceneDelegate {
    var window: UIWindow?
    
    func scene(
        _ scene: UIScene,
        willConnectTo session: UISceneSession,
        options connectionOptions: UIScene.ConnectionOptions
    ) {
        guard let windowScene = scene as? UIWindowScene else { return }
                
        window = UIWindow(windowScene: windowScene)
        window?.rootViewController = YourRootViewController()
        window?.makeKeyAndVisible()
    }
}

Що ще треба врахувати
• Методи з AppDelegate, як-от applicationDidBecomeActive(_), тепер переносяться у SceneDelegate (sceneDidBecomeActive(_) тощо).
• Логіка загалом лишається такою ж, але все прив’язується до сцени, а не до процесу.

📖 Офіційний гайд Apple із порадами та прикладами: TN3187 — Migrating to the UIKit Scene-Based Life Cycle.

🇺🇦 iOSDevUA

🎮 Four Corners: перша гра для Playdate, повністю написана на Swift

У моїй колекції консолей є кілька цікавих екземплярів (наприклад, Game Boy Micro Anniversary Edition, хоч і трохи зношений часом). А серед них — і Playdate, саме вона на фото до цього поста.

📱 Нещодавно з’явилася можливість писати для Playdate на Swift:
🔗 Офіційний анонс.

І от приклад — Four Corners, перша гра на Swift для цієї консолі.

Інтерв’ю зі Стівеном Чіпманом

Я натрапив на цікаву розмову з автором — Стівеном Чіпманом, який поділився як перевагами, так і складнощами під час переписування гри з Lua на Swift.

🔹 Виклики:
• Відсутній Foundation, тому звичних інструментів для роботи з даними немає.
• Немає підтримки Codable, що зробило роботу з JSON доволі складним завданням.
• Налагодження коду виявилось проблемним: якщо застосунок падає в рантаймі, стектрейс недоступний.

🔹 Плюси:
• Swift дозволяє створювати більш структурований код.
• Вища продуктивність і менше багів у порівнянні з Lua.

Чому це важливо

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

📖 Деталі про Four Corners можна почитати у цьому матеріалі.
Рекомендую, якщо вам цікаво, як Swift починає виходити за межі класичного iOS/macOS-світу. 🚀

🇺🇦 iOSDevUA

💡Чи знали ви, що системний UIDatePicker (навіть у «Нагадуваннях» чи «Годиннику») насправді не є нескінченною стрічкою?

У процесі розробки нам усім доводиться мати справу з багами, які QA-відділ відловлює лише в окремих користувачів або за «особливої фази Місяця».

❓ Що ж у такому випадку робить Apple?

✅ Відповідь проста: вони вирішують проблеми для 99,99% користувачів, а не для поодиноких випадків.

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

🇺🇦 iOSDevUA

💡Анатомія AVCaptureSession

У цій статті пояснюється, з яких основних елементів складається сесія захоплення камери (AVCaptureSession), як вони взаємодіють між собою і які класи відповідають за кожен компонент.

Основні елементи AVCaptureSession
• AVCaptureDevice — джерело вхідного сигналу (камера, мікрофон тощо).
• AVCaptureDeviceInput — «обгортка» для підключення пристрою до сесії.
• AVCaptureOutput — вихідний потік (фото, відео, метадані).
• AVCaptureConnection — лінк, що з’єднує input та output, дозволяючи передавати дані.
• AVCaptureSession — центральний керуючий об’єкт, що координує роботу всієї системи.

Як це працює
1. Ініціалізуємо AVCaptureSession.
2. Додаємо AVCaptureDeviceInput (наприклад, камеру).
3. Підключаємо один або кілька AVCaptureOutput (наприклад, фото чи відео).
4. Створюємо AVCaptureConnection, який пов’язує input із конкретним output.
5. Запускаємо сесію, і дані починають передаватися в реальному часі.

Для чого це важливо

Розуміння архітектури AVCaptureSession дозволяє:
• оптимізувати використання камери у застосунку;
• контролювати якість і продуктивність захоплення медіа;
• додавати розширені можливості — від обробки зображень у реальному часі до роботи з метаданими.

Цей матеріал буде особливо корисним розробникам, які працюють над кастомними камерними UI у SwiftUI чи UIKit і хочуть мати більше контролю, ніж пропонують стандартні компоненти. 🚀

🇺🇦 iOSDevUA

📖 Новий реліз Swift AWS Lambda Runtime
💬 Дискусія на Swift Forums

Нещодавно вийшла перша бета другої версії пакета Swift AWS Lambda Runtime, який використовується для запуску Swift-функцій у середовищі AWS Lambda.

Що змінилося порівняно з версією 1.x
🔄 Повністю переписана внутрішня реалізація
🚀 Міграція на Swift Concurrency (async/await), що робить код сучаснішим і безпечнішим

Ключові нові можливості
⚙️ Background execution — підтримка виконання фонового коду
🌊 Streaming responses — тепер можна відправляти дані поступово, а не лише одним блоком
🛠 Інтеграція зі Swift Service Lifecycle (деталі тут) — стандарт для керування життєвим циклом сервісів, який робить застосунки більш передбачуваними й керованими

Висновок

Цей реліз — великий крок уперед для Server-side Swift. Завдяки переходу на Concurrency і підтримці сучасних патернів, Swift у Lambda стає більш продуктивним і ближчим до рівня зрілості інших мов у serverless-екосистемі AWS.

🇺🇦 iOSDevUA

💡Кешування у GitHub Actions — як пришвидшити CI-збірки

Запуск білду на CI часто займає значно більше часу, ніж хотілося б.
Звична картина:
• кілька хвилин завантажуються Ruby-геми,
• ще 5 хвилин SwiftPM підтягує залежності,
• і близько 10 хвилин Xcode збирає весь проєкт.

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

Рішення — кешування на всіх етапах

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

Основні кроки:
1. Кеш Ruby-гемів — щоб не завантажувати їх щоразу.
2. Кеш SwiftPM-залежностей — збереження папки .build для повторного використання.
3. Кеш Xcode Derived Data — економія часу на повторній компіляції.
4. Використання ключів кешу для різних гілок та конфігурацій (щоб уникати конфліктів).

Навіщо це потрібно
• Значне скорочення часу збірки → швидший фідбек від CI.
• Менше витрат при роботі з приватними репозиторіями.
• Оптимізація пайплайнів у великих проєктах.

⚡️ Якщо у вас збірки займають десятки хвилин, кешування в GitHub Actions може стати простим і дуже ефективним апгрейдом.

🇺🇦 iOSDevUA