Кроссплатформенные мобильные приложения: что это и зачем

Что такое кроссплатформенное мобильное приложение

Кроссплатформенное мобильное приложение — это приложение, которое работает на iOS и Android, но разрабатывается преимущественно как один продукт: с общей логикой и единым подходом к интерфейсу. Цель кроссплатформенной разработки — быстрее выпускать функциональность и поддерживать её сразу на двух платформах, не создавая две полностью независимые версии.

Что означает «единая кодовая база»

Под «единой кодовой базой» обычно понимают общий набор исходного кода, где хранится основная бизнес‑логика (экраны, сценарии, работа с сетью, состояние, аналитика, часть UI). При этом не всё обязано быть одинаковым:

• Общее: логика приложения, большинство экранов, модели данных, интеграции с API.
• Разное (по необходимости): доступ к специфичным возможностям устройства (например, Apple Pay/Google Pay, виджеты, некоторые push‑сценарии), настройки сборки и иногда элементы UX, если платформенные гайды требуют различий.

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

Чем это отличается от мобильного сайта и PWA

Кроссплатформенное приложение — это всё-таки мобильная разработка с установкой из App Store/Google Play, доступом к системным API и полноценной работой с уведомлениями, камерой, Bluetooth и т. п.

Мобильный сайт живёт в браузере, а PWA (Progressive Web App) — промежуточный вариант: может устанавливаться как ярлык и частично работать офлайн, но ограничения браузера и платформы остаются (особенно на iOS).

Какие задачи чаще решают кроссплатформенные приложения

Чаще всего кроссплатформа подходит для продуктов, где важны time-to-market и единая функциональность на iOS и Android: клиентские кабинеты, маркетплейсы, сервисы доставки, приложения для бронирований, финтех‑продукты (если нет тяжёлых нативных требований), корпоративные приложения и MVP.

Популярные технологии — Flutter и React Native: обе позволяют собрать приложение с близким к нативному UX и сократить стоимость разработки за счёт общего кода.

Как это работает на практике

Кроссплатформенное мобильное приложение обычно проектируют так, чтобы одно и то же решение запускалось на iOS и Android (а иногда дополнительно — на Web или desktop). Для пользователя это выглядит как обычное приложение из App Store или Google Play, но внутри разработка устроена иначе.

Платформы: iOS, Android (и иногда Web/desktop)

На старте команда определяет набор целевых платформ. Чаще всего это iOS и Android, потому что именно там сосредоточена основная аудитория мобильных продуктов. Если бизнесу важно расширить присутствие, подход иногда позволяет сделать версию для Web или настольных систем — но это отдельная договорённость по объёму работ и ожиданиям от UX.

Общий код: бизнес‑логика и UI

В кроссплатформенной разработке значительная часть кода общая:

• бизнес‑слой (правила, расчёты, работа с данными, авторизация);
• UI (экраны, компоненты, навигация) — в зависимости от технологии.

При этом приложение не обязано быть «на 100% одинаковым». Небольшие платформенные отличия обычно оставляют там, где пользователи ожидают привычное поведение: жесты, системные диалоги, расположение элементов, back‑навигацию.

Нативные модули — точечно

Если нужен функционал, который сложно или неэффективно реализовать стандартными средствами фреймворка, добавляют нативные модули. Это небольшие части кода на Swift/Objective‑C для iOS и Kotlin/Java для Android.

Так обычно подключают продвинутую работу с камерой, специфические Bluetooth‑сценарии, фоновые сервисы, сложные интеграции с SDK банков/маркетинга, глубокую кастомизацию push‑уведомлений.

Доступ к функциям телефона: плагины и «мосты»

Чтобы приложение могло использовать возможности устройства (камера, геолокация, уведомления), применяются плагины или механизм «моста» между кроссплатформенным кодом и системными API.

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

Сборка и публикация: разные пакеты для магазинов

Даже при общем коде итоговые артефакты всегда разные:

• для iOS собирается пакет под App Store;
• для Android — под Google Play.

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

Кроссплатформа vs нативная разработка vs PWA

Когда говорят «сделаем приложение для iOS и Android», на практике чаще всего выбирают один из трёх путей: нативная разработка, кроссплатформа или PWA. Они решают похожие задачи, но по‑разному влияют на сроки, бюджет, UX и доступ к возможностям телефона.

