Progressive Web App: Khi Nào PWA Thắng Ứng Dụng Gốc

Phát triển progressive web app là lựa chọn phần lớn bên mua ở Anh gạt đi trong mười phút đầu dự án, rồi tìm lại sau mười tám tháng, khi mã nguồn gốc thứ hai đã lặng lẽ ăn hết ngân sách. Nó bị gạt vì gần như mọi bài viết về nó đều rơi vào hai phe: bên cổ vũ bỏ qua phần iOS không chịu làm, hoặc bên hoài nghi thừa hưởng từ năm 2019, khi nền tảng thực sự chưa làm nổi.

Cả hai nay đều sai, và sai theo cách làm đổi phép tính. Safari hỗ trợ thông báo đẩy trong web app thêm vào Màn hình chính từ iOS 16.4. Chrome bỏ yêu cầu service worker khi cài đặt. Tháng 10 năm 2025, nhà quản lý Anh xác định Apple và Google có vị thế thị trường chiến lược với trình duyệt và công cụ trình duyệt di động. Cùng lúc, iOS vẫn từ chối chạy nền, xóa dữ liệu đã lưu theo quy tắc bạn không kiểm soát, và không bao giờ đưa web app lên App Store.

Dưới đây là bản tôi đưa cho khách đang chọn giữa một mã nguồn và ba. Mọi tuyên bố năng lực bên dưới đều đối chiếu tài liệu của chính nhà cung cấp, tháng 9 năm 2026, vì đây là chủ đề mà hiểu biết phổ thông luôn chậm hai năm.

Khi nào PWA thắng ứng dụng gốc? Khi người dùng ở trên Android và máy tính để bàn nhiều ngang iPhone, khi ứng dụng là giao diện của máy chủ chứ không phải thiết bị, và khi người ta tìm ra bạn qua tìm kiếm chứ không qua cửa hàng. PWA thua khi bạn cần vị trí chạy nền, tiện ích màn hình chính, Bluetooth trên iPhone, hoặc thanh toán qua cửa hàng. Cái tiết kiệm được là một mã nguồn thay vì ba, theo giá Anh là khoảng £40.000 đến £120.000 tiền dựng, cùng hóa đơn nhỏ hơn hẳn mỗi năm sau đó.

Progressive web app thực sự là gì

Thuật ngữ này bị dùng đủ lỏng để hai người trong cùng một cuộc họp hiểu theo hai nghĩa. Định nghĩa kỹ thuật thì hẹp, và đáng giữ.

MDN mô tả progressive web app là ứng dụng dựng bằng công nghệ nền tảng web, đem lại trải nghiệm giống ứng dụng riêng cho từng nền tảng. Nó chạy trên nhiều nền tảng từ một mã nguồn, cài đặt được, chạy ngoại tuyến được và tích hợp với hệ điều hành.

Trên thực tế nghĩa là ba sản phẩm, và trang thiếu bất kỳ cái nào cũng chỉ là website có tham vọng chứ không phải PWA.

Manifest của web app

Manifest là tệp JSON báo cho hệ điều hành biết ứng dụng tên gì, dùng biểu tượng nào, mở URL nào khi khởi chạy, và chạy trong khung trình duyệt hay chạy độc lập. Thiếu nó, trình duyệt chẳng có gì để cài. Nó nhỏ, tĩnh, và là phần rẻ nhất của cả việc này.

Service worker

Service worker là đoạn mã chạy tách khỏi trang, nằm giữa ứng dụng và mạng, và có thể trả lời yêu cầu từ bộ đệm. Nó làm cho hành vi ngoại tuyến thành khả thi và nó nhận thông báo đẩy. Nó cũng là phần dễ hỏng, vì bộ đệm đặt sai phạm vi sẽ phát mã cũ cho người dùng suốt nhiều tuần.

HTTPS

Service worker, thông báo đẩy, định vị và truy cập máy ảnh đều bị giới hạn trong ngữ cảnh an toàn. Với hạ tầng lưu trữ hiện nay điều này miễn phí và tự động, nên đó là ràng buộc chứ không phải chi phí.

Đã cài đặt nghĩa là gì, xét theo từng nền tảng

Bên mua tưởng cài đặt là một hành vi. Thực ra là ba, và khác biệt giữa chúng có ý nghĩa thương mại.

Android

Chrome trên Android cho kết quả gần ngang bằng nhất. Ứng dụng có biểu tượng màn hình chính, có mục riêng trong trình chuyển ứng dụng, có bộ nhớ riêng, và có thể lên Cửa hàng Play qua một lớp bọc. Sau khi trình duyệt phát sự kiện tương ứng, bạn kích hoạt lời mời cài đặt từ giao diện của mình, nên bạn chọn thời điểm hỏi.

iOS và iPadOS

