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

💡Розробник iOS-застосунка менеджер рецептів Crouton — поділився списком фіч, створених поверх Foundation Model Framework. І виглядають вони справді корисними: 👉 Автоматичне перетворення рецепта з одного суцільного тексту у структурований список кроків. 👉 Пропозиції релевантних тегів для швидкої категоризації. 👉 Іменовані таймери, які підлаштовуються під конкретний етап приготування. Такі функції чудово ілюструють, як AI може покращити юзерський досвід у повсякденних застосунках — тут не про абстрактні демо, а про практичні можливості, які реально полегшують життя користувача. 🇺🇦 iOSDevUA

💡Швидкість оновлення на iOS 26 TelemetryDeck зробили публічний дашборд, який оновлюється кожні кілька годин і показує динаміку переходу користувачів на нові версії iOS, macOS та watchOS. Головні спостереження •⌚️ Apple Watch оновлюються найшвидше — більшість користувачів переходять на нові версії буквально за перші дні. •📱 iOS тримає стабільно високий темп оновлень, але трохи повільніший, ніж у watchOS. •💻 На macOS ситуація інша — статистика майже не змінюється, темпи оновлення дуже низькі, і можна говорити про певну стагнацію. Це наочно показує, як по-різному користувачі ставляться до оновлень залежно від пристрою: на годинниках — максимальна швидкість, на комп’ютерах — найбільший консерватизм. 🇺🇦 iOSDevUA

💡Якщо ви користуєтесь агентами на кшталт Claude Code для iOS-розробки, варто додати у свій файл Agents.md наступний шлях:

Applications/Xcode-26.0.app/Contents/PlugIns/IDEIntelligenceChat.framework/Versions/A/Resources/AdditionalDocumentation

Для чого це потрібно Цей каталог містить markdown-документацію всіх нових фіч, яку використовує Xcode Intelligence. Завдяки цьому агенти отримають прямий доступ до внутрішніх описів і зможуть: • надавати більш точні відповіді на запити, • використовувати приклади коду з офіційних джерел, • краще пояснювати нові API та можливості. 🚀 Додавання цього шляху у вашого агента допоможе йому працювати так, ніби він «знає» усю офіційну документацію Xcode 26 ізсередини. 🇺🇦 iOSDevUA

💡Імпорт файлів у SwiftUI: робочий приклад У багатьох застосунках може знадобитися можливість роботи з файлами — наприклад, імпортувати документи чи медіа. SwiftUI вже має вбудований системний інтерфейс для цього. Використання системного FileImporter Для інтеграції можна використати .fileImporter, який відкриває системний діалог і дозволяє користувачу: • вибирати один або кілька файлів, • обмежувати формати за типами контенту (UTType), • керувати імпортом через completion handler. Приклад реалізації 📖 У цьому матеріалі розглядається покрокова настройка FileImporter і пояснюється кожен параметр окремо. Там можна побачити, як правильно налаштувати allowedContentTypes та обробити результат вибору. Код прикладу 🛠 Вихідний код проєкту доступний тут: FileImporterDemo.zip. Його можна завантажити, щоб протестувати поведінку в реальному застосунку. ✅ Якщо вам потрібно дати користувачеві зручний і зрозумілий спосіб імпортувати файли у SwiftUI-застосунку, fileImporter — це найпростіший і водночас найнадійніший спосіб. 🇺🇦 iOSDevUA

💡M4 та M4 Pro в Amazon EC2 Amazon додала в свої дата-центри Mac Mini з останньої лінійки процесорів Apple M4 та M4 Pro. Це означає, що тепер у EC2 з’явилися нові Mac-інстанси, які можна використовувати для автоматизації збірок та тестування. Що це дає • Якщо ви вже налаштовуєте CI/CD у хмарі AWS, тепер можете запускати збірки на сучасному «залізі» від Apple. • У порівнянні з попередніми поколіннями, M4 і M4 Pro забезпечують значний приріст у продуктивності. • Це корисно як для великих команд, які будують складні пайплайни, так і для інді-розробників, яким потрібна хмарна інфраструктура під iOS/macOS. 🚀 Тепер ті, хто використовує Amazon EC2 для мобільної розробки, отримають відчутний буст до швидкості збірок і тестів. 🇺🇦 iOSDevUA

