我想在 2021 年 12 月记录下我认为的原因，以便我们将来可以不时地回顾它，并看看这些原因是否仍然相关。我本人就是一名 Web 开发人员，因此我对 Web 如何发展以缓解这些问题很感兴趣。
我专注于原生应用相较于网站可能具有的独特优势或至少感觉上是优势的原因。这里没有主观因素，比如“原生应用开发速度更快”或“原生应用更直观”等等，这些都太主观，难以量化。我也不会涉及 Web 占优势的原因。但如果您不确定，这里列举了一些：它是一个开放的标准化平台，它将比封闭系统持续更久，它非常重视向后兼容性，任何人都可以为 Web 构建应用，它跨平台运行，而且，仅 URL 本身就是优先选择 Web 的充分理由。但这并不是说原生应用没有一些极具吸引力的优势，因此才有这篇文章。
因为它们可以在设备的主屏幕上显示图标。
这是一种占据用户心智的方式。当你拿起手机时，图标会映入眼帘，吸引你打开它。 几年前的一份被广泛引用的报告表明，90% 的手机使用时间是在应用中（而不是在移动网络浏览器中），尽管其中存在很多公认的灰色地带。因此，理论上，如果你开发一个应用而不是被限制在可怜的 10% 的区域，你就可以成为这 90% 的一部分。
如果覆盖范围是最主要的考虑因素，那么最好的做法似乎是同时拥有一个 Web 应用和一个原生应用。这样，你就可以从 URL 提供的共享和搜索功能中获益，同时在设备上拥有强大的存在感。
看看我自己的手机主屏幕，绝大多数应用都是原生应用和 Web 应用：Google 日历、AccuWeather、Google 地图、Spotify、Notion、Front、Pocket Casts、Instagram、Discord、Twitter、GitHub、Slack 和 Gmail。许多大型公司都在同时使用这两种方式。
潜在解决方案：iOS 和 Android 都为网站提供了“添加到主屏幕”选项。这只是一个相当“隐藏”的功能，不太可能很多人使用它。Android 上的 Chrome 更进一步，为满足少数额外条件的渐进式 Web 应用 (PWA) 网站提供了 原生应用安装提示，例如网站已被交互至少 30 秒。原生应用安装提示是一个强大的工具，可以平衡竞争环境，理想情况下，希望看到 Apple 更好地支持 PWA 并提供此功能。作为网站作者，我们能做的不多；我们只能等待和希望移动操作系统能够做得更好。还有整个软件工具的世界，你构建的内容可以同时作为 Web 应用和原生应用交付，例如 Flutter。
因为它们的启动速度很快。
原生应用本地存储了运行应用所需的大量资源，这意味着在打开时不需要从网络获取它们。
潜在解决方案：首先，这只是部分正确。当你下载应用时，就像 Web 一样，你也在下载资源。Web 默认情况下会缓存资源，并且可以通过 Service Workers 使用更高级的缓存功能。PWA 在这方面具有竞争力。原生应用并不总是更快。
因为用户更难屏蔽广告，更容易收集数据。
移动设备上存在各种广告拦截器。
Android 广告拦截器
但这些仅适用于移动网络浏览器，不适用于原生应用。如果你想在原生应用中屏蔽广告……那就算了吧？如果构建的内容旨在展示广告或跟踪用户，那么，我猜你将 在原生应用中做得更好，假设你能获得与网站相同的流量（这值得怀疑）。
我犹豫是否将“因为原生应用更安全”作为此列表中的一个原因，因为作为用户，你对资源加载方式的控制力非常有限，因此对我来说，这并不感觉像是增加了安全风险。但原生应用在应用商店上线前通常会经过批准流程，这确实提供了一定程度的保护，而 Web 则没有。
潜在解决方案：允许广告/跟踪拦截应用与原生应用一起使用。
因为用户保持登录状态。
这是一个很重要的原因！当你登录到一个原生应用后，你往往会一直保持登录状态，直到你明确退出登录，或者发生特殊事件，例如你在另一台设备上更改密码。Web 应用似乎比人们希望的更容易丢失登录状态，这会增加人们对应用的潜意识感受。特别是对于 iOS， 客户端 Cookie 的有效期限制为 7 天。
当我打开我的原生 Twitter 应用时，它会直接打开并准备好使用。如果我认为有 30% 的可能性需要我登录，我肯定使用它的频率会低得多。（而且，这可能是一件好事，但企业肯定不会这么认为。）
Web 应用还存在一个有点尴尬的问题，即使你在移动设备的主浏览器中登录，你也不一定会登录到某些其他应用的应用内浏览器上下文中——而原生应用通常会拦截链接，并在原生应用上下文中始终打开。
潜在解决方案：这里没有完美的解决方案。这在很大程度上只是技巧。例如，较长的 Cookie 过期日期（据我所知，如果你幸运的话，可以获得大约六个月的期限）。或者你可以使用一种方法，将 JSON Web Token (JWT) 保存在存储中，并在后台对其进行滚动重新认证。 在这个帖子中还有一些其他的解决方案，其中很多都超出了我的理解范围。简化登录体验也是一种方法，例如使用 OAuth 或魔法邮件链接，但这与“始终保持登录状态”的感觉并不相同。也许聪明的浏览器开发者可以想出一些办法。
因为应用可以拥有“原生体验”。
通常是指：快速流畅，而且外观和感觉与该平台上的其他应用一致。例如，Apple 提供了 SwiftUI，它专门用于使用预构建的、外观符合 Apple 风格的组件构建原生应用。在 Web 上复制所有这些将非常困难。你必须非常努力才能达到使用 SwiftUI 等工具“免费获得”的效果。
潜在解决方案：移动平台创建者可以提供 UI 工具包，将该移动平台的设计语言引入 Web。这基本上是 Google 使用 Material Design 所做的事情，尽管 其 Web 版本 尚未准备好使用，并且仅被视为“计划”发布。
因为它们没有与竞争对手共享虚拟空间，用户只需轻触即可访问。
有一种观点认为，网络浏览器就像一片蛮荒之地，你无法控制用户会跑到哪里。如果用户在你的原生应用中，很好，那就是你想要他们待的地方。如果他们在网络浏览器中，你就是在与无数其他应用共享地盘，而不是让他们留在你的“圣地”。
潜在解决方案： 接受现实。试图掩盖竞争对手的存在并不是一个好的商业策略。网络的优势在于能够在一个共享的、标准化的、开放的平台上自由切换。
因为它们可以获得完整的 API 功能集。
网络所能希望的，就是与原生应用拥有相同的 API 访问权限。例如，访问相机、照片、GPS、推送通知、联系人等。原生应用首先获得 API，然后如果我们幸运的话，几年后，我们才能在网络上获得某种访问权限。
如果网络上缺少关键的 API，开发人员可能会被迫开发原生应用。
一个重要的例子是推送通知。它们通常很烦人吗？是的，但它是一个被广泛使用的 API，并且通常是业务需求。并且对于许多应用程序来说，它非常有意义（“您将在 500 英尺处轮到您”，“您的司机已到达”，“您的行李将到达 9 号传送带”等）。如果您的应用程序需要良好的推送通知，那么在 iOS 上，网络将不是您的应用程序的选择。
潜在解决方案： 网络应具备与设备 API 相同的功能，并且新 API 应同时为两者发布。
因为存在应用商店。
这是关于可发现性的。成为平台上唯一的应用商店意味着您有可能免费获得用户关注。如果您为平台制作了最好的弹球游戏，那么您很有可能获得良好的评价，并最终成为该应用商店中“弹球”的热门搜索结果，从而获得该利基市场的最大份额。这对开发人员来说是一个有吸引力的前景。网络上的市场要大得多，更不用说 SEO 变得更难玩，而且广告和营销都很昂贵。开发人员可能会选择原生应用，仅仅是因为与网络相比，他们可以从一开始就成为更大的鱼。
然而，如果您构建了一个用于收听音乐的应用程序，您将永远无法击败主要参与者，尤其是在平台制造商拥有自己的应用程序进行竞争时。由于更广泛的潜在受众，网络可能为竞争激烈的市场中的应用程序提供更好的机会。
潜在解决方案： 允许网络应用程序进入应用商店。
因为离线支持更简单。
网络上唯一可用的离线功能是通过Service Workers。它们真的很酷，但我可能会争辩说，它们并不特别容易实现，尤其是在计划使用它们为一个原本严重依赖网络的网络应用程序提供真正离线体验的情况下。
原生应用对网络的依赖性较小。使应用程序正常运行的核心资产已在本地可用。因此，如果原生应用程序不需要网络（例如游戏），它就可以正常离线工作。即使它确实需要网络才能发挥最佳性能，拥有最后保存的数据似乎也是许多应用程序采用的典型方法。
潜在解决方案： 使构建离线网络应用程序更容易。
关于此主题的播客
ShopTalk 497：2022 年原生应用和网络应用现状，与 Thomas Steiner 对谈
我是一个网络开发者，我感觉对于绝大多数“应用”场景来说，为网络构建应用是明智之举。但我必须承认，企业选择原生应用的理由足够多，以至于许多企业选择原生应用也就不足为奇了。最成功的企业似乎都在同时做这两件事，尽管维护这两者的成本极高。就像响应式设计成功地避免了我们不得不构建网站的多个版本一样，我希望这种情况朝着让网站成为任何类型应用程序的显而易见且唯一选择的方向发展。
我认为如果能有一些数据来显示有多少开发者为应用开发，有多少开发者为网络开发，这将非常有趣。
其次，如果选择网络开发与原生应用开发，成本是多少？您需要投入多少资金才能开始，包括硬件在内？
我认为您不太常看到这种情况，即在事情发生之前和之后进行真实的成本比较。因为我甚至没有考虑到您还需要了解所有这些平台的所有内容。
那么，如果您查看 iOS 和 Android 开发人员的分布情况，如何分摊坚持使用任一平台的风险，Windows 通常被忽略，但也在那里。
我想说另一个原因是可靠的存储/轻松访问文件系统。IndexedDB 可以保存网站的数据，但所有浏览器处理这些数据的持久性方式都不同。无法保证您的离线数据在网络上是永久性的。
就 Material Design 而言，Angular 有一个可用于生产的环境：https://material.angular.io/ 它具有 Android 风格，带有 FAB 按钮等。
感谢分享，Angular Material 看起来还不错。树组件令人印象深刻。
不要忘记控制：没有人可以限制、审核、拒绝您的网络应用程序，因为它与他们的商业模式相竞争。
另一个：您可以将您的网络应用程序与原生包装器一起发布到应用商店，以获得更多两全其美的好处。
一个小小的旁注，有一个“广告拦截器”/防火墙实际上阻止了（并非全部）应用内广告：LockDown：而且它是免费的！
别忘了我们正在从网站而不是应用中阅读这篇文章。
我不知道网络应用和安装应用是否可以共享相同的访问权限和相同的限制，或者是否需要这样做。安装应用代表着用户的选择，使某项服务更接近、更容易访问，并直接访问其设备的资源。
我敢肯定，将来会有一个时间点，完全相同的代码将运行网络应用和设备应用，但您将有一个“安装”选项。并且企业可能会为安装的应用程序提供一些“专业版”功能，这并非因为这些功能需要它，而是因为他们希望鼓励您为您的已选列表选择他们的应用程序。
有一个被忽视的问题，即大多数人倾向于在手机上的前几个屏幕上放置他们最常用的应用程序，例如 FB、IG、Google 应用等。我安装了许多网络应用程序，但它们通常会被遗忘和丢失。或者它们最终会进入很少打开的主页文件夹中。
我很惊讶您有 iPhone，Chris，您错过了 Termux 和 KDE Connect（现在正在 Apple Flight Test 中进行 Beta 测试）。Termux 对于手机上的 Web 开发非常棒！
感谢您发布一篇有趣的文章，有很多内容需要研究和思考，非常感谢。
我的意思是，有像 Capacitor 这样的混合平台，可以让您构建一次代码并跨平台部署，并让您根据需要桥接到原生层……
我认为在做出此类选择时，考虑一些似乎被遗忘的事情非常重要。
让人们下载应用程序到他们的手机上真的很难。即使您设法说服他们这样做，研究也表明，人们实际上只使用其中的一小部分，其余的只是闲置在那里（这通常会导致始终登录的论点失败）。
此外，管理应用商店中的应用程序会产生经常被遗忘的开销。
作为开发者，我更倾向于开发原生应用而不是 Web 应用的主要原因，可能与我偶尔选择开发 Web 应用的原因相同。原因是苹果。稍后会详细说明。
优先开发 Web 应用的主要优势在于，你立即就能拥有一个兼容任何平台的产品。
然而，Web 应用的主要缺点，也是我更愿意开发原生应用的原因在于，每个浏览器都以不同的方式实现其引擎。每个浏览器对 HTML 和 CSS 代码的解释方式都不同，我不想成为那个抱怨的人，但不得不承认，在我看来，苹果设备是 Web 出现问题最频繁的地方。原因不在于他们的技术，说实话，他们的技术很棒。
原因在于他们对开发者的态度有点“不友好”。如果我想在将网页公开发布到互联网之前在苹果设备上进行测试，我需要要么实际拥有我想要测试的苹果设备（并且为了能够调试 iPhone 上的页面，需要进行各种各样的操作，例如如果我的电脑是 Windows 系统），因为你无法在苹果设备之外运行 iOS 模拟器，要么拥有 Mac 电脑，这违背了我作为开发者优先开发 Web 应用的目的。
如果我拥有 Mac，我也可以为他们的平台开发原生应用。由于我没有 Mac，所以我优先开发 Web 应用，但在我发布之前，我仍然完全没有办法在苹果产品上测试我的产品，除非我专门为此购买一台，而这不在我的计划之内。
最重要的原因：Web 应用很糟糕。
我这么说是有依据的，我拥有超过 20 年的 Web 开发经验和超过 10 年的 iOS 开发经验。
不要再做“Web 开发者”了。如果你唯一的工具是锤子，你就会倾向于把所有问题都当作钉子来解决。
原生应用在开发者和用户体验方面都远胜于 Web 应用。“Web 开发者”的唯一优势是学习成本较低（除了事实上学习成本仍然存在）。而且，当一个新框架即将出现时，谁有时间学习任何东西呢，对吧？
所以，如果你很懒，并且想在所有平台上推广同样的半成品，请使用 Web 技术，它本来就不是为应用而设计的，并且还在努力解决那些使用 SDK 在第一天就能解决的问题。
如果你真的关心你的用户体验，那就学习原生开发。
是的，任何人都可以构建 Web 应用。结果也显而易见。
你成功地变得非常粗鲁，却没有提出任何有意义的观点。
原生？可以称之为“商店分发”，因为几乎没有应用是真正的原生应用，特别是那些很容易就能做成网站的应用，它们通常使用 Cordova 之类的技术构建，并且基本上只是显示一个网站，通常按需下载（以便允许更新跳过商店）。