Мобильный трудоголик

Работа с растровыми изображениями во Flutter

Во Flutter размеры задаются в точках, а не в пикселях. Одна точка может соответствовать разному количеству пикселей в зависимости от плотности экрана. Чтобы изображение выглядело одинаково хорошо на всех устройствах, нужно подготовить несколько версий одного и того же файла под разные коэффициенты масштабирования.


Что такое devicePixelRatio:

Коэффициент devicePixelRatio показывает, сколько физических пикселей содержится в одной логической точке. На старых устройствах это 1x. На современных - 2x, 3x и даже 4x. Чем выше коэффициент, тем больше пикселей нужно для отображения одной точки.

Flutter автоматически выбирает нужную версию изображения, основываясь на плотности экрана устройства.


Сколько версий нужно:

Обычно достаточно подготовить изображения для коэффициентов 1x, 1.5x, 2x, 3x и 4x. Больше требуется редко. Меньше - может привести к размытию на устройствах с высокой плотностью экрана.

Каждая версия должна иметь размер, соответствующий ее коэффициенту. Например, если изображение в точках имеет размер 100x100, то для 2x нужно подготовить 200x200 пикселей, для 3x - 300x300.


Как организовать хранение:

Flutter ожидает, что файлы для разных коэффициентов будут лежать в отдельных папках. Имена папок должны соответствовать коэффициенту: x1.5, x2.0, x3.0, x4.0.

assets/
images/
x1.5/
photo.png
x2.0/
photo.png
x3.0/
photo.png
x4.0/
photo.png
photo.png

В pubspec yaml достаточно указать корневую папку. Flutter сам найдет нужные файлы в зависимости от плотности экрана.

flutter:
assets:
- assets/images/

🔗 Читать подробнее


Вывод:

Подготовка изображений под разные плотности экрана - обязательный шаг для качественного отображения. Несколько версий файлов в папках x1.5, x2.0, x3.0, x4.0 и правильное указание в pubspec yaml - все, что нужно.

Flutter делает выбор автоматически. Разработчику остается только подготовить ассеты и правильно организовать структуру. Это несложно, но влияет на внешний вид приложения на устройствах с разными экранами.

Конец эпохи: почему ИТ больше не привлекает молодежь

Еще недавно быть айтишником считалось престижно и модно. Все представляли себе программиста как свободного художника с высоким доходом, работающего с ноутбука под пальмой. Но времена изменились и сегодня ИТ теряет свою привлекательность для молодого поколения. Давайте разберемся почему.


Рынок переполнен джунами:

Ситуация напоминает историю с экономистами и юристами в 2000-х: вузы массово открыли ИТ-направления, не думая о качестве подготовки. Результат: тысячи выпускников, которые не могут найти первую работу.

Что происходит сейчас:

🔹 В России каждый технический (и даже нетeхнический) вуз выпускает программистов.

🔹 Компании уже не берут джунов с улицы, нужны реальные навыки.

🔹 Конкуренция за вакансии для начинающих достигает 300+ резюме на одно место.


Свобода исчезла:

Раньше ИТ ассоциировалось с гибким графиком, печеньками и комфортными офисами. После ковида многие поняли, что удаленка это не всегда рай.

Почему свободы нет:

🔹 Работодатели внедряют системы трекинга времени.

🔹 Возвращают обязательное присутствие в офисе, хотя бы 2 раза в неделю.


Зарплаты уже не те:

Миф о богатых айтишниках постепенно развеивается. На западе разница в доходах между ИТ и другими профессиями минимальна.

Реальность:

🔹 В Москве курьер может зарабатывать как middle-разработчик.

🔹 В Европе программист получает ненамного больше учителя или бухгалтера.

🔹 Новые профессии (блогеры, инфлюенсеры) приносят больше и быстрее.


Будущее неопределенно:

С появлением нейросетей многие рутинные задачи программирования автоматизируются. Уже сегодня ChatGPT пишет код и предлагает решения.

Что нас ждет:

🔹 Конкуренция с ИИ-инструментами.

🔹 Снижение порога входа (программировать сможет каждый).

🔹 Превращение профессии в ремесло.


Вывод:

ИТ становится обычной профессией, без особых привилегий и со стандартными рабочими буднями. Это не значит, что она плоха, просто перестала быть мечтой.

Многие приходили в ИТ за высокими зарплатами и свободой, не испытывая настоящей страсти к профессии. Именно такие специалисты первыми покидают отрасль при первых же трудностях, будь то сложные задачи, необходимость постоянно учиться или рабочие рутины. Однако те, кто получает настоящее удовольствие от решения нетривиальных задач и не боится постоянно осваивать новые технологии, всегда смогут адаптироваться и остаться востребованными.

Как добиться стабильного выполнения фоновых задач в iOS

Казалось бы, у вас в кармане суперкомпьютер. Он точно должен уметь выполнять рутинные задачи в фоне, пока вы занимаетесь своими делами. Как cron в Unix, который отлично работает с 1970 года. Но реальность iOS оказалась сложнее.

Автор статьи делится опытом работы с BGTaskScheduler - фреймворком для запуска фоновых задач. Методом проб и ошибок, работая с собственным устройством ему удалось добиться приемлемого уровня надежности фонового выполнения.


Типы фоновых задач в iOS:

Есть три основных типа фоновых задач:

🔹 BGAppRefreshTask: короткая задача для обновления. Предназначена для поддержания контента приложения в актуальном состоянии.

🔹 BGProcessingTask: для более тяжелой работы, которая может занимать минуты.

🔹 BGContinuedProcessingTask: появился в iOS 26. Запускается на переднем плане и может продолжать работу в фоне. Для автоматической синхронизации бесполезен.

Apple не публикует точных числовых ограничений. Реальные лимиты приходится выяснять вручную.


Как запланировать задачи:

Для этого необходимо отправить запрос и зарегистрировать обработчик:

let refresh = BGAppRefreshTaskRequest(identifier: "com.app.refresh")
refresh.earliestBeginDate = lastRun.addingTimeInterval(30 * 60)
try BGTaskScheduler.shared.submit(refresh)

let processing = BGProcessingTaskRequest(identifier: "com.app.process")
processing.earliestBeginDate = lastRun.addingTimeInterval(60 * 60)
try BGTaskScheduler.shared.submit(processing)

В обработчике обязательно нужно задать expirationHandler. Если этого не сделать, iOS отметит задачу как завершенную с проблемой.

BGTaskScheduler.shared.register(forTaskWithIdentifier: "com.app.process") { task in
task.expirationHandler = {
cancelWork()
task.setTaskCompleted(success: false)
}

Task {
let ok = await doWork()
task.setTaskCompleted(success: ok)
}
}

Точность планирования:

BGTaskScheduler не похож на cron. Задача может запуститься на несколько часов позже запрошенного времени. На устройстве автора processing задачи чаще запускались ночью на зарядке, а refresh днем, когда телефон активно использовался.

Полный цикл синхронизации укладывался в секунду. Это позволило зарегистрировать оба типа задач, чтобы дать iOS больше возможностей для запуска.

Ошибка: выполнение тяжелых операций в refresh задаче. После этого пробуждения стали менее надежными. Apple объясняет это энергетическим бюджетом приложения. Чем больше энергии и трафика потребляет задача, тем реже iOS ее запускает.


