Endi mavjud! Telegram Tadqiqoti 2025 — yilning asosiy insaytlari 
iOS Broadcast
Kanalga Telegram’da o‘tish
Подборка новостей и статей для iOS разработчиков. Новости Kotlin и мультиплатформы @kotlin_broadcast Новости Android @android_broadcast Реклама и прочее @ab_manager
Ko'proq ko'rsatish3 526
Obunachilar
-224 soatlar
-57 kunlar
-330 kunlar
Ma'lumot yuklanmoqda...
O'xshash kanallar
Taglar buluti
Kirish va chiqish esdaliklari
---
---
---
---
---
---
Obunachilarni jalb qilish
Iyun '26
Iyun '26
+21
1 kanalda
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 | |
| 24 Iyun | +1 | |||
| 23 Iyun | +1 | |||
| 22 Iyun | 0 | |||
| 21 Iyun | 0 | |||
| 20 Iyun | +2 | |||
| 19 Iyun | 0 | |||
| 18 Iyun | +1 | |||
| 17 Iyun | 0 | |||
| 16 Iyun | 0 | |||
| 15 Iyun | 0 | |||
| 14 Iyun | 0 | |||
| 13 Iyun | +3 | |||
| 12 Iyun | +3 | |||
| 11 Iyun | 0 | |||
| 10 Iyun | +1 | |||
| 09 Iyun | +1 | |||
| 08 Iyun | +3 | |||
| 07 Iyun | 0 | |||
| 06 Iyun | 0 | |||
| 05 Iyun | +1 | |||
| 04 Iyun | 0 | |||
| 03 Iyun | +3 | |||
| 02 Iyun | +1 | |||
| 01 Iyun | 0 |
Kanal postlari
📦 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, такие проверки могут стать частью нормального инженерного процесса.
| 2 | 👨🏻💻 Магия Lovable: как создавать готовые интерфейсы с помощью одного запроса.
Хороший интерфейс получается там, где есть хороший промпт.
Точность на входе = качество на выходе.
🗓 На открытом вебинаре 2 июля в 20:00 МСК:
➡️ Разберем, как формулировать задачи для Lovable, чтобы получать предсказуемый результат с первой попытки.
➡️ Поговорим о структуре системного промпта, ключевых словах, которые помогают превратить текст в качественный интерфейс.
➡️ Рассмотрим способы доработки результата через встроенный редактор и повторные запросы.
➡️ Обсудим, как управлять компонентами, просить нейросеть переиспользовать элементы и сохранять единый визуальный стиль.
Бесплатный вебинар курса «Вайб-кодинг: создание цифровых продуктов с ИИ»
🔗 Записаться: по ссылке
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru | 489 |
| 3 | 📳 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, достижение лимита, успешное действие, ошибка. | 683 |
| 4 |  📱 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 под реальное доступное пространство, а не под старые эвристики | 993 |
| 5 |  +5🎯 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. | 974 |
| 6 | 📱 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-анимациях 🥂 | 916 |
| 7 |  +9▶️ Что нового в Swift
Сессии по Swift традиционно не являются сюрпризом для тех кто следит за развитием языка в опенсорс. На сессии нам показали вектор - Apple двигает Swift сразу в двух направлениях:
1. Убрать мелкую боль из обычного app-кода
2. предоставить безопасные инструменты там, где раньше приходилось уходить в unsafe, C-style трюки или ручную дисциплину
Swift 6.4 убирает часть странностей:
🔵any P? и some P? теперь можно писать без лишних скобок
🔵async-вызовы разрешены внутри defer
🔵компилятор лучше предупреждает, если Task молча теряет thrown error
🔵weak let помогает с Sendable-классами
🔵~Sendable позволяет явно сказать: этот тип не должен быть Sendable
🔵После выравнивания версий Apple OS новая availability-платформа выглядит очень логично:
@available(anyAppleOS 27, *)
@diagnose даёт более взрослую модель управления предупреждениями компилятора:
🔵временно подавить deprecated warning в одном месте
🔵включить strict memory safety для чувствительного участка
🔵превратить future Swift errors в ошибки уже сейчас
Улучшения внутри стандартной библиотеке:
🔵withTaskCancellationShield - короткая зона, где cancellation checks возвращают false
🔵mapKeyedValues - mapValues, но mapping closure получает и key, и value
🔵новый FilePath в standard library - более правильная работа с путями между платформами
Swift Testing: миграция становится менее драматичной
🔵severity для Issue.record
🔵динамическая отмена тестов через Test.cancel
🔵repeat-режимы для флакающих тестов в swift test
🔵XCTest assertions теперь могут репортиться как Swift Testing issues
🔵#expect можно использовать из XCTestCase
Большой блок сессии посвящён не iOS-экранам, а interop и portability:
🔵@C позволяет экспортировать Swift-функции обратно в C
🔵Swift/C++ interop лучше работает со span
🔵Swift-Java поддерживает async/throwing Swift functions из Java
🔵Появился официальный Swift SDK for Android
🔵Swift компилируется в WebAssembly
🔵JavaScriptKit стал безопаснее и быстрее
🔵Embedded Swift расширяет поддерживаемый subset языка
Пример Goodnotes из сессии здесь очень показательный: существующий Swift-код можно компилировать в Wasm для web-интерфейса, не переписывая core logic на другой язык.
Самый недооценённый кусок сессии - ownership и performance tuning:
🔵@inline(always) - принудительный inline, когда вы измерили пользу
🔵@specialized - специализация generic-функций под важные конкретные типы
🔵новый Iterable
🔵borrow / mutate accessors - computed property без лишнего копирования
🔵UniqueBox, UniqueArray, Ref, MutableRef — стандартные безопасные версии паттернов, где раньше легко было скатиться в unsafe
Важно что Apple не предлагает писать весь app-код как low-level библиотеку. Обычный Swift должен оставаться обычным Swift.
Что стоит проверить в вашем swift-проекте:
🟢заменить длинные availability-аннотации на anyAppleOS
🟢пересмотреть локально подавленные warnings и часть из них оформить через @diagnose
🟢найти Task { try ... }, где ошибка могла теряться
🟢проверить старые concurrency-компромиссы вокруг Sendable, weak, defer
🟢в тестах начать смешанную миграцию Swift Testing + XCTest, а не ждать идеального момента
🟢в флакающих тестах попробовать repeat-режимы swift test
🟢в shared packages посмотреть на новый FilePath и mapKeyedValues
🟢в performance-коде измерить копирования, ARC и generic overhead перед использованием @inline(always), @specialized, Iterable, borrow/mutate | 1 319 |
| 8 |  +9🔨 Xcode 27: Apple встраивает агента не в чат, а в весь цикл разработки
В этом году вопроса "с чего бы начать просмотр сессий с WWDC" не стояло, начинаем с "Что нового в Xcode 27"! Главная мысль из сессии - агент становится частью IDE, а IDE частью цикла разработки приложения. От идеи и прототипа до локализации, тестов, Device Hub, production-метрик, Instruments и Xcode Cloud. Ide залезает как на этап Discovery по работе с гипотезами, так и на этап приемки, тестирования и поддержки.
Ключевые изменения:
🟢Агенты живут прямо в редакторе
🟢Команда /plan позволяет сначала попросить агента собрать контекст и предложить план без изменений в коде
🟢Изменения, артефакты и скриншоты агента видны рядом, пока он работает с проектом
🟢Device Hub становится отдельным рабочим окном для симуляторов и физических устройств
🟢iPhone Mirroring в macOS 27 можно ресайзить, и Apple прямо говорит: проверяйте, как iPhone-приложение живёт в новых размерах окна
🟢Агент может подготовить проект к локализации: пройтись по строкам, создать String Catalog, перевести UI strings и использовать контекст проекта + специфические правила конкретного языка
🟢Organizer теперь не просто показывает что что-то сломалось, а пытается подсказать, что чинить
🟢Instruments получил Top Functions - быстрый способ увидеть, где приложение реально тратит время, особенно когда дорогая операция выполняется много раз
Apple явно не стремится заменить разработчика агентом. Скорее наоборот: Xcode 27 подталкивает к роли, где разработчик задаёт рамки, ревьюит план, проверяет результат и принимает инженерные решения. Агент забирает на себя грязную рутину: подготовить локализацию, собрать контекст, предложить фикс, найти дорогую функцию, помочь провести регресс. Полезная мысль: если проект хаотичный, без тестов, без нормальных сценариев проверки и без метрик, агенту тоже будет не на что опереться. Xcode 27 делает AI-разработку практичной только там, где уже есть инженерная дисциплина. Подумайте о том как выглядит разработка в вашем продукте, есть ли у вас все этапы? Чем лучше проект описывает сам себя через тесты, локализации, метрики, логику сборки и пользовательские сценарии, тем эффективнее в нём будет агент | 1 188 |
| 9 |  +9🎹 Platforms State of the Union: Apple собирает AI-стек для разработчиков
Если keynote был про смотрите, у нас теперь AI, то Platforms State of the Union — про то, как Apple хочет встроить AI прямо в рабочий цикл разработки
🟢Foundation Models framework
Новое поколение Apple Foundation Models доступно через расширенный framework. Пока приложение не популярное - для разработчика бесплатно
🟢On-device AI стал серьёзнее
Модели на устройстве научились мультимодальности и работе с изображениями. Небольшие image-модели можно запускать прямо на телефоне
🟢Private Cloud Compute
Подписчики iCloud+ получат расширенный доступ к серверным моделям через Private Cloud Compute
🟢Core AI
Новый framework для запуска моделей на устройствах. Плюс RAG на основе данных из Spotlight
🟢Динамические профили
Prompt + model + depth reasoning под разные задачи. По сути — имитация разных агентов внутри одного workflow
🟢App Intents + Siri
Достаточно описать entity и intent-схемы. Пользователь говорит Siri свободной формой, а framework сам мапит запрос на возможности приложения
🟢Agentic Coding в Xcode
Теперь это не просто "напиши мне код". Apple раскладывает процесс по стадиям:
🔵discovery — обсуждаем идею с агентом прямо в Xcode
🔵plan — агент создаёт Markdown-план, его можно править руками
🔵development — агент пишет код по согласованному плану
🔵verification — тесты, API, user flows на симуляторе, отчёт
🔵crashes — анализ prod crash, воспроизведение, описание и фикс
🟢Плагины
Всё это работает через плагины. Часть написана инженерами Apple, но Apple явно ждёт, что разработчики будут добавлять свои
🟢Xcode стал практичнее
MCP / Agent Client Protocol, интеграции с популярными агентами, кастомный toolbar, загрузка проектов до 30% быстрее, надёжнее debug и меньший размер
🟢DeviceHub
Simulator заменили новым DeviceHub: в одном месте симуляторы со всеми настройками и физические девайсы
🟢Локализация в Xcode
Перевод теперь можно делать прямо в IDE. Важно: Xcode смотрит не только на строки, но и на контекст, где они используются
🟢SwiftUI снова продают как будущее
В том числе как путь для переписывания web-приложений через agentic coding.
Появились .reorderContainer, swipe-действия для элементов контейнера и ощущение дежавю: примерно это же когда-то красиво продавали в UICollectionView
🟢SwiftUI performance
@State сделали ленивым, AsyncImage получил кеширование. Это должно ускорить SwiftUI-приложения без доработок
Из важного:
🟡Платформенный сдвиг
Intel Mac — всё. Теперь только Apple Silicon
🟡iPhone Mirroring
В iOS 27 можно менять размер iOS-приложения на Mac и iPad при использовании iPhone Mirroring | 1 045 |
| 10 |  +9🎹 Keynote highlights
WWDC26 получилась больше похожа на Google IO, все вокруг.. Для разработчиков главное начнётся на Platforms State of the Union. То что хоть немного меня зацепило:
🟢iOS 27. Поддерживает все модкли, начиная с iPhone 11, запуск приложений до 30% быстрее
🟢Детские аккаунты. Больше контроля: покупки, сайты, контакты, сообщения и лимиты по категориям контента
🟢Apple Intelligence. Главный акцент — приватность: on-device, Private Cloud Compute и внешние модели там, где нужно
🟢Siri AI. Отдельное приложение, больше контекста, Visual Intelligence и сценарии поверх приложений
🟢App Intents. Самый важный пункт для разработчиков: приложения должны стать понятными новой Siri
🟢Foundation Models. Apple + Gemini: гибридная AI-архитектура вместо попытки делать всё в одиночку
🟢Shortcuts. Вайбкодинг для автоматизаций: описываешь задачу, система собирает сценарий
🟢Xcode. Agentic coding со сторонними моделями: Codex, Claude и Gemini. Ждём деталей по тестам, правкам и границам доступа
🟢DeviceHub. Новое приложение для управления устройствами. Интересно, дадут ли API и intents
🟢Остальные платформы. iPadOS, macOS, watchOS, tvOS и visionOS тоже обновились, но главный разработческий разбор — после SDK и сессий
Мой вывод такой - Keynote дал направление, а не ответы. Теперь смотреть Platforms State of the Union, Xcode, App Intents, AI API и первые developer betas 🍿 | 980 |
| 11 |  Чуть больше чем через час уже начнется трансляция WWDC26 Keynote! Давайте попробуем ввести немного интерактива в этот WWDC Keynote, делитесь в комментариями фото мест просмотра Keynote, мыслями что ждете от Apple в этом году, а в процессе ивента и после обсудим первые впечатления о новинках Apple. Вот так, например мы организовали офис в Воронеже под просмотр Keynote. Мои мысли уже в комментариях | 973 |
| 12 |  🧑💻 WWDC26
Сегодня начинается WWDC26, полезные ссылки:
🍏 Трансляция на сайте Apple
🈸 Трансляция в приложении Apple Developer
🎞 Трансляция на YouTube
🎞 Get ready for WWDC26 — короткое видео Apple о том, как выжать максимум из недели
📅 Расписание WWDC26
🖼 WWDC26 wallpapers - новые обои для Mac, iPad и iPhone
🎧 WWDC26 Hello playlist - плейлист Apple Music для настроения
💬 Apple Developer Forums - место, где обычно быстро всплывают первые вопросы по новым SDK
📦 Downloads — сюда идем после анонсов за beta SDK, Xcode и сопутствующими инструментами
Время UTC+3 / московская тайм-зона:
20:00 Apple Keynote
23:00 Platforms State of the Union
Сессии и материалы будут доступны в Apple Developer, на сайте и на YouTube. Нас ждёт самая насыщенная неделя для iOS-разработчиков: новые SDK, Xcode, SwiftUI, Apple Intelligence и всё то, что завтра придётся аккуратно приносить в реальные проекты 🥂 | 1 475 |
| 13 |  +3🐥 Swift в браузере: кейс Goodnotes, который стоит прочитать iOS‑командам
Иногда кроссплатформенность звучит как "давайте перепишем всё на что-нибудь универсальное и будем страдать одинаково везде". Кейс Goodnotes интереснее: команда взяла большой Swift-код iPad-приложения и вынесла его в web через WebAssembly, не превращая продукт в демо ради конференции.
По цифрам там всё серьёзно: 2,2 млн строк Swift в web-версии, из них 1,47 млн строк общего кода. Общими оказались не кнопочки, а дорогая часть: движок рендера, модель документов, распознавание рукописного ввода, индексации, ViewModel-и. UI и платформенные интеграции остались разными.
Если бизнес-логика, I/O и concurrency прибиты гвоздями к UIKit, GCD и конкретной платформе, то никакой WebAssembly, server-side Swift или будущий SDK вас красиво не спасёт.
О чем я бы задумался:
🟢где доменная логика зависит от UIKit/SwiftUI/Foundation API без реальной причины
🟢есть ли абстракции для network, storage, analytics, feature flags и clock
🟢не спрятаны ли DispatchQueue, locks и callbacks внутри кода, который можно перевести на async/await
🟢нет ли предположений вроде Int всегда 64-bi» в форматах, индексах, offsets и persisted data
Портируемость начинается не с платформы, а с границ
Хороший маленький тест: можно ли прогнать core-логику в обычном Swift Package без симулятора и без UIApplication? Если нет, проблема обычно не в WebAssembly, а в архитектуре
protocol NotesAPI {
func document(id: DocumentID) async throws -> Document
}
struct DocumentIndexService {
let api: NotesAPI
let clock: any Clock<Duration>
func rebuild(id: DocumentID) async throws -> SearchIndex {
let document = try await api.document(id: id)
return SearchIndex(document: document)
}
}
Этот код скучный, зато именно такая скука потом позволяет запускать тесты быстро, менять transport без переписывания core и аккуратно выносить части продукта в другие окружения. AI-generated code часто усиливает старые архитектурные привычки: если в проекте всё связано со всем, агент будет быстро генерировать ещё больше такого же кода | 1 252 |
| 14 | +3 🧵 Swift в браузере: кейс Goodnotes, который стоит прочитать iOS‑командам
Иногда кроссплатформенность звучит как «давайте перепишем всё на что-нибудь универсальное и будем страдать одинаково везде». Кейс Goodnotes интереснее: команда взяла большой Swift-код iPad-приложения и вынесла его в web через WebAssembly, не превращая продукт в демо ради конференции.
По цифрам там всё серьёзно: 2,2 млн строк Swift в web-версии, из них 1,47 млн строк общего кода. Общими оказались не кнопочки, а дорогая часть: rendering engine, document model, распознавание рукописного ввода, indexing, view models. UI и платформенные интеграции остались разными.
Для iOS-разработчика главный вывод не «срочно пишем сайт на Swift». Главный вывод: если бизнес-логика, I/O и concurrency прибиты гвоздями к UIKit, GCD и конкретной платформе, то никакой WebAssembly, server-side Swift или будущий SDK вас красиво не спасёт.
Что я бы проверил в проекте:
🟢 где доменная логика зависит от UIKit/SwiftUI/Foundation API без реальной причины;
🟢 есть ли абстракции для network, storage, analytics, feature flags и clock;
🟢 не спрятаны ли DispatchQueue, locks и callbacks внутри кода, который можно перевести на async/await;
🟢 нет ли предположений вроде «Int всегда 64-bit» в форматах, индексах, offsets и persisted data.
Портируемость начинается не с платформы, а с границ
Хороший маленький тест: можно ли прогнать core-логику в обычном Swift Package без симулятора и без UIApplication? Если нет, проблема обычно не в WebAssembly, а в архитектуре.
protocol NotesAPI {
func document(id: DocumentID) async throws -> Document
}
struct DocumentIndexService {
let api: NotesAPI
let clock: any Clock<Duration>
func rebuild(id: DocumentID) async throws -> SearchIndex {
let document = try await api.document(id: id)
return SearchIndex(document: document)
}
}
Этот код скучный, зато именно такая скука потом позволяет запускать тесты быстро, менять transport без переписывания core и аккуратно выносить части продукта в другие окружения.
Это стало особенно актуально сейчас:
🟡 до WWDC26 остаётся меньше недели, и новые SDK почти наверняка снова поднимут вопрос границ между app code, tooling, AI-assisted workflows и платформенными API;
🟡 AI-generated code часто усиливает старые архитектурные привычки: если в проекте всё связано со всем, агент будет быстро генерировать ещё больше такого же кода.
Я бы вынес отсюда практичный шаг на эту неделю: выбрать один важный сервис и попробовать собрать его как отдельный Swift Package с тестами. Не ради моды на кроссплатформенность, а ради более понятной, проверяемой и живучей iOS-кодовой базы. | 1 |
| 15 | 🧵Actor без state — это баг архитектуры или нормальный инструмент?
Кажется, Swift Concurrency опять подкинула тему - акторы, у которых нет собственных свойств и вроде бы нечего защищать. Кажется что Actor же нужен, чтобы изолировать mutable state. Нет state — нет смысла? Но иногда actor используют не только как сейф для данных, а как способ явно сказать компилятору и рантайму: этот кусок работы не должен жить на MainActor, его можно безопасно передавать между задачами, а синхронная часть должна выполняться в изоляции.
Например, типичный NetworkClient:
actor NetworkClient {
func loadCart() async throws -> [Product] {
let (data, _) = try await URLSession.shared.data(for: cartRequest)
return try JSONDecoder().decode([Product].self, from: data)
}
}
У него может не быть состояния вообще. Но actor всё равно даёт пару эффектов: тип становится Sendable, а синхронная работа внутри метода не уедет на main thread. Для JSON decoding это уже не совсем косметика.
Что я бы проверил в проекте:
🟢есть ли у ваших actors реальное состояние, которое они защищают;
🟢не используются ли actors просто как “модный async-сервис”;
🟢нет ли сериализации там, где нужна параллельная обработка;
🟢не появился ли actor только потому, что так проще заткнуть Sendable-ошибки;
🟢понятно ли, что будет больнее: добавить actor сейчас или убрать его через полгода.
Главная ловушка — actor сериализует синхронные куски работы
Если в NetworkClient прилетит много запросов, actor не будет параллельно декодировать ответы сколько угодно широко. Его изолированная синхронная работа идёт последовательно. Иногда это именно то, что нужно. А иногда вы случайно сделали бутылочное горлышко там, где хотели просто безопасный сервис.
Альтернатива может выглядеть так:
struct NetworkClient: Sendable {
@concurrent
func loadCart() async throws -> [Product] {
let (data, _) = try await URLSession.shared.data(for: cartRequest)
return try JSONDecoder().decode([Product].self, from: data)
}
}
Это не значит что struct всегда лучше actor. Скорее наоборот: если actor появился, нужно уметь объяснить, какую проблему он решает. Защищает cache? Синхронизирует доступ к файловой системе? Интегрируется с legacy queue через custom executor? Отлично.
Если ответ "просто делает сервис более concurrency-friendly” - тут уже стоит притормозить.
Отдельно важный кейс — файловая система
У actor может не быть state в виде properties, но state может жить снаружи: файлы, директории, on-disk cache. Компилятор этого не видит, зато гонки там вполне настоящие. В таком случае "пустой" actor может быть нормальной границей, которая сериализует доступ и не даёт разным частям приложения одновременно ломать один и тот же cache.
Это стало особенно актуально сейчас:
🟡Swift 6 всё сильнее заставляет думать про isolation и Sendable, а не просто писать async вокруг старого кода
🟡AI-агенты легко генерируют actors на любой чих, потому что это выглядит современно и компилятор часто становится тише
🟡но actor — это не декоратор безопасности, а синхронизационный примитив со стоимостью, очередью и архитектурными последствиями
Хорошее правило простое: если в коде появился actor, рядом должен быть внятный ответ, что именно он изолирует. Не обязательно property внутри себя. Это может быть UI, файловая система, serial executor или будущий cache. Но если ответ звучит как "ну, так вроде правильнее для async/await", значит это место лучше открыть в Instruments и в голове, пока оно не стало частью архитектуры. | 1 026 |
| 16 | 😄 AI в разработке: время новых процессов
Сейчас уже поздно спорить о том, нужен ли AI в разработке: он прочно вошёл в процессы — и в стартапах, и в бигтехе.
Эксперты Podlodka AI Crew собрали сезон «AI-First Development», чтобы обсудить уже не отдельные инструменты, а новую инженерную модель, в которой AI становится частью команды.
На конференции с 15 по 19 июня:
🗒️ Разберем, как делать AI-разработку более предсказуемой с помощью Open Spec Development
⚡️ Изучим model routing и prompt caching
⚙ Узнаем, как автоматизировать инженерные процессы с помощью AI
🤖Обсудим навыки и оркестрацию AI-агентов
⚡️ Посмотрим, как AI влияет на качество и скорость разработки.
Формат: пять дней живых Zoom-сессий по утрам и вечерам, закрытое комьюнити в Telegram и обсуждения со спикерами.
🎟 Посмотреть программу и купить билеты по ссылке
Скидка по промокоду BROADCAST_iOS_AI 🎁 — самая приятная цена для тех, кто успеет первым.
#реклама | 768 |
| 17 |  +1🧵 Swift Concurrency опять перестала быть магией
Все уже одной ногой на WWDC и ждут iOS 27, но в iOS-сообществе на этой неделе всплыла куда более приземленная тема: как понять, что реально происходит внутри вашего async/await. Мне нравится, что разговор снова вернулся к Instruments. Потому что вокруг Swift Concurrency до сих пор есть странное ощущение: раз код асинхронный, значит он автоматически быстрый и правильный. Нет, конечно 😁. Иногда это просто очень аккуратный способ наплодить лишних Task, забить actor, подвесить main thread и потом неделю ловить баг из серии: "на моем телефоне экран иногда тупит, но не всегда".
Свежий материал напоминает: у нас для этого есть не гадание по логам, а нормальные инструменты. В Instruments можно открыть Swift Concurrency template и смотреть не только Time Profiler, но и Swift Tasks, Actors, Hangs — то есть видеть, где код реально ждёт, где конкурирует за actor, а где просто делает больно UI.
Что я бы проверил в проекте:
🟢какие Task живут дольше, чем должны;
🟢нет ли actor contention там, где “просто завернули всё в actor”;
🟢не блокируется ли main thread в коде, который снаружи выглядит асинхронным;
🟢что происходит не на тестовых 20 элементах, а на нормальном объёме данных.
Отдельная мелочь, которая сильно помогает — task names
Без имён в отладке легко получить кашу из безликих задач. С именами хотя бы понятно, что именно сейчас выполняется: загрузка профиля, синк сообщений, рекомендации, кеш, аналитика.
await withTaskGroup(of: Void.self) { group in
group.addTask(name: "Load profile") {
await profileService.load()
}
group.addTask(name: "Load feed") {
await feedService.loadFirstPage()
}
}
Это стало особенно актуально сейчас:
🟡AI-агенты всё чаще пишут Swift-код. И они уже вполне могут собрать экран, завести сервис, добавить async и сделать так, чтобы happy path работал.
Но "собирается" и "нормально ведёт себя под нагрузкой" — это разные вещи. Агенту легко сгенерировать код, который выглядит современно, но плодит лишние задачи, плохо отменяется или держит actor в очереди без видимой причины.
Поэтому хороший цикл теперь такой:
→ написали async-код
→ прогнали реальные сценарии
→ открыли Instruments
→ посмотрели tasks/actors/hangs
Перед WWDC полезнее не гадать, что покажут в iOS 27, а снять baseline текущего проекта на Xcode 26.5. Тогда после новых SDK будет понятно, где проблема Apple, где миграция, а где ваш старый async-код просто наконец попросил внимания. | 1 216 |
| 18 |  📱 TimelineView в SwiftUI
Часто при задаче с обновлением UI по времени интуитивно хочется использовать Timer. Но в SwiftUI не всегда нужно вручную пушить изменения в @State. Правильным подходом будет дать системе таймлайн и сказать пересчитать view по таймлайну. Для этого есть TimelineView:
TimelineView(.everyMinute) { context in
Text(context.date, format: .dateTime.hour().minute())
}
Идея простая:
TimelineView сам сообщает SwiftUI, когда нужно заново вычислить body. А внутри closure вы получаете context.date — дату конкретного обновления. Мой UI зависит от времени, переоцени его по расписанию.
Оптимален такой подход для:
🟢часов и обратного отсчета
🟢виджеты времени внутри экрана
🟢периодически обновляемые visual states
🟢анимированные фоны
🟢Загружаемые загрузки
🟢градиенты и эффекты, которые меняются со временем
В SwiftUI уже есть несколько готовых расписаний:
🟢.everyMinute — обновление в начале каждой минуты
🟢.periodic(from:by:) — обновление с заданным интервалом
🟢.animation — обновление с частотой, подходящей для animated content
Например, если нужно показывать секунды:
TimelineView(.periodic(from: .now, by: 1)) { context in
Text(context.date, format: .dateTime.hour().minute().second())
.monospacedDigit()
}
А если нужно двигать визуальный эффект, можно вообще не хранить progress в @State.
TimelineView(.animation) { context in
let time = context.date.timeIntervalSinceReferenceDate
let hue = (sin(time * 0.2) + 1) / 2
Color(hue: hue, saturation: 0.7, brightness: 0.9)
}
важный сдвиг в мышлении В SwiftUI-модели лучше думать: "У меня есть view, значение которого зависит от времени" .И TimelineView как раз про это, но здесь легко ошибиться:
🟡TimelineView — не замена всем таймерам
🟡его не стоит использовать для бизнес-логики
🟡он не нужен, если вы просто хотите загрузить данные раз в N секунд
🟡он не должен становиться способом запускать side effects из UI
🟡частые обновления могут быть дорогими, особенно если view тяжёлый
Для обновления данных, или фоновой работы и координации логики обычный Timer, async task или background mechanism часто подходят лучше. TimelineView хорош именно тогда, когда меняется сам интерфейс. Ещё интересный момент — context.cadence. SwiftUI может снижать частоту обновлений, если live-updates сейчас не нужны или невозможны. Например, можно показывать миллисекунды только при .live, а при более редком cadence откатываться к обычным секундам.
TimelineView(.animation) { context in
let format: Date.FormatStyle =
context.cadence == .live
? .dateTime.hour().minute().second().secondFraction(.fractional(3))
: .dateTime.hour().minute().second()
Text(context.date, format: format)
.monospacedDigit()
}
И это очень Apple-like подход: не пытаться насильно обновлять UI всегда с максимальной частотой, а адаптироваться к тому, что система считает разумным прямо сейчас | 1 401 |
| 19 | 🚫 За что вас могут навсегда заблокировать во Flutter?
Многим кажется, что проекты с открытым кодом — это закрытый клуб для гениев. Тимлид Яндекс Доставки и по совместительству член core-команды Flutter Даниил Липаткин рассказывает, как всё устроено на самом деле.
Спойлер: просто будьте вежливы с людьми, даже когда отправляете код на проверку.
В материале:
🔶 Как выбрать задачу и не сломать проект.
🔶 Почему даже крутой код могут отклонить.
🔶 Как вносить свой вклад вообще без кода.
🔶 За что авторы могут навсегда заблокировать.
Если давно хотели начать писать открытый код, то это тот самый знак!
▶️ Прочитать полную статью можно в блоге Городских сервисов Яндекса
#реклама | 0 |
| 20 | 🚫 За что вас могут навсегда заблокировать во Flutter?
Многим кажется, что проекты с открытым кодом — это закрытый клуб для гениев. Тимлид Яндекс Доставки и по совместительству член core-команды Flutter Даниил Липаткин рассказывает, как всё устроено на самом деле.
Спойлер: просто будьте вежливы с людьми, даже когда отправляете код на проверку.
В материале:
🔶 Как выбрать задачу и не сломать проект.
🔶 Почему даже крутой код могут отклонить.
🔶 Как вносить свой вклад вообще без кода.
🔶 За что авторы могут навсегда заблокировать.
Если давно хотели начать писать открытый код, то это тот самый знак!
▶️ Прочитать полную статью можно в блоге Городских сервисов Яндекса
#реклама | 0 |