Safari cài qua bảng chia sẻ và mục Thêm vào Màn hình chính. Không có lời mời cài đặt trong trang mà bạn kích hoạt được, không có biểu ngữ Apple hiển thị thay bạn, và không có cách nào phát hiện chắc chắn rằng người dùng đã làm. Khoảng trống tương tác đó là khác biệt thực tế lớn nhất giữa các nền tảng, và nó là bài toán thiết kế chứ không phải kỹ thuật: bạn phải dạy người dùng một thao tác.

Máy tính để bàn

Chrome, Edge và Safari trên macOS đều cài web app vào thanh dock hoặc thanh tác vụ với cửa sổ riêng. Máy tính để bàn là nơi PWA ít gây tranh cãi nhất và bị bỏ phí nhiều nhất, nhất là với công cụ nội bộ mà phương án thay thế là một bản dựng Electron không ai muốn bảo trì.

Chrome đã đổi luật cài đặt mà phần lớn hướng dẫn không nhận ra

Nhiều năm liền bài nào cũng lặp lại đúng một danh sách: manifest, biểu tượng, HTTPS, và một service worker có trình xử lý fetch. Mục cuối không còn đúng với đường cài đặt từ menu.

Google đã bỏ yêu cầu service worker triển khai fetch cho việc cài từ menu, ở phiên bản 108 trên di động và 112 trên máy tính, và nay cung cấp trang ngoại tuyến mặc định cho trang nào không tự làm. Thuật toán mời cài đặt vẫn muốn có trình xử lý fetch, nhưng khả năng cài đặt thì không còn phụ thuộc vào nó.

Ảnh hưởng lan tới công cụ. Lighthouse bỏ hẳn hạng mục PWA ở phiên bản 12.0.0, phát hành tháng 4 năm 2024, vì các bài kiểm tra đó tồn tại để đo những tiêu chí nay không còn áp dụng. Nếu quy trình dựng của bạn vẫn báo lỗi vì thiếu điểm PWA, nó đang đo thứ Google đã khai tử.

Cách đọc thực dụng là cài đặt và khả năng ngoại tuyến nay tách rời nhau. Bạn có thể phát hành ứng dụng cài được mà chưa có gì cho ngoại tuyến, vốn thường là bản đầu đúng đắn, rồi thêm bộ đệm khi đã biết người ta thực sự dùng màn hình nào lúc mất sóng.

Ngoại tuyến là quyết định thiết kế có giá của nó

Chữ ngoại tuyến giấu một dải phạm vi rất rộng. Một lớp vỏ đã đệm hiển thị dữ liệu biết lần cuối là một tuần công. Một ứng dụng ưu tiên ngoại tuyến thật sự, biết xếp hàng ghi, giải quyết xung đột và đối soát khi nối lại, là sản phẩm khác.

Chiến lược bộ đệm

Bộ đệm của service worker rút lại còn bốn mẫu và một quyết định cho mỗi loại tài nguyên. Ưu tiên bộ đệm trả bản đã lưu và không kiểm tra lại, hợp cho phông chữ và tài sản dựng có băm. Ưu tiên mạng thử máy chủ rồi mới lùi, hợp cho dữ liệu buộc phải mới. Stale while revalidate trả bộ đệm tức thì rồi làm mới ở nền, là lựa chọn thường thấy cho nội dung. Chỉ mạng dành cho thứ tuyệt đối không được trả lời bằng bản cũ, ví dụ thanh toán.

Sai ở chỗ này là lỗi PWA tôi gặp nhiều nhất. Ưu tiên bộ đệm áp lên vỏ ứng dụng sẽ phát JavaScript của tháng trước cho người quay lại cho tới khi có gì đó buộc cập nhật, và báo lỗi nhận được sẽ mô tả triệu chứng không tồn tại trong mã hiện tại.

Đồng bộ nền

Xếp hàng các thao tác ghi lúc ngoại tuyến rồi đẩy đi khi có mạng chính là việc của Background Synchronization API. MDN xếp nó vào diện khả dụng hạn chế và nói rõ nó không thuộc Baseline, nghĩa là nó không chạy trên vài trình duyệt phổ biến nhất.

Nên trên iOS bạn tự viết phương án lùi: lưu hàng đợi vào IndexedDB, rồi đẩy đi lần kế tiếp ứng dụng được mở. Cách đó chạy được, người dùng chấp nhận, và tốn chừng ba đến năm ngày công thay vì một buổi chiều nếu có API.

Thông báo đẩy quyết định nhiều dự án hơn bất cứ thứ gì

Nếu có một năng lực đủ sức đánh chìm đề xuất PWA thì chính là nó, và thường dựa trên sự thật chỉ đúng vào năm 2022.

Android và máy tính để bàn

Web push trên Chrome Android, Chrome máy tính, Edge và Firefox đã chạy nhiều năm nhờ Push API, Notifications API và service worker phối hợp. Việc chuyển phát do dịch vụ đẩy của hãng trình duyệt lo, quyền là lời mời tiêu chuẩn, và không có khoảng cách đáng kể so với ứng dụng gốc trong trường hợp thường gặp là máy chủ gửi tin cho người đã đăng ký.

