💡Реалізація алгоритму для навігації метро Токіо на Swift

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

Основні дані

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

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

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

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

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

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

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

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

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

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

Вийшов перший реліз пакета swift-subprocess, над яким працювали понад два роки.

У чому суть

У скриптах на Swift завжди було непросто працювати з зовнішніми процесами та запускати інші CLI-утиліти. Це створювало серйозні обмеження для тих, хто хотів використовувати Swift як мову для автоматизації чи системних задач.

Що дає swift-subprocess
• Пряме API для запуску сторонніх процесів
• Можливість інтегрувати CLI-утиліти у Swift-скрипти
• Зручні інструменти для роботи з вхідними та вихідними потоками (stdin/stdout/stderr)
• Покращення надійності та читабельності коду замість «костилів»

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

З появою swift-subprocess Swift отримує повноцінний інструмент для:
• написання автоматизаційних скриптів;
• побудови системних утиліт;
• зручного запуску інших інструментів у складі робочих пайплайнів.

🚀 Це робить Swift ще ближчим до мов на кшталт Python чи Ruby у світі скриптингу, зберігаючи при цьому всю його типобезпеку та продуктивність.

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

Актори — один із ключових інструментів Swift Concurrency, що забезпечує ізоляцію стану й безпечний доступ до даних у багатопотоковому середовищі. Але виникає питання: у яких випадках справді варто застосовувати актори?

Ментальна модель

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

Коли це виправдано
🔹 Спільний mutable state: коли кілька тасків чи потоків повинні читати й записувати одні й ті ж дані.
🔹 Моделі даних: наприклад, об’єкт користувача або кеш, який може оновлюватися з різних частин коду.
🔹 Ізоляція складної логіки: коли хочеться інкапсулювати бізнес-логіку в окрему сутність із контролем доступу.
🔹 Асиметричне навантаження: якщо деякі дані змінюються рідко, але до них часто звертаються на читання.
🔹 Заміна ручної синхронізації: коли інакше довелося б використовувати DispatchQueue, NSLock чи інші низькорівневі механізми.

Коли актори не потрібні
• Якщо дані іммутабельні (struct із let властивостями).
• Якщо використовується локальна змінна всередині функції, до якої немає доступу ззовні.
• Якщо достатньо простих TaskLocal або передачі даних через параметри.

Висновок

Актори найкраще застосовувати там, де є ризик гонок даних (data races) і потрібна чиста модель потокобезпеки. У решті випадків можна обійтися простішими інструментами Swift.

✨ Важливо пам’ятати: актори — це не панацея, а інструмент для специфічних сценаріїв, і використовувати їх варто там, де це справді спрощує код.

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

💡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: 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

💡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

💡Імпорт файлів у SwiftUI: робочий приклад

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

Використання системного FileImporter

Для інтеграції можна використати .fileImporter, який відкриває системний діалог і дозволяє користувачу:
• вибирати один або кілька файлів,
• обмежувати формати за типами контенту (UTType),
• керувати імпортом через completion handler.

Приклад реалізації

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

Код прикладу

🛠 Вихідний код проєкту доступний тут: FileImporterDemo.zip. Його можна завантажити, щоб протестувати поведінку в реальному застосунку.


✅ Якщо вам потрібно дати користувачеві зручний і зрозумілий спосіб імпортувати файли у SwiftUI-застосунку, fileImporter — це найпростіший і водночас найнадійніший спосіб.

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

💡Швидкість оновлення на iOS 26

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

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

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

🇺🇦 iOSDevUA

📦 Керуємо симуляторами через CLI

AXe — це консольний тул для керування iOS-симулятором через механізми accessibility. З його допомогою можна емулявати натискання, вводити текст, виконувати жести та багато інших дій прямо з терміналу.

Чому це корисно
• Дозволяє автоматизувати тестування інтерфейсів і поведінки застосунку.
• Підтримує широкий набір команд, які імітують дії користувача.
• Може бути інтегрований у пайплайни CI/CD або використаний для експериментів із AI-агентами, які зможуть самостійно перевіряти роботу вашої апки.

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

🇺🇦 iOSDevUA

💡Реалізація перетягування елементів у SwiftUI

Застосувань цьому механізму безліч: від впорядкування фото в альбомах до побудови таск-менеджера на кшталт Trello.

Підхід із використанням стандартних модифікаторів onDrag та onDrop має низку переваг.

Зокрема, коли нам важлива робота з даними (а не лише візуальне пересування елементів) і коли застосунок оперує складними структурами даних.

📖 У цьому матеріалі — покрокова реалізація на реальному прикладі, яка демонструє, як організувати drag & drop із коректним оновленням моделі.

🇺🇦 iOSDevUA

💡Підтримка автодоповнення в Swift Argument Parser

Swift Argument Parser — бібліотека для створення CLI-утиліт на Swift із зручними механізмами опису вхідних параметрів. І найприємніше: якщо ви вже її використовуєте, майже «задарма» отримуєте автокомпліт команд і їхніх аргументів у терміналі. Це помітно пришвидшує роботу й зменшує кількість помилок у ввідних параметрах.

🇺🇦 iOSDevUA

💡AppMigrationKit — новий фреймворк для перенесення даних на Android

Експансія Apple триває: щойно анонсували фреймворк для експорту даних застосунку на інший пристрій або імпорту з іншої платформи.

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

Поки деталей небагато, але ключові умови вже відомі:
• AppMigrationKit підтримує міграцію лише з/на не-Apple платформи (наприклад, Android).
• Система не використовує фреймворк для перенесення між пристроями iOS чи iPadOS.
• Немає функціональності у додатках iOS, що працюють у visionOS або macOS на Apple silicon.
• Виклики з Mac Catalyst ігноруються.

📖 Інші подробиці — в офіційній документації: https://developer.apple.com/documentation/appmigrationkit.

🇺🇦 iOSDevUA

💡Немає нічого гіршого за Xcode

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

🇺🇦 iOSDevUA

💡Створення кастомних контролів у SwiftUI

У порівнянні з UIKit сьогодні набагато простіше зібрати власний елемент керування — під будь-які потреби.

Джордан Морган пропонує підхід, де кожен контрол має відповідати трьом правилам:

1️⃣ Легко вивчити — якщо взаємодія неочевидна, користувачі нею не користуватимуться.

2️⃣ Запам’ятовуваність — якщо немає сильної причини відходити від системного UI, варто двічі подумати, перш ніж робити своє.

3️⃣ Доступність — елемент має працювати для всіх; якщо це неможливо, можливо, його не слід реалізовувати.

🇺🇦 iOSDevUA