Делаем первое приложение, на каком софте для мобильной разработки остановиться до сбора офферов?

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

Мы в прошлом году делали похожее приложение для оптовых B2B-заказов в Техасе. Взяли кроссплатформу, отдали всего 22.500 долларов. Обновления выкатываем на обе платформы сразу одним релизом. Сервер и регулярный саппорт библиотек обходятся сейчас где-то в 210 долларов в месяц.

Держитесь подальше от контор, заявляющих: «у нас есть готовый enterprise-движок, просто переоденем под вас». Чаще всего это старое закрытое легаси из прошлых проектов. Разойдетесь с агентством — систему можно выбрасывать, ни один нормальный инженер в этот код потом не полезет.

В ТЗ и договор обязательно забейте три пункта: 1) Передача всех исходников в стандартный публичный Git-репозиторий компании. 2) Аккаунты разработчика в App Store и Google Play оформляются строго на ваше юрлицо. 3) Сдача списка технических зависимостей с актуальными версиями библиотек.

скоро предстоит то же самое. а при единой кодовой базе нет риска нарваться на задержки модерации или реджекты в сторах Apple и Google, правила это не запрещают?

На модерации смотрят на логику и работу приложения а не на то, на каком языке оно написано. Чекают политику конфиденциальности, безопасность данных авторизацию и гайдлайны по UI. Если правила соблюдены, фреймворк сборки роли не играет; процедура проверки в обеих экосистемах абсолютно стандартная.

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

советую на первом этапе не перегружать приложение лишними фичами. клиент закинул в корзину, отправил заказ скачал накладную — и хватит и больше фич — больше багов на оеих платформах и космические счета от агентства.

Отличная работа.

Я сталкивался с тем же. При принятии решений записывайте и худший сценарий, а не только лучший.

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

Без измерений мы всегда приходим к одному и тому же. Это мое мнение, не утверждаю, что оно единственно верное.

Согласен, хочу даже особо подчеркнуть. Ответ сильно зависит от отрасли, универсального правила нет.

Пишите, если есть вопросы, отвечу по мере возможности.

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

на этом всё, извините, если затянул.

У нас было так. короче самое дешевое предложение обычно самое непродуманное.

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

Редко встретишь текст с такой ясностью изложения.

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

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

Спасибо, очень помогло.

Вы правы, я сам проходил через это. Если не зафиксировать это письменно с самого начала, потом возникнут споры.

Оставлю как заметку, пригодится.