💡Основи роботи з пам’яттю в Swift: size, stride, alignment При роботі з низькорівневими API або з бінарними протоколами важливо добре розуміти, як Swift працює з пам’яттю. Часто такі протоколи обирають не лише через компактність у порівнянні з JSON чи XML, а й через ефективність, швидкість обробки та безпеку. Три ключові властивості MemoryLayout У Swift усе зводиться до трьох понять: size, stride і alignment. 1. Size MemoryLayout<T>.size — це кількість байтів, необхідна для збереження одного екземпляра типу T. Але є важливий нюанс:

Розмір не включає в себе динамічно виділену пам’ять. Наприклад, для класу MemoryLayout<T>.size залишиться незмінним, незалежно від того, скільки властивостей чи даних реально збережено.

2. Stride stride — це відстань у байтах від початку одного екземпляра T до початку наступного при зберіганні в безперервному масиві (Array<T>). Іншими словами, stride враховує не лише size, а й можливі додаткові байти для вирівнювання. 3. Alignment alignment — це вимога щодо вирівнювання даних у пам’яті. Деякі типи повинні починатися за певною адресою (наприклад, кратною 4 чи 8), щоб процесор міг ефективно їх читати. Це впливає на зсув (offset) властивостей у структурі й пояснює, чому stride часто більший за size. Приклад

struct Example {
    let a: Int8
    let b: Int32
}

print(MemoryLayout<Example>.size)      // 5
print(MemoryLayout<Example>.stride)    // 8
print(MemoryLayout<Example>.alignment) // 4

• size = 5 → фактично потрібні 5 байтів для збереження даних. • alignment = 4 → через вимогу вирівнювання Int32 (4 байти) структура повинна вирівнюватися по 4. • stride = 8 → наступний об’єкт почнеться з адреси, кратної 8, щоб уникнути помилок доступу. ⸻ 📖 Дуже зрозумілий матеріал з прикладами можна знайти у цій статті. Там на пальцях пояснюється, як працюють size, stride і alignment, і які проблеми можуть виникати через неправильне уявлення про них. 🇺🇦 iOSDevUA

💡Xcode AI Assistant під капотом Автор робить глибокий розбір архітектури, інструментів і обмежень AI-помічника в Xcode, який Apple інтегрувала у версії 26. Що всередині • AI-асистент інтегрований безпосередньо в Xcode та взаємодіє з кодом через системні промпти. • Архітектура побудована так, щоб підтримувати контекстну генерацію коду, тестів і підказок у стилі «copilot». • Є жорсткі обмеження — асистент може працювати тільки в межах тих моделей і API, які вбудовані Apple, що робить його більш контрольованим порівняно з Cursor чи Windsurf. Цікаві деталі Прямо в системних промптах Apple залишає інструкції, які задають стиль відповідей асистента:

“In general, prefer the use of Swift Concurrency (async/await, actors, etc.) over tools like Dispatch or Combine…”

Це означає, що AI-помічник змушений рекомендувати сучасний підхід async/await та actors замість старих інструментів на кшталт GCD чи Combine. А ще:

“In most projects, you can also provide code examples using the new Swift Testing framework that uses Swift Macros.”

Тобто у прикладах коду асистент має орієнтуватися на новий Swift Testing із використанням макросів, а не на XCTest. Висновки • Apple намагається уніфікувати best practices через AI-помічника: користувачі отримуватимуть лише сучасні й рекомендовані патерни. • Це також спосіб підштовхнути спільноту швидше переходити на Swift Concurrency та Swift Testing. • Водночас асистент обмежений у гнучкості — він менш універсальний, ніж сторонні AI-рішення, але краще інтегрований у Xcode. 🇺🇦 iOSDevUA

