Приложения для iOS и Android

Разработка мобильных приложений из Турции для России и СНГ

Разработка мобильных приложений в HazırSoft строится вокруг задач, которые пользователь выполняет на телефоне. В приложениях для iOS и Android на Flutter прорабатываются не только экраны, но и поведение при потере соединения, разрешения устройства, проверки на сервере и совместимость со старыми версиями приложения. Объём разработки зависит от того, как оформление заказа, запись на приём или выполнение выездного задания должны проходить в реальных условиях. Из Турции мы можем удалённо разработать и передать мобильное ПО командам по всей стране и компаниям, создающим продукты для России и СНГ, включая Казахстан, Узбекистан и Азербайджан. На встречах на турецком или английском языке рассматриваем тестовые версии через конкретные пользовательские задачи. Ответственность за аккаунт магазина приложений и условия публикации в целевой стране разграничиваем в начале проекта. Письменный запрос Вы можете отправить по-русски.

  • План приёмочных испытаний для целевых устройств и версий операционных систем
  • Понятные пользователю состояния при отказе в разрешениях и потере соединения
  • Проектирование локального хранения данных и разрешения конфликтов синхронизации
  • API, совместимый со старыми версиями приложения
  • Проверка пользовательских сценариев через TestFlight и тестовые каналы Google Play
  • Подготовка к публикации: аккаунты, подпись приложения и сведения об обработке данных
gonnetlioglu.com
Gönnetlioğlu — Система онлайн-бронирования и многоязычный сайт
Наш запущенный проект Gönnetlioğlu · Аренда автомобилей, автодомов и яхт

Состав услуг

Разработка мобильных приложений — что входит в услугу?

Разработка приложений для iOS

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

Подробнее

Разработка приложений для Android

Определите сценарии работы с клавиатурой, жестом «Назад» и сетевым подключением для целевых версий Android и поддерживаемых размеров экранов.

Подробнее

Кроссплатформенное приложение на Flutter

Развивайте общую кодовую базу с учётом платформенных плагинов и результатов тестирования на устройствах; проверяйте влияние обновлений на обеих платформах.

Подробнее

Мобильное приложение для интернет-магазина

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

Подробнее

Приложение для записи и бронирования

Разграничьте для пользователя доступные варианты, предварительную бронь, истечение срока её действия и подтверждённое бронирование.

Подробнее

Корпоративные приложения и приложения для выездной работы

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

Подробнее

Разработка PWA

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

Подробнее

API и панель управления

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

Подробнее

Публикация в магазинах приложений и сопровождение

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

Flutter и особенности работы на разных платформах

Разработка мобильных приложений требует разграничивать общие проектные решения и особенности каждой платформы. Flutter позволяет использовать общую кодовую базу для iOS и Android, но разрешения на уведомления, жест «Назад», клавиатура, выбор файлов и работа в фоновом режиме всё равно рассматриваются отдельно. Выбор технологии определяется реальными пользовательскими задачами. Сканирование документов камерой и постоянное соединение по Bluetooth предъявляют разные требования. Наличие подходящего плагина не означает, что необходимое поведение уже проверено на целевых устройствах.

Разработка с учётом особенностей платформы

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

Приёмка на устройствах

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

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

Приложение из магазина или PWA?

Потребность в мобильном канале не означает, что каждый посетитель должен устанавливать приложение. Если первое знакомство происходит через поиск, обращения редки, а основная задача — получение информации, подходящим решением может быть сайт, адаптированный для мобильных устройств. Регулярная работа в аккаунте, использование возможностей устройства и ежедневные выездные задания могут сделать приложение из магазина более полезным. Решение зависит от того, насколько оправдана необходимость установки для пользователя.

PWA — это веб-приложение, доступное через браузер, которое при определённых условиях можно добавить на главный экран. Запуск без интернета, уведомления и фоновые задачи зависят от браузера и операционной системы. Нельзя предполагать, что на каждом устройстве PWA предоставляет все возможности приложения из магазина. Нужные сценарии проверяются на целевых устройствах; удобство распространения по веб-адресу оценивается вместе с ограничениями браузера.

КритерийПриложение из магазинаPWA
РаспространениеНеобходимы аккаунт, подпись приложения и проверка магазиномДоступно по веб-адресу
ОбновлениеУ пользователей могут оставаться старые установленные версииНужно продумать обновление кеша
Аппаратные возможностиДоступ регулируется разрешениями платформыДоступ зависит от возможностей браузера

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

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

Разные правила для заказов, записи и выездной работы

Приложения для покупок

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

Приложения для записи

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

Выездные и внутрикорпоративные задачи

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

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

