App Store: год второй

На этой неделе для разработчиков под iPhone была одна знаменательная дата — первая годовщина с момента открытия App Store, магазина приложений для Apple iPhone и iPod touch. За этот год было много всякого, улучшений, ухудшений, и — полтора миллиарда скачанных приложений (огромное количество из этого 1,5 млрд — бесплатные).

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

Размер статьи и разнообразие затронутых в ней тем даст вам представление о том, с чем приходится сталкиваться разработчикам под iPhone. Из-за размеров статьи в ней возможны ляпы с переводом, но суть должна быть понятна :)

Есть надежда
Мы как разработчики, любим замечать то, что “неправильно”, и жаловаться по этому поводу. Также важно смотреть и на то, что улучшилось за последний год: это дает надежду, что мы однажды увидим кое-какие из пожеланий, которые перечислены в этой записи.

Вот некоторые вещи, которые помогли нам продать больше приложений:
▪ Отзывы только от покупателей приложений
▪ Промо-коды
▪ Улучшенные категории
▪ Рекламная кампания по всей стране

Корень проблемы
Создание App Store на базе инфраструктуры iTunes был отличным шагом со стороны Apple. Это позволило им продавать программное обеспечение миллионам пользователей с минимальным количеством разработки. Взглянем на это так: вы бы лучше потеряли 6 месяцев дохода, ожидая пока Apple доведет систему для продажи приложений до ума?

Но теперь iTunes представляет собой проблему для Apple и сторонних разработчиков, потому что ПО это не музыка. Я считаю, что это основная проблема, с которой сталкиваются обе стороны:

▪ Музыка и ПО отличаются по количеству. Apple на данный момент говорит о 50 тысячах приложений в App Store (уже 60 тыс). И хотя это уважительное число в этой категории, оно меркнет по сравнению с 10 миллионами песен.
▪ Как разработчики, мы — небольшая рыба в этом море продуктов, но мы более важны для здоровья платформы iPhone, чем музыканты — для здоровья iTunes. Люди вроде Волта Моссберга не говорят о важности музыки, когда пишут обзоры конкурентов iTunes.
▪ Клиенты iTunes не сталкиваются с функциональными сложностями при работе с песнями. Людям не надо учиться слушать музыку. Любой, кто занимался клиентской поддержкой, скажем вам, что с ПО так не бывает.
▪ Никогда не бывает новых версий песни. Ну да, есть ремиксы и другие адаптации, но они все маркируются, рекламируются и продаются как отдельные продукты. ПО, с другой стороны, обычно обновляется каждые несколько месяцев.
▪ Музыка не может повредить устройство. Вредоносное ПО может.
▪ Музыка не зависит от сети во время проигрывания. Наше ПО может сломаться или начать работать по-другому из-за зависимости от внешних данных.
▪ Многие музыканты продают свой контент через сторонние каналы (медиа-компании), большинство разработчиков этого не делает.

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

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

Теперь же, с 60000 приложений, мы сталкиваемся с 3 неделями задержки для проверки. А когда будет 100 тыс приложений, нам придется ждать утверждения пару месяцев? Или больше?

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

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

Исправляющие обновления нежизненноспособны
Всегда есть ошибки, которые вылезают в последний момент и могут быть легко исправлены. У Twiterrific на данный момент есть проблема с маркировкой твитов как favorite (вызванная изменениями в Twitter). Мы можем исправить эту проблему за 5 минут, но все равно займет три недели, чтобы доставить исправление на телефоны пользователей.

Исправление текущей версии и выкладывание обновления — это то, что все разработчики могут делать на других платформах (Mac, Windows). Но после того, как ваше обновление 1.0.1 провело несколько недель в очереди, оно, скорей всего, будет уже устаревшим, поскольку за это время вы поработали над обновлением 1.0.2. Если вы замените релиз 1.0.1 на новый 1.0.2, вы попадете в конец очереди, и начнете ожидание заново. Вы оказываетесь в цикле, при котором все эти мелкие релизы никогда не выходят.

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

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

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

Я вполне готов отвечать за свои действия. Как и другие разработчики, с которыми я говорил. Если мы сделаем что-то плохое — уберите все наши продукты из App Store. Подайте на нас в суд. Закройте наш бизнес. Тех из нас, кто уважает своих пользователей и ценит свои отношения с Apple, это не затронет.

Мы не против подождать пару недель в случае большого обновления (типа 2.0), потому что это нечто, что, скорей всего, заняло несколько месяцев разработки. Используйте первый или же большой релиз как точку для установки доверия между Apple и разработчиком. А затем дополнительные обновления (вроде 2.0.1 или 2.1) могут быть быстро утверждены благодаря этому доверию. Если разработчик нарушает договор в таком небольшом обновлении, накажите его.

По мере выпуска новых продуктов, у меня все больше стимула поддерживать этот уровень доверия (если из магазина уберут несколько продуктов — это больнее, чем когда убирают один). Зная это, Apple могла бы тратить меньше времени на проверку каждого нового продукта от уже существующих разработчиков.

