Re: Что необходимо для того, чтобы iOS-приложение попало в App Store?

Вступление

Вместо того, чтобы писать очередной гайдлайн о гайдлайнах или ещё один App Store checklist, я хочу поделиться информацией, которая, как мне кажется, дает возможность посмотреть на процесс подготовки немного с другой стороны, сделать его более простым и доступным. Данная статья предлагает начинающим разработчикам ознакомиться с практикой Walking Skeleton (ходячий скелет) и приступить к так называемой ранней интеграции их програмных продуктов (Early Integration). В контексте iOS ранняя интеграция помимо ранней документации, тестирования наперед т.е. Test-Driven Development, означает ранние сборки продакшн-версий приложения для их последующего бета-тестирования с использованием Apple TestFlight или других сервисов.

Walking skeleton (ходячий скелет)

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

A Walking Skeleton is a tiny implementation of the system that performs a small end-to-end function. It need not use the final architecture, but it should link together the main architectural components. The architecture and the functionality can then evolve in parallel.

(взято с Alistair Cockburn: Walking skeleton)

Мой вольный перевод:

"Walking Skeleton (ходячий скелет) это минимальная реализация будущей системы, которая выполняет некую простейшую задачу. Такая реализация не требует полноценной архитектуры готового проекта, ее цель - первоначальная работоспособность компонентов будущей системы и их интеграция друг с другом. Когда минимальная реализация готова, архитектура и реализация могут развиваться параллельно."

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

• по шаблону Xcode создается одноэкранное iOS приложение (Single View Application)
• в Xcode проекте NewApp.xcodeproj создаются пустые, но рабочие тестовые таргеты (юнит-, интеграционное, acceptance и др. виды тестирования)
• проект ставится под контроль версий: Git, Mercurial или др.
• создаются первые фрагменты будущей документации
• налаживается процесс beta-тестирования (как можно раньше)
• дополнительная конфигурация инфраструктуры под специфику проекта

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

• документация того, что будет реализовано (практика documentation-first)
• пишутся соответствующий падающие тесты (test-driven development)
• затем и лишь на этом этапе начинается собственно реализация...

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

Процесс подготовки приложения к App Store

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

В рамках этой статьи процесс подготовки приложения к App Store можно условно разделить на две части (оба перечня неисчерпывающие, лишь для иллюстрации):

1. Приготовить все, что необходимо для любого приложения:

• 100 долларовый аккаунт разработчика Apple Developer
• Meta-data. Подготовить мета-информацию, такую как bundle identifier вашего проекта: com.mycompany.myapp, версия приложения: 0.1 и др.
• Code Signing. Подготовить App ID, ключи и сертификаты: главным образом, production distribution certificate и provisoning profile.
• Изображения. Подготовить картинки с размерами и названиями строго по гайдлайнам, главным образом App Icons и Launch Screens.

2. Приготовить все, что необходимо именно для вашего приложения:

• Убедиться в том, что сторонние (3rd party) библиотеки, которые включены в ваш проект, не используют private API фреймворков Apple.
• Желательно убедиться в том, что сторонние библиотеки имеют правильные и подходящие лицензии:
  • Выбор правильной лицензии для open-source проекта на Objective-C, чтобы не было проблем с App Store?
  • What is the reason for some of the Linux tools on OS X being so old? Is this related to GPL licensing?
• Все дополнительные части функционала вашего приложения работают в приложении, собранном в Release-конфигурации с помощью Archive. Например, для работы push-нотификаций требуется, чтобы Production APN certificate был привязан к вашему App ID.

Walking Skeleton и процесс публикации в App Store

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

• вы выбираете произвольное имя для шаблона Xcode для одноэкранного приложения (например, Sandbox, т.е. "песочница")
• не пишете никакого кода!
• создаете картинки всех разрешений в соответствии с требованиями Guidelines, картинки могут быть просто черным фоном - нужен лишь формальный набор картинок соответствующих разрешений!
• создаете необходимые мета-данные, вроде com.mycompany.sandbox, версии 0.1, и т.д.
• создаете Distribution Certificate на Apple Developer Portal и соответствующий Provisioning Profile
• собираете в iTunesConnect ваше приложение Sandbox с версией 0.1
• нажимаете Archive в Xcode, а затем Upload.

Суть в том, что при таком подходе вы сознательно игнорируете специфику вашего проекта: упражнение состоит в том, чтобы набить руку, разобраться в том, что минимально необходимо для любого релиза любого приложения. После того, как архив вашего приложения (напоминаю: это пустое приложение, созданное по шаблону Xcode и названное Sandbox!) загрузится в iTunesConnect, вы можете пойти туда и посмотреть, каковы следующие шаги и опции, что необходимо для отправки приложения на ревью. Среди прочего вы увидите форму для загрузки скриншотов приложения для всех видов разрешений, дополнительно необходимые поля, которые нужно заполнить перед отправкой приложения на рассмотрение Apple. Таким образом, вы увидите в тренировочном режиме все то, с чем вам придется столкнуться при реальной публикации. Это упражнение может помочь вам разобраться в деталях любой публикации и не волноваться при этом о том, одобрят ли ваше приложение, все ли сделано правильно и т.п., ведь это приложение лишь эксперимент. По ходу действий вы можете сделать заметки, свой собственный чеклист, в которых вы задокументируете свой опыт первой "песочной" публикации.

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

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

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

С тех пор, процесс публикации стал намного лучше:

• Сам процесс стал более отлаженным: стало в целом меньше ошибок, ошибки стали более понятными и дружелюбными;
• Валидации, которые производятся Xcode до загрузки архива приложения на iTunesConnect, стали более качественными, поэтому многие ошибки теперь выявляются до собственно подачи приложения на рассмотрение;
• Apple TestFlight, которые позволяет вам бета-тестировать те самые билды вашего приложения, которые затем подаются на рассмотрение App Store Review.

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

Заключение

В этой статье я постарался поделиться своим знанием о практике Walking Skeleton и ее возможном применении к процессу подготовки iOS приложения к публикации в App Store. Лично мне это знание стало доступно лишь на третьем году моей карьеры разработчика iOS, и так как это знание о необходимости ранней интеграции мне кажется очень ценным, я считаю своим профессиональным долгом поделиться им со своими менее опытными в iOS разработке коллегами. Надеюсь, что статья действительно окажется полезной начинающим.

При необходимости, для обратной связи вы можете связаться со мной по email, который можно найти на моем профиле GitHub.