🇺🇦 iOS Dev UA - спільнота iOS розробників

💡SQLiteData 1.0 від Point-Free — альтернатива SwiftData з CloudKit-синком і шеринґом 📦 GitHub-репозиторій 📖 Великий огляд із прикладами 📚 Документація Основні можливості SQLiteData • Моделі на Swift — створення моделей через звичайні struct і enum. • Типобезпечні запити — гарантія сумісності зі схемою бази даних на етапі компіляції. • Високопродуктивний SQLite-декодер — оптимізований для швидкої роботи з великими обсягами даних. • Аналог @Query у SwiftData — можна використовувати property wrappers, які працюють не тільки в SwiftUI, а й у @Observable-моделях та UIKit-контролерах. • Прямий синхронізатор із CloudKit — для автоматичного оновлення даних між пристроями. • Підтримка iCloud-шеринґу — можливість обміну даними між користувачами. • Побудовано на SQLite — стабільна й перевірена роками технологія. Чому це важливо SQLiteData пропонує знайомий і зрозумілий підхід, але з додатковими можливостями, які раніше були ексклюзивними для SwiftData. Це означає, що розробники отримують: • простішу інтеграцію з існуючими проєктами; • контроль над продуктивністю через SQLite; • зручний синк і шеринг із CloudKit без складних конфігурацій. 🚀 Якщо ви шукали більш прозору й контрольовану альтернативу SwiftData, SQLiteData 1.0 може стати гарним вибором. 🇺🇦 iOSDevUA

💡Як вимкнути Liquid Glass у iOS-додатку при використанні нових SDK у iOS 26 Apple у iOS 26 автоматично вмикає дизайн-систему Liquid Glass, але є спосіб тимчасово відкотитися до старого вигляду. Як це зробити У файл Info.plist потрібно додати ключ:

<key>UIDesignRequiresCompatibility</key>
<true/>

Або ж у Xcode: • Відкрити Info.plist • Додати параметр UIDesignRequiresCompatibility • Встановити його значення у YES Це примусить застосунок працювати з попереднім стилем UI, без Liquid Glass. Важливе застереження Apple вже офіційно повідомила, що ця опція буде прибрана в iOS 27. Тобто UIDesignRequiresCompatibility — це лише тимчасове рішення для підтримки сумісності, яке дозволяє плавно перейти на новий дизайн без термінових переробок. 📖 Детальніше: How to disable Liquid Glass 🇺🇦 iOSDevUA

💡Покрокова візуалізація алгоритму LLM, що лежить в основі ChatGPT Сьогодні хочу поділитися ще одним цікавим ресурсом — цього разу з наочним прикладом. 📖 Є велике інтерактивне керівництво, яке детально пояснює, як працює GPT «під капотом»: дивитися тут. У ньому розглядається мініатюрна модель nano-gpt із лише 85 000 параметрів, що робить пояснення простішим і зрозумілішим. Що саме показано На кожному кроці ви можете простежити, що відбувається всередині нейромережі, коли вона отримує завдання. Для прикладу береться задача:

Вхід: CBABBC Вихід: ABBBCC

Тобто треба відсортувати послідовність літер за алфавітом. Покроково демонструється: • як токенізується вхідна послідовність; • як працюють шари трансформера (self-attention, матриці ваг, активації); • як формується наступний токен на виході; • як модель ітеративно наближається до правильного результату. Чому це варто глянути • Це наочне пояснення LLM, навіть якщо ви не математик і не занурювались глибоко в трансформери. • Допомагає зрозуміти, чому такі моделі працюють саме так, і де у них є обмеження. • Корисний ресурс для студентів, дослідників та розробників, які хочуть інтуїтивно відчути, як працює ChatGPT та подібні системи. 🔗 Переглянути інтерактивне керівництво 🇺🇦 iOSDevUA

💡Що змінилося в роботі зі строками у Swift 6.2 Раніше, якщо ви вставляли в інтерполяцію опціональне значення, компілятор виводив попередження:

String interpolation produces a debug description for an optional value; did you mean to make this explicit?

Приклад:

let age: Int? = nil
print("Your age: \(age)")

У такій ситуації Swift радив явно використовувати String(describing:), аби прибрати warning. Нова можливість у Swift 6.2 У пропозиції SE-0477: Default Value in String Interpolations з’явився зручніший спосіб — тепер можна задати значення за замовчуванням прямо в інтерполяції:

let age: Int? = nil
print("Your age: \(age, default: "missing")")
// Виведе: Your age: missing

Чому це важливо • Код стає чистішим і зрозумілішим, без зайвих обгорток. • Ми уникаємо «nil-протікання» у рядковий вивід. • Підхід є універсальним і працює для будь-яких опціональних типів. ✅ Це невелике, але дуже практичне оновлення, яке зробить роботу з опціональними значеннями у Swift простішою та більш передбачуваною. 🇺🇦 iOSDevUA

