Разработка
мобильных приложений
в Воронеже

Объем задач, количество интеграций и насколько быстро вы отвечаете на наши уточнения. Мы всегда оставляем немного пространства для финальных правок и тестов — чтобы не срывать сроки и спокойно довести все до ума.

Зависит от платформы (iOS, Android, Flutter), функциональности и технической архитектуры. Точную сумму сможем назвать после того, как обсудим задачи.

Да, и это даже удобно: логика будет общей, и ничего не придется клеить потом на ходу. Мы делаем и сайты, и приложения — проектируем все целиком, чтобы все работало как часы.

Не исчезаем :) Поддерживаем, обновляем под новые версии iOS и Android, следим за стабильностью и развиваем проект дальше. Для нас запуск — это точка роста.

Да, и без боли. Мы сразу строим архитектуру так, чтобы было удобно масштабироваться. Нужен чат? Онлайн-оплата? Темная тема? Все добавляется по мере роста.

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

Через СБП и эквайринг с картами «Мир», иногда через веб-кассу за пределами приложения. Встроенные покупки Google Play недоступны, и это ограничение учитывают в проектировании. Отдельно проверяем требования App Store к упоминанию внешней оплаты: формулировки на экране влияют на результат ревью не меньше, чем сама схема платежей.

Для российской аудитории да. Держим сборки синхронно и следим, чтобы номер версии и набор функций совпадали: расхождение рождает обращения в поддержку, которые невозможно воспроизвести на другом сторе. Заодно проверяем глубокие ссылки и push-токены — они зависят от источника установки.

База и резервные копии — на территории России. Сторонние SDK инвентаризируем до релиза: аналитика и крэш-репортеры по умолчанию нередко отправляют идентификаторы за рубеж. Такой трафик либо отключаем, либо заменяем на решение с серверами в стране. Проверка занимает день на старте и экономит переписку с проверяющими потом.

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

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

Минимум под мажорные обновления iOS и Android, то есть примерно раз в год, плюс по требованиям сторов к версии SDK. Без этого приложение сначала перестаёт принимать новые сборки, затем теряет видимость в поиске стора. Поэтому сопровождение закладывают в бюджет сразу, вместе с разработкой.

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

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

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

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

Ставим счётчик событий по ключевым шагам сценария: запуск, регистрация, основное действие, оплата. Важно определить события до релиза, потому что данных задним числом не появится. Выбираем решение с серверами в России, чтобы не конфликтовать с требованием о территории хранения. Дашборд собираем по вашим вопросам к продукту.

Расписание, доступ к материалам, уведомления об изменениях и оплата курса. Основная сложность обычно в материалах: видео и объёмные файлы требуют решения по хранению и кэшированию, иначе приложение расходует трафик студентов. Загрузку для офлайн-просмотра и срок жизни кэша согласуем отдельно.

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