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

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

💡Чим поганий TextKit 2 — досвід Марціна Кшижановскі Marcin Krzyzanowski — один із найвідоміших експертів із роботи з текстом в iOS, а також мейнтейнер бібліотеки STTextView. За роки використання TextKit 2 він зібрав велику кількість проблем і поділився ними у своєму блозі. Основні проблеми TextKit 2 • Нестабільність: багато методів працюють непослідовно, а іноді й зовсім ламаються в різних сценаріях. • Документація: відчутний брак зрозумілих прикладів і пояснень, через що розробникам доводиться здогадуватись, як правильно використовувати API. • Зворотна сумісність: перехід із TextKit 1 виявляється складним і не завжди виправданим. • Обмеженість функціоналу: чимало можливостей, які здавалися очевидними, доводиться реалізовувати вручну. Висновки За словами Марціна, хоча TextKit 2 і був представлений як “нова обітована земля” для роботи з текстом у iOS, на практиці він виявився сирим і проблемним інструментом. Багатьом командам доводиться шукати обхідні рішення або навіть залишатися на старому TextKit 1. Цей розбір буде особливо корисним тим, хто планує працювати з великими обсягами тексту в iOS і вагається, чи варто переходити на TextKit 2. 🇺🇦 iOSDevUA

💡Додаток від творців SwiftUI, який дозволяє писати код прямо на iPhone та публікувати його у TestFlight Bitrig — це новий застосунок, який створює нативні Swift-апки за допомогою AI-асистента. Як це працює • Ви описуєте, яке застосунок хочете отримати. • AI генерує код і збирає апку. • У результаті — можна одразу залити проєкт у TestFlight без складних налаштувань. 🛠 Спробувати можна вже зараз: Bitrig у App Store (доступно 5 запитів без підписки). Чому це особливо цікаво Розробкою займаються люди, які безпосередньо працювали над SwiftUI у Apple, тому можна очікувати якісну інтеграцію. Приклад результату — простий погодний застосунок: код доступний тут. Моє бачення Хайп, ймовірно, спаде, особливо якщо великі AI-гравці додадуть подібні можливості у свої IDE. Але сама ідея створювати й тестувати апки прямо на iPhone виглядає захопливою й відкриває нові сценарії для експериментів. 🚀 Bitrig може стати тим інструментом, що зробить розробку мобільних застосунків ще доступнішою для новачків і швидшою для досвідчених девелоперів. 🇺🇦 iOSDevUA

💡Переходимо з Xcode у Zed Zed — відносно новий редактор коду, який на відміну від більшості конкурентів не є форком VS Code. Він написаний повністю на Rust і його головна перевага — швидкість і легковажність: Zed працює блискавично навіть на великих проєктах. Що можна робити в Zed для iOS/macOS-розробки У статті розглядається, як замінити Xcode в більшості щоденних задач: • Редагування Swift-коду з підсвічуванням синтаксису та автодоповненням. • Дебаг застосунків через інтеграцію з LLDB. • Запуск і складання iOS/macOS-проєктів. • Використання Bazel та інших тулів для керування збірками. Чому це цікаво • Zed дозволяє працювати у знайомому середовищі, але з відчутно більшою продуктивністю. • Він не перевантажений зайвими функціями, як Xcode, і більше нагадує «чистий редактор» із можливістю тонкої кастомізації. • Спільнота активно додає плагіни й інтеграції, у тому числі для Swift. 🚀 Якщо ви шукали легкий і сучасний редактор для роботи зі Swift поза Xcode, Zed може стати гарною альтернативою. 🇺🇦 iOSDevUA