🚪Перетворюємо MacBook на «скрипучі двері» за допомогою датчика нахилу (зі звуком) Виявляється, ще з 2019 року в деяких моделях MacBook існує непублічне API, яке дозволяє отримати дані з датчика кута відкривання кришки. Вперше воно з’явилося в MacBook Pro 16’’, і якщо у вас новіший ноутбук — дуже ймовірно, що підтримка також є. Як це працює • API дає змогу відстежувати, під яким кутом відкрита кришка MacBook. • На основі цих даних можна створити будь-який сценарій — наприклад, відтворювати звук скрипучих дверей щоразу, коли ви відкриваєте ноутбук. Де глянути код 📖 У репозиторії LidAngleSensor можна знайти приклад тестового проєкту з реалізацією цієї ідеї. 😅 Виходить кумедний лайфхак: ваш MacBook перетворюється на двері зі звуковим ефектом — і все це завдяки непомітному датчику, про який більшість навіть не здогадувалась. 🇺🇦 iOSDevUA

💡SF Symbols 7: нові анімаційні API У версії SF Symbols 7 Apple представила набір нових інструментів для створення анімацій, які роблять роботу з іконками ще зручнішою: • Draw On / Draw Off — поступове показування або приховування символу штрих за штрихом. • Progress Draw — використання variableValue для анімації контуру символу та відображення прогресу. • Magic Replace — плавніші й інтелектуальні переходи між схожими символами. • Gradients — новий режим рендерингу, що додає глибини та акцентів завдяки градієнтам. ✨ Ці можливості відкривають простий шлях до створення більш динамічного та виразного інтерфейсу у ваших iOS-застосунках. 🇺🇦 iOSDevUA

🎬 Що нового у Swift 6.2 (поза оновленнями, пов’язаними з concurrency) 📺 Є непоганий відео-огляд, присвячений фічам, які з’являться разом з iOS 26 та Xcode 26. Хоча більшість уваги приділяється Concurrency, у Swift 6.2 є й інші цікаві нововведення. Серед них: Основні пропозиції Swift Evolution ➡️ Default Value in String Interpolations - Можливість задавати значення за замовчуванням у рядкових інтерполяціях. ➡️ Raw identifiers - Використання «сирих ідентифікаторів» для зручності в особливих випадках. ➡️ Collection conformances for enumerated() - Тепер enumerated()може напряму відповідати протоколам колекцій. ➡️ InlineArray (fixed-size array) - Новий тип масиву з фіксованим розміром. ➡️ InlineArray Type Sugar - Скорочений синтаксис для роботи з InlineArray. ➡️ Integer Generic Parameters - Можливість використовувати цілі числа як generic-параметри. ➡️ Span: Safe Access to Contiguous Storage - Безпечний доступ до суміжних ділянок пам’яті — альтернатива для небезпечних вказівників. Висновок Swift 6.2 приносить не лише поліпшення для async/await, але й низку зручних, якісних оновлень синтаксису й типів, які роблять код більш безпечним, передбачуваним і компактним. 🇺🇦 iOSDevUA

💡SwiftUI WebView: налаштування, навігація та кастомні схеми На WWDC 2025 Apple анонсувала новий WebView для SwiftUI. Проте код із презентації виявився сирим: він навіть не компілювався. 📖 У цій статті розглядаються: • базова конфігурація WebView; • приклади навігації між сторінками; • робота з JavaScript-функціями прямо зі SwiftUI. 🛠 Код прикладу доступний на GitHub: trozware/swiftui-webview. Це гарний стартовий матеріал, щоб зрозуміти, як WebView інтегрується в SwiftUI, і які є можливості для кастомізації (включно з власними схемами). 🇺🇦 iOSDevUA

💡Як працює ConcentricRectangle API у SwiftUI У iOS 26 Apple нарешті взялася за одну з найдавніших і найболючіших проблем у розробці інтерфейсів — правильне скруглення кутів. Що змінилося До цього розробники часто змушені були використовувати власні рішення з UIBezierPath або різними обходами, щоб отримати очікуваний результат. Тепер же з’явився новий API — ConcentricRectangle, який вирішує проблему «рівних і узгоджених скруглень» на системному рівні. Як це працює • ConcentricRectangle враховує геометрію контейнера, адаптуючи скруглення автоматично. • На відміну від статичного cornerRadius, цей підхід забезпечує коректне відображення навіть у складних ієрархіях в’юшок. • API особливо корисне для toolbar-ів, search bar-ів, sheet-ів та панелей, де системні елементи повинні мати узгоджені скруглення. Чому це важливо • Менше кастомного коду й хакових рішень. • Узгодженість інтерфейсу з новими дизайн-гайдлайнами iOS 26. • Простота інтеграції в існуючі проєкти. 📌 Якщо ви давно стикалися з проблемою некоректних скруглень у SwiftUI, тепер Apple пропонує нарешті рідний, офіційний інструмент для цього. 🇺🇦 iOSDevUA