iOS và iPadOS

Apple thêm Web Push ở iOS và iPadOS 16.4. Điều kiện kèm theo mới là phần hay bị bỏ sót: WebKit nêu rằng web app phải được thêm vào Màn hình chính, và quyền phải được xin để đáp lại một tương tác trực tiếp của người dùng, chẳng hạn chạm nút đăng ký. Web push không chạy với trang nằm trong thẻ Safari.

Manifest phải đặt display là standalone hoặc fullscreen, và khi đó thông báo hành xử như của mọi ứng dụng khác: màn hình khóa, Trung tâm thông báo, Apple Watch đã ghép đôi, và tùy chỉnh theo từng ứng dụng trong Cài đặt. Huy hiệu số cũng chạy.

Sau đó Apple thêm một lối đơn giản hơn. Web push khai báo đến cùng Safari 18.4, có trên iOS và iPadOS 18.4 cho web app đã thêm vào Màn hình chính, và nó hiển thị thông báo từ một payload JSON chuẩn hóa mà không cần service worker đang chạy. Nó bớt việc. Nó không bỏ điều kiện Màn hình chính.

Khoảng cách của iOS, nói cho chính xác

Khoảng cách là có thật và nhỏ hơn tiếng đồn. Nêu nó cho đúng thì hữu ích hơn cả than phiền lẫn giả vờ rằng nó đã khép.

Dữ liệu bị xóa

WebKit xóa dữ liệu website theo thứ tự ít dùng gần đây nhất, trong đó lần dùng cuối tính từ tương tác người dùng hoặc thao tác lưu trữ gần nhất. Tài liệu chính sách lưu trữ đặt hạn mức mỗi nguồn tới 60% dung lượng đĩa cho ứng dụng trình duyệt và tới 15% cho ứng dụng khác, với hạn mức tổng lần lượt là 80% và 20%, đồng thời xác nhận web app chạy độc lập từ Màn hình chính hưởng hạn mức ngang trình duyệt.

Hai điều rút ra. Lưu trữ không phải ràng buộc như người ta tưởng, và việc xóa là rủi ro về thời điểm chứ không phải về dung lượng. Coi thiết bị là bộ đệm và máy chủ là bản gốc thì việc xóa thôi là khiếm khuyết sản phẩm.

Chạy nền

iOS không có gì tương đương tác vụ nền của ứng dụng gốc. Không nạp định kỳ, không định vị nền, không xử lý ngầm khi ứng dụng đã đóng. Việc nào phải xảy ra theo lịch thì xảy ra trên máy chủ của bạn, rồi tới thiết bị qua một thông báo đẩy mà người dùng nhìn thấy.

Không có mặt trên App Store

PWA không thể lên App Store. Nếu một phần đáng kể khách hàng của bạn trông đợi tìm thương hiệu của bạn trong cửa hàng và thấy nó ở đó, đó không phải bài toán kỹ thuật mà web giải được.

Công cụ trình duyệt, DMA và CMA

Đây là phần mà báo chí đi trước nguồn gốc, nên đáng nói hẹp về những gì thực sự có trong tài liệu.

Apple nay cho phép công cụ trình duyệt thay thế, và nói rõ điều này chỉ áp dụng ở Liên minh châu Âu, trên iOS 17.4 trở lên và iPadOS 18 trở lên, qua hai quyền cấp cho nhà phát triển đạt các tiêu chí bảo mật, quyền riêng tư và bộ kiểm thử đã công bố. Apple đòi đạt 90% Web Platform Tests và 80% Test262, hoạt động không cần JIT, và xử lý phần lớn lỗ hổng trong vòng 30 ngày.

Với doanh nghiệp Anh, không điều nào trong đó thay đổi gì hôm nay. Các quyền này gắn với vùng tài phán, và người dùng Anh trên nhà mạng Anh vẫn đang chạy WebKit, dù họ chạm vào biểu tượng trình duyệt nào.

Phía Anh đang chuyển động riêng. Ngày 22 tháng 10 năm 2025, CMA xác định Apple và Google có vị thế thị trường chiến lược trên nền tảng di động của họ, bao trùm hệ điều hành, phân phối ứng dụng, trình duyệt và công cụ trình duyệt, trong năm năm. Việc xác định là quyền áp đặt yêu cầu hành vi, chứ chưa phải bản thân các yêu cầu. Hãy lập kế hoạch theo cách nền tảng hành xử hôm nay và coi mọi nới lỏng là phần lời.

API phần cứng và thiết bị, kiểm chứng thay vì phỏng đoán

Câu web không truy cập được phần cứng là phản bác tôi nghe nhiều nhất, và cũng là câu sai nhiều nhất khi xét từng trường hợp cụ thể.