В случае критичных обновлений, нам не надо будет ломиться в начало очереди. В идеале вообще было бы здорово выдать каждому разработчику ограниченный набор “ускоренных билетов”, и посоветовать им разумно использовать их (никаких исключений для тех разработчиков, которым нужен “ну еще один”).

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

Вот как это работает:
1. Вы знаете общее количество пользователей вашего продукта.
2. Процент пользователей, который обновляет продукт, предсказуемо. Для большинства продуктов это обычно составляет около 40-60%.
3. Вы знаете, сколько будет стоит апгрейд.

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

К сожалению, App Store не позволяет нам генерировать доходы от апгрейдов. Мы либо делаем бесплатный апгрейд, либо берем деньги за полностью новый продукт. Первое плохо для разработчиков, потому мы не получаем прироста доходов. Второе плохо для клиентов, потому что они не получают скидку.

Многие разработчики, которые в App Store с самого начала, столкнулись сейчас с этой проблемой: мы разрабатываем версию 2.0 и не знаем, как на ней заработать денег. Даже если ваш продукт продается хорошо, все равно сложно оправдать добавление новых возможностей, если они не создают дополнительного потока доходов
Бесплатные апгрейды также означают, что отличные продукты (с небольшой пользовательской базой) в итоге завянут и умрут. “И для этого есть программа” будет относиться только к продуктам с массовым пользователем. Нишевые и вертикальные рынки окажутся недообслуженными.

Для разработчиков игр это не такая большая проблема: каждая новая версия может рекламироваться как отдельная программа. Но если применить этот же подход к другим приложениям, вы получите ““Twitterrific: The Awakening”, “Twitterrific: The Second Coming”, “Twitterrific: The Return of the Tweet” и тд. Это сделает App Store еще более запутанным для покупателей этих приложений.

И последнее, большие обновления невозможно выпускать в предсказуемые сроки. Если вы пытаетесь установить дату доступности приложения на определенный момент в будущем, текущий продукт в App Store становится недоступным (покупатели не могут приобрести продукт, пока он проходит проверку). Apple более чем кто-нибудь, должна понимать преимущества управления релизами продукта. Это значительно больше, чем строка в базе данных iTunes.

Решение
Почему приложения нельзя апгрейдить, как музыку? Если посмотреть на версию 1.0 как песню с DRM, а на 2.0 как песню без DRM, то проблема практически решена. Единственная разница в том, что нам надо апгрейдиться более одного раза.

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

Улучшение правил
Нам нужны улучшенные правила для типов приложений, которые разрешены в App Store: формулировка в разделе 3.3 лицензионного соглашения слишком общая.

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

Когда для интерпретации много пространства, для разработчика несложно помахать флагом и организовать негативные статьи об Apple. По мере добавления приложений в Ap Store, будет все больше этих сенсационных “отказов” в технологических СМИ. Это уже доходит даже до CNN.

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

Четкий набор правил также позволит разработчикам чувствовать себя уверенными в том, что их усилия будут вознаграждены размещением в App Store. На данный момент это как повезет. Если вам не повезло, у вас нет другой возможности продавать свой продукт и вы потеряли много времени и денег.

Мы также понимаем, что есть одно правило, которое сложно определить: “оскорбительное содержимое”. Это очень субъективно.

Если взглянуть на музыкальную индустрию, можно заметить, что у них похожая проблема с 1985 года. После десятилетий обсуждений, все равно хватает неясностей касательно рейтинга музыки. С социальной точки зрения, эту проблему невозможно решить. Текущее “решение” — дать возможность рекординговым компаниям контролировать себя самим.

У разработчиков для iPhone есть одна компания, которая принимает решения. Отсутствие прозрачности в их процессе принятия решения делает невозможным для нас понять, что приемлемо, а что нет. Насколько мы знаем, эти правила создаются и меняются по ходу процесса.

Решение
Четкий набор правил для тех, кто делает проверку, и для разработчиков, сделал бы процесс проще для всех.

Apple должна опубликовать что можно, а что нельзя разрабатывать для App Store. Предоставить примеры того, что ОК, а что нет. У нас есть Human Interface Guidelines по поводу того, как приложения должны вести себя, почему же у нас нет похожих рекомендаций по функциям приложений? (Прим. пер. Кто-то может сказать, что подобные правила есть в соглашении разработчиков. Однако там все очень абстрактно, чтобы на это ориентироваться).

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

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

Оценка продукта
На данный момент, покупатели принимают решение на основе пары снимков экрана и короткого описания продукта. Этого часто недостаточно, чтобы донести преимущества наших продуктов, особенно тех, которые сложные (и стоят дороже).

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

Текущая ситуация похожа на магазин с телефонами, где лежат только муляжи телефонов с наклейками скриншотов, и без батареек. Сравните это с заходом в Apple Store и использованием полнофункционального iPhone.

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

