Как создать свое iOS-приложение. Советуют Reface, BetterMe и FlashBeats

Разработка iOS-приложений имеет свои особенности. Команда Apple модерирует продукты вручную и у них всегда возникает немало вопросов. Но при этом iOS-приложение — это проект, который нужно продвигать и продавать. 

О том, как лучше построить работу над проектом, балансировать между требованиями Apple, рынка и пользователей, Web Academy рассказали представители Reface, BetterMe и FlashBeats.

kirigetov

Роман Киригетов, CEO и Co-Founder FlashBeats

«Первым в App Store пошел примитивный MVP»

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

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

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

На проверку со стороны App Store ушел месяц. В Apple ручная модерация приложений и к новым продуктам они придираются. Нам приходили отказы, потому что сотрудники думали, что наше приложение фишинговое. Присылали отказы, так как считали, что FlashBeats это про гемблинг. Но как? Это же плеер с фонариком! Нам говорили, что не будут публиковать приложение, так как это обычный фонарик, а таких в App Store много — тогда мы доказывали, что разработка уникальная. Знакомые, которые занимались iOS-приложениями объяснили, что это норма для App Store. Нужно просто отвечать в переписке, что проблем, на которые они указывают, нет, и объяснять, почему.

Когда приложение опубликовали, мы стали нагонять трафик на него через рекламу в соцсетях. Очевидно, что на старте скачиваний без рекламы не будет, а нам нужны были пользователи и их отзывы. Самый классный отзыв, который мы получили, звучал в стиле: «Классный концепт, фиговое исполнение». Это не стало для нас сюрпризом, но так как идея большинству людей зашла, мы отключили рекламу и принялись дорабатывать продукт. После обновлений он перестал вылетать, появился новый функционал. Например, мы поняли, что люди ленивые и не хотят добавлять песни сами. Поэтому добавили готовые плейлисты — подборки техно, хип-хопа и прочее. Так как из-за карантина люди не собираются вместе, мы добавили чат, чтобы они могли общаться на расстоянии.

ios 11

Команда Apple всегда придирчива

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

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

У команды Apple, конечно, были вопросы, когда мы монетизировали приложение. Им важно все: как будет называться кнопка [нажав которую, человек оформит подписку], каким шрифтом будут прописаны условия. К paywall (модель заработка на контенте, при которой часть или весь контент становятся доступны только после оплаты, — Прим. ред.) они очень придирчивы и могут отклонять апдейт, если возникают хоть малейшие сомнения. Все это — вопрос переговоров, но с опытом понимаешь, как должно выглядеть приложение, чтобы к нему не цеплялись.

Недавно мы выиграли грант от «Украинского стартап-фонда» на 50 тысяч долларов. Проект хорошо растет, за прошлый год выросли в десять раз.

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

Хотите успеха — сразу идите на глобальный рынок

Чтобы приложение стало успешным, нужно угадать с нишей или хорошо исследовать ее. В нише не должно быть много игроков, максимум — один-два сильных.

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

Ближайший курс IT Product Management

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

Нужно заниматься App Store Optimization (ASO)— это аналог SEO. Мы получаем от него больше половины трафика.

Учитывайте, что App Store дает мало данных о приложении. Это как Google Analytics, только лет 20 назад. А аналитика нужна, чтобы понимать, что происходит в мобильном приложении, почему его скачивают и пр. Без данных не получится понимать юнит-экономику и масштабироваться. Для небольших разработчиков подойдет сервис Amplitude.

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

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

Gutyro

Алексей Гутыро, Engineering Manager в Reface

Разработка на аутсорсе влечет много проблем

Я пришел в команду Rеface в ноябре 2019 и был одним из двух разработчиков ин-хаус, которые готовили iOS-приложение к релизу.

Самая первая версия Rеface разрабатывалась на аутсорсе. Но со временем основатели поняли, что такой подход неэффективен, и в начале зимы 2019-го у нас появилась своя разработка ин-хаус.

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

Первую обновленную версию iOS-приложения мы сделали вдвоем за два месяца. Очень хотели успеть зарелизить до Нового Года, но App Store нас не пропустил из-за слова «дипфейк» в описании. Поэтому первый официальный релиз состоялся в январе 2020. К слову, за «дипфейк» больше не банили, потому что мы не используем его в своей коммуникации и всячески отгораживаем себя от темы дипфейков.

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

ios 22

Чем проще подход к iOS-разработке, тем лучше

Сначала у нас не было какой-то конкретной архитектуры, был MVC, где M — это Massive. И первая цель была разделить этот MVC на части, которые будет проще модифицировать. Это не совсем канонично по книжным понятиям, но было достаточно эффективно и быстро в условиях, когда над приложением работает только два разработчика.

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

К тому же, мы создавали продукт, которого на рынке еще никогда не было. Мы не понимали, будут ли им пользоваться через полгода. Если нет, то кому тогда нужен наш красивый код и архитектура на 300 разработчиков? Мы решили как можно быстрее и чаще итерировать. Особенно на первых этапах, когда только вышли на рынок и собирали очень много фидбека. Старались делать релизы каждые две недели.

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

Ближайший курс Swift с нуля (App for iOS)

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

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

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

Улучшение кода — не цель, а процесс

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

Так как у нас есть культура код-ревью (один разработчик комментирует код другого и следит за соблюдением общих договоренностей), проверка такого количества кода элементарно выматывает. Мы постоянно сталкиваемся с желанием просто впихнуть этот код, как слона в холодильник или как 15 человек в два такси, чтобы уже избавиться от него, но все равно продолжаем переписывать и быть скрупулезными в этом вопросе.

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

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

Malakhovskyi 2

Виталий Малаховский, Chief Technology Officer в BetterMe

Разработка продукта — это работа со старым кодом

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

Отдельно нужно подумать о тестах. Все знают, для чего они нужны и почему важны. Но когда работаешь на продукте, тесты — это всегда компромисс. Потому что, если написать их слишком много, будешь часто менять код. А если мы это будем делать, то навредим продукту. Поэтому мы для себя пришли к распределению по принципу Парето — 80/20. Мы за счет 20 % тестов стараемся покрыть 80 % функционала и не писать 80 % тестов, которые покрывают лишь 20 % функционала, а потом усложняют жизнь.

Чем меньше обновление, тем лучше

Мы делали слишком большие фичи, которые мешали публикации приложения. Процесс релиза затягивался на недели, иногда — месяцы. А это влечет за собой большой стресс, ведь чем больше фича, тем дальше релиз, тем больше тестов, времени и меньше мотивации. Как с этим бороться? Разбивать весь функционал на много маленьких задачек. Так получается не всегда, но там, где возможно, лучше дробить их.

А еще — настроить что-то наподобие релиза раз в определенно запланированное время. Мы релизим обновления раз в неделю. И весь функционал, который успевают сделать разработчики, попадает в этот поезд. Его тестируют и отправляют в магазин приложений. Это снимает стресс с разработчиков и добавляет предсказуемости бизнесу.

На проекте должны быть Continuous Delivery, Continuous Integration. Это нужно, чтобы быстро получать обратную связь о качестве продукта, например, когда проганяются тесты, или нужно быстро релизить приложение в магазин. Отсутствие таких систем в свое время сильно затягивало публикацию приложения вплоть до того, что приходилось до ночи сидеть и заливать в AppStore, ведь было много технических трудностей, которые возникают перед релизом.

ios 33

Лучше плохой продукт, который продается, чем хороший, который не релизнули

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

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

0
0
SAVE