Thứ chạy được gần như ở mọi nơi

Truy cập máy ảnh và micro qua getUserMedia thuộc Baseline trên MDN và chạy xuyên trình duyệt từ năm 2017. Định vị, hướng thiết bị, tải tệp lên gồm cả chụp bằng máy ảnh trên di động, truy cập bảng nhớ tạm, Web Share API trên di động, và passkey qua WebAuthn với Face ID hoặc vân tay làm bộ xác thực đều chạy trên các trình duyệt di động hiện hành. Quét mã vạch và mã QR qua luồng máy ảnh là chuyện thường ngày.

Với đa số ứng dụng kinh doanh, danh sách đó là toàn bộ yêu cầu phần cứng.

Thứ chỉ có trên Chromium, và trên di động thì gần như chỉ có trên Android

Web Bluetooth được Google ghi là khả dụng trên ChromeOS, Chrome for Android 6.0, macOS từ Chrome 56 và Windows 10 từ Chrome 70, không nêu hỗ trợ iOS, còn MDN đánh dấu nó là khả dụng hạn chế chứ không phải Baseline. Web NFC còn hẹp hơn: Google ghi nó khả dụng trên Android ở Chrome 89.

File System Access API để đọc ghi tệp do người dùng chọn cũng là địa hạt Chromium, dù hệ tệp riêng theo nguồn đã đáp ứng phần lớn nhu cầu lưu trữ nội bộ của ứng dụng trên mọi trình duyệt.

Phân phối qua cửa hàng ứng dụng là câu hỏi thương mại, không phải kỹ thuật

Các đội tranh luận về phân phối qua cửa hàng như thể đó là chuyện năng lực. Thực ra đó là bốn biến số thương mại, và chỉ một trong số đó nghiêng hẳn về phía cửa hàng.

Khả năng được tìm thấy là lợi thế thành thật. Người tiêu dùng có tìm trên App Store và Play theo thương hiệu và theo hạng mục, và doanh nghiệp không hiện diện ở cửa hàng thì mất kênh đó. Nó cực kỳ quan trọng với sản phẩm tiêu dùng có tên tuổi dễ nhận ra, và gần như vô nghĩa với công cụ dùng nội bộ cho 200 nhân viên của một công ty.

Niềm tin là có thật và bất đối xứng theo nhóm người dùng. Người lớn tuổi và ít rành công nghệ đọc trang cửa hàng như một tín hiệu an toàn. Người trẻ ngày càng không vậy, và chính họ vẫn thoải mái dùng website ngân hàng trên cùng chiếc điện thoại.

Đổi lại, cửa hàng thêm vào giữa bạn và người dùng một hàng chờ duyệt, rủi ro bị từ chối theo các quy tắc hay đổi, và hoa hồng trên mọi thứ bạn bán trong ứng dụng. PWA không có cái nào. Bạn phát hành khi bạn muốn, và bản vá quan trọng tới mọi người dùng ở lần tải kế tiếp thay vì sau khi duyệt.

Các cửa hàng thực sự thu bao nhiêu

Con số hoa hồng đổi đủ thường xuyên để việc nhớ theo trí nhớ là dại. Đây là điều khoản do chính các hãng công bố, đối chiếu vào tháng 9 năm 2026.

Apple thu 30% làm hoa hồng tiêu chuẩn với hàng hóa và dịch vụ số. App Store Small Business Program hạ mức đó xuống 15% cho nhà phát triển có doanh thu tới 1.000.000 USD trong năm dương lịch trước, nhà phát triển mới cũng đủ điều kiện, và mức tiêu chuẩn quay lại với doanh số sau đó một khi bạn vượt ngưỡng trong năm.

Google công bố phí dịch vụ Google Play theo bậc: 15% cho 1 triệu USD doanh thu đầu tiên mỗi năm, 30% cho phần trên đó, và 15% cho thuê bao tự động gia hạn bất kể doanh thu. Cùng trang đó nêu một cấu trúc khác có hiệu lực từ ngày 30 tháng 6 năm 2026 cho EEA, Anh và Mỹ, dựa trên 10% hoặc 20% cộng thêm phí thanh toán 5% tùy lượt cài là mới hay đã có.

Cả hai hãng đều công bố bằng đô la Mỹ. Bán một gói thuê bao £9,99 mỗi tháng qua cửa hàng ở mức 15% tốn khoảng £18 mỗi năm cho mỗi thuê bao, còn ở mức 30% là khoảng £36. Hãy nhân với số thuê bao trước khi kết luận cửa hàng là miễn phí.

Bạn vẫn phát hành được PWA qua Google Play

Android cho bạn cả hai lựa chọn cùng lúc, đó là bất đối xứng thật sự trong phép so sánh nền tảng và hiếm khi được nhắc.