💡Що нового у Swift for Wasm З моменту офіційного анонсу підтримки WebAssembly на останньому WWDC у проєкті сталося чимало змін. Ключові оновлення 🔄 CI-збірки для Wasm тепер доступні для всіх основних офіційних Swift-пакетів. ⚡️ Embedded Swift Concurrency працює як у CLI-утилітах, так і в застосунках на базі JavaScriptKit. 🛠 Підтримку Wasm інтегровано в LLDB, що дає можливість повноцінного дебагу. 📦 Swift SDK для Wasm тепер включає Foundation, що суттєво спрощує написання багатших застосунків. Статус проєкту За прогресом можна стежити на публічній дошці Swift Project: 👉 GitHub Projects / Swift Wasm Висновок Swift дедалі впевненіше заходить у світ WebAssembly: тепер у розробників є знайомі інструменти (Foundation, Concurrency, LLDB), а також офіційна підтримка збірок. Це робить Swift більш конкурентним варіантом для веб-ігор, CLI-утиліт і навіть UI-фреймворків на Wasm. 🇺🇦 iOSDevUA

💡Коли варто використовувати актори у Swift Concurrency Актори — один із ключових інструментів Swift Concurrency, що забезпечує ізоляцію стану й безпечний доступ до даних у багатопотоковому середовищі. Але виникає питання: у яких випадках справді варто застосовувати актори? Ментальна модель Автор пропонує мислити про актор як про скриньку з даними та чергою повідомлень: усі запити обробляються послідовно, що гарантує безпечний доступ без додаткових локів чи мʼютексів. Коли це виправдано 🔹 Спільний mutable state: коли кілька тасків чи потоків повинні читати й записувати одні й ті ж дані. 🔹 Моделі даних: наприклад, об’єкт користувача або кеш, який може оновлюватися з різних частин коду. 🔹 Ізоляція складної логіки: коли хочеться інкапсулювати бізнес-логіку в окрему сутність із контролем доступу. 🔹 Асиметричне навантаження: якщо деякі дані змінюються рідко, але до них часто звертаються на читання. 🔹 Заміна ручної синхронізації: коли інакше довелося б використовувати DispatchQueue, NSLock чи інші низькорівневі механізми. Коли актори не потрібні • Якщо дані іммутабельні (struct із let властивостями). • Якщо використовується локальна змінна всередині функції, до якої немає доступу ззовні. • Якщо достатньо простих TaskLocal або передачі даних через параметри. Висновок Актори найкраще застосовувати там, де є ризик гонок даних (data races) і потрібна чиста модель потокобезпеки. У решті випадків можна обійтися простішими інструментами Swift. ✨ Важливо пам’ятати: актори — це не панацея, а інструмент для специфічних сценаріїв, і використовувати їх варто там, де це справді спрощує код. 🇺🇦 iOSDevUA

💡Як WebKit поступово переписують із C++ на Swift 📑 Слайди презентації Чому це важливо WebKit — величезна кодова база, яка роками розвивалася повністю на C++. Це серце браузера Safari та безлічі інших систем. Проте одна з найбільших проблем — memory safety: помилки керування пам’яттю (витоки, use-after-free, dangling pointers) залишаються критичним джерелом багів та вразливостей. Чому Swift Swift спочатку розроблявся як безпечна мова: • автоматичне керування пам’яттю (ARC), • типобезпечність, • захист від null pointer dereference, • відсутність undefined behavior у більшості сценаріїв. Тому поступовий перехід частини коду на Swift дозволяє знизити кількість помилок і зробити систему більш надійною. Що вже роблять • Розробники WebKit експериментують із переписуванням окремих модулів на Swift, залишаючи критично важливі частини на C++ (для продуктивності). • Особлива увага приділяється компонентам, де найчастіше виникають memory safety-баги. • Створюються інструменти, які дозволяють C++ і Swift працювати разом у єдиному середовищі. Висновок Цей процес триватиме роками, але він може стати одним із найбільших кейсів інтеграції Swift у світ високонавантажених систем. Це ще раз підкреслює роль Swift не лише в мобільній, а й у системній розробці. 🇺🇦 iOSDevUA

