Xcode *

Привет, Хабр! На связи снова Максим из ATI.SU.

В первой части цикла мы разложили нативную автоматизацию iOS на винтики: разобрались, какое место UI-тесты занимают в пирамиде тестирования, познакомились с фреймворками, раннерами и артефактами сборки и собрали всё в единый алгоритм создания автотеста. Теперь пора переходить к практике.

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

В этой статье разберём:

- что такое таргет в Xcode и зачем он нужен;

- какие настройки важно проверить перед началом работы;

- как добавить UI Testing Bundle в новый и существующий проект;

- на что обратить внимание при настройке подписи и сертификатов.

iPhone Duo сломал часть допущений, зашитых в iOS-приложения с 2007 года: экранов теперь два, safe area асимметрична, «только портрет» больше не значит что думаете. Разбираю по докладам Apple, что реально меняется в вашем Swift-коде — size classes, reserved regions, arrangements, hinge и камера.

Одна минута macOS-раннера в GitHub Actions стоит десять минут Linux. Я перенёс iOS-сборку Flutter-приложения в Xcode Cloud: с ~45 оплачиваемых минут на релиз до 6, без .p12 и профилей в секретах, с тремя shell-скриптами вместо 90 строк YAML. Внутри — схема тегов ios/v* и android/v*, настройки Xcode Cloud, которые молча сжигают compute-часы, и таблица семи падений первого живого прогона — ни одно из них не было ошибкой миграции. Плюс чек-лист и открытый скилл, который из этого вырос.

Привет, Хабр!

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

Привет, Хабр! На связи снова Максим из ATI.SU.

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

Возникает логичный вопрос: можно ли автоматизировать именно эту рутину — прогон сценариев, — чтобы проверки проходили без нашего участия, а нам оставалось разбираться с причинами сбоев, если такие возникнут? Здесь нам помогут нативные автотесты на XCUITest. Они позволяют системно, а не от случая к случаю, прогонять пользовательские сценарии, отслеживать падения и проверять стабильность. А когда тест краснеет, в дело снова вступают логи и креш‑отчёты — те самые, что мы научились искать в предыдущих статьях.

Этой статьёй мы открываем цикл о UI‑тестировании iOS приложений. Начнём с основ: разберёмся, какое место UI‑тесты занимают в пирамиде тестирования, познакомимся с инструментами и постепенно перейдём к построению устойчивых тестов с применением проверенных паттернов.

Привет! Сегодня хочу поделиться, как мне кажется, очень полезной информацией о такой важной теме, как Opaque types vs Existensial Types vs Generics — что это такое, в чем разница и что выбрать. Я действительно считаю эту тему важной, поскольку это мощнейшие инструменты, которые нам дает swift, чтобы сделать код более гибким, поддерживаемым, универсальным и без лишнего дублирования. Итак, погнали. 

Нет, это не déjà vu, это продолжение моей прошлой статьи Самый быстрый XML парсер для iOS в 2026 году? Чтобы вам не тратить время на ее чтение, вот краткий пересказ. В прошлой статье происходит поиск самого быстрого XML парсера со следующими характиристиками:

Для Apple платформы (iOS, tvOS, macOS)

Язык Objective-C или Swift

GitHub как источник исходников

Популярный (хотя бы больше 500 звезд)

Любая интеграция (CocoaPods, SwiftPM)

И самое важное, весь бенчмарк я писал сам с небольшой помощью ИИ, не спеша, под несколько чашечек кофе за 3 часа я нашел нужный мне XML парсер.

Спустя пару месяцев после выхода первой статьи, мне пришла мысль, зачем я тратил 3 часа на эту задачу, если можно было просто это самое задание “скормить” ИИшке и она бы за 5 минут решила бы ее (так пишут в интернетах). Тут же пришла вторая идея. Так как у меня есть мною лично проверенный результат, то я могу загрузить этой задачей все популярные ИИ и их результаты сравнить со своим. Даже не исключаю, что у меня где-то есть ошибка и тогда рейтинг парсеров будет выглядеть совсем иначе и я выбрал не самый быстрый как хотел.

Собственно, что я и сделал. Загнал задачу в топ 15 ИИ и сравнил их результаты со своим. Если вам интересно, кто справился с задачей, кто спасовал, будет описано в развернутой статье под катом.

Для затравки, наихудший результат и последнее место занимает GPT 5.5 Pro. А Claude Opus 4.7 не смог взять первое место.

