The post has been translated automatically. Original language: Russian
A little bit about us
We are a Troubleshooting Technology company, which has been engaged in the design and development of IT solutions for business, education and government agencies for more than 6 years. During this time, we have implemented dozens of projects, from mobile applications and web services to integration platforms and analytics and automation systems.
What are we going to talk about
In the continuation of the last post, let's look at what approaches there are when developing a mobile application. And in this post we'll talk about the native approach (different iOS and Android apps in different languages, on iOS it's Objective-c or Swift, on Android it's Java or Kotlin)
Native development
Native development is the creation of applications directly for a specific platform: iOS or Android. Each OS uses its own language and set of tools. On iOS it's Swift or Objective-C, on Android it's Kotlin or Java.
This is historically the first and most obvious way to create mobile apps. Since the advent of the App Store and Google Play, developers have been writing for specific devices and systems.
It is good because it gives:
- maximum access to the device's capabilities;
- high speed and optimization;
- the best user experience (UI/UX is created by the native means of the platform);
- reliability and support directly from Apple and Google.
What is the difference between PWA and cross-platform
1. Architecture and execution environment
- Native: the code is written in the languages of the platform (Kotlin/Java for Android, Swift/Obj-C for iOS), compiled into bytecode and runs directly in the OS environment using system APIs.
- PWA: Works in a browser engine (WebView or Chrome Custom Tabs), even if "packaged" in TWA and published in the store. In other words, the browser layer always remains.
- Cross-platform (React Native, Flutter, etc.): the code is shared, but either compiled into native widgets (React Native via bridge), or into its own rendering (Flutter via Skia). In any case, there is a gap between the code and the OS.
2. Access to device functions
- Native: direct access to all APIs and new OS features on the day of release (NFC, ARKit, HealthKit, UWB, etc.).
- PWA: access is limited to what is implemented in the browser (Web Bluetooth, Web NFC, Web Push, etc.). It is gradually expanding, but it strongly depends on the engine and platform. On iOS, for example, Safari has been cutting off push and background sync for a long time.
- Cross-platform: almost full access to native features, but through plugins or bridge. New APIs have to wait for them to be wrapped. Sometimes you need to write your own native module.
3. UX and UI
- Native: fully complies with the guidelines (Material, Human Interface Guidelines). The most responsive interface, native animations, full control.
- PWA: The UI is drawn using web tools. You can make it close to native, but there is always a risk of differences (gestures, performance on weak devices, integration with system patterns).
- Cross-platform: React Native uses real native components, Flutter renders everything by itself. Bottom line: very close to the native UX, but there may be nuances (different bugs on different operating systems, "non-standard" sensations in small things).
4. Performance
- Native: maximum — works directly with the OS and hardware.
- PWA: depends on the browser. In heavy scenarios (games, 3D, complex animations) it can be much inferior.
- Cross-platform: performance is close to native, but depends on the engine. Flutter is faster in the UI due to its rendering, React Native can run into bridge with a large number of events.
5. Updates and delivery
- Native: Updates only through stores (Google Play, App Store). This is both a plus (control, user trust) and a minus (deployment speed).
- PWA: it is updated instantly as a website — the user always gets the latest version.
- Cross-platform: usually through stores, but you can implement hot reload through services (CodePush and analogues).
6. Development and support
- Native: separate code base for iOS and Android, different teams, higher cost.
- PWA: one codebase for the web and the "application". Cheap, fast, but limited.
- Cross-platform: a single code, but you still have to take into account platform differences and sometimes write native modules. A balance between speed and capabilities.
Native Development Tools
iOS
- Languages: Swift (primary) and Objective-C (obsolete, but still in use).
- IDE: Xcode.
- Positive: high performance, strict guidelines, convenient stack.
- Cons: closed ecosystem, working only with Apple devices.
Android
- Languages: Kotlin (recommended) and Java (obsolete standard).
- IDE: Android Studio.
- Pros: flexibility, working with any hardware, a huge community.
- Cons: a large number of devices and OS versions, complicated testing and support.
User perception
For the user, a native app is a reference experience. The interface follows the usual iOS or Android patterns, works smoothly, and looks "native". Unlike PWA and cross-platform, there are practically no compromises: the UX is completely the way the platform itself intended it to be. You can compare several applications that are developed separately for each platform, the difference is quite significant.
Functionality Native apps have full and direct access to all device functions: camera, GPS, Bluetooth, NFC, biometrics, ARKit/ARCore, background tasks, push services, and any system API. This makes the native approach a must-have choice for projects where maximum integration and productivity are important.
From the point of view of development
- Resources: we need separate developers for iOS and Android, or two teams.
- Deadlines: longer than for a cross-platform, as you have to run two projects in parallel.
- Cost: higher, almost twice as expensive as cross-platform or PWA.
- Support: More predictable, as OS and SDK updates come directly from Apple and Google.
General conclusion
Native development is the choice for projects where speed, stability, and full access to the device's capabilities are critical, i.e. when you need to be "expensive".
It is suitable for:
- banking and government services;
- games with heavy graphics;
- applications with AR/VR and complex animations;
- solutions that require increased security.
It's not suitable if you need to release an MVP quickly, keep within a small budget, or make do with minimal team effort.
Немного о нас
Мы — компания Troubleshooting Technology, уже более 6 лет занимаемся проектированием и разработкой IT-решений для бизнеса, образования и государственных структур. За это время реализовали десятки проектов: от мобильных приложений и web-сервисов до интеграционных платформ и систем аналитики и автоматизации.
О чем поговорим
В продолжении прошлого поста разберем какие подходы есть при разработке мобильного приложения. И в этом посте поговорим про нативный подход (разные приложения для iOS и Android на разных языках, на iOS это Objective-c или Swift, на Android это Java или Kotlin)
Нативная разработка
Нативная разработка — это создание приложений напрямую под конкретную платформу: iOS или Android. Для каждой ОС используется свой язык и набор инструментов. На iOS это Swift или Objective-C, на Android — Kotlin или Java.
Это исторически первый и самый очевидный способ создавать мобильные приложения. С самого появления App Store и Google Play разработчики писали под конкретные устройства и системы.
Хороша тем, что дает:
- максимально глубокий доступ к возможностям устройства;
- высокую скорость и оптимизацию;
- лучший пользовательский опыт (UI/UX создаётся «родными» средствами платформы);
- надёжность и поддержку напрямую от Apple и Google.
Чем отличается от PWA и кроссплатформы
1. Архитектура и среда исполнения
- Натив: код пишется на языках платформы (Kotlin/Java для Android, Swift/Obj-C для iOS), компилируется в байткод и работает напрямую в среде ОС, используя системные API.
- PWA: работает в браузерном движке (WebView или Chrome Custom Tabs), даже если «упакована» в TWA и опубликована в магазине. То есть слой браузера остаётся всегда.
- Кроссплатформа (React Native, Flutter и др.): код общий, но либо компилируется в нативные виджеты (React Native через bridge), либо в собственный рендеринг (Flutter через Skia). В любом случае есть прослойка между кодом и ОС.
2. Доступ к функциям устройства
- Натив: прямой доступ ко всем API и новым фичам ОС в день релиза (NFC, ARKit, HealthKit, UWB и т.д.).
- PWA: доступ ограничен тем, что реализовано в браузере (Web Bluetooth, Web NFC, Web Push и пр.). Постепенно расширяется, но сильно зависит от движка и платформы. На iOS, например, Safari долгое время резал push и background sync.
- Кроссплатформа: почти полный доступ к нативным функциям, но через плагины или bridge. Новые API приходится ждать, пока их обернут. Иногда нужно писать свой нативный модуль.
3. UX и UI
- Натив: полностью соответствует гайдам (Material, Human Interface Guidelines). Максимально отзывчивый интерфейс, нативные анимации, полный контроль.
- PWA: UI рисуется средствами веба. Можно сделать близко к нативному, но всегда есть риск отличий (жесты, перформанс на слабых устройствах, интеграция с системными паттернами).
- Кроссплатформа: React Native использует настоящие нативные компоненты, Flutter рендерит всё сам. Итог: очень близко к нативному UX, но могут быть нюансы (разные баги на разных ОС, «нестандартные» ощущения в мелочах).
4. Производительность
- Натив: максимум — работает напрямую с ОС и железом.
- PWA: зависит от браузера. В тяжёлых сценариях (игры, 3D, сложные анимации) может сильно уступать.
- Кроссплатформа: производительность близка к нативу, но зависит от движка. Flutter быстрее в UI за счёт своего рендера, React Native может упираться в bridge при большом количестве событий.
5. Апдейты и доставка
- Натив: обновления только через магазины (Google Play, App Store). Это и плюс (контроль, доверие пользователей), и минус (скорость деплоя).
- PWA: обновляется мгновенно как сайт — пользователь всегда получает свежую версию.
- Кроссплатформа: обычно через магазины, но можно внедрить hot reload через сервисы (CodePush и аналоги).
6. Разработка и поддержка
- Натив: отдельная кодовая база для iOS и Android, разные команды, выше стоимость.
- PWA: одна кодовая база для веба и «приложения». Дёшево, быстро, но ограничено.
- Кроссплатформа: единый код, но всё равно приходится учитывать платформенные отличия и иногда писать нативные модули. Баланс между скоростью и возможностями.
Инструменты нативной разработки
iOS
- Языки: Swift (основной) и Objective-C (устаревающий, но всё ещё используется).
- IDE: Xcode.
- Плюсы: высокая производительность, строгие гайдлайны, удобный стек.
- Минусы: закрытая экосистема, работа только с Apple-устройствами.
Android
- Языки: Kotlin (рекомендуемый) и Java (устаревающий стандарт).
- IDE: Android Studio.
- Плюсы: гибкость, работа с любым железом, огромное сообщество.
- Минусы: большое количество устройств и версий ОС, усложнённое тестирование и поддержка.
Восприятие пользователем
Для пользователя нативное приложение — это эталонный опыт. Интерфейс соответствует привычным паттернам iOS или Android, работает плавно, выглядит «родным». В отличие от PWA и кроссплатформы, здесь практически нет компромиссов: UX полностью такой, каким его задумала сама платформа. Можете сравнить несколько приложений, которые разработаны отдельно для каждой платформы, разница довольно существенная.
Функциональные возможностиНативные приложения имеют полный и прямой доступ ко всем функциям устройства: камере, GPS, Bluetooth, NFC, биометрии, ARKit/ARCore, фоновым задачам, push-сервисам и любым системным API. Это делает нативный подход обязательным выбором для проектов, где важны максимальная интеграция и производительность.
С точки зрения разработки
- Ресурсы: нужны отдельные разработчики под iOS и Android, или две команды.
- Сроки: дольше, чем у кроссплатформы, так как приходится вести два проекта параллельно.
- Стоимость: выше, почти вдвое дороже кроссплатформы или PWA.
- Поддержка: более предсказуемая, так как обновления ОС и SDK приходят напрямую от Apple и Google.
Общий вывод
Нативная разработка — это выбор для проектов, где критичны скорость, стабильность и полный доступ к возможностям устройства, т.е. когда нужно "дорого-богато".
Она подходит для:
- банковских и государственных сервисов;
- игр с тяжёлой графикой;
- приложений с AR/VR и сложными анимациями;
- решений, требующих повышенной безопасности.
Не подойдёт, если нужно быстро выпустить MVP, уложиться в небольшой бюджет или обойтись минимальными силами команды.
Share