Внутрикорпоративное распространение отличается от общедоступной публикации в магазине приложений. Изучаются актуальные условия вариантов распространения Apple и Google, тип аккаунта и целевые пользователи. Обучение также проводится на устройстве: сотрудник узнаёт не только названия экранов, но и порядок действий при потере соединения, изменении разрешений и повторном открытии задачи. Это помогает сотрудникам, отвечающим за рабочие процессы, не принимать незавершённые операции за выполненные.

Жизненный цикл API, уведомлений и версий клиента

Мобильный клиент не подключается напрямую к базе данных, а выполняет бизнес-операции через API с проверкой прав доступа. Серверная часть на Laravel и MySQL управляет доступом к записям и бизнес-правилами. Для хранящихся на телефоне данных авторизации определяются срок действия, порядок обновления и отзыв доступа при потере устройства. Экран входа — не единственный рубеж защиты: для каждого запроса должны проверяться права на соответствующую операцию.

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

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

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

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

Процесс работы

Как создаётся мобильное приложение: 6 этапов разработки

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

  1. Задачи и целевые устройства

    Определяются основная пользовательская задача, целевые устройства, разрешения и требования к работе без интернета. Изучаются доступ к API и условия распространения; для первого выпуска выбирается полный пользовательский сценарий.

  2. Проверка прототипа на телефоне

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

  3. Контракт API

    Документируются поля запросов, статусы ответов и права доступа. Определяются условия поддержки старых клиентов и требования к актуальности данных. Устанавливается связь между операциями в панели управления и на мобильных экранах.

  4. Flutter и взаимодействие с устройством

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

  5. Приёмка на реальных устройствах

    На выбранных устройствах проверяются работа с сеансами, потеря соединения, синхронизация и повторная отправка. Используются TestFlight и тестовые каналы Google Play; проверяется, что конфиденциальные данные не отображаются в чужом аккаунте.

  6. Публикация и передача проекта

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

Стоимость

От чего зависит стоимость разработки мобильного приложения?

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

  1. Платформы и технология

    Только iOS, только Android или обе платформы; единая кодовая база на Flutter или нативная разработка? Создание двух отдельных нативных приложений почти удваивает объём работы.

  2. Экраны и функциональность

    Количество и сложность модулей: регистрация и аккаунт, оплата, карты, обмен сообщениями, отслеживание в реальном времени и push-уведомления. Ограничение первой версии рамками MVP — наиболее действенный способ снизить нагрузку на бюджет.

  3. Уровень дизайна

    Простой интерфейс со стандартными компонентами или полностью индивидуальный UI/UX-дизайн для Вашего бренда с оригинальными иллюстрациями и анимацией?

  4. Серверная часть и панель управления

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

  5. Интеграции

    Интернет-эквайринг, подтверждение по SMS, подключение служб доставки, ERP или бухгалтерских систем. Качество документации и процесс тестирования каждой интеграции напрямую влияют на сроки.

  6. Сопровождение и эксплуатационные расходы

    Условия сопровождения после публикации и расходы, оплачиваемые напрямую поставщикам, — аккаунт разработчика, сервер, SMS и картографический сервис — указываются в предложении отдельными статьями.

Чтобы узнать точную стоимость: <a href="https://www.hazirsoft.com/ru/zapros-predlozheniya">Расскажите</a> о целевых пользователях, основной задаче, существующем API и необходимости работы без интернета. Определим состав работ для предложения с учётом поведения приложения на устройствах и способа распространения.

Получить бесплатное предложение

Частые вопросы

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

Не нашли свой вопрос?Давайте уточним вашу задачуНапишите нам

Какие задачи можно продолжить без интернета?

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

Что делает приложение, если пользователь не предоставил разрешение?

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

Кто отвечает за аккаунты в магазинах приложений?

Мы помогаем связать аккаунты с Вашей компанией. Порядок подтверждения организации и необходимые документы зависят от требований Apple и Google. Сведения о конфиденциальности и безопасности данных основываются на фактическом поведении приложения. Срок проверки и одобрение приложения не гарантируются.

Что происходит с ожидающими отправки записями при смене телефона?

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

Как приложение подключается к сайту?

Изучаются существующий API, механизм управления сеансами и модель данных. Для мобильных операций предоставляются защищённые конечные точки API, а не прямой доступ к базе данных. Цены и остатки проверяются на сервере. Единый источник данных не означает автоматического одновременного обновления всех экранов.

Как обеспечивается работа старых установленных версий?

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

Как проверяется производительность приложения на Flutter при приёмке?

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

Блог

Полезные статьи по теме

Получить предложение

Обсудим ваш проект

Давайте уточним вашу задачу

Напишите нам в WhatsApp