Вообще‑то, я бэкендер последние лет 20, но недавно остался без работы (и AI тут не причём), решил «замутить» свой «стартап», пока ищу новую работу Java‑программиста. А заодно подтянуть новые технологии, поглубже изучить немецкий и английский и немного развеяться…

Писать приложения под iOS было моим хобби последние лет 10, и пару моих приложений до сих пор постоянно висят в топе в Российском AppStore, но это были всё «игрушки», а захотелось сделать что‑то взаправду стоящее, и так возникла идея написать лучшее (ни больше ни меньше) приложение для изучения языков с помощью аудирования. Точнее, товарищ подсказал идею. А ещё точнее — идея давно была реализована под Андроид, но аналогов под iOS нет, а очень хотелось. И мне, и товарищу:). Да и смартфона с андроидом у меня нет и никогда не было, не судите строго, но не люблю я вирусы и глюки.

Идея следующая: берёте любое аудио на любом нужном вам языке, загружаете в приложение, и оно автоматически (можно так же вручную) разбивает аудиофайл на нужные вам сегменты для «шэдоуинга», аудирования, многократного прослушивания и тому подобного. Аналогов в сторе я не нашёл, точнее, что‑то отдалённо похожее там есть, но без своих настроек, без выбора своего контента для изучения, без красивой визуализации аудио, короче, без всего того, что нам бы хотелось иметь.

Итак, идея есть, какие технологии использовать? В старых моих приложениях был UIKit, Realm/CoreData, и, сториборды. Не судите строго, я как бэкэндер тогда не знал, что использование сторибордов среди «трушных» айосников считается плохим тоном и плохой приметой. Но теперь‑то я решил использовать современные технологии! И выбрал такой стэк: SwiftUI, SwiftData, Speech Framework. Что касается последнего, то он вроде бы доступен ещё с iOS 10, но я решил, что технологии развиваются, и распознавание текста из аудио должно было бы сделать со времени iOS 10 огромный рывок вперёд. Но теперь я не так сильно в этом уверен, и об этом эта моя маленькая статья…

За последний год я перепробовал всё: Cursor, Claude Code, Codex, локальные Qwen-модели для ревью, пять версий своего CLAUDE.md, Xcode MCP от Apple, mobile-mcp, Conductor для параллельных агентов. Что-то осталось в проде, что-то выкинул через неделю. А какие-то вещи, которые казались обязательными год назад, сегодня выглядят как антипаттерны.

Это статья не про «AI изменит всё» и не про то, как за вечер собрать Todo-приложение через Claude Code. Это про то, как iOS-разработчику, который уже живёт с AI-инструментами, выжать из них максимум - и не наступить на грабли, на которые наступили до тебя остальные.

Представьте ситуацию: вы работаете в огромном проекте, где количество модулей давно перевалило за тысячу. Вы решаете обновиться до свежего Xcode 26.2, ожидая прироста производительности, но вместо заветного «Build Succeeded» получаете молчаливое падение: SWBBuildService quit unexpectedly.

Всем привет, меня зовут Алексей Севко, я ведущий разработчик программного обеспечения из команды Delivery & Performance Яндекс Go. В этой статье я расскажу почти детективную историю о том, как:

— Искать иголку в стоге сена: когда падает закрытый бинарник Xcode.

— Стать контрибьютором swift-build: почему иногда проще переписать системный поиск макросов в swift-build, чем ждать фикса от Apple.

— Использовать свою версию билд-системы: как мы внедрили инфраструктуру прозрачной подмены компонентов Xcode через XCBBUILDSERVICE_PATH, чтобы не ждать релиза Xcode со Swift 6.3 и работать стабильно уже сегодня.

Если ваш проект тоже перерос стандартные инструменты Apple или вам просто интересно, как превратить рекурсию в итерацию и не сойти с ума от 45-минутных дебаг-сессий, — добро пожаловать под кат!

Решение ошибки You do not have required role or permission to perform an operation при загрузке в TestFlight через Xcode

Столкнулся с ошибкой при отправке сборки в TestFlight из Xcode (впервые такое)

При этом:

✅ аккаунт в App Store Connect был владельцем

✅ все соглашения, налоговые формы и банковские данные были заполнены

✅ Bundle Identifier совпадал

✅ архив собирался корректно

Проблема оказалась не в правах App Store Connect, а в том, что в аккаунтах у меня было добавлено несколько учетных записей Apple ID. Из-за этого Xcode путался при работе с App Store Connect и при отправке сборки выдавал ошибку прав доступа.

Помог выпил из Xcode всех учеток кроме той, через которую выполняется публикация. 🔨