💡Кешування у GitHub Actions — як пришвидшити CI-збірки Запуск білду на CI часто займає значно більше часу, ніж хотілося б. Звична картина: • кілька хвилин завантажуються Ruby-геми, • ще 5 хвилин SwiftPM підтягує залежності, • і близько 10 хвилин Xcode збирає весь проєкт. Якщо ж ви працюєте з приватними репозиторіями, кожна додаткова хвилина може коштувати грошей. Рішення — кешування на всіх етапах У статті описано, як правильно налаштувати кешування залежностей та проміжних результатів, щоб прискорити збірку в десятки разів. Основні кроки: 1. Кеш Ruby-гемів — щоб не завантажувати їх щоразу. 2. Кеш SwiftPM-залежностей — збереження папки .build для повторного використання. 3. Кеш Xcode Derived Data — економія часу на повторній компіляції. 4. Використання ключів кешу для різних гілок та конфігурацій (щоб уникати конфліктів). Навіщо це потрібно • Значне скорочення часу збірки → швидший фідбек від CI. • Менше витрат при роботі з приватними репозиторіями. • Оптимізація пайплайнів у великих проєктах. ⚡️ Якщо у вас збірки займають десятки хвилин, кешування в GitHub Actions може стати простим і дуже ефективним апгрейдом. 🇺🇦 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

💡Анатомія 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

💡Чи знали ви, що системний UIDatePicker (навіть у «Нагадуваннях» чи «Годиннику») насправді не є нескінченною стрічкою? У процесі розробки нам усім доводиться мати справу з багами, які QA-відділ відловлює лише в окремих користувачів або за «особливої фази Місяця». ❓ Що ж у такому випадку робить Apple? ✅ Відповідь проста: вони вирішують проблеми для 99,99% користувачів, а не для поодиноких випадків. Мораль цієї історії — не варто прагнути безмежної універсальності там, де вона не потрібна. Іноді практичне обмеження — найкраще рішення і для продукту, і для користувачів. 🇺🇦 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

💡Як мігрувати 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

💡Як зробити «піратський» PassKit-застосунок для власного спортзалу Кумедна історія про те, як автор, трохи занурившись у реверс-інжиніринг, розібрав механізм генерації одноразових QR-кодів для входу в тренажерку. Замість того щоб щоразу відкривати офіційний застосунок і чекати на завантаження, він: • написав власний бекенд на Swift, який генерує валідні коди; • створив PassKit-картку для Apple Wallet, що автоматично підтягує QR-код; • зекономив собі приблизно 8 секунд щодня на вході до спортзалу. Вийшов такий собі «неофіційний застосунок» для доступу до залу — приклад того, як технічна цікавість і трохи креативності можуть перетворитися на корисний лайфхак у повсякденному житті. 🚀 🇺🇦 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

💡Контроль та оптимізація процесу декодування зображень в iOS Робота з графікою в iOS часто стає викликом для розробників. Хтось покладається на сторонні бібліотеки, але багато хто намагається оптимізувати процес власноруч — використовуючи доступні API й експериментуючи з підходами. Наприклад, при генерації кадрів для довгих відео можна варіювати довжину кроку залежно від тривалості та якості оригіналу, щоб зменшити навантаження на систему. Три стовпи ефективності Оптимальна робота зображень у iOS базується на балансі: 1. CPU — скільки обчислювальних ресурсів ми витрачаємо. 2. RAM — наскільки ефективно використовуємо оперативну пам’ять. 3. I/O — наскільки правильно організоване кешування й робота із записами на диск. Основні поради зі статті • Переносьте важкі обчислення з головного потоку, щоб уникати фризів і лагів. • Використовуйте попередньо згенеровані прев’ю, коли це можливо. • Зверніть увагу на CVPixelBuffer для оптимізації відео-кадрів. • Використовуйте профілювання, щоб зрозуміти, на якому етапі рендерингу відбувається декодування і в якому потоці. Висновок Робота з декодуванням зображень — це не лише про відображення картинки, а й про баланс продуктивності та плавності UX. Навіть кілька невеликих оптимізацій можуть помітно знизити навантаження на CPU і пам’ять, покращивши роботу застосунку. 🇺🇦 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

💡UDF у SwiftUI без додаткових бібліотек Unidirectional Data Flow (UDF) — простий і зрозумілий архітектурний патерн, для реалізації якого зовсім не обов’язково підтягувати важкі фреймворки на кшталт TCA. Чому це важливо UDF допомагає: • зробити стан застосунку більш передбачуваним; • зменшити кількість прихованих залежностей; • чітко відділити дані, дії та оновлення інтерфейсу. Ключова ідея Навіть без додаткових бібліотек можна побудувати просту UDF-логіку у SwiftUI. Це особливо зручно для окремих фіч, де важлива прозора обробка стану, але цілий фреймворк був би зайвим. Приклад підходу: • створюємо стан у вигляді структури; • описуємо дії (events), які змінюють цей стан; • використовуємо редʼюсер (функцію, що приймає стан і дію та повертає новий стан); • підключаємо це до SwiftUI-в’юшок. Висновок Використання UDF без сторонніх бібліотек — це мінімалістичний і практичний спосіб додати передбачуваність і контроль над станом, не ускладнюючи архітектуру. 🇺🇦 iOSDevUA