Trusted Web Activity là một ứng dụng Android mở chính PWA của bạn ở chế độ toàn màn hình, không có khung trình duyệt, và được xác thực là của bạn qua Digital Asset Links. Nó cần Chrome 72 trở lên trên Android, và ứng dụng bọc ngoài không truy cập được cookie hay bộ nhớ của nội dung web. Trên thực tế đó là một lớp bọc mỏng sinh ra từ manifest của bạn rồi nộp lên Play như mọi ứng dụng khác.

Vậy nên trên Android, lựa chọn không phải là cửa hàng hay web. Bạn phát hành PWA, bọc nó lại, và có luôn mục trong cửa hàng, từ cùng một mã nguồn, đổi lấy vài ngày đóng gói và phí tài khoản nhà phát triển hằng năm.

iOS không có thứ tương đương. Hướng dẫn duyệt của Apple từ lâu coi một lớp bọc quanh website là chưa đủ, nên đường lên cửa hàng của iOS nghĩa là dựng thứ gốc thật sự. Chính bất đối xứng đó, hơn mọi khác biệt về API, tạo ra bảng chi phí bên dưới.

Chi phí phát triển progressive web app so với hai mã nguồn gốc

Phép so sánh người ta hay làm là chi phí dựng, vốn là nửa nhỏ hơn. Phép so sánh quyết định kết quả là tổng chi phí ba năm, vì chi tiêu cho ứng dụng gốc lặp lại hằng năm.

Hãy đọc đó là khung giá của công ty dịch vụ ở Anh cho ứng dụng kinh doanh độ phức tạp trung bình, không phải báo giá. PWA dạng này thường là một đội hai hoặc ba kỹ sư trong ba đến năm tháng. Hai mã nguồn gốc kèm hiện diện web là ba đội, ba quy trình phát hành và ba đợt nâng cấp nền tảng mỗi năm.

Khoảng cách giữa dòng đầu và dòng cuối, chừng £75.000 đến £175.000 tiền dựng và £27.000 đến £60.000 mỗi năm sau đó, chính là thứ bạn mua khi mua ứng dụng gốc. Đôi khi đó là tiền đáng tiêu. Nó nên là một quyết định, không phải mặc định. Trang phát triển website và phát triển phần mềm của chúng tôi nêu cách chúng tôi khoanh phạm vi cho cả hai hướng.

Tiền bảo trì thực sự chảy đi đâu

Chi phí dựng thì được mặc cả. Chi phí bảo trì thì được phát hiện, và đó là nơi dự án nhiều mã nguồn thất bại âm thầm chứ không ầm ĩ.

Nền tảng gốc bắt bạn làm việc mỗi năm. Bản lớn của hệ điều hành khai tử API, ký và cấp phép đổi, mức SDK tối thiểu tăng, chính sách cửa hàng thêm yêu cầu như manifest quyền riêng tư và khai báo an toàn dữ liệu. Chẳng cái nào ra được tính năng. Trên hai nền tảng bạn trả hai lần, theo lịch do người khác đặt.

Rồi tới độ lệch. Hai mã nguồn cùng làm một tính năng sẽ tách nhau, và độ tách đó lộ ra dưới dạng phiếu hỗ trợ chỉ tái hiện trên một nền tảng. Mọi quyết định sản phẩm phải ra hai lần rồi hòa lại, và chi phí phối hợp đó không hiện trên hóa đơn nào.

PWA thay tất cả bằng sự tiến hóa của trình duyệt, vốn liên tục, tương thích ngược và gần như không phá mã đang chạy. Việc lặp lại là cập nhật phụ thuộc, vá bảo mật và lưu trữ của chính bạn, đúng phần bảo trì mà mọi ứng dụng web đặt riêng vốn đã cần.

Phép so sánh có ý nghĩa không phải hai con số trên đề xuất. Đó là một đội so với ba đội, mỗi năm, suốt vòng đời sản phẩm.

Hiệu năng và Core Web Vitals cho PWA

Ứng dụng đã cài bị đem so với ứng dụng gốc, nên ngưỡng hiệu năng cao hơn chứ không thấp hơn so với website. Tin mừng là các chỉ số đều công khai và ngưỡng thì cố định.

Core Web Vitals hiện gồm ba chỉ số, mỗi chỉ số đo ở phân vị thứ 75 của các lượt tải trang và tách riêng di động với máy tính. Largest Contentful Paint tốt ở mức 2,5 giây trở xuống và kém khi trên 4,0. Interaction to Next Paint, chỉ số thay First Input Delay khi ổn định năm 2024, tốt ở mức 200 mili giây trở xuống và kém khi trên 500. Cumulative Layout Shift tốt ở mức 0,1 trở xuống và kém khi trên 0,25.

PWA có một lợi thế cấu trúc ở đây. Service worker phục vụ lớp vỏ từ bộ đệm khiến lượt ghé lại gần như tức thì, đúng kiểu mà ứng dụng đã cài tạo ra, nên dữ liệu người dùng thật của một PWA đã cài thường đẹp hơn chính mã đó khi truy cập nguội trong trình duyệt.