Подводные камни планирования:

BGTaskScheduler хранит только один ожидающий запрос для каждого идентификатора. Отправка нового запроса заменяет предыдущий. Если не проверять существующий запрос, можно бесконечно отодвигать задачу по времени.

static func shouldSkipSubmit(existingEarliest: Date?, desiredEarliest: Date) -> Bool {
guard let existingEarliest else { return true }
return existingEarliest <= desiredEarliest.addingTimeInterval(5)
}

Важно вычислять время от фиксированной точки, а не от текущего момента.

let desiredEarliest = max(
now.addingTimeInterval(60),
lastRun.addingTimeInterval(interval)
)

earliestBeginDate - это нижняя граница, а не расписание. iOS не гарантирует запуск в указанное время.


🔗 Читать подробнее


Вывод:

BGTaskScheduler не надежен как cron. Но добиться стабильного расписания можно. Планируйте задачи с фиксированной точки отсчета. Не пытайтесь бороться с iOS - она сама решает, когда запускать задачи. Используйте несколько типов фоновых задач, чтобы увеличить шансы на запуск. И помните: поведение пользователя и состояние устройства влияют на выполнение сильнее, чем ваш код.

Agent Skills в Xcode 27: актуальные навыки от Apple

В Xcode 27 появилась новая концепция - Agent Skills. Это наборы инструкций, которые обучают ИИ-агента выполнять конкретные задачи. В комплекте идет семь навыков от Apple: от работы со SwiftUI до аудита безопасности и взаимодействия с симулятором.


Что такое Agent Skills:

Agent Skill - это многократно используемый набор инструкций. Он объясняет агенту, как подходить к задаче: что проверять, какую последовательность действий соблюдать, какие ограничения учитывать и какие справочные материалы использовать.

В отличие от простого промпта, навыки структурированы и могут содержать не только инструкции, но и ссылки на дополнительные материалы. Агент загружает навыки и применяет их к конкретной задаче.


Семь навыков Xcode 27:

Apple включила в Xcode 27 семь готовых навыков:

🔹 SwiftUI Specialist: базовый навык для работы с SwiftUI. Содержит рекомендации по структуре вью, потокам данных, environment values, модификаторам, локализации, анимациям и идентичности элементов. Помогает агенту избегать устаревших API даже без формальной депрекации.

🔹 SwiftUI What's new in iOS 27: навык про новые API в iOS 27: макрос @State, reorderable контейнеры, жесты свайпа, кэширование AsyncImage и другие изменения. Решает проблему, когда модель обучена на старых данных и не знает о свежих API.

🔹 UIKit App Modernization: помогает адаптировать UIKit-приложения к современным многоконным средам. Заменяет устаревшие проверки вроде UIScreen.main на локальную информацию из сцены и окна.

🔹 Test Modernizer: обновляет тесты. Мигрирует XCTest-код на Swift Testing, заменяет ассерты на #expect и #require, перестраивает структуру тестов.

🔹 C Bounds Safety: для проектов с C и Objective-C. Объясняет, как использовать расширение -fbounds-safety для защиты от выходов за границы массивов.

🔹 Audit Xcode Security Settings: проверяет настройки безопасности проекта: предупреждения компилятора, статический анализ, укрепление бинарника, pointer authentication и другие опции.

🔹 Device Interaction: позволяет агенту взаимодействовать с симулятором или физическим устройством. Делать скриншоты, анализировать UI-иерархию, тапать, скроллить, вводить текст.


Как использовать навыки:

Навыки можно экспортировать в Markdown-файлы командой:

xcrun agent skills export ~/.agents/skills

После этого их можно использовать с любым агентом, поддерживающим Skills. Это означает, что одни и те же инструкции от Apple могут работать с Codex, Claude, Cursor и другими инструментами.


Почему это важно:

У LLM есть ограничение: они обучены на данных, которые на момент тренировки были актуальны. Новые API, изменения в iOS 27 и свежие рекомендации могут отсутствовать в знаниях моделей.

Skills решают эту проблему. Они поставляются вместе с Xcode и обновляются вместе с ним. Агент получает актуальные инструкции прямо из SDK, а не из устаревших данных моделей.


🔗 Читать подробнее


Вывод:

Agent Skills в Xcode 27 - это шаг к тому, чтобы ИИ-агенты могли работать с Apple-экосистемой на уровне экспертов. Вместо общих знаний модели агент получает актуальные инструкции от Apple.

Семь навыков покрывают основные сценарии: SwiftUI, UIKit, тесты, безопасность, C-код и взаимодействие с устройством. Их можно экспортировать и использовать с любым агентом.

Пока это только начало. Но направление ясно: Apple готовит Xcode для эры, когда код будет писать не человек, а агент. А навыки - это способ контролировать качество его работы.

Рынок ИТ изменился навсегда. Как не остаться за бортом

Коллеги, давайте честно: если вы разработчик и не можете найти работу, скорее всего это не ваша вина. Рынок изменился, но он не «умер». Он просто стал другим, более жестким, более избирательным и требующим новых стратегий. И сейчас я объясню, почему это даже хорошо для тех, кто готов адаптироваться.

Раньше ИТ воспринималось как социальный лифт: прошел курсы -> получил зарплату в 2-3 раза выше средней. Сейчас медианная зарплата разработчика в России около 200 тысяч рублей. Это достойные деньги, но уже не запредельные. Курьеры в крупных городах зарабатывают сопоставимо, а иногда и больше. ИТ перестало быть гарантией быстрого обогащения, но осталось сферой, где можно строить осмысленную и интересную карьеру.


Почему рынок изменился:

🔹 Перенасыщение. После бума 2010-х годов на рынок хлынули тысячи новичков. Сегодня на одну вакансию мобильного разработчика могут претендовать сотни кандидатов. Рекрутеры вынуждены устраивать «заградительные собеседования», чтобы отсеять тех, кто не соответствует требованиям.

🔹 Экономический кризис. Высокая ключевая ставка и общая экономическая нестабильность заставили компании сокращать бюджеты. В приоритете поддержка существующих продуктов, а не запуск новых. Многие проекты заморожены, а найм сведен к минимуму.

🔹 Санкции и уход западных компаний. Ограничение Apple App Store для многих российских компаний, ограничения Google Play, все это сократило количество рабочих мест и заставило многих iOS-разработчиков переквалифицироваться.

🔹 Рост no-code решений. Такие технологии, как BDUI (Backend-Driven UI), позволяют быстро создавать и обновлять интерфейсы без глубоких знаний нативной разработки. Бизнес все чаще выбирает экономию времени и ресурсов.

🔹 ИИ как конкурент. GPT и другие модели уже сегодня генерируют код на уровне джуниоров. Скоро контекстное окно увеличится до миллиарда токенов, и ИИ сможет самостоятельно создавать сложные приложения, интегрируясь с внешними API. Это изменит роль разработчика с «пишущего код» на «архитектора и контролера».

Но это не конец. Это новая реальность, в которой выживут сильнейшие, те, кто готов учиться, адаптироваться и предлагать уникальную ценность.


Что делать:

🔹 Сменить фокус с технологий на архитектуру. Умение проектировать системы, а не просто писать код, станет ключевым навыком. Изучайте чистую архитектуру, SOLID, паттерны проектирования. Ваша цель стать не «разработчиком», а «архитектором, который решает бизнес-задачи».

🔹 Освоить смежные области. Fullstack, DevOps, безопасность - все, что делает вас универсальным специалистом. Например, умение работать с облачной инфраструктурой (Kubernetes, Docker) или понимание принципов кибербезопасности резко повысит вашу ценность.

🔹 Использовать ИИ как инструмент, а не костыль. Не копируйте код из ChatGPT, а используйте его для генерации идей, декомпозиции задач и поиска решений. Ваша роль - критически оценивать предложения ИИ и дорабатывать их.

🔹 Прокачивать софт-скиллы и личный бренд. В мире, где рутину забирает ИИ, ценность приобретают человеческие качества: креативность, коммуникация, умение работать в команде. Ведите блог, выступайте на митапах, общайтесь в профессиональных сообществах. Ваша репутация может стать главным активом.

🔹 Рассмотреть смежные профессии. Data Engineering, ИИ-разработка - это направления, где спрос будет только расти. Да, придется учиться с нуля, но это инвестиция в будущее.


Вывод:

Да, рынок разработки больше не будет прежним. Но это не трагедия, а возможность перезагрузки. Те, кто готов меняться, углублять знания и брать на себя больше ответственности, не просто выживут, они окажутся в выигрыше. Ваша карьера зависит не от внешних обстоятельств, а от готовности расти вместе с технологиями.

Headless MCP сервер в Xcode 27 Beta 5

В Xcode 27 Beta 5 появился headless MCP сервер. Теперь можно запускать Xcode Tools без открытия самого Xcode. Агент может создавать проекты, собирать их, рендерить превью и управлять симулятором. Все через командную строку.


Что изменилось:

Раньше MCP сервер в Xcode работал только пока была открыта IDE. Как только вы закрывали Xcode - инструменты прекращали работу.

В Xcode 27 Beta 5 добавили команду xcrun mcp-server. Она запускает тот же сервер, но без графического интерфейса. В сочетании с экспортируемыми навыками Apple это позволяет агентам работать с проектом полностью автономно.


Включение headless режима:

sudo xcrun mcp-server enable
xcrun mcp-server start

После этого сервер работает в фоне. Статус можно проверить командой:

xcrun mcp-server status

Что нужно для работы:

Два компонента должны быть в репозитории.

🔹 Первый: регистрация MCP сервера. Это файл .mcp.json, который говорит агенту, как подключаться к Xcode.

{
"mcpServers": {
"xcode": {
"type": "stdio",
"command": "xcrun",
"args": ["mcpbridge"],
"env": {
"DEVELOPER_DIR": "/Applications/Xcode-beta.app/Contents/Developer"
}
}
}
}

🔹 Второй: скиллы Apple. Это файлы SKILL.md с инструкциями для агента: как писать SwiftUI, как работать с симулятором, как использовать новые API.

xcrun agent skills export --output-dir .claude/skills

После экспорта агент автоматически подхватывает навыки из папки .claude/skills.


Как работает разрешение:

Первый раз, когда агент пытается открыть проект, появляется системный запрос. Он идет от headless-сервиса, а не от Claude. Нужно подтвердить доступ к папке с проектом.

Разрешение можно дать на 24 часа или навсегда. Если нужно пропустить все запросы - есть флаг --unsafe-always-allow-all-agents. Но это не рекомендуется применять для прода.


Что может делать агент без Xcode UI:

После настройки агент может:

🔹 Создавать проект через XcodeNewProject.

🔹 Открывать проект через XcodeOpenWorkspace.

🔹 Собирать проект через BuildProject.

🔹 Рендерить превью через RenderPreview.

🔹 Запускать приложение на симуляторе.

🔹 Взаимодействовать с интерфейсом через тактильные команды.

🔹 Проверять логи через OSLog.


🔗 Читать подробнее


Вывод:

Headless MCP сервер в Xcode 27 Beta 5 - это шаг к автономной работе ИИ-агентов с проектами. Агенты могут создавать, собирать, тестировать и запускать приложения без участия человека в UI.

Навыки Apple дают агенту контекст: как писать код, как взаимодействовать с симулятором, как использовать последние API. Это превращает Xcode из IDE в платформу для агентской разработки.

Пока это бета. API может меняться. Но направление ясно: Apple готовит Xcode для эры, когда код будет писать не человек, а агент. А человек будет только задавать направление и проверять результат.

Apple выпустила гайдлайн по созданию хэдеров для приложений

На WWDC26 компания Apple анонсировала новые возможности для продвижения приложений. Теперь разработчики могут использовать хэдеры и другие креативные ассеты в поисковой выдаче, на странице приложения и в In-App Events. И недавно Apple выпустила подробные гайдлайны с примерами и шаблонами.


Новые ассеты:

В iOS 27 и iPadOS 27 появились новые визуальные элементы для App Store:

🔹 Хэдер: крупное изображение или видео в верхней части страницы приложения.

🔹 Ассет для поисковой выдачи: креатив, который пользователь видит до того, как зайдет на страницу приложения.

🔹 Ассеты для In-App Events: визуалы для временных событий внутри приложения.

Все ассеты хранятся в новой библиотеке Asset Library. Их можно загружать независимо от обновления приложения.


Общие правила для всех ассетов:

Apple сформулировала несколько ключевых принципов.

🔹 Визуал должен быть связан с приложением. Можно показывать не только интерфейс, но и брендовые элементы. Главное - чтобы пользователь понимал, что ему предлагают.

🔹 Ассеты должны быть актуальны для глобальной аудитории. Нельзя указывать цены, скидки или ссылки на сайты. Нельзя использовать не подтвержденные награды. Нельзя упоминать другие платформы и магазины.

🔹 Изображения должны быть инклюзивными, подходить для всех возрастов и не содержать контента, который может кого-то оскорбить.


Форматы и рекомендации:

Для статичных изображений Apple рекомендует использовать актуальный дизайн и четкий фокус. Текст должен быть коротким и дополнять визуал, а не дублировать его. Все элементы должны быть читаемы на разных устройствах - ключевые объекты лучше размещать в центре.

Для видео важно выбрать сильный постер. Видео должно начинаться с главной ценности приложения. Монтаж не должен быть слишком быстрым - пользователь должен успевать понять, что происходит. Видео зациклены, так что финал должен плавно переходить в начало.

Звук по умолчанию выключен. Поэтому визуал должен работать без звука. Если звук есть - это должно быть фоновое дополнение, а не способ передачи информации.


Что важно для хэдера:

Хэдер задает тон всей странице. Это первое, что видит пользователь. Apple рекомендует фокусироваться на одной идее. Не стоит перегружать визуал - это размывает впечатление.

Хэдер должен быть понятен человеку, который впервые видит приложение. Визуал должен быть цепляющим, но не перегруженным.

Можно использовать универсальный креатив для хэдера и поиска - это повышает узнаваемость бренда.


Как не совершить ошибку:

Apple прямо запрещает несколько вещей. Нельзя использовать логотипы или отсылки к другим платформам. Нельзя писать про цены и скидки. Нельзя ставить значки «Editor's Choice», «App of the Day» - они уже отображаются системой автоматически.

