Влияет ли выбор языка для iOS-приложения на смету агентства и расходы на поддержку?

Вы уже точно определились с функционалом приложения? Будет ли там сканирование штрихкодов по Bluetooth, постоянный фоновый GPS-трекинг или сложная анимация камеры? Если это стандартные операции с базой данных вроде каталога товаров, подтверждения заказов и отправки пушей, возможно, переплачивать разницу в 110.000 TL за натив и не стоит. Но если планируется серьезная интеграция с железом, кроссплатформа потом влетит в копеечку.

В прошлом году заказывали похожее приложение для заказов. Отдали 180.000 TL и пошли по пути кроссплатформы, первый год все работало без нареканий. Но после обновления операционки отвалился модуль сканирования штрихкодов через камеру. Агентство заявило, что используемая open-source библиотека заброшена, модуль надо писать с нуля, и выкатило нам счет еще на 45.000 TL. Больше половины нашей первоначальной экономии сгорело на исправлении одного-единственного бага.

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

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

Пункты, которые нужно внести в ТЗ еще до финальных переговоров с агентством: 1) Исходный код должен соответствовать стандартам чистой архитектуры и содержать исчерпывающие комментарии. 2) Используемый стек/язык разработки должен быть актуальной версии с долгосрочной поддержкой (LTS). 3) При сдаче проекта должен быть предоставлен полный реестр всех внешних библиотек с указанием их лицензий и версий. 4) На случай прекращения сотрудничества с агентством должно быть подготовлено пошаговое руководство по развертыванию, чтобы проект могла подхватить любая другая команда.

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

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

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

Верно. Доступы должны открываться на компанию, а не на личные аккаунты.

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

Спасибо, это именно то, что я искал. Без измерений мы всегда приходим к одному и тому же.

Надеюсь, это будет полезно.

вы правы.

Вы правы. Самое дорогое в унаследованной системе — неизвестные зависимости.

Проверено опытом.

Давайте немного раскрою техническую сторону. Когда пытаешься изменить всё сразу, ничего не приживается.

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

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

удачи.

Не могли бы вы это пояснить? Самое дешевое предложение обычно самое непродуманное.

Это мое мнение, не утверждаю что оно единственно верное.

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

Интересно есть ли те кто делает иначе.

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

Есть один момент, который меня интересует. Внедрение процесса управления изменениями не замедляет работу, а ускоряет её.

Это мое мнение, не утверждаю, что оно единственно верное.