Иво Димитров (Millt): React Native лучше

Как найти тату-мастера и сделать татуировку? Иво Димитров недавно выпустил свое первое приложение Millt и полагает, что оно поможет вам в этом. Мы поговорили с ним и выяснили зачем он разрабатывал его и как ему в этом помог React Native.

Расскажи немного о себе? Как ты пришел к мобильной разработке?

Меня зовут Иво Димитров. Я занимаюсь стартапами уже много-много лет. Начиная с компании, в которой я работал еще будучи в Москве – Ingenius Systems (компания занималась заказной разработкой стартапов). На тот период это было что-то уникальное. Когда все продавали создание сайтов, мы продавали команду как продукт. Это сейчас стартапы уже модное слово, а раньше такого не было. Проработал там 6-7 лет. Стал учредителем. Я пришел туда просто как проектировщик интерфейсов. Ушел оттуда как учредитель. Сейчас делаю свои проекты, а также консультирую стартапы.

То есть ты начинал именно как дизайнер, UX-проектировщик интерфейсов?

Да. Изначально я был проектировщиком интерфейсов. Когда-то в далеких годах, еще живя в Оренбурге, я был простым дизайнером, потом – арт-директором. Потом приехал в Москву. Потом стал UX-дизайнером, проектировщиком интерфейсов. Пришел в компанию Ingenius Systems. Примерно через три-четыре месяца я стал руководителем отдела проектирования. Через полтора-два года уже стал соучредителем и исполнительным директором. Когда я пришел, в компании было 15 человек, уходил через 5 лет – было 100+ человек. Все это время, даже будучи исполнительным директором (я бы не сказал, что операционка была глобально сложная), занимался продуктами, в первую очередь – дизайном. Дизайн, конечно, для меня – всё. Сейчас я себя продаю людям, в первую очередь, как продакт-дизайнер.

Ты сказал, что и в Ingenius Systems занимался стартапами, и сейчас у тебя основное направление – это продукты, стартапы. С самого начала главный вопрос жизни, Вселенной и всего остального. Какой главный совет ты можешь дать разработчикам своих приложений, своих стартапов, своих продуктов?

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

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

Отлично! Мы собрались здесь по поводу приложения. Называется Millt. Можешь рассказать его предысторию? Насколько я понимаю, вышло на iOS буквально неделю назад. Как оно создавалось? Зачем? Какую проблему решает? О технологической платформе мы дальше немного поговорим. Но сначала – о самом приложении, об идее.

Да, название приложения Millt – сервис для поиска тату-мастера и заказа тату. Идея родилась примерно 1.5-2 года назад, когда я хотел сделать татуировку. Передо мной встал вопрос. Как выбрать мастера? В интернете, конечно, можно набрать «Татуировки в Москве», «Татуировки в Лондоне», еще где-либо. Но это будут просто мастера. Но я не знаю – этот лучше или тот. Как мне их сравнивать на каком-то едином сайте, по единому принципу? Появилась идея. Тогда я это сам для себя назвал «Uber для тату». Изначально идея была очень близка к Уберу: ты открываешь мобильное приложение, у тебя там карта, ты видишь татуировщиков на карте и можешь прямо сделать заказ.

Потом я начал погружаться в это дело с головой и общаться с татуировщиками, посещать тату-конвенции, чтобы лучше понять как это работает. Я же не татуировщик, поэтому надо было все это узнать. Понял, что это так не работает. Примерно 70-80% татуировщиков – это люди, которые очень-очень слабо знакомы с компьютером, то есть они с компьютером «на Вы». Я понял, что нужна какая-то суперпростая штука и решил начать делать проект со стороны татуировщиков.

Изначально Millt — это сайт millt.com. Я нашел парня, который мне стал помогать со стороны разработки. Мы с ним сделали первую версию Millt, именно как сайт, где у нас была и есть, полноценная система управления тату-бизнесом. Я, скорее всего, не соврав, скажу, что именно системы по управлению тату-бизнесом в мире нет вообще. Мы не просто сделали систему бронирования или адаптировали какую-то платформу для парикмахеров. Мы прочувствовали всю боль, все проблемы, которые есть у татуировщиков, и сделали продукт специально для них. Это то, что не видит «обычный смертный», обычный пользователь, но это есть. Тату-салоны и татуировщики этим пользуются. Не только в России, но и во всем мире начинают пользоваться. А со стороны клиентов мы как раз сделали сайт, на котором можно посмотреть работы тату-мастеров, посмотреть самого тату-мастера, информацию о нем и написать ему.

