#мобильная разработка

Помните, мы перезапустили Синхронизацию за 3 месяца вместо года?

Так вот: после этого, мы ещё за месяц работы, силами одного программиста (!) запустили им мобильное приложение!

Есть такой фреймворк Capacitor.js. Он позволяет переиспользовать код сайтов в мобильных приложениях. Это довольно рискованный прием и хочется поделиться тем, как красиво получилось в этот раз, несмотря на 9 кругов ада внутри.

Разработчик приложения и автор статьи — Эдуард Аксамитов.

Иллюстрация: «Круги Ада» Боттичелли, Библиотека Ватикана

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

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

Эмблематично, что сидел, разрабатывал он не приложение для клиента, а свой собственный продукт — сервис для вайб-кодинга.

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

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

Два месяца переписывались с Apple по поводу in-app purchases и прочих коммерческих моментов. В результате всё решилось одним коротким звонком с Купертино. По телефону нам на хорошем русском объяснили, что «правила AppStore — это направляющие принципы, каждую ситуацию не распишешь формально, конкретно вам нужно сделать 1, 2, 3». Не стесняйтесь пользоваться опцией заказа звонка!

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

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

Такой кайф, когда единая команда отвечает за продукт на всех платформах! Нет этого: «веб уже запрогал, андроид сделал не совсем как нужно, но сойдёт, а iOS-команда пока занята, ждём...»

Ура!

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

Яндекс Практикум ищет опытных Android и iOS-разработчиков для соавторства на курсах по мобильной разработке.

Работа командная, уже есть несколько крутых авторов, но нужны еще. Работа удаленная, 8-10 часов в неделю. Денег не много, зато кайф от обучения начинающих и полезные знакомства. Писать @paperbrain.

Вдохновляющая статья Coinbase о том, как они переписали свои приложения для iOS и Android на React Native и переформатировали команды под это. Перескажу основные тезисы.

Крупнейшая криптобиржа на свете, 56 миллионов пользователей в 100 странах, полтора миллиарда долларов прибыли в квартал.

200+ экранов, 30 мобильных разработчиков. Кросс-функциональные команды, которые поддерживали фичи, были такие: 8 человек, 2 бэкендера и 6 фронтов, по 2 на каждую платформу — 2 веб, 2 iOS, 2 Android. Цель перехода: из команд по 8 инженеров, сделать команды по 5, 2 бэкендера и 3 React Native.

Как сделали?

1. Не пытались переписать большое приложение по-частям (очень сложно интегрировать react native с нативой), а сделали отдельное приложение с самой сложной частью функциональности для небольшой части Pro-пользователей, чтобы проверить, возможно это вообще или нет — заняло 6 месяцев, всем понравилось.

2. На втором этапе, решили-таки попробовать впилить небольшой кусочек react native в старое приложение — добавили в основное старое приложение новый онбординг на react native из приложения Pro. Разработчикам было больно (вспомните статьи Airbnb), но за 6 месяцев справились.

3. Учитывая опыт из двух предыдущих шагов, переписали основное приложение на React Native за 6 месяцев, не пытались дружить нативу с react native.

4. Profit. Красивые числа о технических и бизнес-метриках смотрите в картинке ниже.

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

Дальше собираются выделить общий уровень данных из веб-сайта на react и мобильных приложений на react native в общие библиотеки.

Их бы устами да мед пить! 🚀

В React Native есть теоретическая возможность менять поведение мобильных приложений, на лету загружая свежий код. Это почти обновление версий приложения в обход стандартного механизма апстора и google play.

Вчера на нашу вакансию react native разработчика в w1d1 откликнулся Игорь Зиновьев (просто познакомиться) и мы вспомнили, что давно хотим эту функцию, но никак её не прикрутим.

Игорь рассказал, что у Microsoft специально для этого есть удобный продукт, называется App Center CodePush.

Microsoft App Center — очень симпатичный сервис для разработки мобильных приложений. Это полный комплект CI/CD: автоматическая сборка с возможностью загрузки билдов из master ветки в сторы, удобный механизм распространения бета-версий в обход тестфлайта, автоматизированное тестирование на живом железе, креши, аналитика и многое другое. Всё это богатство с нормальным интерфейсом, человеческой документацией и хорошо интегрировано друг-с-другом.

