iOS Broadcast
Kanalga Telegram’da o‘tish
Подборка новостей и статей для iOS разработчиков. Новости Kotlin и мультиплатформы @kotlin_broadcast Новости Android @android_broadcast Реклама и прочее @ab_manager
Ko'proq ko'rsatish3 516
Obunachilar
Ma'lumot yo'q24 soatlar
+27 kunlar
-1130 kunlar
Ma'lumot yuklanmoqda...
O'xshash kanallar
Taglar buluti
Kirish va chiqish esdaliklari
---
---
---
---
---
---
Obunachilarni jalb qilish
Iyul '26
Iyul '26
+20
1 kanalda
Iyun '26
+25
1 kanalda
Get PRO
May '26
+36
1 kanalda
Get PRO
Aprel '26
+42
1 kanalda
Get PRO
Mart '26
+96
1 kanalda
Get PRO
Fevral '26
+55
1 kanalda
Get PRO
Yanvar '26
+43
1 kanalda
Get PRO
Dekabr '25
+35
1 kanalda
Get PRO
Noyabr '25
+109
2 kanalda
Get PRO
Oktabr '25
+59
1 kanalda
Get PRO
Sentabr '25
+114
2 kanalda
Get PRO
Avgust '25
+51
0 kanalda
Get PRO
Iyul '25
+37
0 kanalda
Get PRO
Iyun '25
+69
1 kanalda
Get PRO
May '25
+41
0 kanalda
Get PRO
Aprel '25
+60
1 kanalda
Get PRO
Mart '25
+59
2 kanalda
Get PRO
Fevral '25
+76
1 kanalda
Get PRO
Yanvar '25
+119
2 kanalda
Get PRO
Dekabr '24
+71
2 kanalda
Get PRO
Noyabr '24
+78
2 kanalda
Get PRO
Oktabr '24
+103
2 kanalda
Get PRO
Sentabr '24
+70
3 kanalda
Get PRO
Avgust '24
+83
1 kanalda
Get PRO
Iyul '24
+89
1 kanalda
Get PRO
Iyun '24
+108
2 kanalda
Get PRO
May '24
+180
3 kanalda
Get PRO
Aprel '24
+142
4 kanalda
Get PRO
Mart '24
+100
0 kanalda
Get PRO
Fevral '24
+171
4 kanalda
Get PRO
Yanvar '24
+176
4 kanalda
Get PRO
Dekabr '23
+185
2 kanalda
Get PRO
Noyabr '23
+137
6 kanalda
Get PRO
Oktabr '23
+106
5 kanalda
Get PRO
Sentabr '23
+105
0 kanalda
Get PRO
Avgust '23
+89
0 kanalda
Get PRO
Iyul '23
+199
0 kanalda
Get PRO
Iyun '23
+78
0 kanalda
Get PRO
May '23
+131
0 kanalda
Get PRO
Aprel '23
+127
0 kanalda
Get PRO
Mart '23
+56
0 kanalda
Get PRO
Fevral '23
+57
0 kanalda
Get PRO
Yanvar '23
+101
0 kanalda
Get PRO
Dekabr '22
+540
0 kanalda
Get PRO
Noyabr '22
+407
0 kanalda
Get PRO
Oktabr '22
+46
0 kanalda
Get PRO
Sentabr '22
+22
0 kanalda
Get PRO
Avgust '22
+82
0 kanalda
Get PRO
Iyul '22
+78
0 kanalda
Get PRO
Iyun '22
+28
0 kanalda
Get PRO
May '22
+6
0 kanalda
Get PRO
Aprel '22
+8
0 kanalda
Get PRO
Mart '22
+483
0 kanalda
| Sana | Obunachilarni jalb qilish | Esdaliklar | Kanallar | |
| 21 Iyul | +1 | |||
| 20 Iyul | +1 | |||
| 19 Iyul | +2 | |||
| 18 Iyul | +1 | |||
| 17 Iyul | +2 | |||
| 16 Iyul | 0 | |||
| 15 Iyul | +2 | |||
| 14 Iyul | +2 | |||
| 13 Iyul | +1 | |||
| 12 Iyul | 0 | |||
| 11 Iyul | +1 | |||
| 10 Iyul | 0 | |||
| 09 Iyul | +1 | |||
| 08 Iyul | 0 | |||
| 07 Iyul | +3 | |||
| 06 Iyul | +1 | |||
| 05 Iyul | 0 | |||
| 04 Iyul | +1 | |||
| 03 Iyul | 0 | |||
| 02 Iyul | +1 | |||
| 01 Iyul | 0 |
Kanal postlari
1️⃣2️⃣3️⃣4️⃣5️⃣ SE-0532: Optional noncopyable improvements and generalizations в
Optional добавляют ref, mutableRef, put(), а ещё обобщают map, flatMap и unsafelyUnwrapped для noncopyable wrapped values! Это все про движение Swift в сторону ownership, borrowing, move-only типов и более явного управления ресурсами. Чтобы Swift нормально работал с noncopyable значениями, Optional тоже должен уметь с ними жить без боли. Проблема была в том, что обычный if let для noncopyable optional мог использовать значение:
if let payload = optional {
...
}
И получить ошибку use after consume
Просто потому что значение нельзя скопировать, а язык должен очень аккуратно следить, кто им владеет.
В SE-0532 предлагают сделать работу с такими optional более явно управляемой:
🟢ref — чтобы получить borrowed reference к значению внутри optional
🟢mutableRef — чтобы изменить значение внутри optional без вытаскивания наружу
🟢put() — чтобы положить новое значение в optional и сразу получить mutable reference на него
Плюс map, flatMap и unsafelyUnwrapped становятся более пригодными для noncopyable и nonescapable типов.
Понятное дело, что скорее всего нас это особо не заденет, noncopyable-типы пока не стали повседневной частью iOS-разработки, да и врядли станет, но вот для библиотек и низкоуровневого кода, это удобный синтаксический сахар| 2 | 📱 Три SwiftUI group, которые легко перепутать
В SwiftUI есть три модификатора с очень похожими названиями:
➡️ compositingGroup()
➡️ geometryGroup()
➡️ drawingGroup()
Но работают на разных уровнях. Если добавить не тот group, ничего магического не произойдёт. В лучшем случае не изменится ничего. В худшем появится лишняя работа для рендера
🟡compositingGroup() нужен, когда проблема в графическом результате.
Классический пример: несколько аватарок лежат внахлёст, и вы ставите opacity на весь ряд. Без compositingGroup() прозрачность может примениться к каждой аватарке отдельно. В итоге они начинают просвечивать друг через друга, хотя вы хотели просто сделать весь ряд полупрозрачным. То есть это не про layout. Это про то, как группа выглядит после композиции
🟡geometryGroup() нужен, когда проблема в геометрии.
Например, родитель двигает view, а внутри в этот же момент меняется текст, размер или фон. Без явной границы SwiftUI может анимировать части view отдельно, и интерфейс на мгновение выглядит так, будто элемент развалился на куски
🟡drawingGroup() звучит похожим, но это уже другая история. Он рендерит содержимое в offscreen image, а потом SwiftUI работает с ним как с одной картинкой. Иногда это может помочь, если у вас сложная графика, много shape, blur, clipping и повторяющихся операций. drawingGroup() лучше добавлять не по ощущениям, а после профилирования, т.к. он достаточно затратный. А еще он подходит именно для графического SwiftUI-контента. Text, Image, Shape и композиции из них. А вот произвольные UIKit/AppKit view, web view или media player он нормально в картинку не превратит
Статья отлично демострирует работу SwiftUI изнутри. Иногда баг в интерфейсе не в анимации, не в layout и не в цветах. Он просто в том, на каком этапе SwiftUI вы пытаетесь сгруппировать view. И чем лучше понимаешь этот pipeline, тем меньше хочется лечить всё подряд случайным .drawingGroup() | 937 |
| 3 | 🧠 Разработка ИИ-приложений с Claude Code
В чем суть?
Claude Code ускоряет написание и отладку кода. Но его главная сила — не в магии «сделай всё за меня», а в умении разработчика грамотно ставить задачи.
❌ Если просто попросить «сделай приложение» — получите набор нерабочих кусков.
✅ Если дробить задачу, задавать контекст и контролировать архитектуру — получите готовый продукт.
Бесплатный вебинар курса «Вайб-кодинг» 21 июля в 20:00, где разберем практическое использование Claude Code для создания:
— Telegram-ботов и ИИ-агентов;
— Внутренних сервисов и автоматизаций;
— Серверной логики и программных интерфейсов (API).
🎯 Ключевые темы урока:
Структура промптов и работа с большими проектами;
Пошаговая разработка и проверка результата (а не генерация «вслепую»);
Поиск ошибок и доработка готового кода.
👨💻 Для кого этот урок?
Для тех, кто хочет выстроить процесс вайб-кодинга в реальных продуктах, а не просто играться с генерацией фрагментов.
🚫 Это НЕ для вас, если:
— Вы хотите заменить инженерное мышление одним запросом;
— Не готовы проверять результат и контролировать код;
— Думаете, что ИИ соберет качественный продукт без вашей задачи и контекста.
👉 Зарегистрироваться учиться строить системы, а не просто генерировать строки кода!
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576 www.otus.ru | 729 |
| 4 | 🐥 Multipeer Connectivity все
Multipeer Connectivity нужен для сценариев, когда несколько Apple-устройств должны найти друг друга рядом и обмениваться данными без вашего сервера, например: локальный multiplayer, передача данных между iPhone и iPad, офлайн-синхронизация, companion app, совместная работа рядом. Но использовать это можно было на бумаге - взял MCSession, нашёл соседние устройства, подключился, отправил данные. В реальных же приложениях у Multipeer Connectivity давно накопилась репутация фреймворка, который работает только в демо. У пользователей же
🟡устройства видят друг друга, но не подключаются
🟡сессия зависает в connecting, а потом падает в notConnected.
🟡если на двух девайсах всё хорошо, то на нескольких точно разваливается
Apple выпустила technote про миграцию с Multipeer Connectivity на Network framework. А на Developer Forums инженеры Apple довольно прямо говорят: если вы упёрлись в проблемы MCSession, смотрите в сторону Network framework. Multipeer Connectivity слишком много прячет внутри себя. Он сам решает, как искать устройства, как соединять peers, как строить сессию и какой сетевой путь использовать. Это удобно на старте, но плохо, когда нужно понять, почему всё сломалось. Network framework менее магический, зато честный:
🟢NWBrowser для поиска устройств
🟢NWListener для входящих соединений
🟢NWConnection для общения
🟢TCP, UDP, QUIC и свой протокол поверх этого
Если у вас старый проект на MCSession, не обязательно срочно всё переписывать. Но если вы сегодня проектируете новую фичу для обмена данными между устройствами рядом, я бы уже не начинал с Multipeer Connectivity | 959 |
| 5 | 🔨 Scene Close Confirmation в iOS 27
В iOS 27 у UIWindowScene появился closureConfirmation. Идея простая: перед тем как сцена реально закроется, приложение может показать системное подтверждение. Это именно подтверждение закрытия window scene, а не alert, т.е. пользователь нажал закрыть окно, а приложение может спросить:
🟢сохранить изменения
🟢закрыть без сохранения
🟢отменить закрытие
Сейчас это больше актуально для iPad и split-screet, iOS-приложения чаще выглядят как один большой экран на одной сцене. Сейчас же сдвиг в сторону адаптации iPadOS и macOS-поведение приезжает в UIKit. Очередная подсказка о возможном открытии нескольких приложений на новом iPhone.
Не стоит использовать этот подход везде, Если каждый экран начнёт спрашиватьподтверждение, пользователь очень быстро начнёт ненавидеть это приложение. Возможные сценарии для confirmation:
🟢Есть несохранённые данные
🟢Активная сессия
iOS всё дальше уходит от модели одно приложение - один экран. Сцены, окна, Stage Manager, external displays, document apps, visionOS и Catalyst постепенно делают UIKit более "оконным" | 1 023 |
| 6 | 🌐 Safari MCP server
WebKit добавил Safari MCP server в Safari Technology Preview. Эта новость не только для web-разработчиков, для iOS-разработки она тоже важна. Особенно для тех, кто делает hybrid-интерфейсы, WebView, внутренние панели, лендинги к приложениям или просто пользуется AI-агентами в разработке.
Суть простая: теперь AI-агент может подключиться к реальному окну Safari и сам посмотреть, что происходит на странице. Прямо в браузере: DOM, console output, network requests, screenshots, viewport, клики, ввод текста, состояние элементов на странице. Это хороший шаг от генерации кода к нормальной проверке результата. Потому что главная проблема AI-агентов сейчас не в том, что они плохо пишут код. Они часто не видят, что получилось после запуска.
Агент может:
🔵Проверить, как страница реально отрисовалась в Safari
🔵Посмотреть ошибки в консоли
🔵Разобраться с network-запросами
🔵Сделать скриншот
🔵Поменять размер viewport
🔵Кликнуть по элементам
🔵Проверить форму или сложный UI-сценарий
🔵Найти часть accessibility-проблем
Отдельно важно, что сервер работает локально и не отправляет данные в Apple. Но данные страницы, скриншоты и логи получает тот агент, к которому вы его подключили. Поэтому на продовых админках, личных кабинетах и чувствительных данных я бы включал это аккуратно. | 1 276 |
| 7 | 👨🏻💻 Создание ИИ-продуктов в Lovable: от идеи до рабочего мини-MVP
Раньше путь от идеи до прототипа занимал месяцы. Сейчас ИИ-инструменты позволяют быстро собрать MVP и проверить гипотезу. Но скорость работает, только если есть структура: экраны, логика и путь пользователя.
🗓 14 июля в 20:00 на вебинаре разберём, как создавать мини-MVP в Lovable без классической разработки.
Что будет:
• Что такое вайб-кодинг и интерфейс Lovable
• Как ставить задачи, чтобы получать не макеты, а рабочие пользовательские сценарии
• Практика: соберём мини-MVP — интерфейсы, логику экранов, путь пользователя
• Как итерациями дорабатывать продукт и улучшать UX без дизайнера
• Главные ошибки: перегруженные промпты, отсутствие структуры, потеря логики между экранами
Бесплатный вебинар курса «Вайб-кодинг: создание цифровых продуктов с ИИ»
❗️ Не для тех, кто ждёт «продукт по одной кнопке», не готов продумывать сценарии и считает прототип просто набором красивых экранов.
👉 Зарегистрироваться по ссылке
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576 | 640 |
| 8 | 🔨 iOS 27 готовит почку для раскладывающихся iPhone?
На WWDC26 Apple сказала вроде бы скучную вещь: в iOS 27 iPhone-приложения становятся resizable, а в Xcode 27 у Live Previews появились resize handles. Звучит как забота про iPhone Mirroring и запуск iPhone-приложений на iPad. Но у меня ощущение, что это не только про них. Если сложить это с текущими слухами про foldable iPhone, картина становится слишком аккуратной.
По инсайдам, Apple готовит не раскладушку в стиле Samsung, а "book-style" iPhone: с внешним экраном около 5.5″ и внутренним экраном около 7.8″ - почти маленький iPad, который всё ещё остаётся iPhone. Пишут и про революционный шарнир, позволяющий исключить складку и очень тонкий корпус
Очередной раз Apple пытается внедрить в умы iOS разработчиков size классы, адаптивную геометрию, и интерфейсы которые нормально переживают сжатие, растягивание и смену пропорций. Не думаю что выход нового iPhone удет проблемой для iOS, многие приложения прилично работают на iPad, но с выходом нового устройства, должны появиться новые механики в UX.
Источники:
🔵Apple SwiftUI / resizability
🔵MacRumors по iOS 27 и утечкам о foldable
🔵Ming-Chi Kuo про foldable | 1 230 |
| 9 | 📱 Топ 10 обновлений SwiftUI с WWDC26
Информации после WWDC конкретно про SwiftUI много, но что действительно изменилось? Собрал свои хайлайты на основе сессий и статьи:
1. Новый внешний вид Liquid Glass
Стандартные компоненты получают обновлённый вид почти бесплатно. Можно просто собрать проект в Xcode 27 и посмотреть, что изменилось в реальном интерфейсе
2. Больше контроля над кастомным Liquid Glass
Для своих glass-элементов теперь можно явно указать, что они интерактивные. Особенно актуально для iPad и macOS, где интерфейс живёт не только под пальцем, но и под курсором
3. appearsActive для окон
Наконец-то можно нормально реагировать на активное и неактивное окно. Маленькая штука, но для iPadOS и macOS это тот самый штрих, который делает приложение менее айпадным на большом экране
4. Toolbars стали взрослее
Появились приоритеты видимости, отдельное overflow-меню, возможность закреплять важные действия и автоматически сворачивать navigation bar при скролле. То есть меньше попыток угадать, что спрячется на маленьком экране и где окажется кнопка Share.
5. Новый Document API
SwiftUI серьёзно прокачали для document-based приложений. Асинхронное чтение и запись, работа с большими файлами, прогресс операций, несколько сценариев создания нового документа. Для заметок, редакторов, графических приложений и любых файловых историй это прям вау
6. Drag & Drop без танцев
Теперь можно добавлять reordering не только в List, но и в сетки, стеки и кастомные layout. И всё это одним подходом на разных контейнерах.
7. Swipe Actions не только внутри List
Swipe actions теперь можно использовать в произвольных scrollable layout. Кажется мелочью, пока не надо добавить знакомое iOS-взаимодействие в кастомную ленту или карточный интерфейс
8. Confirmation dialogs и alerts стали ближе к sheets
Появился нормальный item-based подход. Положили объект в binding, SwiftUI сам показывает нужный диалог. Меньше булевых флагов вида isShowingDeleteDialog, меньше шансов случайно открыть не тот alert.
9. AsyncImage начал уважать HTTP cache
SwiftUI теперь использует стандартное HTTP-кеширование по умолчанию и учитывает cache headers сервера. Это один из тех апдейтов, которые работают сами из коробки, проверьте что на беке хедеры настроены.
10. @State для классов стал ленивым
Объекты, созданные внутри @State, больше не пересоздаются впустую при каждом обновлении view. Меньше лишних аллокаций, меньше странных сайд-эффектов в init, чуть спокойнее профайлер.
Полезные ссылки:
🔵 What’s new in SwiftUI, WWDC26
🔵 SwiftUI guide, WWDC26
🔵 SwiftUI updates в документации Apple
🔵Build powerful drag and drop in SwiftUI | 1 664 |
| 10 | ➕ «В Яндекс я попал только с третьего раза!». Побывали в офисе Яндекс Еды, потрогали самурайский меч и поговорили со старшим iOS-разработчиком Львом Бондаренко — обсудили его любимые проекты, тренды мобильной разработки и алгоритмы на собеседованиях.
↘️ Это «1х1» — формат, в котором яндексоиды проводят с вами личную встречу на работе. Смотрите здесь, на YouTube и в VK Видео.
👀 Присоединяйтесь к нашей команде | 526 |
| 11 | 🕸 HTTP QUERY: наконец-то GET с body без нюансов
HTTP стандарт, обновился и на этот раз добавили новый метод, QUERY. Поражает, конечно что это случилось только сейчас, с учетом какие танцы проводила вся it индустрия. Давайте на примере, какой метод выбрать для метода поиска?
🟡GET метод с аргументами в query мараметрах выглядит сложно и имеет ограничение по-длинне, а лимиты у прокси еще меньше по факту чем в стандартах
🟡POST метод с аргументам в теле запроса не будет кешироваться cdn и будет создавать доп. нагрузку на ваш сервер. Не говоря о том что даже в стандарте этот метод не для этого и является не идемпотентным
🟡GET метод чисто по спеке тоже может иметь тело, но значительная часть прокси его игнорируют или перетирают
Вот и получается что есть 3 стула и все с нюансами.
Новый метод QUERY, опубликованный как RFC 10008, закрывает именно эту дыру. Его смысл простой: это безопасный и идемпотентный запрос, который может нести тело.
QUERY /feed HTTP/1.1
Content-Type: application/json
{"q":"swift","limit":20,"sort":"-published"}
QUERY говорит серверу, клиенту, CDN, прокси, SDK и будущему человеку в коде: это запрос данных, он не должен менять состояние целевого ресурса, его можно безопасно повторить после сетевого сбоя, и его ответ в принципе может кэшироваться.
Пока рано радоваться, блеснуть этим знанием можно разве что на собесе, стандарту нет еще и месяца и aboption произойдет в лучшем случае через год. | 1 494 |
| 12 | 🎯 Apple официально депрекейтит ImageCreator
ImageCreator больше не будет работать в iOS/iPadOS/macOS/visionOS 27. На форумах тема болезненная: у кого уже была кастомная AI-image UX, остаётся ImagePlaygroundViewController или внешний сервис. Программная генерация картинок через системную on-device модель больше не должна быть частью вашего production-кода.
И тут важно не само слово deprecated. Мы все привыкли, что deprecated API может жить годами, иногда почти как домашний питомец в legacy-коде. Здесь история жёстче. В beta OS код ещё будет компилироваться, но Xcode начнёт показывать warnings. При этом TestFlight-сборки с ImageCreator уже не будут нормально работать и могут падать в runtime. А на public-релизах iOS 27+ такой код вообще перестанет компилироваться.
Что я бы проверил в проекте:
🟢Есть ли прямое использование ImageCreator в app target, extensions, внутренних SDK или feature modules
🟢Не спрятана ли генерация картинок за абстракцией вроде AIImageService, AvatarGenerator, StickerGenerator
🟢Есть ли fallback для пользователей на iOS 27+, если генерация картинок была частью ключевого сценария
Apple меняет границу контроля: вместо того чтобы приложение программно просило систему "сгенерируй мне картинку", разработчику предлагают показывать Image Playground sheet — системный, управляемый Apple компонент. Это заметная разница для продукта. Sheet — это безопаснее, консистентнее и понятнее для App Review. Но это хуже для тех сценариев, где нужна полностью кастомная генерация: аватары, стикеры, обложки, onboarding, игровые ассеты, автоматические превью. Если такой контроль нужен, Apple прямо оставляет второй путь: интегрировать другой image generation service. Перевод с apple-ского: теперь это ваша инфраструктура, ваши лимиты, ваши moderation rules, ваша стоимость запросов и ваши edge cases. | 1 183 |
| 13 | Apple официально депрекейтит ImageCreator
ImageCreator больше не будет работать в iOS/iPadOS/macOS/visionOS 27. На форумах тема болезненная: у кого уже была кастомная AI-image UX, остаётся ImagePlaygroundViewController или внешний сервис
🧵 Apple выключает ImageCreator: AI-картинки теперь не просто API
Вот это хороший пример новости, которая выглядит маленькой строкой в Apple Developer News, а на практике может сломать вполне реальную фичу в приложении.
Apple объявила, что ImageCreator из Image Playground framework прекращает работу в iOS 27, iPadOS 27, macOS 27 и visionOS 27. То есть программная генерация картинок через системную on-device модель больше не должна быть частью вашего production-кода.
И тут важно не само слово deprecated. Мы все привыкли, что deprecated API может жить годами, иногда почти как домашний питомец в legacy-коде. Здесь история жёстче.
В beta OS код ещё будет компилироваться, но Xcode начнёт показывать warnings. При этом TestFlight-сборки с ImageCreator уже не будут нормально работать и могут падать в runtime. А на public-релизах iOS 27+ такой код вообще перестанет компилироваться.
То есть Apple фактически говорит: если вы успели встроить ImageCreator как «тихий» API для генерации картинок внутри своего UX — пора перепроектировать сценарий.
Что я бы проверил в проекте:
🟢 есть ли прямое использование ImageCreator в app target, extensions, внутренних SDK или feature modules;
🟢 не спрятана ли генерация картинок за абстракцией вроде AIImageService, AvatarGenerator, StickerGenerator;
🟢 проходят ли TestFlight-сборки на iOS 27 beta без runtime-сюрпризов;
🟢 есть ли fallback для пользователей на iOS 27+, если генерация картинок была частью ключевого сценария;
🟢 не обещает ли onboarding, paywall или marketing screen фичу, которая теперь зависит от удалённого сервиса или системного sheet.
Главная мысль
Apple не просто убирает класс. Она меняет границу контроля: вместо того чтобы приложение программно просило систему «сгенерируй мне картинку», разработчику предлагают показывать Image Playground sheet — системный, управляемый Apple experience.
Это заметная разница для продукта. Sheet — это безопаснее, консистентнее и понятнее для App Review. Но это хуже для тех сценариев, где нужна полностью кастомная генерация: аватары, стикеры, обложки, onboarding, игровые ассеты, batch generation, автоматические превью.
Если такой контроль нужен, Apple прямо оставляет второй путь: интегрировать другой image generation service. Перевод с apple-ского: теперь это ваша инфраструктура, ваши лимиты, ваши moderation rules, ваша стоимость запросов и ваши edge cases.
Почему это актуально сейчас:
🟡 iOS 27 ещё в beta, но TestFlight уже важен: именно там такие вещи обычно всплывают перед релизом, когда «ну мы потом поправим» внезапно превращается в блокер;
🟡 это хороший сигнал по Apple Intelligence API в целом: не стоит строить продуктовую фичу так, будто любой новый AI-класс Apple навсегда станет стабильным headless API;
🟡 если AI-фича влияет на монетизацию или core UX, её нужно закрывать feature flag’ом, аналитикой, fallback-экраном и отдельным smoke-тестом под новые OS.
Мой вывод простой: ImageCreator стоит искать в коде уже сейчас, даже если фича экспериментальная. Apple оставляет Image Playground как пользовательский системный сценарий, но забирает у разработчика удобный программный рычаг. Для маленького pet feature это неприятно. Для production-фичи с paywall — уже миграционный план, а не новость на потом. | 1 |
| 14 | 🎯 iOS 27, Your App, and Siri
Вот это уже не про вау, Siri наконец-то сможет ответить на вопрос из старой переписки. Для разработчика интереснее другое: если новая Siri действительно начинает работать с личным контекстом и данными приложений, то приложение должно заранее объяснить системе, какие сущности у него есть, как их искать и что сейчас показано на экране. Главная мысль Jordan Morgan: лето перед iOS 27 стоит потратить не на гадание про магию AI, а на скучную, но важную инвентаризацию App Intents/App Entities.
Для себя вижу схему работы примерно в следующем:
🔵Какие модели должны быть видны Siri, Shortcuts и системному поиску
🔵Есть ли для них легковесные AppEntity, а не попытка тащить доменную модель целиком
🔵Можно ли просто сделать сущность IndexedEntity, чтобы система сама индексировала данные
🔵Попадает ли ваша модель в готовый Apple App Schema. Если да — это почти всегда лучший путь
🔵Есть ли привязка текущего экрана к сущности через NSUserActivity или view annotations
🔵Нужен ли Transferable, чтобы Siri могла передавать ваши данные дальше: например, отправь эту тренировку по почте
Отдельно важный сниппет: App Schemas выглядят как самый ценный слой. Apple уже обучает Siri понимать эти домены, их свойства и follow-up вопросы. Если приложение попадает в готовую схему — сообщения, контакты, медиа, события и т.п. — лучше использовать ее, а не изобретать свой полусамодельный смысловой слой.
Где пока мутно
Самый неприятный вопрос: что делать приложениям, чьи данные не ложатся в заранее заданные App Schemas? В статье честно отмечено, что это пока не до конца понятно. @Property(indexingKey:), IntentValueQuery, IntentValueRepresentation и прочие приятные механики сильнее всего раскрываются там, где система уже знает тип данных.
Мой вывод: для iOS 27 подготовка к Siri — это не «добавить AI-фичу». Это привести модель данных к виду, в котором система может ее понять: AppEntity, IndexedEntity, схемы, экранный контекст и экспорт через Transferable. Начинать стоит с одного-двух ключевых пользовательских сценариев, где фраза вида "Siri, что я недавно делал в этом приложении?" реально имеет смысл. После подготовки, это все обложить аналитикой и следить какие сценарии пользуются спросом и добавить их в регресс вашего приложения | 1 565 |
| 15 | 📦 Swift Package Index присоединился к Apple
Отличная новость для всего swift сообщества! Это не просто сайт, где удобно искать Swift-пакеты. SPI давно стал нормальным рабочим фильтром перед тем, как тащить зависимость в проект: посмотреть совместимость с платформами, версии Swift, документацию, активность, состояние пакета и вообще понять, живое это что-то или археология с красивым README. И теперь Apple забирает эту часть экосистемы ближе к себе.
В официальном посте аккуратно говорят: для разработчиков и авторов пакетов прямо сейчас ничего не меняется. Пакеты индексируются как раньше, документация хостится как раньше, проект остаётся open source, а инженеры Apple будут участвовать в развитии вместе с комьюнити.
Самая интересная часть — в том, что они прямо называют будущие направления: discovery, security, reliability, package signing и identity. То есть Swift Package Index постепенно может стать не просто поиском по пакетам, а более официальным слоем доверия вокруг Swift-зависимостей. Если вы не использовали SPI до этого но используете swift package, самое время проверить:
🟢какие SPM-зависимости у вас живут в проектах
🟢есть ли у них нормальная поддержка актуальных Swift/iOS/macOS версий
🟢есть ли DocC или хотя бы внятная документация
🟢кто автор, как часто выходят релизы, реагируют ли на issues
🟢насколько критична зависимость для production-кода
🟢сможете ли вы быстро заменить её, если пакет заброшен или сломается на новом SDK.
SPI уже сейчас помогает отвечать на эти вопросы. А если Apple дальше добавит identity/signing, такие проверки могут стать частью нормального инженерного процесса. | 1 516 |
| 16 | 👨🏻💻 Магия Lovable: как создавать готовые интерфейсы с помощью одного запроса.
Хороший интерфейс получается там, где есть хороший промпт.
Точность на входе = качество на выходе.
🗓 На открытом вебинаре 2 июля в 20:00 МСК:
➡️ Разберем, как формулировать задачи для Lovable, чтобы получать предсказуемый результат с первой попытки.
➡️ Поговорим о структуре системного промпта, ключевых словах, которые помогают превратить текст в качественный интерфейс.
➡️ Рассмотрим способы доработки результата через встроенный редактор и повторные запросы.
➡️ Обсудим, как управлять компонентами, просить нейросеть переиспользовать элементы и сохранять единый визуальный стиль.
Бесплатный вебинар курса «Вайб-кодинг: создание цифровых продуктов с ИИ»
🔗 Записаться: по ссылке
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru | 720 |
| 17 | 📳 SensoryFeedback в SwiftUI: маленький параметр, который мог раздуть cache
Иногда самые интересные изменения SwiftUI выглядят вообще не как новая фича. Вот пример: SensoryFeedback.impact(..., intensity:). Снаружи всё выглядит безобидно: есть тип haptic feedback, есть intensity, можно подвязать его к слайдеру, прогрессу или жесту и менять силу отклика. Но в старой реализации SwiftUI была неприятная деталь: intensity жил прямо внутри FeedbackType. А этот FeedbackType использовался как ключ для cache UIFeedbackGenerator.
То есть для кода вроде такого:
Slider(value: $intensity, in: 0...1)
Button("Trigger") {
trigger.toggle()
}
.sensoryFeedback(
.impact(weight: .medium, intensity: intensity),
trigger: trigger
)
SwiftUI мог видеть не один и тот же feedback с разной силой, а много разных ключей:
.impactWeight(.medium, 0.10)
.impactWeight(.medium, 0.11)
.impactWeight(.medium, 0.12)
Для UIKit это странно. Генератор здесь один и тот же:
let generator = UIImpactFeedbackGenerator(style: .medium)
generator.impactOccurred(intensity: intensity)
style определяет, какой генератор нужен.
intensity определяет, как сыграть конкретное срабатывание.
Это разные уровни жизни значения. Одно должно быть cache identity, другое — runtime payload.
Что поменялось в iOS 27:
Apple, судя по dump’ам SwiftUI, поправила именно модель:
struct SensoryFeedback {
var type: SensoryFeedback.FeedbackType
var payload: SensoryFeedback.Payload
}
Теперь стабильная часть feedback лежит в FeedbackType, а intensity вынесен в Payload:
enum Payload {
case intensity(Double)
case empty
}
Это правильнее архитектурно: cache больше не должен раздуваться из-за произвольного Double, который меняется во время drag gesture или slider interaction.
Если вы поддерживаете iOS 17–26, это значит что не нужно передавать в intensity бесконечно плавные значения напрямую из жеста или слайдера, лучше хотя бы квантовать:
let quantizedIntensity = (intensity * 10).rounded() / 10
Button("Trigger") {
trigger.toggle()
}
.sensoryFeedback(
.impact(weight: .medium, intensity: quantizedIntensity),
trigger: trigger
)
Или ещё лучше — триггерить haptic feedback только на смысловых порогах: смена состояния, snap point, достижение лимита, успешное действие, ошибка. | 1 267 |
| 18 | 📱 SwiftUI после WWDC26: Apple постепенно убирает старые костыли
Кажется, одно из самых практичных изменений в SwiftUI WWDC26 — не Liquid Glass и не очередной визуальный эффект, а то, что Apple наконец начала развязывать поведение, которое годами было прибито к List.
Раньше хочешь нормальные swipe actions — бери List
Хочешь reorder — снова думай через List, EditMode, drag/drop или кастомную механику
Хочешь кастомный layout, но с системными жестами — готовься к компромиссам
Теперь SwiftUI двигается в более взрослую сторону: контейнеры становятся не магическими списками со спецвозможностями, а обычными строительными блоками, к которым можно добавлять нужное поведение. Например, swipe actions теперь можно использовать не только в List, но и в ScrollView, lazy stacks и даже кастомных layout’ах:
ScrollView {
LazyVStack {
ForEach(items) { item in
ItemRow(item)
.swipeActions {
Button("Delete", role: .destructive) {
delete(item)
}
}
}
}
}
.swipeActionsContainer()
Это маленькая строчка .swipeActionsContainer(), но смысл большой: больше не нужно выбирать List только потому, что тебе нужны системные свайпы.
Что стоит проверить в своих проектах:
🟢Экраны, где List используется только ради swipe actions
🟢кастомные списки на ScrollView + LazyVStack, где свайпы были самописными
🟢reorder-логику, которую теперь можно заменить на reorderContainer и .reorderable()
🟢toolbar’ы, где на компактных экранах кнопки сейчас ведут себя непредсказуемо
🟢AsyncImage, если раньше приходилось городить отдельный слой кэширования
Пример с reorder теперь тоже выглядит сильно чище:
struct ContentView: View {
@State private var landmarks: [Landmark] = []
var body: some View {
VStack {
ForEach(landmarks) { landmark in
LandmarkView(landmark)
.reorderable()
}
}
.reorderContainer(for: Landmark.self) { difference in
difference.apply(to: &landmarks)
}
}
}
Постепенно можно удалять локальные костыли там, где SwiftUI теперь даёт системное поведение из коробки. Особенно интересно это выглядит на фоне resizable iPhone-приложений на iPad и более гибких оконных сценариев. Чем меньше экран завязан на конкретный контейнер вроде List, тем проще адаптировать UI под реальное доступное пространство, а не под старые эвристики | 1 347 |
| 19 | 🎯 Foundation Models в iOS 27: Apple превращает локальный LLM в нормальную AI-платформу
Сделал большой обзор основной темы этого года - Foundation Models. Если в прошлом году Foundation Models выглядел как аккуратный способ позвать системную on-device модель из Swift, то в iOS 27 Apple явно расширяет ставку. Теперь это уже не просто локальный LLM для подсказок в приложении, это слой, через который приложение может работать с разными моделями, разными источниками контекста и разными режимами выполнения — локально, через Private Cloud Compute или даже через сторонних провайдеров.
🟢Новая on-device модель
Apple говорит, что модель стала сильнее в логике и tool calling. Плюс появились API для context size и token counting — то есть приложение может адаптироваться под конкретное устройство, а не молиться, что prompt влезет.
🟢Vision в Foundation Models
Теперь в prompt можно передавать изображения: UIImage, CGImage, CIImage, pixel buffers, file URLs. Модель может отвечать по картинке, а размер изображения влияет на токены и latency. Наконец-то мультимодальность выглядит не как демо, а как API для реальных фич.
🟢Private Cloud Compute как модель внутри того же API
Появляется PrivateCloudComputeLanguageModel: больше контекст, reasoning, более тяжёлые задачи. Для разработчика это выглядит почти как обычная LanguageModelSession, но модель уже не локальная.
🤩 Важная деталь: Apple обещает отсутствие API keys, отдельной авторизации и cloud API costs для разработчиков с менее чем 2 млн first-time downloads. Звучит очень по-Apple: меньше DevOps, больше платформенной магии.
🟢Единый LanguageModel protocol
Вот это, возможно, главный сдвиг. SystemLanguageModel, PrivateCloudComputeLanguageModel, Core AI, MLX и сторонние модели могут жить за общей абстракцией. То есть downstream-код приложения может не знать, кто именно отвечает: локальная Apple-модель, PCC, Anthropic, Google или свой серверный backend.
🟢System tools: Vision и Spotlight
Apple добавляет встроенные инструменты вроде OCR, barcode reader и Spotlight-powered поиск. Последнее особенно важно: локальный RAG поверх Spotlight index — это прямой путь к AI-фичам, которые работают с персональным или доменным контекстом без отправки всего подряд наружу.
🟢Dynamic Profiles для agentic apps
Вместо ручного пересоздания сессий можно декларативно описывать режимы: например, один профиль анализирует картинку локальной моделью, другой переключается на PCC с reasoning для генерации идей.
Это уже не просто чатик в приложении. Это примитив для маленьких агентов внутри приложения.
🟢Evaluations framework
Apple наконец признаёт неприятную правду: LLM-фичи недетерминированы, поэтому их надо не только попробовать руками, а измерять. Новый Evaluations framework нужен, чтобы проверять качество prompt/tool/model изменений статистически, а не на ощущениях после трёх запусков. По сути это тесты для AI
iOS 27 делает Foundation Models серьёзнее. Если вы уже думали, как добавить AI в приложение, этот доклад стоит смотреть одним из первых. Не ради хайпа, а чтобы правильно выбрать границы: что держать на устройстве, что отдавать в PCC, а что вообще не стоит строить на LLM. | 1 424 |
| 20 | 📱 SwiftUI navigation transitions в iOS 27
В iOS 27 SwiftUI получил маленькое, но очень практичное обновление для навигационных анимаций.
До этого NavigationTransition уже позволял управлять переходами в NavigationStack, sheets и full-screen covers, но встроенных вариантов было мало: по сути .automatic и .zoom(sourceID:in:). Теперь появилось две полезные вещи:
🟢 .crossFade
Новый transition для случаев, где у экрана нет нормального visual source.
zoom хорошо работает, когда пользователь тапнул карточку, картинку или ячейку. Но если экран открылся из deep link, notification, App Intent или программного состояния, zoom часто выглядит натянуто.
crossFade даёт спокойный fade-переход без необходимости придумывать искусственный source.
.sheet(isPresented: $showInfo) {
LandmarkInfo()
.presentationDetents([.medium])
.navigationTransition(.crossFade)
}
🟢AnyNavigationTransition
Вторая новинка позволяет выбирать transition динамически.
Один и тот же экран может открываться по-разному:
🟡из tap по карточке — .zoom(...)
🟡из уведомления или deep link — .crossFade / .automatic
Раньше это упиралось в то, что .navigationTransition(_:) ждёт один конкретный тип. Теперь можно завернуть transition в AnyNavigationTransition и передавать его как значение.
Навигация в iOS-приложениях давно не только про тапнул в списке → открыл экран. Есть widgets, notifications, Spotlight, App Intents, Siri, universal links. Разные входы в один экран должны ощущаться по-разному. Кастомные NavigationTransition всё ещё не поддерживаются, но iOS 27 уже убирает часть странных компромиссов в SwiftUI-анимациях 🥂 | 1 038 |