Изначально была идея – сделать только мобильное приложение. Но ввиду того, что это все-таки стартап, и я сам себе основатель, сам дизайнер, сам разработчик, я не умел программировать под iOS, под Android. Ярослав, мой разработчик, тоже не умел и не умеет. Он пишет на Ruby on Rails и в первую очередь делает сайты. Поэтому мы решили начать с сайта. С приложением у нас начались эксперименты, параллельно с разработкой сайта. Сначала я пробовал пройти курс по Swift…

Давай вернемся к основам, к самому бизнесу – тату. Насколько я понимаю, я читаю зарубежные источники, чуть ли не каждые три месяца появляется какой-то сайт, подобный Millt. В мае мы писали о Tattoodo, который получил 2.5 миллиона долларов инвестиции. Примерно тот же самый хаб для татуировщиков, для тех, кто хочет сделать татуировку. В чем ваше коренное отличие от всех стальных?

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

Сейчас большинство татуировщиков пользуется бумажными блокнотиками, Excel, Google Docs и т.д. Это на полном серьезе. Я знаю туту-студии из 10-20 человек. Там в день делается очень много татуировок, но при этом они пользуются такой старой бухгалтерской книгой, где они записывают клиентов, их звонки и т.д. Это все дико неудобно. Это не мои слова о том, что это дико неудобно. Это их слова.

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

Есть еще суперинтересные проекты, которые технологичные. Например, ребята сделали мобильное приложение INK HUNTER. Это уникальная идея. Они просто взорвали App Store. Вроде такая узкая ниша – татуировки, но у них в первые несколько дней был чуть ли не миллион загрузок. Вся фишка в том, что они сделали приложение, где можно попробовать – примерить татуировку. Это очень круто.

Дополненная реальность. Я правильно понимаю?

Да. Техническая реализация очень простая, но идея очень крутая, потому что, когда ты делаешь татуировку, это же все-таки на всю жизнь. Человек чаще сталкивается с вопросом «А как мне это все примерить?». Как одежду. Когда покупаешь брюки, сначала меряешь, а потом покупаешь. Тут то же самое. Ребята решили эту проблему. Мы с ними подружились, общаемся. Они сейчас попали в Акселератор в Штатах, в Нью-Йорке, кажется. Возможно, мы будем как-то с ними партнерствовать в дальнейшем. У нас одна сфера, одна ниша, но разные подходы, и мы решаем разные задачи.

Millt, с одной стороны, решает CRM-проблему для тату-салонов, если я правильно понял…

Да.

…С другой стороны, он позволяет пользователю выбрать исполнителя для своей татуировки. У меня самого пять татуировок и я понимаю, что никакие сторонние советы, никакие эскизы и выполненные работы на меня не повлияют. У меня есть совет моего друга, который посоветовал мне мастера. На сайте я вряд ли выберу себе подходящего. Есть ли такая проблема у вас в Millt? Если есть, то как вы ее решаете?

Все очень просто. Аудиторию Millt можно условно разбить на несколько. Первая – это люди, которые вообще никогда не делали татуировку. Вообще никогда. У них нет такого крутого друга, который может посоветовать. Они приходят к нам по SEO, либо по рекламе. Они пользуются сайтом, чтобы как раз выбрать мастера для своей первой тату. Важный момент – то, что у проектов подобного типа, неважно, у Millt, у каких-то других, retention, возврата добиться достаточно сложно, потому что когда ты сделал тату, ты, наверно, сам по себе знаешь, что либо а) ты будешь делать у того же мастера, либо б) ты в крайнем случае поменяешь мастера по рекомендации старого мастера. Обычно происходит так. Поэтому, сделав один раз тату, обычно люди не «прыгают» по мастерам. Это суперредкий кейс.

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