Nó cũng có một rủi ro cấu trúc. Framework một trang đẩy việc về phía máy khách, và INP là chỉ số trừng phạt điều đó. Nếu bạn đang vật lộn với các con số này, hướng dẫn đạt Core Web Vitals của chúng tôi bàn về chẩn đoán sâu hơn bài này.

SEO là lợi thế không ai tính vào giá

Đây là lập luận tôi đưa lên đầu trong hầu hết tình huống thương mại, và nó gần như luôn bị bỏ hẳn khỏi phép so sánh.

PWA là một website. Mỗi màn hình có URL, mỗi URL đều thu thập, lập chỉ mục, liên kết và chia sẻ được, và mỗi cái đều có thể lên hạng. Ứng dụng gốc không có gì trong số đó. Mục trên cửa hàng chỉ được lập chỉ mục nông và xếp hạng trong một khu vườn có tường theo tín hiệu hoàn toàn khác, còn nội dung bên trong ứng dụng thì vô hình với tìm kiếm.

Hệ quả cộng dồn. Tiền tiếp thị đổ vào ứng dụng gốc mua lượt cài và dừng đúng ngày bạn ngừng chi. Cũng khoản đó đổ vào nội dung và chất lượng kỹ thuật của PWA mua được một trang tiếp tục lên hạng. Qua ba năm, khác biệt ấy thường vượt toàn bộ chi phí dựng của cả hai hướng.

Nó chỉ có lãi nếu bản triển khai thu thập được, và đó là chỗ ứng dụng dựng hoàn toàn ở máy khách hỏng việc: vẽ mọi thứ bằng JavaScript với một URL duy nhất và không có HTML dựng từ máy chủ là vứt bỏ trọn vẹn lợi thế này. Cách sửa là dựng phía máy chủ hoặc dựng trước những tuyến cần lập chỉ mục, và một lần kiểm tra SEO kỹ thuật trước khi phát hành rẻ hơn nhiều so với sau nửa năm mới biết chẳng có gì được lập chỉ mục.

Những yêu cầu loại thẳng PWA

Quyết định này dễ hơn khi viết thành danh sách phủ quyết thay vì danh sách lợi ích, vì các điểm phủ quyết đều khách quan.

Bạn cần ứng dụng gốc nếu bất kỳ điều nào sau đây là yêu cầu thật chứ không phải mong muốn. Theo dõi vị trí chạy nền khi ứng dụng đã đóng. Tiện ích màn hình chính, ứng dụng đồng hồ, hoặc tích hợp CarPlay và Android Auto. Bluetooth hay NFC trên iPhone. HealthKit, Apple Pay trong ứng dụng, hoặc bất kỳ tích hợp hệ điều hành sâu nào Apple chưa mở cho web. Thanh toán qua cửa hàng cho hàng hóa số ở nơi chính sách cửa hàng bắt buộc. Tính toán nặng kéo dài, như xử lý video thời gian thực hoặc dựng 3D ở tốc độ khung hình như ứng dụng gốc. Hiện diện trên App Store như một yêu cầu tiếp thị mà doanh nghiệp bạn thực sự phụ thuộc.

Nếu không điều nào đúng, PWA rất có thể là đáp án đúng, và trách nhiệm chứng minh thuộc về bên muốn ba mã nguồn.

Hai cân nhắc nữa nghiêng cán cân thêm. Nếu người dùng của bạn chủ yếu ở máy tính hoặc Android, các khoảng trống của iOS chỉ chạm tới thiểu số khán giả. Và nếu ứng dụng là giao diện cho máy chủ của chính bạn chứ không phải cho thiết bị, điều mô tả đúng phần lớn phần mềm kinh doanh, thì năng lực thiết bị gần như không quan trọng.

Tình huống một, dịch vụ hiện trường của nhà thầu quản lý tòa nhà

Hai trăm kỹ sư, phiếu công việc, ảnh chụp việc đã xong, thu chữ ký, sóng chập chờn trong phòng máy và tầng hầm. Đây là tình huống người ta đinh ninh phải dùng ứng dụng gốc, và là tình huống PWA thắng rõ nhất.

Mọi yêu cầu đều được đáp ứng. Máy ảnh chạy qua getUserMedia. Chữ ký là một phần tử canvas. Dữ liệu công việc nằm trong IndexedDB và hàng đợi ghi được đẩy đi khi nối lại mạng, viết tay vì Background Sync không đáng tin xuyên trình duyệt. Cảnh báo điều phối gửi bằng web push, chạy trên Android và trên iOS với kỹ sư đã thêm ứng dụng vào Màn hình chính, còn việc cài đặt là mục năm phút trong buổi đào tạo nhập việc chứ không phải bài toán thu hút người dùng.

