🚪Перетворюємо 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

💡Вийшла перша версія 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