Примерно две такие аудитории. В дальнейшем мы планируем ввести какие-то функции, чтобы как раз увеличить эти сферы пользователей. Например, мы придумали, как можно делать ту же самую примерку. Только уже без дополненной реальности, решили проблему, правда, не с помощью приложения, а сделали специальные наборы. В Штатах сейчас это очень популярно. По сути – сводилка. Ты увидел какую-то татуировку. Ты хочешь такую же. Нажимаешь на кнопочку «купить набор для временной тату». Я говорю условно. Ты сможешь сделать себе временную тату, которая у тебя будет держаться две недели. Она в визуале выглядит на 99% как настоящая. Обычные люди вряд ли отличат. Люди, которые шарят в татуировках, конечно, может быть, заметят разницу. Это позволяет тебе полноценно, уже по-настоящему примерить, оценить, услышать отзывы о тату.

Давай вернемся к технологиям. Вы сделали сайт и настало время мобильного приложения. Ты начал говорить о курсах Swift. Давай продолжим с этого места. Почему не получилось со Swift?

Дело вообще не в Swift. Дело конкретно в Xcode. Swift – крутой язык программирования. Работая на Millt, я погрузился в программирование достаточно сильно в плане того же сайта. На Ruby on Rails писал вместе со своим разработчиком. Сейчас какие-то сложные вещи делает он, а какие-то простые вещи я уже делаю спокойно один. Swift очень похож на Ruby. Я бы сказал, они очень многое оттуда взяли. С самим языком проблем нет. Правильно, что они пошли в эту сторону. Даже если бы его не было, был бы Objective-C, но сам язык это полбеды.

Беда в самом Xcode, как мне кажется. Чтобы изменить там многие элементы, я тратил безумное время.

Как я уже говорил, я в первую очередь дизайнер. Если разработчику важно, чтобы при нажатии на кнопки получалось, мне важно, чтобы при нажатии на кнопки была какая-то крутая анимация, все это плавненько и круто происходило. Во мне включался дизайнер. Поэтому вместо того, чтобы быстренько наклепать функционал, а потом уже заморачиваться по дизайну, по анимациям и т.д., я тратил очень много времени на все это. Я искал какой-то универсальный подход, чтобы можно было тратить время на так называемый пиксель-хантинг, и чтобы одновременно мобильное приложение обрастало функционалом. Поэтому я на какое-то время забил на Swift, Objective-C и начал искать альтернативы. Так как я уже хорошо познакомился с Ruby, то нашел Ruby Motion. Это прикольная штука. Ребята сделали фреймворк для разработки под iOS, Android, OS X. И все это на Ruby. Как раз очередной конвертер.

