💡Чи знали ви, що системний 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

💡Як працює ConcentricRectangle API у SwiftUI

У iOS 26 Apple нарешті взялася за одну з найдавніших і найболючіших проблем у розробці інтерфейсів — правильне скруглення кутів.

Що змінилося

До цього розробники часто змушені були використовувати власні рішення з UIBezierPath або різними обходами, щоб отримати очікуваний результат. Тепер же з’явився новий API — ConcentricRectangle, який вирішує проблему «рівних і узгоджених скруглень» на системному рівні.

Як це працює
• ConcentricRectangle враховує геометрію контейнера, адаптуючи скруглення автоматично.
• На відміну від статичного cornerRadius, цей підхід забезпечує коректне відображення навіть у складних ієрархіях в’юшок.
• API особливо корисне для toolbar-ів, search bar-ів, sheet-ів та панелей, де системні елементи повинні мати узгоджені скруглення.

Чому це важливо
• Менше кастомного коду й хакових рішень.
• Узгодженість інтерфейсу з новими дизайн-гайдлайнами iOS 26.
• Простота інтеграції в існуючі проєкти.

📌 Якщо ви давно стикалися з проблемою некоректних скруглень у SwiftUI, тепер Apple пропонує нарешті рідний, офіційний інструмент для цього.

🇺🇦 iOSDevUA

💡SwiftUI WebView: налаштування, навігація та кастомні схеми

На WWDC 2025 Apple анонсувала новий WebView для SwiftUI. Проте код із презентації виявився сирим: він навіть не компілювався.

📖 У цій статті розглядаються:
• базова конфігурація WebView;
• приклади навігації між сторінками;
• робота з JavaScript-функціями прямо зі SwiftUI.

🛠 Код прикладу доступний на GitHub: trozware/swiftui-webview.

Це гарний стартовий матеріал, щоб зрозуміти, як WebView інтегрується в SwiftUI, і які є можливості для кастомізації (включно з власними схемами).

🇺🇦 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

💡SF Symbols 7: нові анімаційні API

У версії SF Symbols 7 Apple представила набір нових інструментів для створення анімацій, які роблять роботу з іконками ще зручнішою:

• Draw On / Draw Off — поступове показування або приховування символу штрих за штрихом.
• Progress Draw — використання variableValue для анімації контуру символу та відображення прогресу.
• Magic Replace — плавніші й інтелектуальні переходи між схожими символами.
• Gradients — новий режим рендерингу, що додає глибини та акцентів завдяки градієнтам.

✨ Ці можливості відкривають простий шлях до створення більш динамічного та виразного інтерфейсу у ваших iOS-застосунках.

🇺🇦 iOSDevUA

🚪Перетворюємо MacBook на «скрипучі двері» за допомогою датчика нахилу (зі звуком)

Виявляється, ще з 2019 року в деяких моделях MacBook існує непублічне API, яке дозволяє отримати дані з датчика кута відкривання кришки. Вперше воно з’явилося в MacBook Pro 16’’, і якщо у вас новіший ноутбук — дуже ймовірно, що підтримка також є.

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

Де глянути код

📖 У репозиторії LidAngleSensor можна знайти приклад тестового проєкту з реалізацією цієї ідеї.

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

🇺🇦 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

💡Покрокова візуалізація алгоритму LLM, що лежить в основі ChatGPT

Сьогодні хочу поділитися ще одним цікавим ресурсом — цього разу з наочним прикладом.

📖 Є велике інтерактивне керівництво, яке детально пояснює, як працює GPT «під капотом»: дивитися тут. У ньому розглядається мініатюрна модель nano-gpt із лише 85 000 параметрів, що робить пояснення простішим і зрозумілішим.

Що саме показано

На кожному кроці ви можете простежити, що відбувається всередині нейромережі, коли вона отримує завдання. Для прикладу береться задача:

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

Тобто треба відсортувати послідовність літер за алфавітом.