Важно помнить про возрастной рейтинг. Даже если приложение 17+, ассеты в App Store должны соответствовать 4+. Никакого оружия, направленного на зрителя, крови, откровенных сцен и запрещенных тем.


🔗 Читать подробнее


Вывод:

Новые креативные ассеты в App Store - это гибкий инструмент для продвижения. Хэдеры, поисковые креативы и ассеты для событий дают больше контроля над визуалом. Apple выпустила четкие гайдлайны, чтобы разработчики не тратили время на догадки.

Главное: помнить про ограничения. Не использовать цены, логотипы других платформ, контент для взрослых. И не перегружать визуал. Хороший хэдер - это одна идея, ясная с первого взгляда. И шаблоны помогут реализовать ее быстрее.

Синдром самозванца - обратная сторона роста в ИТ

Здравствуйте, друзья! Сегодня поговорим на одну неудобную, но очень важную тему. Ту самую, о которой многие молчат, но которая живет в голове у большинства из нас.

Вам знакомо чувство, когда смотришь на код коллеги и думаешь: «Вау, он такой умный, а я вообще ничего не понимаю»? Или когда получаешь оффер и первая мысль: «Ой, а они точно не ошиблись?»

Поздравляю, вы не одиноки. Это тот самый «синдром самозванца», и в мобильной разработке он распространен как нигде. Почему? Потому что экосистема iOS меняется со скоростью света. Только разобрался с UIKit, появился SwiftUI. Только освоил GCD, все переходят на async/await. Вчера Objective-C, сегодня Swift, завтра - кто знает, что еще.


Типы «синдрома самозванца»:

🔹 Перфекционист: будет переписывать код десять раз, потому что «еще не идеально». Знакомо? Многие иногда ловят себя на том, что тратят час на нейминг переменной.

🔹 «Я же должен все знать»: этот парень уверен, что Senior iOS разработчик должен помнить наизусть всю документацию Apple. А когда сталкивается с задачей, которую не может решить за пять минут, начинает сомневаться в своей профпригодности.

🔹 Одиночка: три дня бьется над проблемой с Auto Layout, но не спросит помощи, потому что «буду выглядеть глупо». Признаюсь, я и сам через это проходил в начале карьеры.

🔹 Супермен: берет все задачи подряд, работает по ночам, доказывает что-то миру и выгорает через полгода.

🔹 Вечный студент: «мне нужно пройти еще один курс по iOS-разработке, прежде чем я буду готов к собесу». Узнаете?


Что может помочь улучшить ситуацию:

🔹 Фокус на решении, а не на знании: вместо «я должен выучить весь Swift» думайте «мне нужно решить вот эту конкретную задачу». Это сильно снижает уровень давления.

🔹 Блокнот маленьких побед: звучит банально, но работает. Раз в неделю записывайте 2-3 вещи, которые получились хорошо: пофиксили сложный баг, помогли коллеге разобраться, написал чистый код. Со временем начнете видеть реальную картину вместо выдуманной.

🔹 Экспериментальный подход: смотрите на сложные задачи не как на экзамен, а как на исследование. Не получилось с первого раза? Ну и ладно, получили опыт, собрали данные, пробуйте иначе.

🔹 Помните, что сомнения - это нормально: если вы в чем-то не уверены значит вы растете и выходите из зоны комфорта. Отсутствие сомнений это скорее повод для беспокойства.


Вывод:

Синдром самозванца не исчезает с опытом. Он просто трансформируется. Даже спустя годы в индустрии иногда ловлю себя на мысли: «А не переоценивают ли меня?» Но теперь я понимаю, что это не слабость, а обратная сторона развития.

Apple сокращает команду Vision Pro и переключается на ИИ

Apple провела реструктуризацию, затронувшую команды, работающие над Vision Pro, Siri и ИИ-интеграциями. Сокращено более 200 позиций: около 100 в Vision Pro, 100 в Siri и софтверных командах. Это часть стратегии по перераспределению ресурсов в сторону новых ИИ-разработок и устройств.


Что произошло с Vision Pro:

Команда Vision Pro сокращена примерно на 100 человек. Закрыто направление, отвечавшее за игры и уменьшена группа, создававшая иммерсивный видео-контент. Причина кроется в дороговизне производства. Один эпизод 3D-видео может стоить несколько миллионов долларов, а количество активных пользователей у данного устройства остается небольшим.

Apple не полностью отказывается от иммерсивного видео. Компания планирует производить меньше такого контента силами Apple и больше полагаться на сторонних разработчиков.


Почему так происходит:

Гарнитура, вышедшая в 2024 году за $3500 (сейчас стоит $3699) не стала массовым продуктом. Она оказалась дорогой, тяжелой и нишевой. Основное применение нашла в инженерной и медицинской среде, где требуется высокая точность визуализации.

Новый CEO Джон Тернус, по слухам, с самого начала не был сторонником Vision Pro. Именно он весной 2025 года перехватил команду разработчиков прикладного ИИ и контролировал развитие Apple Intelligence. Его приоритеты очевидны - ИИ и устройства, которые могут быть интегрированы в повседневную жизнь большего числа пользователей.


Сокращения в Siri и ИИ-командах:

100 сокращений пришлись на команды Siri и Intelligent Systems Experience - подразделение, отвечающее за интеграцию ИИ в устройства Apple. Это связано с переходом на новую архитектуру Siri AI.

Обновленная Siri, анонсированная на WWDC, построена на совершенно новой технической базе. Она должна понимать контекст, содержимое экрана и выполнять действия в приложениях. Переход на эту архитектуру требует других навыков, поэтому часть старых позиций сокращается, а новые создаются.


🔗 Читать подробнее


Вывод:

Apple сокращает 200 позиций - это капля в море для компании со штатом в 166 тысяч человек. Но это четкий сигнал: приоритеты изменились.

Vision Pro оказался слишком дорогим, слишком тяжелым и слишком нишевым. Иммерсивный контент - слишком дорогим в производстве. Игры - не нашли аудиторию. Компания не закрывает продукт, но сворачивает активное развитие.

Новая стратегия - ИИ и устройства, которые можно носить каждый день. Умные очки. AirPods с камерами. Siri, которая действительно работает. Vision Pro был экспериментом. И, судя по всему, Apple сделала соответствующие выводы.

Код после нейросетей: почему без рефакторинга не обойтись

Всем привет! Недавно я писал пост с иронией про новый скилл разработчиков: чистку кода от вайбкодинга. Оказалось все куда серьезнее и это не ирония, а реальность рынка.


Что происходит:

Компании начали нанимать дорогих разработчиков для одной задачи - чистить код, который сгенерировали нейросети. Появились целые продукты, бизнес которых построен на приведении AI-кода в человеческий вид.


Три главные проблемы ИИ-генерации кода:


Неэффективность и изобретение велосипедов:

Нейросети прямолинейны как трамвай. Если в проекте уже есть функция умножения двух чисел, ИИ напишет новую. Если есть готовый хелпер для работы с датами, создаст свой.

Результат: дублирование кода, раздутые билды и архитектурный хаос.


Проблемы безопасности:

Нейросети игнорируют базовые правила безопасности. В коде остаются:

🔹 Проблемы с аутентификацией.
🔹 Утечки чувствительных данных.
🔹 Уязвимости инъекций.


Низкая читаемость кода:

ИИ любит:

🔹 Вкладывать функции в функции до бесконечности.
🔹 Создавать мега-файлы с десятками методов.
🔹 Генерировать многословные комментарии вместо понятного кода.

Получается не архитектура, а дерево зависимостей, где все вызывает все.


Мой опыт:

В личных проектах я активно использую ИИ для рутины, но перед релизом такой код требует серьезного рефакторинга. Особенно страдают:

🔹 Code style: совсем не соответствует внутренним стандартам проекта.
🔹 Переиспользование кода: дублирует существующую логику.
🔹 Архитектура: ИИ не понимает текущую архитектуру приложения и концепцию разделения ответственности.


Вывод:

Нейросети не заменяют разработчиков, они меняют их роль. Теперь мы не только пишем код, но и рефакторим и приводим в порядок то, что создает ИИ.

iOS 27: что нового в SwiftUI navigation transitions

В iOS 27 SwiftUI получил обновление для управления анимациями при навигации. Раньше для переходов было только два встроенных варианта: .automatic и .zoom(sourceID:in:). Теперь добавили .crossFade и AnyNavigationTransition. Это дает больше гибкости без необходимости писать кастомные решения.


Проблема с zoom:

ZoomNavigationTransition хорошо работает, когда у перехода есть визуальный источник. Пользователь тапает карточку или ячейку, и она плавно расширяется до полноэкранного вида. Это выглядит естественно.

Но что делать, если экран открывается по-другому? Например, из deeplink, уведомления, App Intent или Siri. В таких случаях у системы нет визуальной точки отсчета. Zoom становится искусственным и неестественным.


Решение - crossFade:

В iOS 27 появился CrossFadeNavigationTransition. Это новый тип перехода, который не требует источника. Экран просто плавно появляется через затемнение, без привязки к какому-либо элементу.

.sheet(isPresented: $showInfo) {
LandmarkInfo()
.presentationDetents([.medium])
.navigationTransition(.crossFade)
}

Идеально для случаев, где у системы нет визуального источника. Например, открытие по уведомлению или из виджета.


Динамический выбор перехода через AnyNavigationTransition:

Второе нововведение - AnyNavigationTransition. Раньше .navigationTransition(_:) требовал конкретный тип на месте вызова. Нельзя было выбрать переход динамически, в зависимости от того, как был открыт экран.

Теперь можно обернуть любой переход в AnyNavigationTransition и использовать как значение.

struct LandmarkInfo: View {
var useCrossFade: Bool

var transition: AnyNavigationTransition {
useCrossFade
? AnyNavigationTransition(.crossFade)
: AnyNavigationTransition(.automatic)
}

var body: some View {
InfoContent()
.presentationDetents([.medium])
.navigationTransition(transition)
}
}

Один и тот же экран может открываться по-разному. По тапу - используем zoom. Из уведомления - crossFade. По диплинку - automatic. И это работает без дублирования кода.


🔗 Читать подробнее


Вывод:

CrossFadeNavigationTransition решает проблему переходов без визуального источника. AnyNavigationTransition позволяет выбирать переход динамически в зависимости от контекста.

Современные приложения открываются не только по тапу на ячейку. Виджеты, уведомления, Siri, universal links - каждый сценарий требует своего поведения. Новые API делают навигацию в SwiftUI более гибкой и естественной.

Когда логи бессильны: истории о самых неочевидных багах в мобильной разработке

Всем привет! Сегодня хочу поговорить о самой изматывающей части работы разработчика: поиске багов, которые возникают в самых неожиданных условиях. Когда проблема есть только у одного пользователя, воспроизводится раз в полгода и вообще выглядит как мистика.


Загадка с Face ID и темной темой:

Недавно мы получили странный баг-репорт: «Приложение зависает при попытке войти через Face ID». Особенность была в том, что проблема возникала только у пользователей с включенной темной темой и только на iPhone 14 Pro.

Логи показывали стандартный поток аутентификации, но при вызове Face ID приложение просто замирало. Оказалось, что кастомная анимация загрузки конфликтовала с системным модальным окном Face ID в темной теме. Система пыталась применить темную тему к нашему кастомному компоненту, что приводило к бесконечному циклу обновления UI.


Проблема с арабским языком и скроллом:

Другой интересный случай: пользователь жаловался на дергающийся скролл в списке. Особенность: устройство было настроено на арабский язык с направлением текста справа налево.

Мы тестировали приложение с английским и русским языками, но забыли про RTL-локации. Оказалось, что кастомный индикатор скролла неправильно рассчитывал позицию при RTL-раскладке, из-за чего происходило постоянное перерисовывание контента.


Режим энергосбережения как тормоз:

Классика: жалобы на тормозящее приложение, когда у телефона меньше 20% заряда и включен режим энергосбережения. Система ограничивает производительность, а пользователь винит наше приложение.


Slide Over и потерянный контент:

Еще одна история: пользователь сообщал, что в режиме Slide Over на iPad пропадает часть контента. При обычном использовании все работало идеально.

Проблема была в том, что мы не учитывали изменение safe area insets в компактном режиме. Контент просто уезжал за границы видимой области, но только при определенной ширине Slide Over.


🔗 Читать подробнее


Что я из этого вынес:

🔹 Контекст важнее технических данных: иногда нужно спросить не «что делали?», а «где и при каких условиях?».

🔹 Логи не всесильны: они показывают только то, что мы предусмотрели.

🔹 Пользователи живут в другом мире: их сценарии использования часто отличаются от наших, тестовых.

🔹 Тестируйте неочевидные сценарии: темная тема, разные языки, специальные возможности.

🔹 Учитывайте особенности платформы: Slide Over, Split View, Picture-in-Picture.

Разрабатывайте не только для идеальных условий. Пользователи будут использовать ваше приложение в самых неожиданных местах и ситуациях. И иногда самое сложное не пофиксить баг, а найти его причину.

Apple дает бесплатный доступ к Foundation Models в Private Cloud Compute для небольших разработчиков

На WWDC 2026 компания Apple объявила, что разработчики с менее чем 2 миллионами первых загрузок в App Store смогут использовать Foundation Models, работающие в Private Cloud Compute, без оплаты облачного API. Это делает ИИ-инфраструктуру доступной для тех, кто только начинает.


Кто может получить доступ:

Условия простые. Разработчик должен быть участником программы малого бизнеса Apple. Общее количество первых загрузок всех его приложений в App Store должно быть меньше 2 миллионов. Также нужен entitlement для Private Cloud Compute.

Если приложение превышает лимит, Apple уведомляет разработчика и дает 6 месяцев на переход к платной модели или альтернативному решению.


Почему это важно:

Сейчас эксперименты с ИИ перестали быть дешевыми. Запросы к большим моделям - это затраты на инфраструктуру, которые для начинающих разработчиков могут стать серьезным барьером. Apple убирает этот барьер, давая доступ к моделям с беспрецедентной защитой приватности.