The app was not found in the store. :-(

Go to store Google websearch

Я начал смотреть в его сторону. Сначала попробовал, потыкал, посмотрел. Понял, что, в принципе, это ничем не отличается от разработки в Xcode, потому что ты пишешь, ты используешь методы и функции, которые заложены в стандартных фреймворках, например, iOS-ных, просто языком Ruby. Ничего не изменилось. По сути, все то же самое, что я бы делал в Swift.

Стал искать альтернативу. Я постоянный читатель вашей рассылки. В одной из рассылок я прочитал о React Native. Начал все это смотреть, гуглить. Сначала меня это расстроило, потому что я не был фанатом JavaScript. Я мог сделать к JavaScript какую-то простейшую анимацию на сайте, на jQuery максимум. Я вообще на JavaScript никогда ничего серьезного не писал. Начал смотреть примеры, все прелести. Я просто удивился (это меньшее, что могу сказать), насколько круто делают приложения на React Native. Я буквально за пару дней стал евангелистом этого дела. Ходил всем рассказывал, показывал всем друзьям, говорил, насколько это круто. Потому что это действительно круто.

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

Вернемся на шаг назад. Ты говорил, что занимался программированием сайта, и сейчас сам занимаешься программированием, созданием приложения. Почему ты, исполнительный директор в Ingenius Systems, самостоятельно занимаешься программированием? Не проще было нанять какого-то человека, а самому заниматься продуктовой стратегией, заниматься какими-то делами, в которых ты более компетентен, и в которых твой вклад мог бы быть заметно больше? Как все пошло в эту сторону?

Очень просто. Что касается сайта, это больше хобби. Обычный процесс перед релизом – процесс тестирования. Мой разработчик Ярослав занимался основной разработкой, но были какие-то маленькие проблемы. Мне просто было жаль времени. Я постоянно спешил, как в любом стартапе. Я не хотел отвлекать его по пустякам – когда кнопочка съехала на два пикселя и т.д. Я начал с таких мелочей. Я говорил: «Ладно. Не трогай это. Я сам сейчас поучусь, попробую это все сдвинуть сам». Мне просто было жалко времени, чтобы он отвлекался на такие мелочи. Эти мелочи я больше стал брать на себя. Я не могу сказать, что у меня есть четкие серьезные задачи по программированию. Нет. Я в основном беру на себя именно задачки по каким-то мелким доработкам и багфиксам.

Что касается мобильной разработки, здесь все интереснее. Я, конечно же, начал с поиска исполнителя, какого-то человека, которого либо – вариант А – я думал, найму его в команду полноценно, на зарплату, либо вариант Б – может быть, в долю, в зависимости от ситуации. Конечно, я больше всего рассчитывал на более реалистичный план – найти исполнителя, который бы выполнил мне проектную задачу, и мы бы с ним попрощались.

Я создал проекты на всяких фриланс-биржах и т.д. Получал оценки, общался с людьми. Я понял в какой-то момент, что меня, в первую очередь,  не устраивали сроки, которые мне говорили. Аналогичный функционал, самый минимальный, мне оценивали в месяц. Максимальный мне оценивали в 6 месяцев. Я думал: «Какое-то безумие!». Поскольку я не парень с улицы, который в этом вообще не сечет, а полжизни проработал в стартапах, в разработке, я знаю сроки, цены и т.д., я недоумевал.

Спорил с ребятами, с разными компаниями: «Ребята, вы что?! Давайте, может быть, я как-то помогу». Я уже старался максимально помочь. Дизайн я рисую в Sketch. Говорю: «Я уже там все нарезал, вот вам готовый набор картинок для разработки. Вам вообще не надо думать. Хотите – я вам нарисую полностью карту переходов, взаимодействий и т.д.». Я был максимально готов помочь, чтобы ускорить. Но – нет. С учетом сроков, конечно, была и цена. Цена, которую мне предлагали. Сам понимаешь, три-четыре месяца работы iOS-разработчика стоят денег. Поскольку я понимал, что это можно сделать быстрее, я не понимал, почему я должен столько платить. Поэтому решил сделать так.

Но еще раз напомню, что это не было первичной целью. Это получилось чисто случайно. В итоге я и так, и так планировал нанять разработчика. Вышло это случайно только потому, что я прочитал о React Native, и у меня был свободный вечер. Я просто его установил и, наверно, через 30 минут после установки у меня был некий Hello World — было полноценное приложение, которое работало с API, авторизовывалось, показывало картинки, там были анимации. Я удивился, что я это сделал за полчаса, полноценно не зная JavaScript. Я бы не сказал, что я крутой разработчик и т.д. Я понял, что это оно, поэтому решил это сделать сам.

Спасибо за развернутый ответ. Я правильно понимаю, что React Native ты выбрал именно из-за гибкости, а не в силу его кроссплатформенности или каких-то других его достоинств?

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

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

Третий момент, который меня сильно впечатлил. Я сам для себя его назвал «бесшовные апдейты». Я говорю как раз о CodePush. Есть такой инструмент от Microsoft. Есть еще аналогичный проект — ребята появились буквально месяц назад, AppHub. Это два проекта, которые позволяют для проектов, написанных на React Native, либо тех, которые использую фреймворк Cordova, делать апдейты, при этом без переапрува в App Store или в Google Play. Аналогичную историю использует Facebook в своем приложении. Он очень часто что-то обновляет. При этом у вас новая версия приходит не через App Store. Просто – хоп, и появляется кнопка, и ты не знаешь, откуда она там появилась. Это как раз «бесшовный апдейт». Наверно, это три основные вещи.

А как React Native работает с нативными функциями? Сам сайт Millt, судя по всему, использует какую-то геолокацию. Насколько сложно прямо из React Native получить доступ к фотокамере, к геолокации, ко всем звонкам и т.д., нативным функциям, которые есть в iOS или в Android?

Я бы сказал, что во многом так же, как если бы я писал на Objective-C или на Swift, а иногда даже еще проще. Доступ суперпростой. Они написали свои обертки, свои оболочки под самый основной функционал, то есть к навигатору, к фотокамере, к картам и т.д. А к тем, к которым не написали, они придумали такую штуку как бридж – некий мост. Ты просто можешь его использовать, чтобы достучаться до нативного элемента.

Из высокого уровня какие в Millt используются iOS-ные компоненты? Это навигаторы. Это карты. Геолокация там есть. Всякие лист вью и т.д., скролл вью. Но это мелочи. Доступ ко всем этим компонентам суперпростой, даже можно сравнить кусочки кода.

Как React Native от Facebook изменит мобильные приложения

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

Я просто не знаю, каким образом еще показать простоту использования. Если многие аналогичные проекты заменяют нативные элементы, то здесь, когда у тебя эта скомпилированная версия, у тебя абсолютно нативные элементы.

У многих приложений, по крайней мере, у меня на Android, которые сделаны через PhoneGap, заметна проблема с быстродействием: интерфейс не очень хорошо откликается на действия пользователя. Есть ли такое у React Native? В твоем рассказе все выглядит очень круто. Есть ли какие-нибудь «темные стороны» разработки на React Native?

Существенное отличие от PhoneGap состоит как раз в том, что PhoneGap эмулирует нативные элементы. Когда ты делаешь на нем какой-нибудь tabbar, хочешь сделать, например, менюшку или лист вью, то он визуально выглядит так же, как нативный элемент, но по факту это тот же HTML и CSS с JavaScript. React Native на выходе тебе не HTML, CSS и JavaScript, а это прямо настоящие нативные элементы. Поэтому по быстродействию он аналогичен обычному нативному приложению.

У него есть офигенные инструменты для работы с производительностью – отслеживание, профилирование и т.д. В том же Millt я включал этот профайлер, там смотрел и FPS, смотрел и загрузку процессора и т.д. Там все супер быстренько. Таких глобальных проблем по производительности вообще ни разу не замечал. Я думаю, основное отличие – это то, что все-таки React Native на выходе дает (почему он и называется Native) нативные элементы. А всевозможные PhoneGap и т.д. – это всего лишь эмуляция нативных элементов.

React Native – это продукт Facebook. Насколько у него большое сообщество и поддержка самой компании? В процессе разработки всегда встречаются какие-то проблемы, задачи. Если это происходит на Swift, зашел на Stack Overflow, узнал ответ. В плане React Native насколько большое сообщество и поддержка комьюнити, поддержка самого Facebook, разработчиков? Как быстро ты мог найти ответы на какие-то вопросы, которые у тебя, я думаю, неизменно возникали?

Здесь все очень хорошо. Во-первых, есть React Native, есть ReactJS. ReactJS – это аналогичная штука, тоже от Facebook, только уже для веба. Очень многие вещи, как минимум, философия и принципы, пересекаются. Если у тебя проблема не на уровне использования какого-то компонента, а на уровне понимания глобально ядра, фреймворка, подхода, то за счет того, что они пересекаются, у тебя огромная аудитория ReactJS, именно веб-реализацией пользуется безумное количество людей.

Есть, конечно, Stack Overflow. Всегда можно обратиться, как и с любым другим языком программирования или с техническим вопросом. Но самое главное – как это обычно возникало в 99% случаев. Я хотел сделать какую-то штуку. Я просто набирал «React Native», пробел, “эта штука”. Я обязательно попадал на GitHub, и по-любому уже существовал какой-то аналогичный проект. Из-за того, что React Native придумали хитрый бридж, мост между нативными компонентами и ReactJS, чтобы превратить любой компонент, написанный когда-либо для нативной разработки, на Objective-C, на Swift, на Android, в удобную библиотечку для React Native, надо потратить не так много времени. Получается, реализация всех основных популярных библиотек для мобильной разработки существует под React Native. Начиная от каких-то простых вещей (всякие крутые табары, анимации и т.д.), заканчивая сложными вещами. Например, есть популярная библиотечка для iOS, Android, чтобы сканировать кредитные карты, или что-то аналогичное, всякие математические библиотеки. Это все есть на GitHub, само собой.

В самом Facebook есть небольшое сообщество React Native, где можно задать супер сложный вопрос или просто подискутировать. Вопрос все-таки задавать лучше на Stack Overflow. Там более оперативно все получаешь. В Facebook проходят всякие мероприятия. У них еще есть программа FbStart. Она не связана напрямую с React Native, но там люди все-таки пересекаются. Я тоже сейчас отправил заявку. Кстати, очень рекомендую особенно начинающим разработчикам, потому что они дают на входе очень много инструментов для разработки и дальнейшего продвижения мобильного приложения, которые тебе позволят полгода-год вообще не думать о затратах ни на какие-то инструменты для маркетинга, ни на инструменты разработки, ни на что.

Все-таки потом за это придется платить, когда полгода закончится.

Да. Но это позволит тебе бесплатно протестировать твои основные гипотезы.

Это – безусловно.

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

Ты сказал, что есть возможность пользоваться сторонними библиотеками. Но одна из хороших особенностей Xcode, Swift и Objective-C это CocoaPods, где совершенно безумное количество библиотек. Есть ли у React Native такая система? Не нативная библиотека, а библиотека именно под React Native, которой можно пользоваться.

Любая библиотека под React Native, что самое интересное, это те же поды, один в один. Например, чтобы использовать карты, я также прописывал использование MapKit. Я устанавливал их прямо, потому что это же нативный элемент.

Любая библиотека React Native состоит из двух сторон. Первая сторона – это какая-то нативная история. Вторая – это JS-ная история, которая позволяет обращаться к этой нативной истории из JS-а. Это касается не всех библиотек. Это касается только тех библиотек, которые достаточно сильно влияют на нативную часть. На примере Millt это карты, это Mixpanel, потому что он должен работать прям с инициализацией и т.д. Это как раз всякие истории, как CodePush. Наверно, все. Это то, что прямо потребовало устанавливать какие-то поды.

Есть, например, такой сайт, называется JSCoach. Это очень удобный поисковик по React Native компонентам, каким-то библиотечкам. Здесь и React, и React Native, и другие фреймворки.

В своем посте на Facebook с анонсом приложения ты писал, что еще какое-то время у тебя ушло на адаптацию под разные разрешения. В Xcode есть Auto Layout с constraints. В чем проблема адаптации React Native приложений под разные разрешения? Насколько я понимаю, совсем грубо, это HTML-разметка, которая резиновая.

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

Безусловно, каждый раз, когда я пользуюсь constraints в Xcode, я проклинаю все и вспоминаю HTML.

Верстка по React Native – это как верстка обычной странички. У тебя отдельный, чаше всего делают отдельный, CSS-файлик, там синтаксис примерно такой же. Есть файлик твоей верстки, теги у тебя такие же, как HTML. У тебя есть открывающий тег, закрывающий тег, какие-то его параметры и т.д. В вебе сейчас используется очень популярная штука для верстки. Называется «flex», по-другому — «flexbox». Это вебовский аналог constraints, который позволяет указывать направление, как там растягиваться правильно и т.д. Он более простой, и в то же время более гибкий, удобный. По сути, здесь то же самое.

Почему были проблемы, и я потратил какое-то время? Я сейчас немного отступлю от того, что я рассказывал. Когда я разрабатывал, я долго думал, как же разрабатывают люди, которые пишут, например,  на Objective-C, на Swift, потому что им же приходится каждый раз перекомпиливать. Они что-то поменяют, и не знают каких-то правильных вещей, им надо все время смотреть и каждый раз перекомпиливать. В React Native ты просто пишешь код, нажимаешь Command+S – сохранить в своем любимом блокнотике, в котором ты пишешь. У тебя в реальном времени в симуляторе отображается результат.

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

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

Спасибо за такой интересный рассказ о React Native. Я к нему, честно говоря, присматривался, наверно, полгода назад, но тогда он мне почему-то не показался особо адекватным в разработке. Но сейчас, наверно, придется вернуться. Спасибо еще раз за интересный подробный рассказ. Попробуем React Native в деле.