Многие приложения для здоровья в России перестали нормально работать. Omron — одно из них. А давление мерить надо каждый день. Поэтому я решил сделать своё iOS-приложение, которое через камеру считывает показания с любого тонометра, сохраняет их и строит графики динамики.

Я Senior CV-инженер — компьютерное зрение моя основная работа. Так что OCR с дисплея тонометра технически не должен был стать проблемой. Но как iOS-разработчик я — полный ноль. Xcode открыл впервые. Swift видел мельком. Это честный рассказ о том, как это выглядит изнутри.

И да, я делаю open source приложение за свободу здоровья от политики — и при этом только под iOS. Ирония не ускользнула. Но это open source — найдётся кто-нибудь с Android-девайсом и свободным вечером 🙂

Привет, Хабр! На связи снова Максим из ATI.SU. В прошлой статье мы научились собирать логи на iOS устройствах разными способами и теперь для нас не вопрос разобраться, почему кнопка не нажимается, а данные не грузятся.

Но бывают ситуации куда страшнее. Вы запускаете приложение, а оно... тут же исчезает. Или вы работали в приложении, раз... и вы видите домашний экран. А еще приложение может так зависнуть, что помогает только полная перезагрузка самого устройства. Все это — его величество креш (a.k.a. краш, крэш, crash, вылет, сбой, падение, аварийное завершение).

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

Для тестировщиков поймать креш и не допустить его до прода — это как для сапёра обезвредить мину раньше, чем на неё наступят. Работу можно сделать и после взрыва, но цена вопроса уже совсем другая. Сегодня я расскажу о 4+ проверенных способах собрать информацию о креше: от уже знакомых нам способов из предыдущей статьи до продвинутых систем мониторинга.

Всем привет! Меня зовут Роман, я iOS разработчик. Сегодня я поделюсь с вами пошаговым планом создания демо приложения на SwiftUI с использованием Yandex MapKit SDK. Поехали!

Небольшая инструкция для всех, кто работает в Unreal Engine и пишет на C++ или иных языках + компилирует файлы для Андроид.

2026 год. У вас 8–16 ядер в ноутбуке. M-чипы летают.

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

Вы нажимаете ⌘B – и одно ядро уныло крутится на 100% загрузки, пока остальные отдыхают.

Добро пожаловать в мир однопоточной компиляции Asset Catalog’а.

В этой статье я покажу, почему Asset Catalog тормозит сборку и как заставить Xcode использовать больше ядер CPU. Пошагово и с примерами.

Swift 6 вышел чуть больше года назад, однако iOS-сообщество не спешит поднимать версию в коммерческих проектах. Да и среди энтузиастов на Хабре не так много тех, кто готов поделиться практическим опытом миграции. Поэтому остаётся пробовать самому. Проверим, насколько сложно будет поднять версию для простого приложения на SwiftUI.

Привет! Меня зовут Ринат, я iOS-разработчик в Naumen. В компании я занимаюсь разработкой нескольких iOS-продуктов: клиента для SMP-сервера (Service Management Platform) и SDK чата.

В этой статье расскажу, как мы используем связку Proxyman + HAR, чтобы готовить mock-данные сетевых запросов для интеграционных UI-тестов одного из iOS-приложений. Такой подход выручает, когда для тестов нет возможности поднять сервер с нужным наполнением или сервер не предоставляет дополнительных методов API для имитации определенного сценария — например, переписка в чате с собеседником, обновление статуса заказа.

Xcode ужасен, и об этом много кто говорит. Постоянные ошибки, баги интерфейса, неочевидное поведение и местами плохая документация — всё это мешает спокойно писать код. Вместо работы над проектом приходится искать решения проблем и пытаться починить то, что должно работать из коробки. Ещё одна неприятность на этом пути заключается в том, что Apple не всегда публично рассказывает о багах в Xcode, поэтому надо ещё догадаться, что именно не работает.

В этой статье автор делится ошибками и «особенностями» Xcode, которые больше всего его раздражают. Главный совет: держитесь подальше от этой IDE и всегда ищите альтернативы.

Привет, Хабр! Меня зовут Максим, и я тестирую мобильные приложения в ATI.SU. Знакома ситуация, когда кнопка не работает, приложение виснет, анимации тормозят, но при этом нет никаких ошибок на экране?
Можно часами играть в детектива, гадая по UI и строя догадки, что пошло не так. А можно за несколько минут найти настоящего преступника — ведь iOS щедро оставляет улики в виде логов. Нужно лишь знать, где их искать. Секрет — в грамотном выборе способа, как собрать доказательства. Но обо всём по порядку.