Cách đưa ứng dụng Lovable lên App Store: PWA, Capacitor hay viết lại, và cách tránh lỗi 4.2 (2026)

Nếu bạn đang tìm cách đưa ứng dụng Lovable lên App Store, điều đầu tiên cần biết là Lovable không thể làm việc đó thay bạn. Tài liệu xuất bản của Lovable cho biết "Lovable xây dựng ứng dụng web và việc xuất bản luôn triển khai ra một URL web", đồng thời "không có quy trình tích hợp sẵn để đóng gói và gửi dự án của bạn lên App Store hoặc Google Play." Dưới đây là ba lựa chọn thực tế, chi phí của từng lựa chọn, và các bước giúp một ứng dụng Lovable được bọc lại tránh khỏi Nguyên tắc 4.2.

Có thể xuất bản ứng dụng Lovable trực tiếp lên App Store không?

Không. Tính đến tháng 10/2026, Lovable xuất bản lên một tên miền phụ lovable.app hoặc tên miền riêng, và muốn lên store thì bạn phải đóng gói ứng dụng bên ngoài Lovable rồi gửi từ tài khoản nhà phát triển của chính mình.

Tài liệu của Lovable gợi ý hai cách xoay xở: biến trang đã xuất bản thành một PWA cài đặt được, hoặc "bọc URL đã xuất bản của bạn trong một lớp vỏ native bằng Capacitor bên ngoài Lovable" rồi tự gửi lớp vỏ đó. Tài liệu cũng nói rõ hai điều. Lovable không tạo dự án React Native, và ứng dụng di động Lovable chỉ dùng để xây dựng dự án từ điện thoại. Nó "không biến dự án của bạn thành một ứng dụng native cho người dùng cuối."

PWA, bản bọc Capacitor hay viết lại: nên chọn hướng nào?

Chọn PWA nếu bạn không cần trang trên store, Capacitor nếu bạn cần có mặt trên store và có thể bổ sung tính năng native thực sự, và viết lại native nếu ứng dụng phải mang lại cảm giác và hoạt động như một sản phẩm ưu tiên điện thoại.

Mức phí lấy từ trang đăng ký Apple Developer Program ("99 USD mỗi năm thành viên. Giá có thể khác nhau theo khu vực") và Trợ giúp Google Play Console ("phí đăng ký một lần 25 USD"). Trên Google Play, tài khoản cá nhân mới còn phải chạy thử nghiệm kín với 12 người thử trong 14 ngày trước khi được quyền phát hành production. Hướng dẫn thử nghiệm kín của chúng tôi trình bày bước này.

Làm thế nào để bọc ứng dụng Lovable bằng Capacitor?

Xuất mã Lovable sang GitHub, build trên máy, thêm Capacitor và trỏ webDir vào thư mục đầu ra của bản build. Sau đó mở các dự án native trong Xcode và Android Studio rồi archive.

1. Trong Lovable, kết nối GitHub. Việc đồng bộ là hai chiều và luôn tạo một repository riêng tư mới, nên bạn vẫn có thể tiếp tục chỉnh sửa trong Lovable trong khi làm lớp vỏ native trên máy.
2. Clone repo, chạy npm install, rồi npm run build. Kiểm tra nơi Vite ghi đầu ra, thường là dist. Capacitor cần một tệp index.html có thẻ <head> ở thư mục gốc đó.
3. Cài Capacitor và các nền tảng bằng các lệnh trong khối mã bên dưới, lấy từ tài liệu bắt đầu của Capacitor.
4. Trong capacitor.config, đặt webDir thành dist. Đừng đặt server.url trỏ vào tên miền Lovable đang chạy: tài liệu tham chiếu cấu hình Capacitor nói rằng nó "không dành cho môi trường production."
5. Thêm các plugin native (thông báo đẩy, phản hồi rung, chia sẻ, sinh trắc học, thông báo cục bộ) cùng biểu tượng ứng dụng và màn hình khởi động native.
6. Chạy npx cap sync sau mỗi lần build web, rồi archive trong Xcode và tải lên App Store Connect. Checklist gửi duyệt App Store của chúng tôi hướng dẫn phần còn lại.

npm i @capacitor/core
npm i -D @capacitor/cli
npx cap init
npm i @capacitor/android @capacitor/ios
npx cap add android
npx cap add ios
npm run build && npx cap sync
npx cap open ios

Hãy gửi từ tài khoản Apple của chính bạn. Nguyên tắc 4.2.6 từ chối các ứng dụng được tạo từ dịch vụ tạo ứng dụng, trừ khi "được gửi trực tiếp bởi nhà cung cấp nội dung của ứng dụng." Hướng dẫn về Nguyên tắc 4.3 và 4.2.6 của chúng tôi giải thích cách quy định này áp dụng cho ứng dụng xây bằng AI.

Làm sao để ứng dụng Lovable được bọc lại không bị từ chối theo Nguyên tắc 4.2?