Нативная разработка (Swift/Objective‑C и Kotlin/Java)

Нативный подход — это два отдельных технологических стека: iOS обычно пишут на Swift, Android — на Kotlin. Часто это означает две команды (или минимум два набора компетенций), раздельные кодовые базы и отдельные релизы.

Плюсы: максимальная производительность, «идеальные» нативные анимации и UI‑паттерны, самый полный доступ к API устройства (камеры, Bluetooth, геолокации, фоновым задачам и т. д.). Минусы: дороже поддержка и сложнее синхронизировать изменения между платформами.

Кроссплатформенная разработка (Flutter, React Native и др.)

Кроссплатформа опирается на единый подход и в значительной степени общую кодовую базу для iOS и Android. Это помогает быстрее стартовать, проще запускать MVP и ускорять time‑to‑market, особенно когда продукт часто меняется.

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

Гибридные решения и WebView

Гибридные приложения часто «упаковывают» веб‑интерфейс в контейнер (WebView). Это уместно для контентных сервисов, внутренних корпоративных кабинетов или прототипов, когда нужен быстрый выпуск, а функциональность близка к сайту.

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

PWA

PWA — это веб‑приложение, которое можно «установить» из браузера. Оно удобно тем, что не требует публикации в сторе и обновляется как сайт. Но отличия принципиальные: установка зависит от браузера и ОС, а доступ к API устройства часто ограничен по сравнению с мобильными приложениями (особенно на iOS).

Основные технологии: Flutter, React Native и другие

Кроссплатформенная разработка опирается не на одну «волшебную» платформу, а на набор технологий, каждая из которых по‑своему решает задачу выпуска одного продукта для iOS и Android. Ниже — самые популярные варианты и то, чем они отличаются на практике.

Flutter

Flutter — фреймворк от Google, где интерфейс рисуется собственным движком. Это значит, что UI выглядит и ведёт себя одинаково на разных устройствах: вы описываете экраны на Dart, а Flutter сам рендерит их без опоры на нативные компоненты.

Сильные стороны: предсказуемый UI, хороший контроль над анимациями и визуальными эффектами, часто высокая производительность. Экосистема пакетов быстро растёт: есть готовые решения для навигации, авторизации, аналитики, работы с камерой и push‑уведомлениями — что ускоряет time‑to‑market.

React Native

React Native логично выбирать, если у команды уже есть опыт с React и веб‑разработкой. UI строится через декларативный подход: вы описываете компоненты, а приложение отображает их на нативных элементах платформы (через «мост»/интеграцию с нативным слоем).

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

Xamarin / .NET MAUI

Эти варианты рассматривают команды на .NET: можно переиспользовать C#‑код и существующие наработки. Подходит бизнесу, где уже есть .NET‑экосистема (бэкенд, экспертиза, инструменты), и важно снизить порог входа.

Kotlin Multiplatform (KMP)

Kotlin Multiplatform — подход, где общий не весь интерфейс, а в первую очередь бизнес‑логика (например, расчёты, модели, сетевой слой). UI при этом остаётся нативным для iOS и Android. Это компромисс: меньше общего кода, зато максимальная «нативность» UX там, где это критично.

Где здесь TakProsto.AI

Если ваша цель — быстро собрать и проверить кроссплатформенный MVP, стоит рассмотреть TakProsto.AI. Это vibe‑coding платформа для российского рынка: вы описываете продукт в чате, а система помогает собрать приложение (в том числе мобильное на Flutter), бэкенд на Go + PostgreSQL и веб‑часть на React. Важные практичные опции для продуктовой разработки: режим планирования, снапшоты и откат, экспорт исходников, деплой/хостинг и работа на серверах в России (данные не отправляются за рубеж).

Преимущества кроссплатформенной разработки

Кроссплатформенная разработка — это способ создать одно кроссплатформенное приложение для iOS и Android на общей кодовой базе. Для бизнеса это обычно означает более быстрый запуск продукта и меньшую стоимость разработки, особенно на старте.

Сокращение сроков и быстрый time‑to‑market

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

Быстрый MVP и проверка гипотез

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

Единый пользовательский опыт

Кроссплатформенные фреймворки (например, Flutter и React Native) позволяют держать единый дизайн и логику на двух платформах. Это снижает риск, что на iOS «одно», а на Android — «другое»: одинаковые сценарии, тексты, состояния экранов и правила валидации.