Это похоже на программу малого бизнеса, где Apple снижает комиссию для небольших разработчиков. Цель - привлечь независимых разработчиков и стартапы, которые не хотят нести дополнительные расходы на облачные сервисы.


Что еще изменилось в Foundation Models:

В этом году платформа расширяется. Появилась поддержка работы с изображениями. Добавлена интеграция с серверными моделями - разработчики могут подключать поставщика облачных услуг по своему выбору. Это дает гибкость для решения более сложных задач.


🔗 Читать подробнее


Вывод:

Apple делает ИИ доступным для небольших команд. Бесплатный доступ к Foundation Models в Private Cloud Compute - это способ снизить порог входа в мир больших моделей. Независимые разработчики могут экспериментировать и создавать функции на основе ИИ без начальных затрат на инфраструктуру.

Если приложение выстрелит и превысит 2 миллиона загрузок - придется начать платить. Но к тому моменту у разработчика уже будет работающий продукт, а не гипотеза. Это разумный подход, который помогает стартапам не тратить дополнительные средства на этапе прототипа.

Релиз Dart 3.13: что принесла новая версия

Вышла новая версия Dart 3.13. Главное изменение - primary constructors стали стабильными. Это сокращает количество шаблонного кода при объявлении классов. Кроме того, улучшили форматирование, добавили tree-shaking для нативных библиотек и обновили поддержку веба.


Primary constructors стали стабильными:

В Dart 3.13 primary constructors наконец-то добавили в стабильную версию. Теперь класс с полями и конструктором можно объявить в одну строку.

class Point(final int x, final int y);

Больше не нужно писать отдельный конструктор и повторять имена полей. Для миграции добавили новые линты с автофиксами и рефакторинг «Convert to primary constructor» прямо в IDE.


Форматер стал умнее:

В dart format несколько изменений, которые делают код чище. Исправлена ошибка, из-за которой методы с большими коллекциями форматировались некрасиво. Теперь вызовы разбиваются более читаемо.

Также форматер начал автоматически разделять секции импортов пустыми строками, как того требует Effective Dart. Импорты dart:, package: и относительные пути теперь визуально отделены друг от друга.


Tree-shaking нативных библиотек:

Появилась возможность удалять неиспользуемый нативный код из финального бинарника. Раньше даже если вы вызывали только одну функцию из большой нативной библиотеки, вся библиотека оставалась в сборке. Теперь это можно исправить.

Нужно пометить FFI-биндинги аннотацией RecordUse(), а в link hook через package:record_use оставить только те символы, которые действительно вызываются. Если биндинги не используются - библиотека выкидывается целиком. Это значительно уменьшает размер финального приложения.


Web - deferred loading и отказ от dart:html:

Для dart2wasm появилась экспериментальная поддержка отложенной загрузки (--enable-deferred-loading). Это улучшает время начальной загрузки больших приложений.

Также библиотека dart:html объявлена устаревшей. Вместо нее нужно использовать dart:js_interop и package:web. Многие пакеты уже мигрировали, так что обновление зависимостей часто решает проблему автоматически.


🔗 Читать подробнее


Вывод:

Dart 3.13 - насыщенное обновление. Primary constructors сокращают шаблонный код. Форматер делает импорты чище. Tree-shaking нативных библиотек уменьшает размер бинарников. Веб-инструменты двигаются в сторону dart2wasm и современных библиотек.

Primary constructors упростят код, а tree-shaking пригодится в проектах с тяжелыми нативными зависимостями. Особенно если вы собираете релизные сборки, где каждый мегабайт имеет значение.

Apple добавила CLI для Foundation Models

На WWDC26 компания Apple представила новый способ работы с Foundation Models. Теперь с ними можно взаимодействовать не только через Xcode, но и напрямую из терминала. Для этого достаточно обновить Mac до последней версии, установить Xcode 27 (бета) и запустить команду fm в консоли.

Инструмент позволяет отправлять запросы к моделям, проверять их доступность, считать токены и работать со структурированными данными. Например команда fm respond "Ваш запрос" отправит запрос к модели, а fm available покажет, какие модели доступны на устройстве. Есть поддержка потоковой передачи, структурированного вывода через JSON Schema и работа с изображениями. CLI также позволяет запускать локальный сервер для интеграции с другими инструментами.


🔗 Читать подробнее


Вывод:

Foundation Models CLI - это шаг к тому, чтобы сделать Apple Intelligence доступной не только для iOS-разработчиков, но и для всех, кто работает в терминале. Скрипты, автоматизация, быстрые эксперименты - теперь все это можно делать без Xcode.

Релиз Flutter 3.47: главные изменения для разработчиков

Вышла новая версия Flutter 3.47. Обновление заметное. Material и Cupertino наконец-то выехали из SDK в отдельные пакеты. Impeller стал рендерером по умолчанию на десктопе. Плюс подготовка к осенним обновлениям Apple и другие улучшения. Давайте разберем все основные изменения.


Material и Cupertino теперь отдельные пакеты:

Главное изменение: Material и Cupertino больше не встроены в SDK. Теперь это отдельные пакеты на pub dev: material_ui и cupertino_ui. Это значит, что обновления виджетов теперь могут выходить независимо от релизов Flutter.

Пока это опционально. Старые импорты из package:flutter/material.dart все еще работают, но они объявлены устаревшими и будут удалены в ноябре.

Для миграции достаточно выполнить команду:

dart fix --apply --code=migrate_design_widgets

После этого импорты обновятся автоматически. Если что-то пошло не так, можно добавить пакеты вручную:

flutter pub add material_ui
flutter pub add cupertino_ui

Важный момент для пакетов с зависимостями: если вы еще не обновились, а ваши зависимости уже используют новый подход, поможет MaterialUiCompatibilityBridge.

Также вместе с UI-пакетами разобрали flutter_localizations. Теперь делегаты локализации живут внутри material_ui и cupertino_ui, а не в отдельном пакете.


Подготовка к iOS 27 и macOS 27:

Apple осенью выпустит Xcode 27 с новыми требованиями. Минимальная версия iOS поднята до 15, macOS до 12. iOS 27 SDK требует жизненного цикла UIScene. Приложения без него не запустятся на новых устройствах.

Для большинства проектов CLI мигрирует автоматически. Но если в проекте есть кастомный AppDelegate, придется править руками. Лучше проверить сейчас.

Также Flutter постепенно сворачивает поддержку Intel Mac. В этой версии только предупреждения, но в будущем сборка на Intel перестанет работать. Можно уже сейчас переключиться на ARM64-only:

flutter config --enable-macos-arm64-only

По Swift Package Manager прогресс: 92 из топ-100 плагинов уже перешли на SPM. Если вы еще не включили SPM, можно попробовать:

flutter config --enable-swift-package-manager

Impeller теперь на десктопе по умолчанию:

Impeller стал рендерером по умолчанию на macOS, Windows и Linux. Если вы не знаете, что это - новый рендеринг-движок, который компилирует шейдеры на этапе сборки, а не в рантайме. Это решает проблему шейдерных джанков. Первая анимация работает так же плавно, как и все последующие.

На macOS также включили Wide Gamut Color - более насыщенные и точные цвета.

Отключить Impeller можно, но в будущих версиях опция будет удалена.


Flavors для десктопа:

