Как стать автором
Обновить

Переход на Swift UI и React Native: как за 3 месяца мы запустили новое приложение, быстро набравшее популярность

Время на прочтение7 мин
Количество просмотров7.2K
Всего голосов 11: ↑8 и ↓3+5
Комментарии16

Комментарии 16

Немного не пойму математику
`над мобильным приложением работали 4 разработчика из сторонней компании, а сегодня платформы поддерживают 60 штатных сотрудников`
`конверсия в заказ выросла на 10%`
т.е. при переходе с xamarin на более попсовые технологии стоимость разработки и поддержки выросла в 15 раз, а прибыль всего в 1.1 раза?

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

x15 vs x1.1 звучит конечно дико, но это только на первый взгляд,
ибо надо учитывать еще и базу, к которой этот множитель применяется.

И каждый следующий процент будет давать еще большими усилиями. угу.

Использование SwiftUI для создания прототипов очень экономит время, но когда появляется куча мелких окон и различных алертов, то сложность начинает расти лавинообразно. Вообще, Алерты в SwiftUI - отбельная боль, как по мне.

А в чем там проблема? Со SwiftUI не разбирался, но вроде бы как раз простота создания «мелких окон» должна быть вроде бы его преимуществом…

Если коротко, то коллекция компонентов неполная, а это значит, что приходится клепать обертки uiviewrepresentable, чтоб использовать uikit, например.

Доброе утречко! SUI созрел для прода, мы потратили большие усилия чтобы сравнить с UIKit. Мы используем SUI 2, он достаточен чтобы писать большие приложения. Проблем с алертами не испытываем, в будущем надеюсь расскажем, как их правильно готовить )

а что вы делаете со старыми осями на проде? отправляете их в мобильный веб?
ну в принципе вполне себе решение.

Вопрос нтереснее по первой статье когда пытались масштабировать MySQL? Вы по-преднему на MySQL? Как спраляетесь с возврошей загрузкой?

А почему iOS не на ReactNative? Мотивация взять ReactNative более менее понятна, но когда вы уже выбрали его набирать отдельную команду iOS разработки, чтобы делали все тоже самое что уже сделано на кроссплатформе выглядит не очень.

Доброе утро! Изначально хотели и андроид на нативе сделать, но оказалось у нас на старте есть хорошая компетенция в RN. iOS изначально планировался только на нативе делать. RN требует большой команды для интеграции платформеных фичей, поэтому никто и не думал его брать на обе платформы.

А не подскажите, что вы вкладываете в слово "планировался только на нативе"?

Исходя из чего принималось это решение?

Доброе утро. «Планировался только на нативе» – это swift для iOS.

\ Исходя из чего принималось это решение?

Планы по развитию приложения составляли с акцентом на платформенный функционал в будущем.

И вот нет бы сделать быстрое нативное приложение на Kotlin — неее, сделаем тормозного монстра на недобраузере. Тьху.

React Native - это все таки не WebView, контролы там будут дергаться те же самые что и из Kotlin.

Сервисом пользуюсь давно и постоянно, но вот что расстраивает – так это потеря части фукциональности приложения при обновлении. Раньше была возможность доукомплектации уже оформленного заказа (забыл включить в заказ на завтра печеньки – не беда, их можно добавить и к сформированному заказу). В новой версии приложения она пропала, обещают через твитор вернуть "когда-нибудь".

Зарегистрируйтесь на Хабре, чтобы оставить комментарий