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

Руководство по адаптации приложений под iPhone Duo

Apple выпустила руководство по адаптации приложений под iPhone Duo - свой первый складной смартфон. Главная новость: отдельного FoldableKit нет. Apple просто продолжает двигать разработчиков в сторону адаптивных интерфейсов.


С чего стоит начать:

Приложение будет работать на iPhone Duo, даже если оно не собрано при помощи iOS 27 SDK. Но чтобы использовать все возможности, нужно обновление.

В режиме совместимости, как iPhone-приложение на iPad, все будет работать не очень красиво. Если собрать с iOS 27 SDK, появится полноэкранный режим с черным статус-баром. С iOS 27.1 SDK можно сделать полноценную поддержку.

Для тестирования нужно скачать Xcode 27.1 и выбрать симулятор iPhone Duo в Device Hub. Там можно открыть, закрыть, повернуть и сложить устройство, чтобы посмотреть, как ведет себя layout.


Как работает адаптация:

На внешнем экране iPhone Duo все выглядит как на обычном iPhone: regular для вертикального положения, compact для горизонтального. На внутреннем экране - regular и по горизонтали и по вертикали. Это позволяет показывать sidebar и больше контента.

Внутренний экран не обязан соблюдать supportedInterfaceOrientations. Apple прямо говорит: не проверяйте ориентацию для layout-решений. Используйте size classes.


Проблема с UIScreen.main:

У iPhone Duo два дисплея, поэтому понятие UIScreen.main становится неоднозначным. Apple объявила такие обращения устаревшими.

Если действительно нужен экран конкретного окна, его можно получить через UIWindowScene:

window?.windowScene?.screen

Но лучше вообще работать через environment, traits и размеры самой scene.


Асимметричные safe areas:

Safe area теперь может быть асимметричной. Формула width - leftInset * 2 больше не гарантирует правильный результат. Левый и правый inset могут отличаться из-за формы устройства, камеры и системного UI.

Apple советует считать каждую сторону отдельно. Весь интерактивный UI держать внутри safe area, а фон растягивать edge-to-edge.


Автоматическая адаптация:

Если вы используете стандартную навигацию, большая часть адаптации произойдет автоматически. NavigationSplitView, UISplitViewController, TabView, UITabBarController, sheets, popovers и alerts уже умеют адаптироваться к разным положениям Duo.

На внутреннем экране tab bar можно автоматически превратить в sidebar. Для SwiftUI это настройка default tab bar placement, для UIKit - preferred placement.


ReservedRegion:

В iOS 27.1 появилась новая возможность - ReservedRegion в SwiftUI и UIViewReservedRegion в UIKit. Она нужна кастомному edge-to-edge UI, чтобы сказать системе: дай максимум пространства, но не залезай туда, где уже живет системный интерфейс.

Это полезно для собственных баров и сложных лайаутов.


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


Вывод:

iPhone Duo не приносит отдельный фреймворк. Apple просто продолжает давить в сторону адаптивного интерфейса. Не определять устройство. Не ориентироваться на конкретную ширину. Не считать, что экран один. Не ожидать симметричные safe areas. Если вы уже следовали этим правилам, у вас будет минимум работы по адаптации.

Реалии разработки: почему 50% времени уходит не на код

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


Цикл разработки, который знаком каждому:


Неделя 1 - начало разработки:

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


Неделя 2 - ожидания тестирования:

Отдел тестирования перегружен, ваша задача висит в статусе «готова к тестированию». Вы переключаетесь на другие задачи и проекты, постепенно забывая детали реализации. Контекст стирается, а энтузиазм угасает.


Неделя 3 - неожиданное возвращение:

Внезапно приходит сообщение: «Задача возвращена на доработку». Оказывается, требования изменились, нашли краевой случай или продукт-менеджер придумал улучшение. Теперь вам нужно заново вникать в задачу, которую вы уже считали завершенной.


Немного статистики:

🔹 Каждая третья фича возвращается на доработку минимум один раз.

🔹 15% задач требуют кардинальных изменений после тестирования.

🔹 Среднее время ожидания тестирования: от 2 дней до 7 дней.

🔹 Большинство разработчиков одновременно ведут несколько задач.


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

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


Как с этим работать:


Ментальные практики:

🔹 Не привязываться эмоционально к написанному коду.

🔹 Воспринимать изменения не как неудачу, а как возможность сделать продукт лучше.

🔹 Понимать, что выпиливание фичи - это не личное поражение, а забота о пользователе.


Построить рабочие процессы:

🔹 Организовать регулярные встречи с продукт-менеджерами для синхронизации.

🔹 Проводить промежуточные демо для стейкхолдеров до финального тестирования.

🔹 Выполнить детальные чек-листы перед сдачей задачи.

🔹 Назначить четкие критерии приемки для каждой фичи.


Вывод:

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

Apple может изменить App Store, чтобы увеличить доходы

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


Почему ушел Фил Шиллер:

Новый курс стал одной из причин, по которой Фил Шиллер покинул руководство App Store. 66-летний топ-менеджер хотел уделять больше времени семье и благотворительности, но, по информации Bloomberg, одновременно опасался, что попытка извлечь из магазина еще больше денег усилит противостояние Apple с разработчиками и государственными регуляторами.

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


Как Шиллер относился к разработчикам:

Бывший глава отдела проверки приложений Apple Филлип Шумейкер, напротив, рад уходу Шиллера. Его мнение: «У него не было ни малейшего желания садиться за стол с разработчиками и модернизировать правила. Не из злого умысла, а из убеждения, что правила пишет Apple, а разработчики должны им следовать - и точка».


Что может измениться:

Есть несколько потенциальных способов увеличить прибыльность App Store:

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

🔹 Второй вариант: повысить стоимость участия в Apple Developer Program. Сейчас она составляет $99 в год. Многие независимые разработчики уже тратят сотни долларов в месяц на инструменты вроде Claude и Cursor. Теоретически Apple могла бы повысить ежегодный взнос без потери значительной части разработчиков.

🔹 Третий вариант: взимать с крупных разработчиков дополнительную плату в зависимости от объема трафика. Так Apple могла бы переложить часть расходов на инфраструктуру App Store на наиболее крупные приложения.


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


Вывод:

Конкретных изменений Apple еще не объявляла. Пока это лишь возможные варианты. Но ясно одно: новое руководство Apple рассматривает App Store не только как платформу распространения приложений, но и как направление, из которого можно получать больше регулярной выручки и более высокую прибыль.

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

Работа с растровыми изображениями во 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 выпустила четкие гайдлайны, чтобы разработчики не тратили время на догадки.

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