Комментарии 16
Немного не пойму математику
`над мобильным приложением работали 4 разработчика из сторонней компании, а сегодня платформы поддерживают 60 штатных сотрудников`
`конверсия в заказ выросла на 10%`
т.е. при переходе с xamarin на более попсовые технологии стоимость разработки и поддержки выросла в 15 раз, а прибыль всего в 1.1 раза?
Ну у меня есть кейс когда четырех парттайм разработчиков нашей команды на аутстафе заменили 150 человеками фултайм "своими". А еще раньше это все далал парттайм один разаботчик, но его обманул его бухгалтер который вступил в сговор с менеджером заказчика и они распиливали бюджет заказчика, — чего этот разработчик какое-то время не знал и был против такого рода эксплуатации. Это же корпорация.
x15 vs x1.1 звучит конечно дико, но это только на первый взгляд,
ибо надо учитывать еще и базу, к которой этот множитель применяется.
И каждый следующий процент будет давать еще большими усилиями. угу.
Использование SwiftUI для создания прототипов очень экономит время, но когда появляется куча мелких окон и различных алертов, то сложность начинает расти лавинообразно. Вообще, Алерты в SwiftUI - отбельная боль, как по мне.
А в чем там проблема? Со SwiftUI не разбирался, но вроде бы как раз простота создания «мелких окон» должна быть вроде бы его преимуществом…
Доброе утречко! SUI созрел для прода, мы потратили большие усилия чтобы сравнить с UIKit. Мы используем SUI 2, он достаточен чтобы писать большие приложения. Проблем с алертами не испытываем, в будущем надеюсь расскажем, как их правильно готовить )
Вопрос нтереснее по первой статье когда пытались масштабировать MySQL? Вы по-преднему на MySQL? Как спраляетесь с возврошей загрузкой?
А почему iOS не на ReactNative? Мотивация взять ReactNative более менее понятна, но когда вы уже выбрали его набирать отдельную команду iOS разработки, чтобы делали все тоже самое что уже сделано на кроссплатформе выглядит не очень.
Доброе утро! Изначально хотели и андроид на нативе сделать, но оказалось у нас на старте есть хорошая компетенция в RN. iOS изначально планировался только на нативе делать. RN требует большой команды для интеграции платформеных фичей, поэтому никто и не думал его брать на обе платформы.
А не подскажите, что вы вкладываете в слово "планировался только на нативе"?
Исходя из чего принималось это решение?
И вот нет бы сделать быстрое нативное приложение на Kotlin — неее, сделаем тормозного монстра на недобраузере. Тьху.
Сервисом пользуюсь давно и постоянно, но вот что расстраивает – так это потеря части фукциональности приложения при обновлении. Раньше была возможность доукомплектации уже оформленного заказа (забыл включить в заказ на завтра печеньки – не беда, их можно добавить и к сформированному заказу). В новой версии приложения она пропала, обещают через твитор вернуть "когда-нибудь".
Переход на Swift UI и React Native: как за 3 месяца мы запустили новое приложение, быстро набравшее популярность