📦 Реліз пакета swift-subprocess Вийшов перший реліз пакета swift-subprocess, над яким працювали понад два роки. У чому суть У скриптах на Swift завжди було непросто працювати з зовнішніми процесами та запускати інші CLI-утиліти. Це створювало серйозні обмеження для тих, хто хотів використовувати Swift як мову для автоматизації чи системних задач. Що дає swift-subprocess • Пряме API для запуску сторонніх процесів • Можливість інтегрувати CLI-утиліти у Swift-скрипти • Зручні інструменти для роботи з вхідними та вихідними потоками (stdin/stdout/stderr) • Покращення надійності та читабельності коду замість «костилів» Чому це важливо З появою swift-subprocess Swift отримує повноцінний інструмент для: • написання автоматизаційних скриптів; • побудови системних утиліт; • зручного запуску інших інструментів у складі робочих пайплайнів. 🚀 Це робить Swift ще ближчим до мов на кшталт Python чи Ruby у світі скриптингу, зберігаючи при цьому всю його типобезпеку та продуктивність. 🇺🇦 iOSDevUA

💡Вийшла перша версія Swift Configuration — нового інструмента від Apple для роботи з конфігураціями 📢 Офіційний анонс на Swift Forums 📦 Приклади на GitHub 📚 Документація з кейсами використання Для чого це потрібно Swift Configuration розроблено насамперед для екосистеми Swift на сервері, де конфігурації часто зчитуються з кількох джерел. Але нова бібліотека стане у пригоді й у CLI-утилітах, і в застосунках, і в бібліотеках, які потребують гнучкого управління налаштуваннями. Основні переваги • Єдиний API для читання конфігурацій у будь-якому Swift-застосунку чи бібліотеці. • Швидкий старт з підтримкою таких джерел, як environment variables, аргументи командного рядка, JSON/YAML та in-memory дані. • Можливість створювати власні провайдери конфігурацій завдяки відкритому протоколу ConfigProvider. Коли це корисно • У серверних застосунках для централізованого керування параметрами. • У CLI-інструментах, де зручно змішувати аргументи командного рядка з іншими джерелами конфігурацій. • У бібліотеках, які хочуть надавати користувачам простий і гнучкий спосіб передавати налаштування. 🚀 Swift Configuration 1.0 робить роботу з конфігами набагато прозорішою й передбачуваною. Це ще один крок до єдиної та зручної інфраструктури для Swift як на сервері, так і в утилітах чи мобільних проєктах. 🇺🇦 iOSDevUA

💡Реалізація алгоритму для навігації метро Токіо на Swift У своєму нестандартному докладі Кріс розповідає не лише про те, як отримати наступні доступні станції в метро, а й про інтеграцію результатів у Dynamic Island. Основні дані Алгоритм працює на основі двох джерел: • статичної інформації від залізничної системи (розклад, структура ліній); • GPS-даних у реальному часі від користувача. Поєднання цих двох типів даних дозволяє визначати актуальні станції та напрями руху. Чому важлива стейт-машина Ключовим компонентом є state machine, яка: • стабілізує результати в умовах шумних GPS-даних; • забезпечує правильне оновлення інтерфейсу; • допомагає уникати «стрибків» між станціями у випадках збоїв у навігації. Додаткові аспекти • Піднімалися питання зберігання даних та їх візуалізації у застосунку. • Продемонстровано, як алгоритм робить результати більш передбачуваними й стабільними навіть у складній транспортній мережі. Де подивитися 🛠 Хоч сам алгоритм не відкритий у публічному доступі (що зрозуміло з міркувань безпеки), Кріс виклав приклади — цілих 5 допоміжних застосунків, які він використовував для збору даних: 👉 GitHub-репозиторій 📖 Докладний розбір: блог Кріса 🎥 Відео виступу: YouTube (версія японською очікується пізніше). ✨ Це чудовий кейс для тих, хто цікавиться embedded Swift, роботою з реальними датчиками та інтеграцією в системні компоненти iOS. 🇺🇦 iOSDevUA

