iTunesConnect и дистрибуция iOS-приложений (в сравнении с Google Play) – 5 глава

Глава 1. Готовим данные для регистрации аккаунтов разработчика.

Глава 2. Всё-таки регистрируем.

Глава 3. Готовимся выложить приложение.

Глава 4. Продажа приложения и встроенных покупок.

Глава 5. Нюансы.

Приходит Петька к Василию Ивановичу и спрашивает:
— Что такое нюанс?
— Ну, Петька, хочешь узнать, тогда раздевайся…
Петька разделся.
— Становись раком…
Петька встал. Василий Иванович вставил. Петька:
— Ну и что?
— Ну вот смотри, Петька. У тебя член в жопе, и у меня член в жопе. Hо есть один нюанс…

Работая с iTunesConnect надо очень строго следить за своими косяками ибо сервис этот — как минное поле и ошибок не прощает. Да, вроде бы ты виноват — это всё понятно. Но зачем же так жестоко наказывать за малейшие ошибки? Наказание должно быть пропорционально степени вины.

5.1. Названия и идентификаторы

Вот к примеру: выложили мы одно приложение, но напутали с идентификатором. Пришлось делать новый идентификатор и для этого — новое приложение. Значит, старое надо убить — правильно? Правильно. Удаляем. Создаём новое и получаем ошибку: "Приложение с таким названием уже существует". Где же оно существует, если мы его только что удалили? iTunesConnect не позволит повторно использовать и идентификатор товара — даже если вы старый удалили, а новый создали и по логике вашего приложения те, кто купил первый, считаются покупателями и второго.

Ну ладно, решит читатель, не всё потеряно — наверняка, ведь, можно восстановить удалённое приложение и изменить ему название? А вот и нельзя! Никак нельзя вернуть удалённое приложение. Ни сам бинарник, ни информацию о нём. При этом, очевидно же, что эта информация где-то сохраняется.

5.2. Изменения

Если вы решили что-то изменить в данных своего приложения: добавить скриншотов, которые пользователи видят в App Store, поменять категорию, изменить ключевые слова для удобства поиска — вам нужно создавать новую версию и отправлять её на модерацию. Причём, необходимость модерации вроде как понятна — вдруг вы решили добавить какой-нибудь неприличный скриншот смеха ради. Но зачем же требовать новую версию?

Представьте, что у вас — жёсткий план. На каждую версию расписаны изменения, которые должны быть реализованы. Так вот — все изменения в iTunesConnect придётся привязывать к выходу новой версии. Здесь нельзя просто пересобрать приложение — нужно обязательно перещёлкнуть версию. iTunesConnect не учитывает номер билда — у вас не получится вместо 2.1.8.512 загрузить 2.1.8.514 — только 2.1.9. Пару раз нам из-за этого даже приходилось пропускать некоторые номера версий.

5.3. Каникулы

Сотрудники ItunesConnect так усердно работают, создавая проблемы разработчикам, что им нужен отдых. Например, недельку, ммм… ну, скажем, перед самым Новым Годом — а почему бы и нет? В течение этого времени нельзя ничего выкладывать — сервис просто недоступен. Советское обслуживание просто в ужасе щемится в сторонке, с его непродолжительными выходными и перерывами. Вы только можете себе это представить? В 21-м веке? Сервис, обслуживающий весь мир вдруг устраивает "каникулы" на целых две недели!

5.4. Управление аккаунтом

Доступ в iTunesConnect осуществляется по логину/паролю — это логично. Также логично, что если с аккаунтом должны работать разные люди, передавать всем логин и пароль — есть нарушение безопасности. Что ж, в iTunesConnect есть возможность создавать дополнительные аккаунты внутри и настраивать для них доступ — чтобы, например, один человек мог выкладывать новые версии, но не мог видеть финансовую информацию.

Это удобно. Но проблема в другом — нельзя пригласить одного и того же юзера в разные аккаунты. То есть, если в консоли управления Google я могу под одним своим аккаунтом управлять приложениями всех клиентов, в iTunesConnect для каждого клиента нужно создавать отдельный свой Apple ID. А это означает и создание отдельных почтовых аккаунтов, т.к. один почтовый аккаунт может быть привязан только к одному Apple ID. Разумеется, это плохой вариант, поэтому мы владеем паролями наших клиентов от iTunesConnect либо клиенты выкладывают приложения сами. Первый вариант плохой потому, что это нарушение безопасности. Второй вариант плохой потому, что разобраться сходу с iTunesConnect очень сложно даже читая мануалы. Но что поделаешь. Здесь хороших вариантов нет вообще. Просто передать пароль — наиболее удобный и простой.

Впрочем, это ещё не всё. Заключительный пост про iTunesConnect, в котором я подведу итоги и расскажу про ещё некоторые особенности — в следующий четверг.

Поделиться в соц. сетях

Опубликовать в Facebook
Опубликовать в Google Plus
Опубликовать в LiveJournal
Опубликовать в Мой Мир
Опубликовать в Одноклассники
Опубликовать в Яндекс