为什么我们要构建 NativePHP

Tinywan

发布于 2026-07-06 11:11:28

130

我们为何选择开发 NativePHP

几十年来，应用程序开发一直遵循着一个假设，即大多数开发者都认为：网络、桌面和移动设备是三个独立的领域。

如果你想要构建一款 Web 应用程序，你会选择使用像 Laravel 这样的框架。如果用户的后续需求是获得一款桌面应用程序，那么你就会使用 Electron 或原生语言来重新编写代码。

如果他们想要一款移动应用，那么你就需要再次开始使用 Swift、Kotlin、React Native 或 Flutter 等技术。每个新的平台意味着需要全新的代码库、全新的工具链，往往还需要全新的团队来负责开发。这种分工方式已经持续了多年，成为了软件行业的一种常态。

我们认为，这种分裂的时代已经结束了。

在过去的几年里，出现了几种独立的趋势。设备的功能得到了显著提升。PHP 本身也成熟成为了一种现代编程语言，并且持续发展着。Laravel 从一款 Web 框架发展成了完整的应用程序平台。Livewire 证明了，丰富的、反应式的用户界面不再需要放弃使用 PHP。而围绕 Laravel 的生态系统现在提供了几乎所有构建复杂软件所需的东西，从零到一地打造出高级软件。

与此同时，人工智能辅助开发方式从根本上改变了软件编写的方式。编写代码的成本持续下降，因此开发者的生产力不再取决于频繁地输入代码，而是取决于能否选择合适的抽象层次来解决问题。在这种环境下，那些能够让开发者一次性解决多个问题的框架将会变得非常有价值。

一种解决方案，适用于所有平台

从历史的角度来看，支持桌面系统和移动设备显著增加了软件开发的成本。每个新的平台都会带来新的工程需求、新的发布流程、新的任务积压问题，以及一系列与平台相关的特殊问题。即使业务逻辑基本保持不变，团队仍然需要维护同一产品的多个版本。

跨平台框架显著改善了这一情况，但它们仍然基于这样一个假设：你首先是在开发移动应用。如果你的业务已经基于 Laravel 框架构建，那么采用其他框架往往意味着需要重新付出多年积累的成果，才能带来实际的价值。

我们认为，这个机会不仅仅在于让移动开发变得更加简单；更重要的是，让构建完全原生的移动应用变得和构建网页应用一样简单。

与其要求开发者在网页版和原生应用之间做出选择，我们认为他们已经使用的框架应该能够自然而然地扩展到用户拥有的每台设备上。

为什么选择 NativePHP？

NativePHP 存在是因为我们相信 Laravel 不仅仅是一个 Web 框架，它还有更多的潜力。数百万开发者花费数年时间学习这一技术的规则，围绕它构建商业模型，并创造出能够推动真实公司发展的应用程序。

这项投资不应该因为用户期望在应用商店中找到原生应用程序而贬值。

与引入额外的抽象层不同，NativePHP 让 Laravel 本身就能直接作为应用程序运行。PHP 代码直接在设备上运行，而 Laravel 仍然负责处理路由、验证、队列管理以及 Eloquent、Livewire 等功能的实现。同时，NativePHP 通过熟悉的 API 接口与操作系统进行交互。

仅针对移动设备的 NativePHP 技术，在 2026 年的应用规模预计将比 2025 年增长 10 倍以上。PHP 拥有全球最大的开发者社区之一，据保守估计，全球有 500 万名开发者使用 PHP 开发应用程序，而且这一数字还在持续增长。

由于 Laravel 和 PHP 在 LLM 训练数据中的广泛应用，利用人工智能工具用 PHP 构建移动应用简直是理所当然的事情。已经有成千上万的开发者抓住了这个机会，充分利用了 PHP 带来的更快的开发速度和更低的成本。

这个结果并没有改变应用程序的构建方式；它仍然是一种针对全新平台的 Laravel 开发体验。

这种区别非常重要。开发者们并不是在学习新的框架，而是在扩展他们已经熟悉的那一套框架。

为什么是现在？

五年前，要做到这一点简直是极其困难的。

当时的现代智能手机性能并不强，嵌入式 PHP 运行环境也几乎未被充分开发，许多开发者现在依赖的工具当时还并不存在。更重要的是，Laravel 这个框架当时还并没有发展成如今那样完善的应用程序平台。

如今，那些碎片已经排列整齐了。

剩下的挑战就是如何说服开发者认同这一想法。同时，还需要构建能够实现这一目标的基础设施。在原生应用程序中运行 PHP 代码、提供平台 API 接口、为桌面和移动设备打包 Laravel 框架、支持开发工作流程，以及与现有的 Laravel 项目进行集成……这些都需要多年的工程设计才能让开发者愿意开始编写他们的第一个应用程序代码。

当基础设施取得成功时，往往不会受到太多关注。而这样的状态正是它应该拥有的。