Результативное собеседование, хоть и без оффера сразу после!

P.S. Интересно, как сработала идентификация «свой-чужой» у ребят, серьезно занимающихся react native. Кодовое слово — gesture handler.

Airbnb — одна из немногих крупных компаний (больше 100 мобильных разработчиков!), которая сделала ставку на React Native в мобильной разработке два года назад.

Их библиотека Native Navigation — одна из самых популярных.

За два года Airbnb написали на RN 80 тысяч строк кода, 220 экранов и 40 тысяч строк js-инфраструктуры (натива при этом 800 экранов и 320 тысяч строк кода).

Так вот, Airbnb отказывается от RN. Они описывают технические и организационные трудности в серии постов.

Аргументы, как всегда: незрелость технологии, плохие инструменты разработки, малое комьюнити и как следствие слабая веб-документация (в сравнении с iOS и Android), необходимость разбираться хорошо в мобайле и в js одновременно, сложность комбинации команд, сложность найма, низкая «воспринимаемая разработчиками» скорость разработки, добавленная сложность тестирования.

Ух.

Интересно, что они продолжают верить в Server-Driven Rendering. Это подход, в котором клиенты (мобильные приложения) умеют рисовать базовые компоненты, а сервер присылает список компонент и данные для экрана. Это дико интересный подход, и его на самом деле можно реализовать без RN (с RN он сам напрашивается). Сложности, которые возникают со старыми клиентами и фолбеками компонент в SDR — по настоящему интересная техническая задача. В ней нужно балансировать «красоту и гибкость в будущем» со сложность разработки «здесь и сейчас», а цена ошибки достаточно высока. Вот бы кто-то поделился своим опытом в этой области.

Часть проблем с RN, описанные Airbnb, специфичны для продуктовых компаний, часть — для крупных продуктовых компаний. В любом случае, «не создай себе кумира», выбирайте технологии не по хайпу, но на основе ваших потребностей и ваших ресурсов.

React Native: батл-по фактам в одном действии.

Произошел только что вот тут.

Айфоны и андроиды. Для потребителя разница минимальна. Тот же экран блокировки с большими цифровыми часами, те же самые приложения.

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

Если компания хочет сделать приложение и для андроидов и для айфонов, она содержит два параллельных отдела мобильной разработки - для iOS и для Android. Каждая из двух программ выглядит немного по-своему, сроки разработки немного разные, ошибки — уникальны.

Каждые пару лет появляется новая технология «кроссплатформенной разработки». Меняются названия, технологии под капотом и компании, её продвигающие. Я на своём профессиональном веку увидел хайп и угасание гигантов PhoneGap — монструозный HTML, купленный Adobe и позже отданный в Open Source и переименованный в Apache Cordova; Xamarin — пишем на C#, который компилируется в нативные приложения для каждой платформы. Microsoft купила её в 2016.

Остаются неизменными:
1) набор обещаний: в два раза меньше разработчиков (одна общая команда) и программы, выглядящие и работающие одинаково на айфонах и на андроидах;
2) проблемы — кросплатформенные программы тормозят, нещадно жрут батарейку, выглядят как пришельцы с другой планеты для внимательных пользователей каждой платформы, а ещё в какой-то момент эти инструменты начинают создавать больше проблем, чем решают.

Последняя модная (суперхайп) технология такого рода — React Native от Facebook. Программируем на современном lingua franca — javascript, а весь пользовательский интерфейс может быть нативным для платформы. Работает быстро, выглядит классно. Потенциально можно программировать силами веб-разработчиков (ну почти). Самое главное — в старые приложения можно добавлять новые экраны, сделанные на react-native. Технология молодая (2015 год), есть множество нерешенных проблем, но это первая кроссплатформенная балалайка, которую мне хочется попробовать. В России я знаю несколько компаний, которые успешно используют RN в продакшен-разработке. Радио Арзамас сделано на RN, например.

iOS разработчик из восхитительного Basecamp рассказывает, как они делают мобильные приложения.

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

Интересный способ делать "нативные" кросс-платформенные мобильные приложения. Особенно мне понравилось утверждение, что веб/нативное - не бинарное отношение, а целый спектр возможностей.

https://m.signalvnoise.com/basecamp-3-for-ios-hybrid-architecture-afc071589c25