Поддержка и развитие без двойной работы

Практичный плюс — меньше дублирования изменений. Исправления багов, улучшения UX, обновления бизнес‑логики и интеграций чаще всего делаются один раз и попадают сразу в обе версии. В результате снижается операционная нагрузка и проще планируется roadmap.

Эти преимущества сильнее всего проявляются, когда продукт активно развивается и требуется регулярно выпускать обновления, сохраняя сопоставимое качество на iOS и Android.

Недостатки и типичные ограничения

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

Доступ к самым новым нативным API

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

На практике это означает риск: вы хотите внедрить новую системную фичу «в этом квартале», а в выбранном стеке её ещё нет или она работает нестабильно.

Нативные модули: иногда без них не обойтись

Если нет готового плагина или он не подходит по качеству, приходится писать нативный модуль (Swift/Obj‑C для iOS, Kotlin/Java для Android) и связывать его с кроссплатформенным кодом. Это увеличивает стоимость и добавляет отдельный слой поддержки: обновления SDK, изменения в iOS/Android, разные пайплайны сборки.

Тонкая настройка UI под каждую платформу

Даже при общей дизайн‑системе пользователи ожидают «родного» поведения: анимации, жесты, отступы, системные компоненты, навигация. В кроссплатформе можно приблизиться к нативному уровню, но иногда приходится делать развилки по платформам, поддерживать два варианта экранов или мириться с компромиссами.

Производительность: где может уступать и почему

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

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

Какие проекты хорошо подходят для кроссплатформы

Кроссплатформенная разработка особенно хорошо показывает себя там, где важны скорость запуска, единый функционал для iOS и Android и понятные пользовательские сценарии. Если продукту не нужно «выжимать максимум» из специфики каждой платформы, общий код часто даёт хороший баланс по стоимости, качеству и time‑to‑market.

Сервисы с типовыми сценариями

Лучшие кандидаты — приложения, где пользователь выполняет знакомые действия: авторизация, поиск, каталог, корзина, профиль, уведомления, чаты, оплата (через стандартные SDK).

Сюда часто попадают:

• маркетплейсы, сервисы доставки, личные кабинеты, мессенджеры

В таких продуктах ключевое — стабильный UX, быстрые итерации и одинаковое поведение на iOS и Android.

Контент и каталоги

Новости, медиа, витрины товаров, каталоги услуг, приложения для мероприятий — всё, где основная ценность в контенте и удобной навигации. Обычно требования к устройству умеренные, а производительности Flutter или React Native достаточно при аккуратной реализации.

Внутренние и корпоративные решения

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

Продукты с «умеренной» графикой

Если нет сложных 3D‑сцен, тяжёлой AR/VR‑части или уникальных анимаций «на грани» возможностей устройства, кроссплатформенное приложение обычно выглядит и ощущается нативно для большинства пользователей.

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

Когда лучше выбрать нативную разработку

Кроссплатформенный подход часто выигрывает по скорости и бюджету, но есть случаи, когда нативная разработка (отдельно для iOS и Android) даёт ощутимо лучший результат. Обычно это связано с предельными требованиями к производительности, нестандартным «железом» или нюансами UX, которые трудно повторить один в один.

Игры и высокая нагрузка на графику

Если вы делаете игру с динамичной 3D‑графикой, сложными шейдерами и стабильными 60–120 FPS, нативный стек и прямой доступ к игровым движкам/графическим API помогают выжать максимум.

AR/VR и необычные датчики

Для проектов со сложными AR/VR‑сценариями, компьютерным зрением, продвинутой работой с камерой, LiDAR, глубиной сцены, гироскопами и другими специфичными датчиками нативная разработка снижает риски. Так проще использовать новые возможности платформ сразу после релиза iOS/Android и точнее контролировать качество.

Поддержка старых устройств и «железная» стабильность

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

Уникальный «нативный» UX в деталях

Если продукт строится на тонких микровзаимодействиях: нестандартных жестах, сложных анимациях, глубокой интеграции с системными паттернами (например, iOS Human Interface Guidelines), нативный подход даёт больше контроля. Он помогает добиться ощущения «как будто это встроенное приложение», без компромиссов в мелочах.

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

Сроки, стоимость и команда: что меняется