💡Як працювати зі SwiftData у фоновому режимі в Swift 6 Це може стати в пригоді у багатьох сценаріях — наприклад, при інтеграції з новими LLM API, коли потрібно зберігати відповіді чи проміжні результати у вже наявні моделі SwiftData. 📖 У цьому матеріалі наведено приклад того, як адаптувати існуючий проєкт для роботи з фонoвими задачами. Спойлер: усе набагато простіше, ніж може здатися на перший погляд. Ключові моменти: • Використання background context для уникнення блокування UI. • Робота з асинхронними операціями збереження, щоб дані записувались без шкоди для продуктивності. • Інтеграція з Task та async/await для зручного керування операціями у фонових потоках. Таким чином можна створювати застосунки, які залишаються відзивчивими, навіть коли відбувається масове збереження або оновлення даних у SwiftData. 🇺🇦 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

💡Великий огляд усіх змін у UIKit в iOS 26 Кілька місяців тому багато великих iOS-ресурсів поширювали чутки про те, що UIKit (і зокрема UIApplicationDelegate) збираються депрекейтити. Як це часто буває — жодних підтверджень не було. Після WWDC стало зрозуміло, що на практиці все інакше: UIKit нікуди не зникає, і найближчим часом ми ще активно ним користуватимемось. Себ Відаль підготував детальний розбір, над яким працював кілька тижнів. 📖 У своєму пості він розглядає: • UIBackgroundExtensionView — новий API для роботи з розширенням фону. • UICornerConfiguration — нарешті офіційне рішення для скруглень, яке замінить кастомні реалізації з UIBezierPath. • Зміни в UIResponder — нові можливості для роботи з відповідями на події. • Оновлення в UIScrollView — покращення поведінки скролу та візуальних ефектів. • Та інші дрібні, але важливі зміни, які вплинуть на розробку. 🔗 Раджу зберегти пост «What’s new in UIKit 26» у закладки, адже реліз iOS 26 вже зовсім скоро. 🇺🇦 iOSDevUA

💡Global actor у Swift Concurrency на практичних прикладах ℹ️ У Swift Concurrency з’явилась концепція глобального актора, яка використовується разом із async/await та задачами. Найвідоміший приклад — @MainActor, який забезпечує виконання коду в головному потоці. Докладніше про нього можна почитати тут. Але Swift також дозволяє створювати власні глобальні актори. Що таке глобальний актор? Глобальний актор забезпечує таку ж ізоляцію даних, як і звичайний актор (тобто безпечний, послідовний доступ до ресурсу), але з однією ключовою відмінністю: він прив’язаний не до конкретного екземпляра, а до більш широкого контексту — наприклад, до функції, властивості чи навіть цілого типу. Це означає, що весь код, анотований певним глобальним актором, виконуватиметься в одному визначеному контексті, незалежно від того, звідки його викликають. Де це корисно? • Централізоване керування доступом до спільних ресурсів • Ізоляція важливих операцій (наприклад, доступу до бази даних або файлів) • Побудова потокобезпечних API без необхідності вручну синхронізувати доступ 📖 У статті Avanderlee розглядається: • як правильно створювати глобальні актори; • як використовувати їх у коді; • типові помилки та як їх уникати. 🇺🇦 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

💡Підтримка OpenRouter у Xcode OpenRouter — це платформа, яка надає доступ до більшості великих мовних моделей (LLM) через єдиний API і спільну систему токенів. Завдяки цьому немає потреби окремо налаштовувати підключення до кожної моделі — все працює через один інтерфейс. Тепер ви можете викликати API OpenRouter прямо з Xcode, що спрощує інтеграцію AI-асистентів у процес розробки. Це означає, що будь-яку підтримувану модель можна підключити до вашого робочого середовища без додаткових конфігурацій та зайвих ключів для кожного провайдера. 🇺🇦 iOSDevUA

🔐 Захист iOS-застосунку сьогодні — це значно більше, ніж просто складний пароль Для надійної безпеки потрібен багаторівневий захист, що охоплює мережеву взаємодію, зберігання даних, автентифікацію та безпеку під час виконання коду. 🔥 У цій статті я ділюся перевіреними практиками, зручними для розробників інструментами та техніками, які допоможуть створити застосунок, що буде не лише функціональним, а й справді захищеним. Також розглядається, як убезпечнити застосунок відповідно до стандарту OWASP MASVS (Mobile Application Security Verification Standard) — від мережевих запитів і шифрування до виявлення джейлбрейку та захисту від реверс-інжинірингу. 👉 Читати статтю 👉 Swift-бібліотека для безпеки iOS-застосунків — SecurityKit на GitHub 🇺🇦 iOSDevUA

