Как проверить доступность iPhone Duo в Xcode 27.2? 2026

Сначала установите, что именно не удалось проверить

В примечаниях к выпуску Apple прямо указано, что VoiceOver, Accessibility Inspector и другие инструменты доступности в Device Hub не могут передавать экранное содержимое iPhone Duo. Это описание границы инструмента. Оно не утверждает, что приложение обязательно нарушает требования доступности, и не означает, что все способы проверки iPhone Duo недоступны. Для воспроизводимой проверки сохраните именно эту формулировку и сопоставьте её с фактическим поведением своей среды.

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

• экранное содержимое не передаётся инструменту;
• средство показывает содержимое, но в приложении отсутствуют или неверны сведения об элементе;
• проверка завершилась ошибкой из-за сценария, среды или настроек теста.

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

Описание самого Device Hub и управления симуляторами и физическими устройствами Apple находится в документации по Device Hub. При расследовании используйте её вместе с примечаниями к выпуску: общая документация о возможностях управления устройствами не отменяет отдельного ограничения, отмеченного для этой версии и этого устройства.

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

test_scope: iPhone Duo / экран оформления заказа
xcode: 27.2
environment: Device Hub
check: Accessibility Inspector — чтение содержимого экрана
result: not_verified
reason: инструмент не передаёт содержимое экрана для iPhone Duo
evidence: ссылка на журнал и приложенный снимок ошибки
owner: команда iOS QA

Это шаблон записи, а не утверждение о результате конкретного запуска. Значение not_verified важно: оно не равно ни failed, ни passed. Если в используемом формате отчётности нет такого состояния, заведите отдельную категорию «не проверено — ограничение инструмента» и не преобразуйте её автоматически в успешный статус.

Ошибку визуального макета разбирайте по состоянию интерфейса

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

Зафиксируйте исходные условия: открыт или закрыт экран, какая ориентация задана, какой экран приложения проверяется, куда перемещается фокус и на каком действии проявляется проблема. Важен не общий снимок «интерфейс выглядит неправильно», а связка «состояние — действие — ожидаемый вид — фактический вид». Так QA может отличить дефект адаптивной компоновки от проблемы, которая воспроизводится только в определённом пользовательском потоке.

Снимок экрана полезен как подтверждение геометрии, но его возможности ограничены. По нему можно обсуждать расположение, наложение или обрезание элементов; он не доказывает, что VoiceOver объявляет правильную метку, что фокус идёт в логичном порядке или что элемент доступен для взаимодействия. Эти выводы требуют другого вида проверки.

Практическая последовательность для визуальной проблемы:

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

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

Сведения о доступности проверяйте отдельно от чтения экрана

У элемента интерфейса могут быть нужные для доступности свойства, даже если Device Hub не может передать экранное содержимое. И наоборот: наличие метки в коде ещё не подтверждает корректный пользовательский опыт. Разделите проверку на сведения, заданные приложением, и поведение при использовании.

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

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

Чтобы выводы не смешивались, ведите для каждого пункта три самостоятельные записи:

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

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

Частые вопросы о проверке в Device Hub

Почему именно Device Hub не показывает содержимое?
Ориентируйтесь на описанное Apple ограничение чтения экранного содержимого средствами доступности в Device Hub для iPhone Duo. Сверьте версию Xcode, выбранную среду и конкретное средство, а затем сохраните наблюдение. Не распространяйте этот вывод на другие инструменты или все возможные сценарии без отдельной проверки.

Как дополнить проверки VoiceOver и Accessibility Inspector?
Проверяйте свойства интерфейса и макет раздельно, а критичные действия — в доступной для команды среде, которая позволяет наблюдать нужное поведение. Фиксируйте, что подтверждает каждый метод. Просмотр разметки или снимка не заменяет проверку того, как пользователь находит элемент, слышит его описание и выполняет действие.

Когда считать причиной ограничение, а когда — дефект?
Если не удаётся передать экранное содержимое и это совпадает с описанием Apple, зафиксируйте ограничение инструмента. Дефект приложения регистрируйте, если получено отдельное воспроизводимое свидетельство неверной реализации или поведения. Если такого свидетельства нет, оставьте результат непроверенным и запланируйте альтернативную проверку вместо предположения о причине.

