📖 Як у Swift працює мʼютекс — новий Synchronization фреймворк в iOS 18

Починаючи з iOS 18, Apple представила фреймворк Synchronization, який надає зручні засоби синхронізації, включно з мʼютексами, спеціально оптимізованими для роботи з Swift Concurrency.

У статті розглядається:

🔹 як використовувати нові мʼютекси в Swift
🔹 у чому їх переваги порівняно з класичними локами (NSLock, os_unfair_lock)
🔹 чим вони відрізняються від actors
🔹 приклади використання для захисту критичних секцій коду без втрати продуктивності

Це чудова можливість поглибити розуміння сучасної синхронізації в Swift — особливо якщо ви працюєте з async/await і хочете більше контролю над доступом до спільного стану.

🇺🇦 iOSDevUA

💡LLM Leaderboard — порівняння понад 100 AI‑моделей від OpenAI, Google, DeepSeek та інших

Корисний ресурс, де зібрано більше 100 великих мовних моделей (LLM) із порівнянням за ключовими характеристиками:

🔹 ціна за токен
🔹 швидкість генерації (токени/секунда)
🔹 затримка відповіді (TTFT)
🔹 обсяг контекстного вікна
🔹 продуктивність у бенчмарках

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

Ідеальний інструмент для розробників, які хочуть обирати модель не за брендом, а за фактичними метриками.

🇺🇦 iOSDevUA

💡Threads vs Tasks у Swift Concurrency — у чому різниця?

Як зазначає Антуан у своїй статті, багато розробників, особливо ті, хто працював зі Swift або Objective‑C з використанням GCD, можуть задуматися:
у чому різниця між потоками (threads) і задачами (tasks)?

Раніше ми звикли до “потокового мислення”, що допомагало створювати асинхронні функції з замиканнями.
Але з появою Swift Concurrency і async/await усе змінюється:
тепер достатньо написати Task { ... }, щоби запустити код в асинхронному контексті — без явного керування потоками.

❓ Та виникає логічне питання:
а де саме виконується Task — в основному чи у фоновому потоці?

У статті розглядаються:

🔹 ключові відмінності між Task і Thread
🔹 як Swift сам керує плануванням задач
🔹 чому Task — це не потік у класичному розумінні
🔹 як уникнути поширених помилок і хибних уявлень

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

🇺🇦 iOSDevUA

💡let чи var у структурах Swift — як обирати правильно

У цьому матеріалі Джон Санделл аналізує, коли варто використовувати var, а коли — let для властивостей у структурах.

🔍 Основна думка:
— за замовчуванням краще використовувати var,
— а let — тільки там, де справді потрібна фіксована, незмінна властивість, яка має очевидне смислове навантаження.

Такий підхід спрощує масштабування коду й дозволяє уникнути зайвих обмежень, які можуть ускладнити рефакторинг.

✅ Якщо хочете краще зрозуміти принципи проєктування чистих Swift-структур — цей текст варто додати в закладки.

🇺🇦 iOSDevUA

💸 Яка середня зарплата мобільного розробника у світі — дані з опитування StackOverflow

StackOverflow опублікував щорічний звіт за результатами опитування розробників. Окрім традиційних питань про стек, досвід і зарплати, цього року багато уваги приділено темі AI.

📌 Цікаво:
— Третина розробників вже регулярно використовує AI‑асистентів
— Але лише 3.1% повністю довіряють їхнім відповідям

💸 Що до зарплат мобільних розробників (брутто, до податків):
• 🇺🇸 США — $170 000/рік
• 🇬🇧 Велика Британія — $99 383/рік
• 🇩🇪 Німеччина — $93 972/рік
• 🇫🇷 Франція — $63 228/рік
• 🇮🇳 Індія — $10 462/рік

У середньому по всіх країнах зафіксовано зростання на 20% у порівнянні з 2024 роком.

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

🇺🇦 iOSDevUA