💡AI-friendly документація Apple Однією з найбільших проблем для AI-IDE та агентів є робота з офіційною документацією Apple: вона не відображається без ввімкненого JavaScript, що робить її майже непридатною для автоматизованої обробки. Як вирішує проблему Sosumi Сервіс Sosumi: • конвертує всю документацію Apple у текстовий формат, • надає зручний API для інтеграції з AI-агентами, IDE чи іншими інструментами, • дозволяє працювати з довідкою Apple напряму, без браузера та без JavaScript. Навіщо це потрібно • Спрощує роботу AI-асистентів (на кшталт Claude Code, Copilot чи Cursor) із документацією Apple. • Дозволяє швидко витягувати потрібні описи методів і приклади коду. • Дає можливість робити власні пошукові системи та інтеграції для розробників. ✨ Якщо ви пробували підключати AI до офіційних Apple Docs і стикались із труднощами — Sosumi може стати корисним містком між закритою документацією та AI-інструментами. 🇺🇦 iOSDevUA

💡swift-parca — профілювальник для Server-side Swift 📦 GitHub-репозиторій Що таке swift-parca? swift-parca — це нова бібліотека для continuous profiling серверних застосунків на Swift. Її головна ідея — ви не повинні заздалегідь продумувати, які метрики логувати в продакшні. Усі потрібні події профілювання збираються автоматично. Ключові особливості • Автоматичний збір даних: не потрібно писати додатковий код для логування подій. • Мінімальний overhead: профілювання практично не впливає на продуктивність серверного застосунку. • Безперервний моніторинг: ви отримуєте картину навантаження й продуктивності у реальному часі. • Побудовано для Server-side Swift: інтегрується в сучасні Swift-проєкти без складної конфігурації. Навіщо це потрібно? • Вирішення проблем продуктивності ще до того, як вони стануть критичними. • Спрощена діагностика “вузьких місць” у реальному середовищі. • Зручна інтеграція в CI/CD пайплайни та моніторингові системи. 🚀 Якщо ви працюєте з Server-side Swift, то swift-parca може стати базовим інструментом для підтримки продуктивності у продакшні без складних налаштувань і ризику втратити дані. 🇺🇦 iOSDevUA

💡Розбираємось із Big-O нотацією Big-O нотація — це спосіб описати, як змінюється швидкодія алгоритму залежно від розміру вхідних даних. Вона дозволяє зрозуміти, наскільки ефективним буде ваш код у найгіршому випадку. Основні приклади: • O(1) — постійний час виконання. Приклад: доступ до елемента масиву за індексом. • O(log n) — логарифмічний час. Приклад: бінарний пошук. • O(n) — лінійний час. Приклад: звичайний перебір елементів у циклі. • O(n²) — квадратичний час. Приклад: подвійний цикл для порівняння всіх елементів між собою. Чому це важливо Знання Big-O допомагає: • вибирати ефективні алгоритми та структури даних; • оцінювати, наскільки масштабуватиметься програма; • знаходити «вузькі місця» ще на етапі проєктування, а не після появи проблем на продакшні. ✨ У статті є інтерактивні приклади, де ви можете наочно побачити, як змінюється час виконання при збільшенні кількості даних. Дуже рекомендую для тих, хто хоче швидко й наочно зрозуміти основи алгоритмічної складності. 🇺🇦 iOSDevUA

💡Swift Raw Identifiers у Swift 6.2 📄 Пропозиція Swift Evolution SE-0451 У Swift 6.2 з’явилася нова мовна можливість — raw identifiers. Що це таке? Зазвичай у Swift назви змінних, констант і функцій не можуть: • починатися з цифри, • містити пробіли, • або включати інші заборонені символи. Тепер це можливо, якщо взяти ідентифікатор у лапки. Наприклад:

let `123abc` = "valid now!"
let `user name` = "John"