Покроково демонструється:
• як токенізується вхідна послідовність;
• як працюють шари трансформера (self-attention, матриці ваг, активації);
• як формується наступний токен на виході;
• як модель ітеративно наближається до правильного результату.

Чому це варто глянути
• Це наочне пояснення LLM, навіть якщо ви не математик і не занурювались глибоко в трансформери.
• Допомагає зрозуміти, чому такі моделі працюють саме так, і де у них є обмеження.
• Корисний ресурс для студентів, дослідників та розробників, які хочуть інтуїтивно відчути, як працює ChatGPT та подібні системи.

🔗 Переглянути інтерактивне керівництво

🇺🇦 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

💡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

💡OpenAI придбав Alex Sidebar

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

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

Отже — чи варто чекати глибшої інтеграції Codex прямо в Xcode? Я думаю, що так — це може стати наступним логічним кроком.

🇺🇦 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

💡Шейдер із ефектом скла

Щоб поверхня виглядала як справжнє скло, потрібно відтворити чотири ключові ефекти:
1. Відбиття світла — симуляція того, як світло відбивається від поверхні скла.
2. Ефект лінзи — легке збільшення чи викривлення зображення за склом.
3. Тінь — правильне затемнення об’єктів, що перекривають прозорий елемент.
4. Підсвічування країв — створює відчуття товщини та реалістичності скла.

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

✨ Результат — реалістична поверхня зі справжнім «скляним» виглядом, яку можна застосовувати в UI, іграх чи AR-проєктах.

🇺🇦 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

💡Розбираємось із Big-O нотацією

Big-O нотація — це спосіб описати, як змінюється швидкодія алгоритму залежно від розміру вхідних даних. Вона дозволяє зрозуміти, наскільки ефективним буде ваш код у найгіршому випадку.

Основні приклади:
• O(1) — постійний час виконання. Приклад: доступ до елемента масиву за індексом.
• O(log n) — логарифмічний час. Приклад: бінарний пошук.
• O(n) — лінійний час. Приклад: звичайний перебір елементів у циклі.
• O(n²) — квадратичний час. Приклад: подвійний цикл для порівняння всіх елементів між собою.

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

Знання Big-O допомагає:
• вибирати ефективні алгоритми та структури даних;
• оцінювати, наскільки масштабуватиметься програма;
• знаходити «вузькі місця» ще на етапі проєктування, а не після появи проблем на продакшні.

✨ У статті є інтерактивні приклади, де ви можете наочно побачити, як змінюється час виконання при збільшенні кількості даних. Дуже рекомендую для тих, хто хоче швидко й наочно зрозуміти основи алгоритмічної складності.

🇺🇦 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

💡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

У своєму нестандартному докладі Кріс розповідає не лише про те, як отримати наступні доступні станції в метро, а й про інтеграцію результатів у Dynamic Island.

Основні дані

Алгоритм працює на основі двох джерел:
• статичної інформації від залізничної системи (розклад, структура ліній);
• GPS-даних у реальному часі від користувача.

Поєднання цих двох типів даних дозволяє визначати актуальні станції та напрями руху.

Чому важлива стейт-машина

Ключовим компонентом є state machine, яка:
• стабілізує результати в умовах шумних GPS-даних;
• забезпечує правильне оновлення інтерфейсу;
• допомагає уникати «стрибків» між станціями у випадках збоїв у навігації.

Додаткові аспекти
• Піднімалися питання зберігання даних та їх візуалізації у застосунку.
• Продемонстровано, як алгоритм робить результати більш передбачуваними й стабільними навіть у складній транспортній мережі.

Де подивитися

🛠 Хоч сам алгоритм не відкритий у публічному доступі (що зрозуміло з міркувань безпеки), Кріс виклав приклади — цілих 5 допоміжних застосунків, які він використовував для збору даних:
👉 GitHub-репозиторій

📖 Докладний розбір: блог Кріса
🎥 Відео виступу: YouTube (версія японською очікується пізніше).

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

🇺🇦 iOSDevUA