Можно ли выпустить сборку на основании успешного статуса CI?
Только если нужные для выпуска проверки действительно выполнены и для них сохранены результаты. Успешная сборка или отсутствие ошибки в Device Hub не доказывают прохождение проверки, которую инструмент выполнить не смог. Команда определяет собственные критерии выпуска и ответственных за принятие остаточного риска; это рекомендация по управлению проверками, а не отдельное требование Apple.

Симулятор подтверждает не всё, что требуется от реального взаимодействия

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

Перед тем как переносить результат симулятора в критерии допуска, определите, какое утверждение он подтверждает. Например: нужный экран открылся; доступные автоматизации прошли; свойство элемента присутствует; известная компоновка воспроизводится. Не дополняйте это утверждение словами «взаимодействие VoiceOver полностью принято», если такое взаимодействие фактически не проверялось.

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

Чтобы согласовать разные команды, укажите владельца теста и минимальное свидетельство для каждого обязательного сценария. Например, QA может отвечать за запись фактического взаимодействия, платформа — за воспроизводимость среды CI, а ответственный за выпуск — за проверку полноты доказательств. Это рабочая модель распределения обязанностей, а не предписанная Apple схема.

Настройте отчёт Mac CI так, чтобы ограничение не маскировалось под успех

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

Полезно разделить статусы на четыре смысловые категории: проверка пройдена; обнаружен воспроизводимый дефект; проверка не выполнена из-за ограничения инструмента; проверка выполнена альтернативным способом. Последний статус должен вести к описанию метода и доказательства, иначе отчёт не позволяет понять, что именно было проверено.

Чтобы CI не превращал «не проверено» в «пройдено» при сводном подсчёте, согласуйте правила обработки статусов с QA и владельцами выпуска. Сборка может успешно собраться, а обязательная проверка доступности при этом остаться незакрытой. Эти два результата должны быть видны отдельно.

Для команд, которым требуется пересмотреть архитектуру Mac CI или способы удалённой работы со средой, пригодится обзор облачного Mac mini. А общие вопросы организации доступа и работы с удалённой средой можно сверить с центром помощи по облачному Mac. Такие материалы помогают оценить среду, но сами по себе не подтверждают выполнение теста доступности.

Решение о выпуске опирайте на покрытые сценарии и остаточный риск

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

Условия выбора следующего действия

• Если требуется подтвердить компоновку, а проблема видна на экране, проведите визуальную проверку в нужном состоянии устройства и сохраните снимок с условиями воспроизведения. Не засчитывайте этот результат как доказательство поведения VoiceOver.
• Если требуется подтвердить метки, роли или порядок фокуса, используйте доступный способ анализа свойств и отдельно отметьте, удалось ли наблюдать реальное взаимодействие.
• Если Device Hub не передаёт экранное содержимое, классифицируйте конкретную проверку как ограниченную или непроверенную. Не открывайте дефект приложения без независимого свидетельства и не присваивайте проверке статус успеха.
• Если симулятор прошёл тест, засчитывайте только тот класс поведения, который действительно проверялся в симуляторе. Для критичного взаимодействия добавьте подходящую проверку на физическом устройстве или альтернативный согласованный тест.
• Если обязательный сценарий не имеет результата, не включайте его молча в покрытые. Зафиксируйте владельца, способ дополнения и решение о риске до выпуска.
• Если Apple обновит инструменты или документацию, повторите проверку поведения в своей среде и измените процесс только после сохранения новых свидетельств.

Таблица ниже помогает отличать цель проверки от того, что её результат реально доказывает.

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

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

Практичный следующий шаг — взять ключевые пути приложения и создать для каждого запись «состояние — проверка — свидетельство — статус — владелец». Затем проверьте, может ли используемая Mac CI-среда стабильно выполнять именно те сборки и тесты, которые команда планирует на неё возложить. Если требуется временная среда для проверки такого процесса, ознакомьтесь с вариантами удалённого Mac от NodeMini; для постоянной тяжёлой нагрузки или сценариев, которым необходим физический интерфейс, сначала сравните аренду с собственным оборудованием и другими подходящими средами.