💡SwiftUI та розробка для macOS 26 — що нового?

Хоча більшість розробників не створює окремі таргети під macOS, є чимало застосунків, для яких Mac — основна платформа. І саме для них оновлення SwiftUI в macOS 26 буде особливо цікавим.

У матеріалі розглянуто ключові нововведення та приклади використання:

🔹 Оновлений підхід до App Icon — із прикладом використання Icon Composer
🔹 Нові стилі контролів
🔹 Робота з WebView
🔹 Підтримка Rich Text
🔹 Обробка великих списків
🔹 Меню з іконками
🔹 Concurrency у SwiftUI на Mac
🔹 Тулбари і кастомізація

🛠 А ще весь приклад коду доступний на GitHub — чудовий ресурс для тих, хто хоче спробувати нові можливості вже зараз.
👉 GitHub-демо проєкту

🇺🇦 iOSDevUA

💡Невелика CLI-утиліта для оптимізації зображень у вашому iOS‑проєкті

Ця проста у використанні командна тулза допоможе навести лад у ресурсах проєкту — особливо в розділі зображень. Автор описує її призначення так:

Виявляти невикористані зображення, перевіряти відповідність вимогам Apple і надавати чіткі рекомендації для покращення продуктивності застосунку та шансів проходження рев’ю в App Store.

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

🇺🇦 iOSDevUA

💡Swift-Erlang Actor System — об’єднання акторів Swift та Erlang у єдину розподілену систему

Після обговорень Java та Haskell — настала черга Erlang. Нова бібліотека дає змогу Swift‑застосункам підключатися до розподілених Erlang-кластерів.

🔗 Що це означає на практиці:

— актори, написані на Swift, можуть вільно спілкуватися з Erlang-акторами
— ви можете надсилати повідомлення, викликати функції, обробляти відповіді
— усе це — в межах єдиної розподіленої системи, незалежно від мови

Це справжній прорив для тих, хто хоче будувати розподілені системи або інтегрувати Swift у наявну інфраструктуру на Erlang/Elixir.
Акторна модель стає по-справжньому міжмовною.

🇺🇦 iOSDevUA

💡Combine та Swift Concurrency — як поєднувати, мігрувати і не наламати

У матеріалі розглядається, як правильно поєднувати Combine та Swift Concurrency, а також які можуть виникнути проблеми з потоками, якщо зробити це некоректно.

🔀 Основні теми:

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

Корисний розбір для команд, які переходять на Swift Concurrency, але ще мають велику кодову базу на Combine.

🇺🇦 iOSDevUA

💡Жахи вайб-кодингу — коли AI не рятує, а ламає

Схоже, що вайб-кодинг (коли код пишеться «на натхненні» разом з AI) дуже швидко пережив пік свого гіпу — і дедалі більше розробників починає усвідомлювати: одних промптів замало.

Ось декілька яскравих прикладів, чому сліпа довіра до AI може мати критичні наслідки:

👉 Replit випадково видалив усю продову базу знань без можливості відновлення
👉 Увесь список очікування був збережений… на фронтенді
👉 Класичний кейс: AI згенерував застосунок із десятками вразливостей

🤖 Moral of the story: AI — чудовий інструмент, але він не замінює розробника, який думає, аналізує й перевіряє.

🇺🇦 iOSDevUA

💡Як створювати зручні CLI-інтерфейси на Swift — практичні прийоми

Якщо ви працюєте зі Swift‑утилітами для терміналу, ця добірка порад допоможе зробити інтерфейс не лише функціональним, а й приємним у використанні.

У статті розглядаються такі техніки:

👉 Як визначити поточний розмір вікна терміналу й адаптувати інтерфейс під нього
👉 Як видаляти надруковані символи, щоб реалізовувати прості анімації в консолі
👉 Як сховати курсор, коли він заважає візуально
👉 Як слухати сигнали про зміну розміру вікна чи переривання виконання