Apple уже сказала, что “бесплатное остается бесплатным”. Я понимаю, почему они так делают — это способ избежать приложений, которые будут использовать метод наживки.

Почему бы не прийти к какому-то компромиссу? И у iTunes на компьютере, и у приложения App Store на мобильном устройстве есть отличные мультимедийные способности. Почему бы не использовать их для показа пары минут видео для каждого приложения? Это не так хорошо, как возможность попробовать приложение, но точно лучше, чем пять скриншотов. Дайте возможность разработчикам закачивать ролики в QuickTime в iTunes Connect и всем от этого будет только лучше.

Отзывы на обзоры
Опять же, музыка — это не программное обеспечение. Музыка — это просто, вам либо нравится песня, либо нет.

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

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

Опять же, может быть это слишком много просить это от инфраструктуры iTunes. Я также сомневаюсь, что Apple отдаст нам почтовые адреса покупателей (что можно рассматриваться как личные данные).

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

Поиск приложений
Песни и игры вписываются в текущий рейтинг “популярных”. Популярность в этом типе контента однодневна. Этот тип контента также легко идентифицируется по названию бренда (“Death Cab for Cutie”, “Flight Control”, и тд).

Проблема в обнаружении приложений, которые не попадают в список популярных. Очень сложно найти “это” в “и для этого есть приложение”. Между спамом по ключевым словам и огромным выбором в каждой категории, покупатели не могут найти то, что им нужно.

Решение
Решить эту проблему можно, организовав поиск по решениям, не по названиями или рейтингу продаж. Этим летом, покупатели заинтересованы в приложениях, которые:
▪ Развлекают их в путешествиях в/из мест отпуска
▪ Ведут их по этим местам
▪ Помогают им отдохнуть во время перерыва
Единственное, что вы обнаружите, если поищете “Париж” в App Store — так это то, что есть дохрена иконок с Эйфелевой башней.

Macworld, с их Гидом по приложениям, разобрался с этим. Apple должна посмотреть на успех категории “любимые приложения персонала” и расширить это на весь iTunes.

Берите с нас больше денег
99 долларов, которые платят сейчас разработчики — неплохой вариант за “все включено” в App Store. Но потребности больших, полноценных разработчиков сильно отличаются от того, что требуется тем, кто делает это в виде хобби или в свободное время.

Решение
Берите 999 долларов за премиальный сервис. Для профессиональных разработчиков эта сумма не запредельна, и позволит Apple предоставлять дополнительные услуги, вроде:

▪ Более короткое время проверки приложений. Уровень доверия между Apple и разработчиком выше, если сумма денег выше.
▪ Большее количество “скоростных билетов”, о которых мы говорили выше. У компаний с большим количеством персонала больше шансов сделать какую-то глупость, так что дайте нам больше свободы, чтобы решать их.
▪ Скидки на тестовые устройства. С каждым новым выпуском устройств, для разработчиков все сложнее поддерживать новые устройства. Основной фактор заключается в том, что для получения нового устройства надо заключать контракт с AT&T Что-то подобное скидкам на Маки для участников ADC очень сильно помогло бы.
▪ Фоновые картинки для наших продуктов в iTunes. Поставить симпатичную фоновую картинку значит для нас много: это делает наши продукты более привлекательными для потенциальных покупателей. Давайте мы заплатим за время, которое занимает ее установка.
▪ Утверждение идей до разработки. У разработчиков есть безумные идеи. До того, как потратить месяцы разработки на эти безумные мысли, было бы неплохо получить предварительное согласие от Apple на этот концепт.
▪ Больше устройств в Портале разработчиков. Текущее ограничение в 100 устройств — это издевательство над разработчиками с множеством продуктов: если у тебя 5 продуктов, то ты получаешь 20 устройств на программу. Это, в комбинации с обновлениями устройств за 12 месяцев, означает, что мы не можем тестировать наши приложения до 12 июля.
▪ Контакт в отделе отношений с разработчиками. Иногда нам надо поговорить напрямую с кем-то в Apple.

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

Эти низкие цены принимают решения за нас. Если вы дадите разработчику под iPhone 50 тыс долл потратить по их усмотрению, они сделают 5 дешевых приложений по 10 тыс каждая, вместо одного суперприложения за 50 тыс. Во время золотой лихорадки лучше иметь 5 мелких заделов, чем один большой.

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

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

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

Предложения, описанные выше, предназначены для того, чтобы помочь нам растить этот бизнес и содержать экосистему в здоровом состоянии. Страх всех разработчиков — что Apple не желает открытого диалога относительно App Store. Меня очень сильно напугало, когда наши вопросы не получили ответов на WWDC.

Успешное партнерство — это то, в котором обе стороны работают на благо друг друга. Если наши потребности игнорируются, это лишь приведет к разочарованию. Работа с разработчиками, которые двигают эту новую платформу — это и есть лучшая долгосрочная бизнес-стратегия Apple.

Оригинал