Де це корисно? 👉 У тестових функціях — тепер можна писати більш зрозумілі назви без додаткових анотацій:

func test(`when user enters invalid email`) { ... }

👉 У enum-ах із числовими або нестандартними значеннями:

enum StatusCode: Int {
    case `200` = 200
    case `404` = 404
}

Чому це важливо • Код стає більш читабельним і близьким до доменної мови (особливо у тестах). • Зменшується потреба у workaround-ах чи спеціальних коментарях. • Це ще один крок до гнучкості синтаксису Swift без шкоди для типобезпеки. ✅ Невелике, але зручне оновлення, яке може спростити життя при написанні тестів чи роботі з нестандартними даними. 🇺🇦 iOSDevUA

💡Шейдер із ефектом скла Щоб поверхня виглядала як справжнє скло, потрібно відтворити чотири ключові ефекти: 1. Відбиття світла — симуляція того, як світло відбивається від поверхні скла. 2. Ефект лінзи — легке збільшення чи викривлення зображення за склом. 3. Тінь — правильне затемнення об’єктів, що перекривають прозорий елемент. 4. Підсвічування країв — створює відчуття товщини та реалістичності скла. У статті розбирається, як реалізувати все це за допомогою шейдерів у Metal, комбінуючи математику заломлення, текстури середовища та ефекти освітлення. ✨ Результат — реалістична поверхня зі справжнім «скляним» виглядом, яку можна застосовувати в UI, іграх чи AR-проєктах. 🇺🇦 iOSDevUA

💡Як використовувати [weak self] у Swift Concurrency Task? У Swift Concurrency питання утримання об’єктів у пам’яті залишається важливим. Використання [weak self] допомагає уникнути циклів сильних посилань і витоків пам’яті, але варто знати кілька нюансів. 🔹 Основи Donny починає з класичних прикладів — використання [weak self] у completion handlers. Це звична практика, яка працює й у Task. 🔹 [weak self] усередині Task Можна одразу розгорнути self, щойно стартує Task:

Task { [weak self] in
    guard let self else { return }
    await self.loadData()
}

Але важливо розуміти, що self може звільнитися ще до виконання коду. 🔹 Проблеми з guard let self на старті Якщо ви робите guard let self на самому початку, то фактично утримуєте сильне посилання всередині Task. Це може суперечити очікуванням: ви подумали, що у вас “weak self”, але насправді отримали strong self у тілі задачі. 🔹 Як уникати strong self Є способи правильно уникнути повторного утримання: • Використовувати weak self у конкретних викликах (await self?.fetch()), замість того щоб робити unwrap один раз на початку. • Для довготривалих задач краще працювати з умовними викликами, щоб Task завершувався, якщо self вже вивантажено. 🔹 Довготривалі Task У завданнях, які тривають довго (наприклад, оновлення даних у фоні), [weak self] допоможе гарантувати, що self не буде утримуватись дарма. Якщо об’єкт знищено, задача просто не виконає подальший код. ✅ Висновок • [weak self] у Task потрібен, щоб уникнути витоків пам’яті. • Не робіть один глобальний unwrap — краще перевіряйте self у потрібних місцях. • Для довгих операцій використовуйте self?, аби безпечно завершати виконання після деалокації об’єкта. Це правило особливо важливе для UI-компонентів, які живуть недовго (наприклад, вью-контролери). 🇺🇦 iOSDevUA

💡OpenAI придбав Alex Sidebar Пам’ятаєте Alex Sidebar — надбудову над Xcode, яка створює досвід, схожий на Cursor для iOS-розробників? OpenAI придбав команду, що стоїть за цим проєктом, і зараз її підключать до розвитку їхнього агента Codex. Існуючі користувачі ще зможуть користуватися Alex Sidebar протягом певного часу, але нові завантаження буде вимкнено. Отже — чи варто чекати глибшої інтеграції Codex прямо в Xcode? Я думаю, що так — це може стати наступним логічним кроком. 🇺🇦 iOSDevUA