🛠 Корисно для всіх, хто створює CLI‑інструменти або хоче додати трохи “живості” у свій термінальний досвід на Swift.

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

🔎 Як змінився пошук у SwiftUI в iOS 26

У iOS 26 та iPadOS 26 Apple трохи оновила поведінку пошуку в SwiftUI — як у toolbar, так і в tab bar. Більшість змін — косметичні, але є й нові можливості в API.

Основні оновлення
• Покращений вигляд поля пошуку — адаптивна анімація й оновлений стиль інтеграції в панель інструментів і вкладок.
• Нове API для кастомізації — тепер можна зробити так, щоб у неактивному стані поле пошуку перетворювалося на кнопку, яка відкриває пошук при натисканні.
• Краща інтеграція з системними патернами — поведінка пошуку тепер більш узгоджена з новими гайдлайнами iOS 26.

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

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

💡Як обійти автоматичне приховування даних у логах macOS

Коли ви виводите в консоль macOS дебажні повідомлення, Apple автоматично приховує частину інформації задля забезпечення приватності.
Замість реальних значень (наприклад, шляхів до файлів, вставлених рядків чи UUID) система підставляє тег <private>.

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

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

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

📦 Bazel + iOS + VS Code — сервер збірки від Spotify

Spotify випустили сервер збірки, який дозволяє розробляти iOS-застосунки з Bazel у будь-якому редакторі, що підтримує LSP (Language Server Protocol).

Що працює прямо зараз
• Індексація проєкту — швидкий пошук та автодоповнення
• Навігація по коду — перехід до визначень і пошук використань
• Складання та запуск застосунків
• Дебаг через lldb

Це відкриває можливість працювати з iOS-кодом у VS Code або інших редакторах, не прив’язуючись до Xcode, але зберігаючи всі ключові можливості для продуктивної розробки.

Чудове рішення для тих, хто хоче поєднати Bazel та кросредакторський підхід у мобільній розробці.

🇺🇦 iOSDevUA

🔐 Захист iOS-застосунку сьогодні — це значно більше, ніж просто складний пароль

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

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

Також розглядається, як убезпечнити застосунок відповідно до стандарту OWASP MASVS (Mobile Application Security Verification Standard) — від мережевих запитів і шифрування до виявлення джейлбрейку та захисту від реверс-інжинірингу.

👉 Читати статтю
👉 Swift-бібліотека для безпеки iOS-застосунків — SecurityKit на GitHub

🇺🇦 iOSDevUA

💡Підтримка OpenRouter у Xcode

OpenRouter — це платформа, яка надає доступ до більшості великих мовних моделей (LLM) через єдиний API і спільну систему токенів.
Завдяки цьому немає потреби окремо налаштовувати підключення до кожної моделі — все працює через один інтерфейс.

Тепер ви можете викликати API OpenRouter прямо з Xcode, що спрощує інтеграцію AI-асистентів у процес розробки. Це означає, що будь-яку підтримувану модель можна підключити до вашого робочого середовища без додаткових конфігурацій та зайвих ключів для кожного провайдера.

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

💡Global actor у Swift Concurrency на практичних прикладах

ℹ️ У Swift Concurrency з’явилась концепція глобального актора, яка використовується разом із async/await та задачами.

Найвідоміший приклад — @MainActor, який забезпечує виконання коду в головному потоці. Докладніше про нього можна почитати тут.

Але Swift також дозволяє створювати власні глобальні актори.

Що таке глобальний актор?

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

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

Де це корисно?
• Централізоване керування доступом до спільних ресурсів
• Ізоляція важливих операцій (наприклад, доступу до бази даних або файлів)
• Побудова потокобезпечних API без необхідності вручну синхронізувати доступ

📖 У статті Avanderlee розглядається:
• як правильно створювати глобальні актори;
• як використовувати їх у коді;
• типові помилки та як їх уникати.

🇺🇦 iOSDevUA