PHP-разработчик обычно живёт в довольно понятном мире: Laravel, PostgreSQL, Redis, API, очереди, Blade или Livewire.
Но рано или поздно появляется задача сделать мобильное приложение. И тут привычный PHP внезапно заканчивается.
Можно сделать PWA. Можно написать отдельное приложение на Flutter или React Native. Можно сделать TWA для Android. А можно попробовать довольно необычный вариант — NativePHP.
NativePHP позволяет писать приложения для Android и iOS на PHP и Laravel. Причём PHP действительно выполняется непосредственно на устройстве.
На первый взгляд звучит подозрительно хорошо.
Поэтому мне было интересно разобраться не только в том, как установить NativePHP, а в более практичных вопросах:
- насколько это вообще рабочая технология;
- что в ней действительно нативное;
- чем она отличается от PWA;
- какие возможности бесплатные;
- за что придётся платить;
- можно ли выпустить коммерческое приложение без подписки;
- и главное — стоит ли PHP-разработчику тратить на NativePHP время.
Разбираемся.
Что такое NativePHP
NativePHP — проект, позволяющий создавать desktop- и mobile-приложения с использованием PHP.
При этом это не новый PHP-фреймворк вместо Laravel.
Наоборот, NativePHP строится вокруг Laravel.
Для мобильного приложения схема примерно такая:
Laravel-приложение
↓
PHP
↓
NativePHP
↓
Swift / Kotlin bridge
↓
Android / iOS API
В приложение встраивается PHP runtime. Ваш Laravel-код выполняется непосредственно на телефоне, а NativePHP предоставляет мост между PHP и API операционной системы.
Поэтому это принципиально отличается от обычной схемы:
Мобильное приложение
↓
HTTP
↓
Laravel API
↓
Сервер
NativePHP позволяет выполнять Laravel непосредственно на устройстве.
Например, приложение может работать с локальной базой, файлами и частью возможностей телефона даже без подключения к вашему серверу.
Разумеется, серверный API при необходимости никто не запрещает использовать.
Это просто сайт внутри WebView?
Раньше такой вопрос был вполне справедлив.
Первые версии NativePHP Mobile использовали WebView: интерфейс приложения делался привычными веб-технологиями, а NativePHP обеспечивал доступ к возможностям устройства.
Но летом 2026 года вышел NativePHP 4 с технологией SuperNative.
В ней появился полноценный native UI.
Можно использовать EDGE-компоненты, которые выглядят примерно как Blade-компоненты, но в результате превращаются в реальные SwiftUI-компоненты на iOS и Jetpack Compose-компоненты на Android.
Получается довольно интересная конструкция:
Blade / EDGE
↓
NativePHP
↙ ↘
SwiftUI Jetpack Compose
iOS Android
То есть утверждение «NativePHP — это просто Laravel в WebView» для актуальной четвёртой версии уже неверно.
При этом веб-технологии никуда не исчезли. В зависимости от приложения можно использовать привычный стек Laravel и комбинировать его с нативными компонентами.
Зачем вообще запускать PHP на телефоне?
Главное преимущество очевидно для Laravel-разработчика.
Не нужно сначала изучать Dart и Flutter или погружаться в React Native, а затем поддерживать ещё одну технологическую экосистему.
Большая часть привычного мира остаётся:
Route::get(...);
User::query()->where(...);
Cache::get(...);
Storage::put(...);
Laravel остаётся Laravel.
Можно использовать Blade, Livewire и знакомую архитектуру приложения.
Особенно интересно это небольшим командам.
Представим компанию, в которой есть два Laravel-разработчика и нужно сделать внутреннее мобильное приложение.
Обычный вариант:
Laravel backend
+
Flutter / React Native frontend
Теперь нужны знания ещё одного стека.
NativePHP предлагает:
Laravel
+
NativePHP
Для небольшой команды разница может оказаться существенной.
Что с производительностью
Здесь у NativePHP была вполне реальная проблема.
В ранних версиях Laravel загружался заново при каждом запросе. По данным разработчиков проекта, это давало примерно 200–300 мс.
В NativePHP 3.1 появился persistent runtime: Laravel загружается один раз, после чего ядро повторно используется последующими запросами.
Разработчики сообщали о снижении времени ответа примерно до 5–30 мс.
А NativePHP 4 пошёл ещё дальше, убрав обязательную зависимость интерфейса от WebView.
Это не означает, что NativePHP внезапно стал быстрее приложения, написанного напрямую на Swift или Kotlin.
Но проблема «Laravel слишком тяжёлый для телефона» уже не выглядит настолько очевидной, как несколько версий назад.
Какие возможности телефона доступны
NativePHP использует систему плагинов.
Плагин представляет собой Composer-пакет, внутри которого могут находиться:
PHP
Swift
Kotlin
nativephp.json
PHP предоставляет удобный интерфейс для Laravel, а Swift и Kotlin реализуют взаимодействие непосредственно с операционной системой.
Через такую архитектуру можно подключать камеру, биометрию, геолокацию, Bluetooth или вообще собственный SDK. Плагины умеют подключать Gradle-зависимости, CocoaPods и Swift Package Manager, регистрировать Android Services и Receivers и взаимодействовать с lifecycle приложения.
То есть технически NativePHP не ограничен только тем API, который предусмотрели его авторы.
Если нужного API нет, можно написать собственный plugin.
Правда, в этот момент обещание «никакого Kotlin и Swift» немного заканчивается.
NativePHP бесплатный?
Вот здесь легко запутаться, особенно если читать статьи 2025 года.
Раньше NativePHP Mobile был коммерческим продуктом.
Но с NativePHP 3 ситуация изменилась.
Сам NativePHP Mobile теперь бесплатный и open source.
Core распространяется под MIT License.
Desktop-версия также является open source.
То есть платить просто за право написать и выпустить приложение на NativePHP сейчас не требуется.
Но есть важный нюанс.
Бесплатный NativePHP не означает, что все плагины бесплатные
После перехода на новую модель часть возможностей вынесли в отдельные плагины.
Среди бесплатных официальных возможностей есть:
- Camera;
- Browser;
- Device;
- Dialog;
- File;
- Microphone;
- Network;
- Share;
- System.
Например, обычное приложение может бесплатно работать с камерой, файлами, микрофоном, сетью, системными функциями и системным Share.
Но часть весьма востребованных функций стала Premium.
Например:
- Biometrics;
- Geolocation;
- Firebase / Push Notifications;
- Secure Storage.
Кроме официальных плагинов существует Marketplace, где сторонние разработчики публикуют бесплатные и коммерческие расширения.
На момент написания статьи там уже есть плагины для Bluetooth LE, In-App Purchases, Stripe, AdMob, background tasks, local notifications, geofencing, home-screen widgets и других возможностей.
Есть и бесплатные community-плагины: например Social Auth, датчики, DateTime Picker и другие.
Поэтому правильная формулировка такая:
NativePHP использовать бесплатно можно. Но конкретное приложение вполне может потребовать платных плагинов.
И это нужно учитывать ещё до начала разработки.
Хватит ли бесплатных возможностей для реального приложения?
Зависит от приложения.
Допустим, мы делаем простое приложение:
- каталог;
- личный кабинет;
- работа с REST API;
- фотографии;
- загрузка файлов;
- формы;
- локальная SQLite;
- обычный Share;
- работа через интернет.
Такое приложение вполне реально сделать без покупки набора коммерческих API.
А теперь возьмём другое приложение:
- авторизация по Face ID;
- GPS;
- push-уведомления;
- безопасное хранение токенов;
- фоновые задачи;
- Bluetooth.
Тут вероятность использования Premium-плагинов резко возрастает.
Именно поэтому перед выбором NativePHP я бы сначала составил список необходимых native-функций, а потом проверил Marketplace.
Не наоборот.
Нужно ли покупать NativePHP Ultra
Нет.
Есть подписка NativePHP Ultra, но для работы самого NativePHP она не требуется.
Ultra даёт доступ ко всем first-party Premium-плагинам, Plugin Dev Kit, расширенной поддержке, командным возможностям и дополнительным бонусам. На официальном сайте прямо указано, что Ultra является опциональной подпиской.
Для изучения NativePHP покупать её точно не нужно.
Для коммерческого проекта уже нужно считать стоимость необходимых плагинов и сравнивать её со стоимостью разработки этих возможностей самостоятельно.
А что такое Bifrost и почему он тоже просит денег?
Есть ещё один продукт разработчиков NativePHP — Bifrost.
Важно не путать его с самим NativePHP.
NativePHP — framework.
Bifrost — облачный сервис сборки и публикации приложений.
Он умеет собирать Android и iOS, управлять signing credentials, отправлять сборки в магазины и автоматизировать сборку через workflows.
Особенно полезно это Linux- и Windows-разработчикам.
Проблема iOS известна: нормальная локальная сборка iOS требует macOS.
Bifrost позволяет переложить эту работу на облако.
Но Bifrost платный.
На момент написания статьи самый дешёвый Apprentice стоит $10 в месяц, Loki — $29, Hela — $69, Thor — $129 при помесячной оплате.
Но опять же:
Bifrost не является обязательной частью NativePHP.
Можно собирать приложение самостоятельно.
То есть модель выглядит так:
NativePHP
бесплатно
+
Free plugins
бесплатно
+
Premium plugins
по необходимости
+
Bifrost
опционально
Как попробовать NativePHP бесплатно
Самый простой способ сейчас — Jump.
NativePHP Jump позволяет запустить разрабатываемое приложение на настоящем телефоне без полноценной настройки Xcode или Android Studio.
Создаём Laravel-проект со starter kit:
laravel new my-app --using=nativephp/mobile-starter --no-node
cd my-app
php artisan native:jump
Или добавляем NativePHP в существующий Laravel:
composer require nativephp/mobile
php artisan native:jump
После этого появляется QR-код.
Устанавливаем Jump на телефон, сканируем его — и приложение запускается на устройстве.
Причём Jump бесплатный и не имеет лимитов подписки.
Это, пожалуй, лучший способ познакомиться с NativePHP: ничего покупать не нужно.
Полноценная установка
Для нормальной локальной разработки устанавливаем пакет:
composer require nativephp/mobile
Указываем ID приложения:
NATIVEPHP_APP_ID=ru.example.myapp
Затем:
php artisan native:install
и:
php artisan native:run
NativePHP создаст каталог nativephp с необходимыми проектами Android/iOS и конфигурацию config/nativephp.php. Сам каталог считается генерируемым и обычно не должен храниться в Git.
Для NativePHP Mobile 4 нужен PHP 8.4+.
А зачем NativePHP, если есть PWA?
Вот это, на мой взгляд, главный вопрос.
PWA сегодня умеет довольно много:
сайт
↓
PWA
↓
установка на главный экран
↓
почти приложение
Для огромного количества бизнес-приложений этого достаточно.
Каталог ресторана, личный кабинет, CRM, сервис заказов, программа лояльности — всё это зачастую прекрасно работает как PWA.
И PWA имеет огромный плюс:
пользователю вообще необязательно идти в магазин приложений.
Открыл ссылку — приложение работает.
Обновление тоже моментальное: разработчик обновил сервер, пользователь получил новую версию.
У NativePHP появляются:
- сборки;
- подписи;
- App Store;
- Google Play;
- требования магазинов;
- обновления приложения;
- особенности Android и iOS.
Поэтому превращать каждый Laravel-сайт в NativePHP-приложение никакого смысла нет.
А TWA?
Trusted Web Activity решает похожую задачу на Android.
Она позволяет упаковать веб/PWA-приложение в Android-приложение и распространять его через Google Play.
Если вам нужен в основном существующий веб-интерфейс, TWA зачастую намного проще NativePHP.
Но возможности TWA по определению остаются привязанными к веб-платформе.
NativePHP интереснее тогда, когда приложение должно активно взаимодействовать с устройством:
камера
GPS
биометрия
файлы
Bluetooth
фоновые процессы
push
native UI
системные API
Здесь разница становится существенной.
NativePHP или PWA?
Я бы проводил границу очень просто.
Если приложение фактически является сайтом, который удобно установить на телефон, сначала стоит смотреть на PWA.
Если нужен только Android-магазин поверх существующего PWA — можно посмотреть в сторону TWA.
Если требуется полноценное мобильное приложение и вы хотите получить доступ к native API, но команда уже отлично знает Laravel — тогда появляется смысл смотреть на NativePHP.
А если создаётся большой мобильный продукт, где мобильное приложение является основным продуктом компании, требования высоки, команда большая и бюджет позволяет содержать отдельных mobile-разработчиков — я бы всё ещё обязательно рассматривал Flutter, React Native, Kotlin Multiplatform или полноценную native-разработку.
NativePHP не отменяет остальные технологии.
Он закрывает вполне конкретную нишу.
Где NativePHP выглядит особенно интересно
На мой взгляд, самый удачный сценарий — существующая Laravel-команда.
Например, уже есть:
Laravel backend
PostgreSQL
Redis
API
админка
бизнес-логика
И бизнес говорит:
Теперь нам нужно приложение для Android и iPhone.
Раньше вариантов было немного.
Либо нанимать mobile-разработчика, либо изучать React Native/Flutter, либо делать PWA.
Теперь появляется ещё один:
Laravel developers
↓
NativePHP
↙ ↘
Android iOS
И вот здесь технология действительно может экономить деньги.
Но есть и проблемы
NativePHP пока молодой.
Это важно.
Даже официальная документация прямо говорит, что Mobile ещё очень новый проект, а команда сравнительно небольшая. Поддержка всех функций на всех версиях мобильных ОС не гарантируется.
Кроме того, экосистема несравнима с Flutter или React Native.
В npm можно найти библиотеку практически для любой странной задачи.
В NativePHP нужного плагина может просто не оказаться.
Тогда есть три варианта:
написать самому
↓
найти community plugin
↓
купить Premium plugin
А самостоятельный plugin уже требует знания Swift/Kotlin либо помощи человека, который их знает.
Есть ещё один риск: архитектура проекта развивается очень быстро.
За сравнительно небольшой промежуток времени NativePHP прошёл путь от коммерческого Mobile, через бесплатную plugin-архитектуру v3, до SuperNative UI в v4.
Для молодого проекта это хороший признак активности.
Для корпоративного проекта — одновременно риск.
Можно ли уже делать production?
Технически — да.
Есть production packaging:
php artisan native:package android
или:
php artisan native:package ios
NativePHP умеет создавать подписанные production-сборки для App Store и Google Play.
То есть это уже не proof of concept, который умеет показывать Hello World только на телефоне разработчика.
Но я бы разделял «можно выпустить production» и «подходит для любого production».
Для внутреннего приложения компании, небольшого B2B-сервиса, приложения ресторана, каталога, CRM-клиента, личного кабинета или собственного небольшого продукта NativePHP уже выглядит вполне интересно.
Для банковского приложения на миллионы пользователей я бы пока не стал первым добровольцем.
Стоит ли изучать NativePHP
Для PHP/Laravel-разработчика — да.
Причём порог входа сейчас настолько низкий, что вопрос скорее не «стоит ли изучать», а «стоит ли потратить вечер и попробовать».
composer require nativephp/mobile
php artisan native:jump
После этого можно открыть приложение на телефоне и самостоятельно понять идею технологии.
Не нужно покупать лицензию.
Не нужно покупать Ultra.
Не нужно покупать Bifrost.
Не нужно сразу изучать Kotlin или Swift.
Для знакомства практически всё необходимое бесплатно.
Стоит ли начинать на NativePHP реальный проект
Здесь ответ уже не такой однозначный.
Я бы использовал следующий чек-лист.
NativePHP подходит, если:
- команда хорошо знает PHP/Laravel;
- нужно Android + iOS;
- PWA уже недостаточно;
- требуется доступ к возможностям телефона;
- приложение небольшое или среднее;
- хочется сохранить максимум разработки внутри Laravel;
- необходимые native API уже существуют в виде нормальных плагинов.
Я бы выбрал PWA, если:
- приложение в основном отображает данные и формы;
- native API почти не нужны;
- установка из магазина необязательна;
- важны максимально простые обновления;
- хочется поддерживать одну веб-версию.
Я бы серьёзно смотрел на Flutter/React Native/native, если:
- мобильное приложение является главным продуктом;
- интерфейс очень сложный;
- требуется множество специфических SDK;
- критична зрелость экосистемы;
- приложение должно жить много лет;
- есть отдельная mobile-команда.
Главный вопрос — придётся ли платить?
Для меня это был один из самых интересных моментов.
Ответ получился такой:
нет, платить обязательно не нужно.
NativePHP Mobile бесплатный.
Core open source.
Для разработки есть бесплатные native API.
Jump бесплатный.
Собирать приложение самостоятельно можно без Bifrost.
Но коммерческое приложение может потребовать платных плагинов.
Особенно внимательно я бы проверял:
- push;
- biometrics;
- secure storage;
- geolocation;
- background tasks;
- Bluetooth;
- payments;
- In-App Purchases.
И только после этого принимал решение о технологии.
Потому что стоимость разработки определяется не ценой:
composer require nativephp/mobile
а тем, что понадобится приложению через полгода.
Итог
NativePHP несколько лет назад я бы скорее назвал интересным экспериментом.
В 2026 году ситуация уже другая.
Mobile стал бесплатным и open source. Появилась plugin-архитектура. Есть Android и iOS. Есть публикация в магазины. Есть бесплатный Jump для тестирования. В четвёртой версии появился настоящий native UI вместо обязательного WebView. Проект активно развивается: например, релизы Mobile 4.2 и 4.3 вышли в августе 2026 года.
Поэтому игнорировать NativePHP Laravel-разработчику я бы уже не советовал.
Но и переписывать на нём всё подряд тоже не стоит.
PWA остаётся более простым вариантом, если вам фактически нужно веб-приложение на телефоне.
NativePHP становится интересным, когда возможностей PWA уже недостаточно, нужен доступ к устройству и хочется остаться внутри Laravel-экосистемы.
А Flutter, React Native и полноценная native-разработка остаются более зрелыми вариантами для серьёзных mobile-first продуктов.
Поэтому мой вывод довольно простой:
Изучить NativePHP — стоит. Сделать небольшой проект — точно стоит. Использовать в production — уже можно, но решение нужно принимать после проверки необходимых native API и плагинов.
Самое приятное, что для проверки этой технологии сегодня практически ничего не нужно покупать.
А для PHP-разработчика возможность написать:
composer require nativephp/mobile
и через несколько минут увидеть Laravel-приложение на собственном телефоне — как минимум достаточно интересный повод потратить на NativePHP один вечер.
Полезные ссылки
Документация NativePHP Mobile 4