📦 Bazel + iOS + VS Code — сервер збірки від Spotify Spotify випустили сервер збірки, який дозволяє розробляти iOS-застосунки з Bazel у будь-якому редакторі, що підтримує LSP (Language Server Protocol). Що працює прямо зараз • Індексація проєкту — швидкий пошук та автодоповнення • Навігація по коду — перехід до визначень і пошук використань • Складання та запуск застосунків • Дебаг через lldb Це відкриває можливість працювати з iOS-кодом у VS Code або інших редакторах, не прив’язуючись до Xcode, але зберігаючи всі ключові можливості для продуктивної розробки. Чудове рішення для тих, хто хоче поєднати Bazel та кросредакторський підхід у мобільній розробці. 🇺🇦 iOSDevUA

💡Perception 2.0 — оновлений бекпорт Observation framework Півтора року тому Point-Free випустили бібліотеку Perception — бекпорт Observation framework для всіх версій iOS, починаючи з iOS 13. Це дозволило використовувати сучасний реактивний підхід до відстеження змін навіть у проєктах, що підтримують старі системи. На цьому тижні вийшла новa мажорна версія — Perception 2.0. Що нового Найголовніше оновлення — бекпорт нової функціональності Observations із Swift 6.2 📄 Пропозиція SE-0475: @Observed Це означає, що розробники тепер можуть: • використовувати найсвіжіші можливості Observation на старих iOS • отримати більш передбачуване та ефективне відстеження змін • зменшити кількість бойлерплейт-коду в SwiftUI-проєктах 🇺🇦 iOSDevUA

💡Як обійти автоматичне приховування даних у логах macOS Коли ви виводите в консоль macOS дебажні повідомлення, Apple автоматично приховує частину інформації задля забезпечення приватності. Замість реальних значень (наприклад, шляхів до файлів, вставлених рядків чи UUID) система підставляє тег <private>. У статті пояснюється: • як macOS визначає, яку саме інформацію прибрати • які правила приватності застосовуються до логів • як обійти ці обмеження, якщо вам потрібні повні дані під час відлагодження Цей матеріал буде корисним розробникам, яким важливо бачити повний вміст логів під час тестування, але при цьому варто пам’ятати про ризики витоку чутливої інформації при вимкненні таких захистів. 🇺🇦 iOSDevUA

💡Full-stack Swift: гібридний застосунок із Vapor на сервері та SwiftUI+Observation на клієнті Technicolor — сайд-проєкт Кріса Тротта, над яким він працює вже понад 10 років. Спочатку це був Ruby on Rails-додаток, що працював лише у браузері, а тепер — повноцінний Swift-on-server із нативним клієнтом для пристроїв Apple. Що описано у статті Кріс поділився досвідом переходу на повний стек Swift і описав ключові частини архітектури: • Огляд архітектури • Shared API-шар • Серверна частина на Vapor та його плюси/мінуси • Аутентифікація, сервіси та тестування • Клієнтська частина на SwiftUI + Observation: налаштування проєкту, робота з API та внутрішня архітектура Висновок автора Попри те, що йому вдалося збудувати весь стек на Swift, Кріс вважає, що Swift як серверна мова поки що не є найпрагматичнішим вибором. Його переваги не перекривають відставання від великих веб-фреймворків за шириною екосистеми та готовими інструментами. 🇺🇦 iOSDevUA