Không có yêu cầu về khả năng được tìm thấy trên cửa hàng, vì người dùng là nhân viên. Không có thanh toán nên hoa hồng không liên quan. Thiết bị lẫn lộn Android và iOS, đúng trường hợp trừng phạt hai mã nguồn gốc nặng nhất.

Hãy dựng một PWA với chừng £45.000 đến £70.000 thay vì hai ứng dụng gốc £120.000 đến £200.000, phát hành bản sửa ngay chiều hôm đó thay vì chờ duyệt, và dồn phần chênh vào hệ thống điều phối vốn mới thực sự quyết định thứ này chạy được hay không.

Tình huống hai, chuỗi salon muốn đặt lịch và nhắc hẹn

Mười bốn chi nhánh, hướng tới người tiêu dùng, đặt lịch hẹn, nhắc hẹn, chương trình tích điểm, thanh toán tại quầy chứ không trong ứng dụng. Bản năng là làm ứng dụng gốc vì đối thủ có.

Danh sách yêu cầu không có gì đặc biệt: biểu mẫu đặt lịch, lịch, nhắc hẹn, khu vực tài khoản. Chỉ nhắc hẹn là đáng bàn, và ở thị trường này tin nhắn cùng email phục vụ tốt hơn thông báo đẩy, vì khách đặt hai lần một năm sẽ chẳng cài gì.

Yếu tố quyết định là khả năng được tìm thấy, và nó nghiêng hẳn về web. Người ta tìm salon qua tìm kiếm và bản đồ chứ không phải bằng cách lướt cửa hàng ứng dụng, nên những trang mô tả dịch vụ và nhận đặt lịch cần lên hạng. Ứng dụng gốc hoàn toàn vô hình với việc đó. Chi phí của chính website mới là khoản ngân sách thật, còn lớp ứng dụng chỉ thêm vào dưới dạng khả năng cài đặt.

Hãy dựng trang đặt lịch cho tử tế, làm cho nó cài được để khách quen giữ trên màn hình chính, và thêm web push cho thiểu số đồng ý nhận. Bản gốc ở đây tiêu £80.000 trở lên để chạm tới ít khách hơn số website đã chạm tới.

Tình huống ba, sản phẩm thể hình theo thuê bao

Bài tập có hướng dẫn, nội dung video, tích hợp thiết bị đeo, £12,99 mỗi tháng, bán thẳng cho người tiêu dùng, tăng trưởng bằng tiền quảng cáo. Tình huống này đi theo hướng ngược lại, và đáng nêu vì sao.

Khả năng được tìm thấy trên cửa hàng có ý nghĩa ở đây, vì thể hình là hạng mục người ta lướt xem và một mục trong cửa hàng là kênh thu hút thật. Tích hợp thiết bị đeo nghĩa là HealthKit, thứ web không với tới. Âm thanh nền và hành vi giữ sáng màn hình trong buổi tập tốt hơn trên ứng dụng gốc. Tải video về xem ngoại tuyến ở quy mô lớn thì web làm được nhưng không thoải mái.

Phần thú vị là thanh toán. Hoa hồng cửa hàng trên gói £12,99 mỗi tháng vào khoảng £23 mỗi năm cho mỗi thuê bao ở mức 15% và £47 ở mức 30%, với 20.000 thuê bao thì thành £460.000 đến £940.000 mỗi năm. Đó là lý do mạnh để thu tiền trên web và coi ứng dụng chỉ là máy khách, điều mà vài sản phẩm thuê bao lớn nay đang làm.

Đáp án là ứng dụng gốc cho sản phẩm, còn PWA hoặc web app thường cho đăng ký, thanh toán và tiếp thị nội dung. Cả hai cùng tồn tại, và việc tách ra là có chủ ý chứ không phải tình cờ.

Cách quyết trong một buổi chiều

Quyết định này không cần giai đoạn khảo sát. Nó cần bốn câu trả lời, viết ra giấy.

Thứ nhất, liệt kê các năng lực thiết bị bạn thật sự cần, rồi đối chiếu từng cái với tài liệu của chính nhà cung cấp thay vì với một bản tóm tắt. Phần lớn danh sách ngắn đi rõ rệt ở bước này. Thứ hai, xác định người dùng đến từ đâu: nếu câu trả lời là tìm kiếm thì web đã có lợi thế, còn nếu là lướt cửa hàng thì không.

Thứ ba, định giá cả ba hướng theo ba năm thay vì một năm, gồm cả các con số bảo trì ở trên, và tính cả hoa hồng cửa hàng trên thứ bạn định bán. Thứ tư, hãy thành thật về đội của bạn. Một mã nguồn do ba kỹ sư bảo trì luôn ra được nhiều hơn ba mã nguồn do ba kỹ sư bảo trì.