Flavors, которые работали на мобилках, теперь доступны и на Windows и Linux. Можно использовать разные ассеты и настройки для разных окружений.

flutter build windows --flavor production
flutter build linux --flavor staging

Экспериментальный многооконный режим тоже доработали. На Windows и Linux появились popup-окна. Можно делать контекстные меню и палитры.


🔗 Читать подробнее


Вывод:

Flutter 3.47 - важное обновление. Главное - Material и Cupertino выехали из SDK. Это упростит обновления виджетов и снизит зависимость от релизов Flutter.

Impeller на десктопе - большой шаг для производительности. Flavors и многооконный режим делают десктоп-разработку более гибкой. А подготовка к осеннему релизу Apple заставляет проверить проекты на совместимость.

Ошибки iOS-разработчиков при работе с Derived Data

Всем привет! Сегодня поговорим о Derived Data - одной из самых загадочных, но важных папок в жизни iOS-разработчика. Хотя мы редко взаимодействуем с ней напрямую, именно здесь Xcode хранит кэш для ускорения сборки проектов.

Обсудим основные ошибки, которые совершают разработчики при работе с Derived Data:


Непонимание предназначения папки:

Derived Data это не просто папка для мусора. Здесь хранится:

🔹 Кэш компиляции модулей.
🔹 Информация о Swift packages.
🔹 Символы для отладки.
🔹 Собранные бинарные файлы.

Папки с суффиксом .noindex (ModuleCache, SDKStatCaches, SymbolCache) лучше не трогать без необходимости. Хотя иногда их очистка помогает решить проблемы с симулятором, в 90% случаев достаточно работать только с папкой конкретного проекта.


Ручной поиск папки:

Не ищите Derived Data вручную через Finder! Есть простой способ:
Xcode -> Settings -> Locations -> Derived Data

Маленькая синяя стрелка - это кнопка, которая мгновенно откроет папку в Finder.


Удаление папки Derived Data:

Классическая ошибка, когда Xcode заглючил, многие удаляют всю папку Derived Data. Правильный подход:

🔹 Сбросить настройки симулятора.
🔹 Сделать Clean Build в Xcode.
🔹 Удалить ТОЛЬКО папку проблемного проекта.

Удаляя всю Derived Data, вы заставляете Xcode пересобирать ВСЕ проекты с нуля, что может занять много времени.


Игнорирование метрик сборки:

Это особенно критично для команд. Представьте:

🔹 Сборка замедлилась на 30 секунд.
🔹 В команде 20 разработчиков.
🔹 Каждый делает 10 сборок в день.

Итого: команда теряет полтора часа в день!

Решение: использование инструменты вроде RocketSim Team Insights для мониторинга:

🔹 Время типичной и максимальной сборки.
🔹 Разницу между чистыми и инкрементальными сборками.
🔹 Влияние версий Xcode и macOS на производительность.

Эти данные помогают обосновать покупку новых MacBook для команды, иногда это дает до 30% прироста скорости!


Отсутствие анализа сборок:

В подпапках проекта в Derived Data лежит собранное приложение. Если заглянуть внутрь (Show Package Contents), то можно обнаружить следующие папки и ресурсы:

🔹 Resources: могут содержать неиспользуемые ассеты.
🔹 Frameworks: иногда там остаются ненужные зависимости.
🔹 Bundles: сторонние библиотеки могут добавлять лишние ресурсы.

Это напрямую влияет на размер приложения! Однажды нам удалось уменьшить размер приложения на 70 МБ, благодаря удалению неиспользуемых ресурсов и лишних библиотек.


Неиспользование кэша для CI/CD:

Многие команды напрасно игнорируют Derived Data в процессах непрерывной интеграции. При каждой сборке на CI-сервере Xcode заново компилирует все зависимости. Правильный подход: кэшировать папку Derived Data между сборками, особенно:

🔹 Кэш компиляции Swift Packages.
🔹 Скомпилированные модули зависимостей.
🔹 Кэш Asset Catalog.


Игнорирование проблем с инкрементальной сборкой:

Если вы замечаете, что Xcode постоянно пересобирает файлы, которые не менялись - проблема часто кроется в Derived Data. Типичные причины:

🔹 Поврежденный кэш модулей.
🔹 Неправильные временные метки файлов.
🔹 Конфликт версий Swift компилятора.

Решение: использовать флаг -driver-show-incremental в настройках сборки, чтобы увидеть, что именно заставляет Xcode пересобирать файлы. Это помогает выявить проблемы с зависимостями и оптимизировать структуру проекта.


Вывод:

Derived Data не враг, а мощный инструмент для оптимизации процесса разработки. Правильная работа с ним экономит часы и нервы.

Советы, которые помогли бы мне в начале карьеры в ИТ

За годы работы в ИТ я собрал советы, которые значительно ускорили бы мне рост на старте карьеры.


Никогда не поздно сменить направление:

Многие остаются в нелюбимом направлении из-за комфортной зарплаты или страха начать заново. Но самый большой рост происходит именно тогда, когда вы слушаете себя, а не внешние обстоятельства. Если чувствуете, что перестали развиваться - это знак, что пора что-то менять.

Я начинал с web-разработки на PHP, но со временем понял, что мобильная разработка для меня гораздо интереснее.


Инструменты меняются, принципы остаются:

Не зацикливайтесь на конкретных технологиях. Языки и фреймворки приходят и уходят, а фундаментальные принципы, такие как архитектура, алгоритмы, проектирование остаются актуальными годами. Умение адаптироваться ценнее знания конкретного стека.


Командная работа - вот настоящая суперсила:

Современная разработка невозможна в одиночку. Системы контроля версий, ревью кода, CI/CD - это не просто инструменты, а необходимость. Чем раньше вы освоите культуру совместной работы, тем быстрее будете расти.


Умение искать информацию важнее запоминания:

Не пытайтесь держать все в голове. Ключевой навык это быстро находить и фильтровать информацию. Правильный запрос в поисковике или чат-боте часто ценнее часа чтения документации.


Практика единственный путь к мастерству:

Теория дает основу, но настоящие навыки приходят только с практикой. Не бойтесь экспериментировать и делать ошибки, именно так формируется настоящий опыт.


Баланс не роскошь, а необходимость:

Выгорание не признак профессионализма. Регулярный отдых и перезагрузка это инвестиция в вашу продуктивность и креативность. Качество работы важнее количества часов.


Широкий взгляд важнее узкой специализация:

Программирование это не только написание кода. Понимание бизнес-контекста, коммуникация с командой, умение работать с требованиями часто важнее технических деталей.


🔗 Читать подробнее


Вывод:

Карьера в ИТ - это марафон, а не спринт, где важно сохранять гибкость мышления и готовность к изменениям. Самые успешные специалисты не те, кто знает все, а те, кто умеет адаптироваться, сотрудничать и постоянно учиться. Найдите то, что приносит вам искреннее удовольствие, и не бойтесь менять направление, именно это приводит к настоящему профессиональному удовлетворению и росту.

Тайпчекер в Swift 6.4 стал быстрее

В Swift 6.4 продолжается работа над улучшением тайпчекера. Знаменитая ошибка «The compiler is unable to type-check this expression in reasonable time» во многих ситуациях теперь будет появляться реже. Слава Пестов в большом посте на Swift Forums делится прогрессом по роадмапу и показывает, как это работает на практике.


