💡Що нового у 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

💡Легка демонстрація «липкого» ефекту в SwiftUI

📖 Мінсан Чой поділився оригінальним підходом до реалізації gooey-ефекту в інтерфейсі — і все це без Metal 😉
Дивитися пост

🛠 Вихідний код доступний на GitHub:
radiofun/gooeyblobs — Gooey.swift.

🇺🇦 iOSDevUA

💡Чому зміна розміру зображень на macOS у 5 разів повільніша, ніж на iOS

Дуже якісне пояснення, чому ресайз через NSImage на macOS займає неприйнятно багато часу, тоді як у симуляторі iOS все працює блискавично. Розбір причин і більш швидких підходів (зокрема через CGImageSource) — всередині.

🇺🇦 iOSDevUA

💡Відтворюємо ефект Apple Intelligence — розбір + код

В новій iOS можна помітити анімований контурний «glow», який динамічно підсвічує форми та компоненти.

📖 У цьому розборі автор пробує відтворити ефект у SwiftUI за допомогою поєднання модифікаторів background і overlay, а також ділиться готовим розширенням:
https://livsycode.com/swiftui/an-apple-intelligence-style-glow-effect-in-swiftui/

🛠 Код доступний тут:
https://github.com/Livsy90/IntelligenceGlow/tree/main

🇺🇦 iOSDevUA

💡Swift Profile Recorder

В екосистемі серверного Swift з’являються нові офіційні інструменти. Цього разу — in-process профілювальник, який просто вбудовується в будь-який сервіс і віддає результати профілювання через cURL-запити. Ідеально для швидкої діагностики продуктивності без складного оверхеду.

🇺🇦 iOSDevUA

💡Кешування зображень у SwiftUI

Ще з iOS 15 з’явився дуже корисний AsyncImage (дозволяє завантажувати картинки без блокування інтерфейсу), але є нюанс: під час швидкого скролу вгору-вниз зображення може завантажуватися повторно.

У таких випадках без кешу не обійтися. Часто бачу, як заради цього підтягують зайві залежності, хоча все значно простіше — особливо, якщо нам достатньо кешу лише в пам’яті (а запис на диск додає не так вже й багато складності).

📖 У цій статті розглянуто базовий, але дієвий підхід із використанням NSCache та його налаштування — чудово підходить для новачків:
https://www.createwithswift.com/image-caching-in-swiftui/

🇺🇦 iOSDevUA