Кроссплатформенная разработка заметно влияет на планирование проекта: по‑другому раскладываются релизы, бюджет и состав команды. Важно понимать, где выгоды действительно устойчивы, а где «экономия» может исчезнуть из‑за особенностей продукта.

Время до рынка: как влияет на релизы

Главный плюс — единая кодовая база для iOS и Android, поэтому функциональность часто выходит одновременно на обе платформы. Это ускоряет первые запуски (MVP) и упрощает регулярные обновления: меньше расхождений между версиями, проще синхронизировать бэклог.

Но сроки могут вырасти, если:

• нужно много нативных интеграций (Bluetooth, сложная камера, AR, виджеты);
• проект требует высокой «полировки» анимаций и поведения под каждую платформу;
• часть библиотек нестабильна или не поддерживает нужные версии iOS/Android.

Стоимость: где экономия реальна, а где нет

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

Где кроссплатформа может не дать ожидаемого эффекта:

• разработка и поддержка нативных модулей (иногда их становится много);
• сложная оптимизация производительности и памяти;
• длительная отладка «плавающих» багов, завязанных на конкретные устройства.

Команда: один стек вместо двух

Часто вместо двух мобильных команд (iOS + Android) достаточно одной кроссплатформенной. Однако платформенные нюансы никуда не исчезают: кто-то в команде должен понимать iOS/Android на уровне интеграций, сборки, публикации и диагностики.

Тестирование: матрица устройств никуда не исчезает

Даже при общей кодовой базе тестировать придётся обе платформы. Меняется лишь фокус: больше внимания к различиям UI, разрешениям (permissions), фоновой работе, push‑сценариям и особенностям системных компонентов.

Практичный подход — заранее составить матрицу устройств/ОС и закрепить её в критериях релиза, чтобы сюрпризы не «съели» сроки и бюджет.

Ключевые требования к продукту и UX

Кроссплатформенная разработка ускоряет запуск на iOS и Android, но успех приложения всё равно определяется качеством продукта и пользовательским опытом. Перед стартом стоит зафиксировать требования к UX так же строго, как требования к функциям: что пользователь должен сделать, за сколько шагов и в каких условиях (в дороге, без сети, одной рукой).

UI/UX: единый стиль или следование гайдам

Есть два рабочих подхода.

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

Второй — учитывать платформенные привычки: навигацию, расположение кнопок, жесты, системные элементы (например, модальные окна, переключатели, back‑навигацию). Такой UX часто воспринимается «роднее», но требует больше внимания к деталям и тестирования.

На практике обычно выбирают гибрид: общий дизайн‑системный набор + несколько «платформенных исключений» там, где это влияет на конверсию или снижает ошибки.

Доступность (a11y) и локализация

Доступность — не опция «на потом». Проверьте: контраст, масштабирование шрифтов, озвучивание элементов (screen readers), размеры зон касания, порядок фокуса. Это снижает количество жалоб и улучшает метрики удержания.

Локализация — не только перевод. Закладывайте разные форматы дат/валют, длину строк (например, текст на немецком или финском часто длиннее), направления письма (если планируются RTL‑языки), а также различия в правовых текстах.

Офлайн‑режим и кэширование

Чётко опишите, что работает без интернета: просмотр данных, черновики, очередь действий. Определите правила кэша (срок жизни, очистка, приоритет) и понятные состояния интерфейса: «нет сети», «обновляем», «данные устарели».

Push, глубокие ссылки и аналитика

Push‑уведомления должны быть полезными и управляемыми: категории, тихие часы, явная настройка. Глубокие ссылки (deep links) обязаны открывать нужный экран и корректно отрабатывать сценарий «приложение не установлено».

Аналитику лучше проектировать как часть продукта: ключевые события воронки, источники установок, ошибки, производительность. Это позволит сравнивать iOS и Android по одним и тем же метрикам и быстрее улучшать UX.

Техническая основа: архитектура, сборка и поддержка

Кроссплатформенное приложение — это не только «один код на iOS и Android», но и набор инженерных практик, которые помогают выпускать обновления предсказуемо и без сюрпризов. Если технический фундамент заложен правильно, скорость разработки (time‑to‑market) растёт, а стоимость поддержки снижается.

Архитектура: разделение бизнес‑логики, данных и UI

Самая частая причина «тормозов» и сложной поддержки — смешивание всего в одном месте. Практичнее заранее разделить:

• UI‑слой (экраны, компоненты, навигация);
• бизнес‑логику (правила, расчёты, сценарии пользователя);
• данные (API, база, кэш, работа с сетью).

Так проще менять интерфейс, не рискуя логикой, и наоборот. Для кроссплатформы это особенно важно: один и тот же модуль бизнес‑логики должен одинаково вести себя на iOS и Android.

Качество кода: линтеры, код‑ревью, стандарты

Чтобы кроссплатформенная разработка не превращалась в «зоопарк» стилей, закрепляют единые правила:

• линтеры и автоформатирование в репозитории;
• обязательное код‑ревью (минимум один проверяющий);
• соглашения: нейминг, структура папок, подход к состоянию и навигации.

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

CI/CD: автоматические сборки для iOS и Android

Даже при одном коде сборка остаётся «двухплатформенной»: сертификаты, подписи, сторы, версии. CI/CD решает это через автоматизацию:

• сборки по коммиту/тегу;
• прогон тестов;
• формирование релизных артефактов для App Store и Google Play;
• быстрые тестовые раздачи команде и бизнесу.

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

Мониторинг: крэши, перфоманс, логи, метрики

После релиза важнее всего видеть реальную картину: крэши, время запуска, «тяжёлые» экраны, сетевые ошибки. Для этого подключают мониторинг производительности, сбор логов и продуктовые метрики. Так команда быстрее находит регрессии, подтверждает улучшения и понимает, что именно влияет на UX.

Как выбрать подход: быстрый чек‑лист и следующие шаги

Выбор между кроссплатформой и нативом проще, если сначала зафиксировать вводные: кому вы делаете продукт, какие функции «обязательны», и что для вас важнее — скорость запуска или максимум возможностей устройства.

Быстрый чек‑лист перед стартом

Ответьте на вопросы (лучше письменно — это сразу превращается в требования):

• Аудитория: где больше пользователей — iOS, Android или примерно поровну? Нужны ли разные сценарии для разных платформ?
• Сроки: есть ли жёсткий дедлайн (релиз под сезон, контракт, инвестиционный раунд)?
• Бюджет: готовы ли вы финансировать две кодовые базы (iOS + Android) или важнее экономия на разработке и поддержке?
• Критичные функции: требуется ли тяжёлая графика, офлайн‑режим, AR, работа в фоне, Bluetooth/NFC, сложная камера, высокие требования к плавности UI?
• Интеграции: какие SDK обязательны (аналитика, платежи, карты, чат, push)? Есть ли у них стабильная поддержка Flutter/React Native?
• Команда: кого проще нанять и удержать под ваш стек? Есть ли экспертиза внутри?

Мини‑матрица выбора: кроссплатформа или нативная

Скорее кроссплатформа (Flutter/React Native), если:

• нужно быстрее выйти на рынок и параллельно запустить iOS и Android;
• интерфейс и логика в основном общие, без сильных различий по платформам;
• важнее предсказуемый бюджет на первую версию и дальнейшие итерации.

Скорее нативная разработка, если:

• критична максимальная производительность, сложная анимация/3D или «железные» сценарии;
• продукт сильно зависит от специфичных API платформы (фоновые сервисы, низкоуровневые сенсоры);
• вы строите долгосрочную платформенную стратегию и готовы инвестировать в две команды.

Риски и как их снизить

• Риск: «не потянем нужные функции» → сделайте прототип ключевого экрана/сценария (камера, карта, офлайн) до старта полного проекта.
• Риск: «производительность хуже ожиданий» → запустите пилот/MVP с измеримыми метриками (время старта, FPS, память) и зафиксируйте пороги качества.
• Риск: «не хватает библиотек/SDK» → заранее заложите нативные модули для узких мест и проверьте, кто будет их поддерживать.

Следующие шаги

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

• ориентиры по бюджету и форматам: /pricing
• практические статьи и кейсы: /blog
• обсудить ваш проект и получить рекомендацию по стеку: /contact

Если ваша задача — максимально ускорить путь от идеи до работающего прототипа (в том числе с мобильным клиентом на Flutter), попробуйте TakProsto.AI: можно зафиксировать требования в «планировании», быстро собрать первую версию, а затем при необходимости экспортировать исходники и развивать продукт уже в привычном процессе разработки.