Nếu sau đó câu trả lời vẫn mơ hồ, hãy dựng PWA trước. Đó là lựa chọn rẻ hơn để đảo ngược. Đi từ PWA sang ứng dụng gốc về sau nghĩa là viết máy khách gốc dựa trên một API đã có sẵn và đã được kiểm chứng, còn chiều ngược lại nghĩa là làm lại từ đầu. Bất đối xứng đó đáng giá hơn phần lớn các bảng so sánh tính năng ở trên.

Chỗ này dẫn bạn tới đâu

Phát triển progressive web app không phải phương án chắp vá cho người không đủ tiền làm ứng dụng gốc, và cũng không phải đáp án cho mọi trường hợp. Nó là kiến trúc đúng cho một nhóm sản phẩm lớn và xác định được: phần mềm kinh doanh, công cụ nội bộ, hệ thống đặt lịch và tài khoản, sản phẩm nội dung, và mọi thứ có khách đến từ tìm kiếm.

Các khoảng trống của iOS là có thật, cụ thể, và phần lớn né được chứ không chí mạng. Thông báo đẩy chạy nếu người dùng cài. Lưu trữ rộng rãi nhưng có thể bị xóa. Chạy nền không tồn tại và vốn dĩ thuộc về máy chủ của bạn. Bluetooth và NFC không chạy trên iPhone, và không lượng kỹ thuật nào đổi được điều đó.

Mecanik dựng cả hai hướng và sẽ nói thẳng khi đáp án là ứng dụng gốc. Nếu bạn muốn chạy phép so sánh này trên đúng yêu cầu của mình thay vì một danh sách chung chung, trang phát triển website và phát triển phần mềm mô tả cách chúng tôi khoanh phạm vi, còn hướng dẫn xây dựng web app năm 2026 của chúng tôi bàn về các quyết định công nghệ tiếp theo.

Câu hỏi thường gặp

Progressive web app là gì? Progressive web app là ứng dụng dựng bằng công nghệ web nhưng hành xử như ứng dụng riêng của từng nền tảng. Về kỹ thuật, đó là một ứng dụng web phục vụ qua HTTPS, kèm manifest mô tả tên, biểu tượng và hành vi khởi chạy, cùng một service worker có thể trả lời yêu cầu từ bộ đệm và nhận thông báo đẩy. MDN định nghĩa nó là phần mềm chạy trên nhiều nền tảng từ một mã nguồn mà vẫn cài đặt được và chạy được khi ngoại tuyến.

PWA có gửi được thông báo đẩy trên iPhone không? Có, với một điều kiện. Apple thêm Web Push ở iOS và iPadOS 16.4, nhưng WebKit đòi web app phải được thêm vào Màn hình chính trước, và quyền phải được xin để đáp lại một tương tác trực tiếp của người dùng, chẳng hạn chạm nút đăng ký. Thông báo đẩy không chạy với trang mở trong thẻ Safari. Web push khai báo, thêm ở iOS và iPadOS 18.4, giúp triển khai đơn giản hơn nhưng giữ nguyên điều kiện Màn hình chính.

Chi phí phát triển progressive web app ở Anh là bao nhiêu? Với ứng dụng kinh doanh độ phức tạp trung bình, hãy tính £35.000 đến £75.000 để dựng một mã nguồn PWA và £8.000 đến £20.000 mỗi năm để bảo trì. Hướng ứng dụng gốc tương đương, gồm ứng dụng iOS và Android riêng kèm trang tiếp thị, tốn £110.000 đến £250.000 để dựng và £35.000 đến £80.000 mỗi năm sau đó. Đây là khung giá của công ty dịch vụ ở Anh chứ không phải báo giá, và khoản chênh lặp lại hằng năm thường quan trọng hơn khoản chênh khi dựng.

Có thể đưa PWA lên App Store hoặc Google Play không? Google Play thì được, App Store thì không. Trên Android, Trusted Web Activity bọc PWA của bạn trong một lớp vỏ gốc mỏng được xác thực qua Digital Asset Links, nên cùng một mã nguồn có mục trên Play chỉ với vài ngày đóng gói. Apple không có thứ tương đương và hướng dẫn duyệt của họ coi một lớp bọc quanh website là chưa đủ, nên hiện diện trên App Store nghĩa là dựng thứ gốc thật sự.

Khi nào nên chọn ứng dụng gốc thay vì PWA? Hãy chọn ứng dụng gốc khi bạn cần vị trí chạy nền lúc ứng dụng đã đóng, tiện ích màn hình chính, tích hợp đồng hồ hoặc xe hơi, Bluetooth hay NFC trên iPhone, HealthKit hoặc Apple Pay trong ứng dụng, tính toán nặng kéo dài như xử lý video thời gian thực, hoặc hiện diện trên App Store như một kênh thu hút khách thật sự. Nếu không điều nào đúng, PWA rất có thể là lựa chọn đúng và trách nhiệm chứng minh thuộc về bên muốn bảo trì ba mã nguồn.