🔎 Як змінився пошук у SwiftUI в iOS 26 У iOS 26 та iPadOS 26 Apple трохи оновила поведінку пошуку в SwiftUI — як у toolbar, так і в tab bar. Більшість змін — косметичні, але є й нові можливості в API. Основні оновлення • Покращений вигляд поля пошуку — адаптивна анімація й оновлений стиль інтеграції в панель інструментів і вкладок. • Нове API для кастомізації — тепер можна зробити так, щоб у неактивному стані поле пошуку перетворювалося на кнопку, яка відкриває пошук при натисканні. • Краща інтеграція з системними патернами — поведінка пошуку тепер більш узгоджена з новими гайдлайнами iOS 26. Ці зміни не ламають наявний код, але дають більше контролю над UX, особливо в застосунках з багатьма точками пошуку. 🇺🇦 iOSDevUA

💡FoundationModels Framework та приклад створення застосунку з підтримкою зовнішніх LLM-провайдерів У Xcode 26 Beta 4 з’явилася нова опція GeneratedContent, яка дозволяє передавати JSON-відповіді від зовнішніх LLM-провайдерів — таких як OpenAI, Anthropic, Gemini та інші. Хоча FoundationModels дає змогу використовувати AI-можливості безпосередньо на пристрої, обмеження вбудованої моделі (не надто великий список підтримуваних мов і відносно мале вікно контексту) роблять її недостатньою для багатьох сценаріїв. Тому чимало застосунків і надалі покладатимуться на зовнішні LLM-API. 📖 У детальному гайді показано, як створити застосунок, що: • дозволяє обрати компанію зі списку для отримання звітності; • встановлює часовий діапазон даних; • дає можливість ставити додаткові запитання до моделі. 🛠 Код прикладу доступний на GitHub: FinancialAnalyst — для роботи потрібні Xcode Beta 4, а також останні версії macOS та iOS. Цей підхід дає змогу комбінувати локальний AI з потужними зовнішніми моделями, отримуючи баланс між приватністю, швидкодією та якістю результату. 🇺🇦 iOSDevUA

💡Як створювати зручні CLI-інтерфейси на Swift — практичні прийоми Якщо ви працюєте зі Swift‑утилітами для терміналу, ця добірка порад допоможе зробити інтерфейс не лише функціональним, а й приємним у використанні. У статті розглядаються такі техніки: 👉 Як визначити поточний розмір вікна терміналу й адаптувати інтерфейс під нього 👉 Як видаляти надруковані символи, щоб реалізовувати прості анімації в консолі 👉 Як сховати курсор, коли він заважає візуально 👉 Як слухати сигнали про зміну розміру вікна чи переривання виконання 🛠 Корисно для всіх, хто створює CLI‑інструменти або хоче додати трохи “живості” у свій термінальний досвід на Swift. 🇺🇦 iOSDevUA

💡Жахи вайб-кодингу — коли AI не рятує, а ламає Схоже, що вайб-кодинг (коли код пишеться «на натхненні» разом з AI) дуже швидко пережив пік свого гіпу — і дедалі більше розробників починає усвідомлювати: одних промптів замало. Ось декілька яскравих прикладів, чому сліпа довіра до AI може мати критичні наслідки: 👉 Replit випадково видалив усю продову базу знань без можливості відновлення 👉 Увесь список очікування був збережений… на фронтенді 👉 Класичний кейс: AI згенерував застосунок із десятками вразливостей 🤖 Moral of the story: AI — чудовий інструмент, але він не замінює розробника, який думає, аналізує й перевіряє. 🇺🇦 iOSDevUA

💡Combine та Swift Concurrency — як поєднувати, мігрувати і не наламати У матеріалі розглядається, як правильно поєднувати Combine та Swift Concurrency, а також які можуть виникнути проблеми з потоками, якщо зробити це некоректно. 🔀 Основні теми: — як поступово мігрувати з Combine на async/await — у яких випадках можна безпечно використовувати обидва підходи одночасно — які ризики виникають при змішуванні потоків (особливо з receive(on:) у Combine) — чому Task у Swift Concurrency не гарантує, що ви опинитесь у потрібному потоці Корисний розбір для команд, які переходять на Swift Concurrency, але ще мають велику кодову базу на Combine. 🇺🇦 iOSDevUA