О проблеме известно давно:

Тайпчекер в Swift - это сложная система, которая пытается вывести типы выражений, когда они не указаны явно. Чем больше перегрузок, дженериков и неявных преобразований, тем сложнее компилятору найти правильный тип. Иногда он перебирает слишком много вариантов и либо выдает ошибку, либо компилирует слишком долго.

В Swift 6.3 добавили механизм favoring - когда компилятор пытается угадать наиболее вероятный вариант перегрузки и проверяет его первым. Это работает хорошо, когда угадывание правильное. Но если нет - компилятор все равно перебирает все варианты, и это может занять много времени.


Что изменилось в Swift 6.4:

В Swift 6.4 появился механизм, который называется disjunction pruning - обрезка перегрузок. Суть простая: когда компилятор проверяет конкретную перегрузку функции, он может понять, что она точно не подходит. В таком случае он просто исключает этот вариант из рассмотрения.

Раньше компилятор мог потратить время на перебор вариантов, которые заведомо не работают. Теперь он сразу понимает, что вариант не подходит, и даже не пытается его проверить.

Это работает в двух направлениях. Если из всех вариантов остался только один подходящий - компилятор сразу выбирает его, не тратя время на остальные. Если же подходящих вариантов не осталось - компилятор сразу понимает, что выражение ошибочно, и не пытается перебирать дальше.


Улучшения в binding inference:

Вторая важная область - вывод конкретных типов из неявных преобразований. Раньше, когда компилятор видел выражение вроде Int conv $T (где $T - неизвестный тип), он не мог сразу понять, чему равен $T. Приходилось откладывать решение и перебирать варианты позже.

В Swift 6.4 появилась более точная логика, которая анализирует все ограничения на тип одновременно. Если все ограничения указывают на единственный возможный тип - компилятор выбирает его сразу. Если же ограничения противоречат друг другу - компилятор понимает, что выражение ошибочно, и не тратит время на перебор.


Что это дает на практике:

Есть несколько примеров, которые раньше компилировались очень долго или вообще не компилировались.


🔹 Побитовые операции с UInt64:

func f(word: UInt64, offset: Int, numBits: Int) -> UInt {
    return UInt((word >> offset) & ((1 << numBits) - 1) & ((1 << numBits) - 1) & ((1 << numBits) - 1))
}

В Swift 6.3 это выражение было слишком сложным для тайпчекера. В Swift 6.4 компилируется мгновенно.


🔹 Операции с SIMD:

func f() {
  let u = SIMD2<Float>(0, 1)
  let v = SIMD2<Float>(1, 2)
  let r = [2*u + 3*v, 4*u + 5*v, 5*u + 6*v, 6*u + 7*v]
}

Теперь тоже компилируется быстро.


🔹 Словари с IUO (implicitly unwrapped optional):

func f(str: CFString!) {
  let _ = [
    str: String(str),
    str: String(str),
    str: String(str)
  ]
}

Раньше было слишком сложно, теперь - мгновенно.


🔹 Цепочки вызовов с lazy, flatMap, map, filter - раньше занимали секунды, теперь миллисекунды.


🔗 Читать подробнее


Вывод:

Swift 6.4 не делает тайпчекер идеальным, но делает его заметно быстрее в распространенных сценариях. Механизмы disjunction pruning и улучшенный binding inference позволяют компилятору быстрее принимать решения и избегать перебора заведомо неподходящих вариантов.

Это не решит все проблемы с тайпчекингом, но во многих случаях ошибка «unable to type-check in reasonable time» станет встречаться реже. А в некоторых сложных выражениях компиляция ускорится в десятки раз. Хорошее улучшение для повседневной разработки.

Как изменится продвижение приложений в App Store с выходом iOS 27

На WWDC26 компания Apple показала несколько обновлений, которые касаются не только разработчиков, но и тех, кто занимается продвижением приложений. Изменения в App Store и App Store Connect затронули визуальное оформление карточек, управление креативами и персонализацию рекомендаций.


Header вместо Feature Banner:

В карточке приложения появился новый визуальный элемент - Header. Раньше на этом месте мог быть только баннер, который добавлялся через модерацию Apple и был доступен не всем. Теперь хэдер можно будет загружать самостоятельно через App Store Connect.

Главное отличие от скриншотов и промороликов - header не обязан показывать только интерфейс приложения. Это может быть брендовый креатив, сезонное изображение, видео с атмосферой продукта. Например приложение доставки еды может показывать аппетитный бургер, а не скринкаст с каталогом товаров.

Хэдер можно использовать в нескольких местах: на главной странице приложения, в поисковой выдаче, на странице с товарами приложения и в рекламных объявлениях Apple Ads. Причем это один и тот же ассет, который загружается один раз и применяется в разных местах.

Те приложения, которые не внедрят качественные хэдер, рискуют потерять клики и установки на фоне конкурентов. Визуал в выдаче становится еще одним фактором конкуренции.


Библиотека ассетов:

Самое практичное изменение - появление Asset Library в App Store Connect. Теперь все медиа (скриншоты, проморолики, хэдер) хранятся в одном месте и организованы по платформам и размерам.

Главное преимущество: креативы можно загружать и отправлять на модерацию без выпуска нового билда приложения. Раньше, чтобы поменять скриншоты к новому году или подстроить графику под рекламную кампанию, нужно было ждать новый релиз. Теперь маркетинг не зависит от разработчиков при работе с визуальным составляющим в App Store.

Загруженные ассеты можно переиспользовать в разделе с товарами приложения, In-App Events и рекламных кампаниях. Все из одной библиотеки, без дублирования загрузок.


Персонализированные рекомендации:

Apple анонсировала новый тип подборок - персонализированные коллекции. Они формируются не модераторами, а алгоритмами на основе поведения пользователя. App Store анализирует, какие приложения пользователь устанавливает и как использует, и на основе этого адаптирует рекомендации.

Коллекции будут появляться на вкладках «Приложения», «Игры» и в поиске. К каждому приложению будет выводиться объяснение, почему оно релевантно конкретному пользователю.

Для маркетологов это означает, что органический трафик станет качественнее, но менее предсказуемым. Алгоритмы - это черный ящик. Чтобы попадать в рекомендации, придется работать в тесной связке с разработчиками. App Intents теперь важны не только для Siri, но и для того, чтобы алгоритмы Apple Intelligence правильно считывали семантику приложения и понимали, кому его рекомендовать.


🔗 Читать подробнее


Вывод:

WWDC26 принесла несколько полезных обновлений для тех, кто продвигает приложения в App Store. Хэдер добавляет новый визуальный слой в карточку приложения и поисковую выдачу. Библиотека ассетов убирает зависимость маркетинга от разработчиков при работе с визуалом. Персонализированные рекомендации открывают новые возможности для органического трафика, но требуют более тесной работы с семантикой приложения.

Самое важное изменение - маркетинг теперь может обновлять креативы независимо от релизов. Это серьезно упрощает работу с визуалом и ускоряет эксперименты. Если вы занимаетесь продвижением приложений, стоит изучить новые возможности до осеннего релиза iOS 27.