Разработка мобильных приложений на C# для iOS и Android

Что на самом деле означает «приложение на C#»

C# — язык платформы .NET. Если команда делает мобильное приложение на нём, значительная часть кода — обмен с сервером, расчёты, проверки, хранение данных — пишется один раз и работает и на iPhone, и на Android-смартфонах. Отдельными остаются вещи, которые зависят от системы: push-уведомления, доступ к камере и геолокации, подпись сборок и публикация в App Store и Google Play.

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

Какие технологии на C# выбирают сейчас

Раньше стандартом был Xamarin, но его поддержка прекращена, поэтому новые проекты на нём начинать не стоит. Его место занял .NET MAUI. Есть и другие варианты:

• .NET MAUI — один проект и общий интерфейс для Android и iOS; основной выбор для бизнес-приложений с формами, каталогами и личным кабинетом.
• Blazor Hybrid — экраны собираются из веб-компонентов внутри нативной оболочки; удобно, если у вас уже есть веб-часть на .NET с похожими страницами.
• Uno Platform и Avalonia — альтернативы с собственной отрисовкой интерфейса; их берут, когда нужен одинаковый вид на всех устройствах, включая компьютер.
• Общее ядро на C# и нативные экраны — логика одна, а интерфейс каждой платформы делается отдельно на Swift и Kotlin.

C# или натив: сравнение по задачам

Решать лучше по функциям, а не «вообще». Вот как это выглядит на практике:

• Каталог, корзина, заявки, личный кабинет, статусы заказа — общий код справляется хорошо.
• Курьеры и торговые агенты: карта, трекинг, работа при слабом интернете в регионах — подходит, но офлайн-режим и фоновую работу нужно проверять на реальных телефонах.
• Сложная работа с камерой, AR, обработка видео, нестандартные анимации — чаще лучше натив.
• Нужны новые функции iOS или Android сразу после выхода системы — натив получает доступ раньше, кроссплатформенные инструменты догоняют с задержкой.
• Игры и тяжёлая графика — отдельная категория, там обычно используют игровые движки.

Смешанная схема как компромисс

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

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

Пример: приложение для оптового склада в Ташкенте

Допустим, оптовая компания в Ташкенте продаёт хозтовары магазинам в областях. Заказы приходят в Telegram и по телефону, часть данных теряется, остатки в учёте расходятся с тем, что знают клиенты. Владелец хочет приложение: каталог с остатками, заказ в несколько касаний, оплата через Click или Payme, история закупок и кнопка «повторить заказ».

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

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

Как вести проект по шагам

Порядок действий, который снижает риск переделок:

• Определите действие, которое приносит деньги: заказ, запись, повторная покупка. Всё остальное вторично.
• Опишите минимальную версию — несколько ключевых сценариев, без «хотелок на потом».
• Выясните серверную часть: есть ли API, откуда берутся товары и цены, как связаны 1С или CRM.
• Выберите подход по функциям: общий код, натив или смешанный.
• Сделайте кликабельный прототип и покажите его сотрудникам и нескольким клиентам.
• Разрабатывайте этапами с тестовыми сборками на реальных устройствах, включая недорогие Android-телефоны, которых много в регионах.
• Подготовьте публикацию: аккаунты разработчика Apple и Google на компанию, политику конфиденциальности, скриншоты, описание на русском и узбекском.

Типичные ошибки

Самые дорогие промахи случаются не в коде, а в решениях до него:

• Начинать с приложения, не проверив спрос другими каналами.
• Выбирать технологию по моде или по цене первого этапа, а не по требованиям функций.
• Не заложить два языка интерфейса и корректный ввод кириллицы и латиницы.
• Тестировать только на новом iPhone и одном «идеальном» Android.
• Регистрировать магазинные аккаунты на подрядчика, а не на свою компанию.
• Не получить исходники, доступы к серверу и документацию.
• Не планировать обновления: версии систем выходят регулярно, и без поддержки приложение со временем ломается.

Из чего складывается стоимость

Без привязки к цифрам: цену формируют объём экранов и функций, дизайн под обе платформы, серверная часть и интеграции (Click, Payme, SMS, 1С, CRM), доля нативных узлов, тестирование, публикация и поддержка после релиза. Общий код снижает сумму запуска, потому что исчезает дублирование логики, но дизайн, бэкенд и проверки он не отменяет.

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

Чек-лист перед стартом и роль сайта

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

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