Hãy để ứng dụng làm được những việc mà trang web không làm được. Nguyên tắc 4.2 yêu cầu "tính năng, nội dung và giao diện nâng ứng dụng vượt lên trên một trang web được đóng gói lại", và 4.2.2 loại trừ các ứng dụng chủ yếu là "trích đoạn web, trình tổng hợp nội dung hoặc tập hợp các liên kết."

Dùng checklist này trước khi gửi duyệt:

• Bản build web được đóng gói trong binary và mở được khi không có kết nối mạng, hiển thị dữ liệu đã lưu đệm hoặc một màn hình ngoại tuyến đàng hoàng.
• Điều hướng dùng thanh tab dưới cùng thay vì menu hamburger, và không có footer hay banner cookie chỉ dành cho web.
• Đăng nhập, đăng ký và đặt lại mật khẩu đều diễn ra trong ứng dụng. Không có gì đẩy người dùng ra Safari.
• Ít nhất một luồng chính dựa vào thiết bị, chẳng hạn chụp ảnh bằng camera, thông báo cục bộ gắn với dữ liệu của chính người dùng, widget hoặc sinh trắc học.
• Các liên kết ra ngoài tới trang quyên góp, cửa hàng hay mạng xã hội được gỡ bỏ hoặc giữ ở mức tối thiểu.
• Ghi chú cho App Review giải thích vì sao ứng dụng hữu ích trên điện thoại và kèm tài khoản đăng nhập demo.

Chuyện gì đã xảy ra khi các ứng dụng nền web khác bị từ chối theo 4.2?

Các chủ đề thảo luận công khai cho thấy cùng một khuôn mẫu: người duyệt từ chối giao diện mang cảm giác web và các liên kết ra Safari, và chỉ thêm vài tính năng native nhỏ không làm thay đổi quyết định của họ.

Vào tháng 12/2020, một nhà phát triển trên Ionic Forum có ứng dụng thành viên câu lạc bộ bị từ chối với lý do "Ứng dụng của bạn mang lại trải nghiệm người dùng hạn chế vì không đủ khác biệt so với trải nghiệm duyệt web trên di động", kèm theo "phần lớn nội dung ứng dụng liên kết ra Safari." Gỡ InAppBrowser và cải thiện hỗ trợ ngoại tuyến là chưa đủ, và lần gửi thứ hai cũng bị từ chối. Lần thứ ba được duyệt sau khi nhà phát triển làm lại màn hình chính với danh sách và thẻ hình ảnh theo phong cách native, thêm nhiều nội dung tin tức trong ứng dụng và gỡ phần lớn liên kết ra ngoài.

Vào tháng 1/2026, một nhà phát triển trên Apple Developer Forums cho biết ứng dụng lập lịch của họ bị từ chối vì "không đủ khác biệt so với trải nghiệm duyệt web" dù đã dùng thông báo đẩy, Core Location và quyền truy cập danh bạ. Họ dự định thêm phản hồi rung, thao tác nhanh và tích hợp lịch sâu hơn, và hỏi thế nào thì được coi là "native hơn". Tại thời điểm viết bài, chủ đề này chưa có phản hồi nào và chưa có kết quả được xác nhận.

So sánh hai trường hợp: nhà phát triển thứ nhất vượt qua nhờ thay đổi bản chất ứng dụng (nội dung trong ứng dụng, bố cục native, không có liên kết ra ngoài). Người thứ hai chỉ thêm API thiết bị và vẫn chưa chắc chắn. Hãy dồn công sức vào trải nghiệm cốt lõi, đừng chỉ kéo dài danh sách quyền truy cập.

Khi nào nên viết lại thay vì bọc lại?

Hãy viết lại native khi giá trị chính của ứng dụng là nội dung web, hoặc khi bạn đã bị từ chối 4.2 hai lần với cùng một giao diện.

Ví dụ cụ thể: một công cụ đặt lịch xây bằng Lovable cho một phòng tập yoga hiển thị danh sách lớp, một biểu mẫu đặt chỗ và một liên kết thanh toán Stripe. Nếu bọc nguyên trạng, nó dính cả ba dấu hiệu cảnh báo của 4.2: giao diện web, liên kết ra ngoài và không dùng được ngoại tuyến. Dưới dạng PWA, nó có thể phát hành ngay hôm nay mà không tốn thêm chi phí. Để có mặt trên store, hãy giữ backend Lovable, làm lại danh sách lớp và luồng đặt chỗ bằng màn hình native, thêm nhắc nhở cục bộ trước mỗi buổi học, và xử lý thanh toán theo đúng quy định của Nguyên tắc App Review 3.1. Backend và mô hình dữ liệu của bạn được giữ lại. Thứ bạn viết lại là giao diện.

Nếu bạn muốn có thêm ý kiến về hướng đi phù hợp với dự án Lovable của mình, dịch vụ của The App Guy bao gồm bọc ứng dụng, viết lại và gửi duyệt lên store, hoặc gửi email tới yagyeshsrbobde@gmail.com.