TÌM HIỂU CHUYÊN SÂU VỀ APP RELEASE & DEPLOYMENT TRONG FLUTTER

1. App Release & Deployment là gì?

Trong quá trình phát triển ứng dụng Flutter, sau khi hoàn thành các chức năng, lập trình viên cần đưa ứng dụng đến người dùng thực tế.

Ví dụ, một nhóm đã xây dựng xong ứng dụng bán hàng với những chức năng như đăng nhập, xem sản phẩm, giỏ hàng, đặt hàng và nhận thông báo.

Ứng dụng chạy tốt trên máy tính và điện thoại của lập trình viên. Tuy nhiên, khách hàng vẫn chưa thể tìm kiếm hoặc tải ứng dụng trên Google Play hay App Store.

Để ứng dụng trở thành sản phẩm có thể sử dụng thực tế, nhóm phát triển cần thực hiện quy trình App Release & Deployment.

App Release là quá trình chuẩn bị và cung cấp một phiên bản ứng dụng cho nhóm người dùng hoặc đối tượng sử dụng cụ thể.

Deployment là quá trình triển khai phần mềm hoặc phiên bản phần mềm vào một môi trường hoạt động hoặc phân phối phù hợp.

Trong phát triển ứng dụng di động, hai khái niệm này thường liên quan đến việc build, ký ứng dụng, kiểm thử, tải bản build lên nền tảng phân phối và đưa ứng dụng đến người dùng.

Tuy nhiên, App Release không đơn giản chỉ là tạo ra file APK hoặc IPA.

Một bản phát hành còn liên quan đến version, cấu hình môi trường, bảo mật, kiểm thử, khả năng tương thích với Backend và quá trình theo dõi sau khi phát hành.

2. Vì sao cần quy trình Release & Deployment?

Khi mới học Flutter, lập trình viên thường nhấn Run trong VS Code hoặc Android Studio để chạy ứng dụng trên thiết bị.

Cách này phù hợp cho phát triển nhưng chưa đáp ứng đầy đủ yêu cầu phát hành.

Một ứng dụng được đưa đến người dùng cần được chuẩn bị cẩn thận hơn.

Ví dụ, ứng dụng phải sử dụng đúng Backend production, có tên và biểu tượng chính thức, được ký bằng thông tin phù hợp và không chứa những cấu hình debug không cần thiết.

Nếu không có quy trình phát hành rõ ràng, có thể xuất hiện nhiều vấn đề.

Ứng dụng có thể kết nối nhầm API development, không thể cập nhật vì sai khóa ký hoặc không tương thích với Backend mới.

Ngoài ra, bản phát hành có thể bị từ chối do chưa đáp ứng những yêu cầu của cửa hàng ứng dụng.

Vì vậy, Release & Deployment là giai đoạn chuyển ứng dụng từ sản phẩm đang phát triển thành phần mềm có thể được sử dụng thực tế.

3. Phân biệt Debug, Profile và Release Mode

Flutter hỗ trợ các chế độ build khác nhau.

3.1. Debug Mode

Debug Mode phục vụ quá trình phát triển.

Chế độ này hỗ trợ những công cụ như Breakpoint, Debugger và Hot Reload.

Ví dụ, khi lập trình viên đang xây dựng giao diện, Debug Mode giúp kiểm tra thay đổi nhanh chóng.

Tuy nhiên, Debug Mode có thêm chi phí phục vụ gỡ lỗi nên không phù hợp để đánh giá chính xác hiệu năng bản phát hành.

3.2. Profile Mode

Profile Mode phục vụ phân tích hiệu năng.

Lập trình viên có thể sử dụng chế độ này để đo thời gian xử lý frame, CPU và những vấn đề liên quan đến hiệu năng trong điều kiện phù hợp.

3.3. Release Mode

Release Mode được tối ưu hóa cho việc phát hành ứng dụng.

Ví dụ:

flutter build apk --release

Tuy nhiên, Release Mode không tự động bảo đảm ứng dụng đã sẵn sàng cho production.

Một bản Release vẫn có thể chứa lỗi nghiệp vụ hoặc sử dụng nhầm API Base URL.

Vì vậy, Release Mode phải được kết hợp với quy trình kiểm thử và kiểm tra cấu hình.

4. Quy trình phát hành ứng dụng Flutter

Một quy trình phát hành thường gồm nhiều bước.

Bước 1: Hoàn thành chức năng

Nhóm phát triển xác định những chức năng sẽ có trong phiên bản mới.

Ví dụ, phiên bản 1.0 có thể bao gồm đăng nhập, xem sản phẩm, giỏ hàng và đặt hàng.

Những chức năng chưa hoàn thiện có thể được chuyển sang phiên bản sau.

Bước 2: Kiểm thử

Trước khi phát hành, nhóm cần kiểm tra các chức năng quan trọng.

Có thể sử dụng Unit Test để kiểm tra logic.

Widget Test để kiểm tra giao diện.

Integration Test để kiểm tra những luồng sử dụng.

Ngoài ra, cần kiểm thử thủ công trên những thiết bị và phiên bản hệ điều hành phù hợp.

Bước 3: Kiểm tra cấu hình

Cần xác nhận ứng dụng sử dụng đúng môi trường.

Ví dụ, bản production phải kết nối với Backend production và Firebase Project phù hợp.

Không nên mặc định rằng chỉ cần build Release là toàn bộ cấu hình sẽ tự động chuyển sang production.

Bước 4: Cập nhật version

Nhóm phát triển xác định số phiên bản và số build.

Bước 5: Build ứng dụng

Tạo bản build Android hoặc iOS theo yêu cầu.

Bước 6: Ký ứng dụng

Sử dụng cơ chế signing phù hợp với nền tảng.

Bước 7: Phân phối thử nghiệm

Đưa bản build đến nhóm kiểm thử trước khi phát hành rộng rãi.

Bước 8: Phát hành chính thức

Tải bản build lên nền tảng phân phối và thực hiện những bước phát hành theo yêu cầu.

Bước 9: Theo dõi sau phát hành

Quan sát crash, lỗi API, hiệu năng và phản hồi người dùng.

Những bước này có thể được tự động hóa một phần bằng CI/CD.

5. Version và Build Number

Trong Flutter, thông tin phiên bản thường được khai báo trong pubspec.yaml.

Ví dụ:

version: 1.2.0+15

Trong đó, 1.2.0 là phần version.

Số 15 sau dấu cộng là build number.

Flutter sử dụng những giá trị này để hỗ trợ cấu hình phiên bản tương ứng trên Android và iOS.

Ví dụ:

1.0.0+1: Phiên bản đầu tiên.

1.0.1+2: Bản cập nhật sửa lỗi.

1.1.0+3: Bản cập nhật bổ sung tính năng.

Đây chỉ là ví dụ về quy ước đặt phiên bản.

Điều quan trọng là version và build number phải đáp ứng quy định của nền tảng phân phối.

Ví dụ, Google Play yêu cầu các bản cập nhật sử dụng version code phù hợp và không được trùng với bản đã phát hành theo những quy tắc của hệ thống.

6. Semantic Versioning là gì?

Semantic Versioning là một quy ước quản lý phiên bản phần mềm theo cấu trúc:

MAJOR.MINOR.PATCH

Trong đó:

MAJOR thường thay đổi khi có những thay đổi không tương thích ngược theo quy ước SemVer.

MINOR thường thay đổi khi bổ sung chức năng theo cách tương thích ngược.

PATCH thường thay đổi khi sửa lỗi tương thích ngược.

Ví dụ:

1.0.0 là phiên bản ban đầu.

1.1.0 có thể bổ sung chức năng mới.

1.1.1 có thể sửa lỗi.

Tuy nhiên, quy ước Semantic Versioning không bắt buộc áp dụng nguyên xi cho mọi ứng dụng di động.

Nhóm phát triển cần lựa chọn cách quản lý phiên bản phù hợp với sản phẩm và yêu cầu của nền tảng phân phối.

7. Android APK là gì?

APK là viết tắt của Android Package Kit, là định dạng gói ứng dụng Android.

Trong Flutter, có thể tạo APK bằng lệnh:

flutter build apk --release

Sau khi build thành công, tệp APK thường được tạo trong thư mục output của dự án.

Ví dụ:

build/app/outputs/flutter-apk/

APK có thể được sử dụng để cài đặt ứng dụng trên thiết bị Android trong những trường hợp phù hợp.

Tuy nhiên, đối với phát hành ứng dụng mới trên Google Play, Android App Bundle là định dạng tiêu chuẩn theo yêu cầu hiện hành.

8. Android App Bundle (AAB) là gì?

Android App Bundle, viết tắt là AAB, là định dạng gói phát hành ứng dụng Android.

Khác với APK có thể được cài đặt trực tiếp trong những điều kiện phù hợp, AAB thường được cung cấp cho hệ thống phân phối như Google Play.

Google Play có thể sử dụng App Bundle để tạo những APK phù hợp với thiết bị của người dùng.

Ví dụ, một ứng dụng có nhiều tài nguyên và thư viện hỗ trợ những cấu hình thiết bị khác nhau.

Hệ thống phân phối có thể lựa chọn những thành phần cần thiết để tối ưu dung lượng tải xuống.

Trong Flutter, có thể build AAB bằng lệnh:

flutter build appbundle --release

Tệp AAB thường được tạo trong thư mục:

build/app/outputs/bundle/release/

Vị trí cụ thể có thể khác tùy cấu hình dự án.

9. APK và AAB khác nhau như thế nào?

APK là gói ứng dụng Android có thể được cài đặt trực tiếp trong những điều kiện phù hợp.

AAB là định dạng gói phát hành được sử dụng để hệ thống phân phối tạo ra những APK phù hợp.

Ví dụ, nếu lập trình viên muốn cài ứng dụng lên một thiết bị Android để kiểm thử thủ công, APK có thể thuận tiện.

Nếu muốn phát hành ứng dụng mới trên Google Play, AAB thường là lựa chọn cần sử dụng theo yêu cầu nền tảng.

Cần lưu ý rằng AAB không phải là một file APK thông thường có thể nhấn vào để cài đặt trực tiếp.

10. App Signing là gì?

App Signing là quá trình ký ứng dụng bằng những thông tin mật mã phù hợp.

Trên Android, việc ký ứng dụng giúp nền tảng xác minh danh tính ký và hỗ trợ kiểm tra tính toàn vẹn của gói ứng dụng.

Điều này đặc biệt quan trọng khi cập nhật ứng dụng.

Ví dụ, một ứng dụng đã được phát hành với danh tính ký nhất định. Khi phát hành phiên bản mới, bản cập nhật phải đáp ứng cơ chế xác minh chữ ký của nền tảng.

Nếu sử dụng sai khóa ký, quá trình cập nhật có thể gặp vấn đề.

Vì vậy, thông tin ký ứng dụng cần được quản lý cẩn thận.

11. Keystore là gì?

Keystore là nơi lưu trữ khóa mật mã và những thông tin liên quan trong những cơ chế được hỗ trợ.

Trong quá trình phát hành Android, lập trình viên thường cần cấu hình khóa ký.

Những thông tin liên quan có thể bao gồm:

• Tệp keystore.
• Key alias.
• Mật khẩu keystore.
• Mật khẩu khóa khi áp dụng.

Những thông tin này không nên được đưa vào repository công khai.

Nếu sử dụng CI/CD, nên quản lý chúng bằng cơ chế Secrets phù hợp.

Việc mất hoặc làm lộ khóa ký có thể ảnh hưởng nghiêm trọng đến khả năng phát hành và bảo mật ứng dụng, tùy cơ chế ký đang sử dụng.

12. Google Play App Signing

Google Play hỗ trợ cơ chế Play App Signing.

Trong cơ chế này, cần phân biệt app signing key và upload key.

App signing key được sử dụng trong cơ chế ký ứng dụng phân phối đến người dùng.

Upload key được sử dụng để xác thực bản build tải lên trong quy trình phù hợp.

Việc phân biệt hai loại khóa giúp hiểu cách Google Play quản lý quá trình ký và phân phối ứng dụng.

Tuy nhiên, không nên xem upload key là thông tin có thể công khai. Nó vẫn cần được bảo vệ.

13. Application ID

Application ID là định danh của ứng dụng Android.

Ví dụ:

com.example.milkstore

Application ID giúp nền tảng phân biệt ứng dụng này với ứng dụng khác.

Khi ứng dụng đã được phát hành, application ID có vai trò quan trọng trong quá trình cập nhật.

Nếu thay đổi application ID, hệ thống có thể xem đó là một ứng dụng khác.

Vì vậy, cần lựa chọn application ID phù hợp trước khi phát hành chính thức.

Khi sử dụng Flutter Flavors, có thể cấu hình application ID khác nhau cho bản development và production.

14. Phát hành ứng dụng Flutter lên Google Play

Để phát hành ứng dụng Android trên Google Play, nhóm phát triển cần thực hiện nhiều công việc.

Đầu tiên, chuẩn bị bản ứng dụng production.

Tiếp theo, kiểm tra tên, biểu tượng, version, application ID và cấu hình signing.

Sau đó, build Android App Bundle.

Nhóm phát triển sử dụng Google Play Console để tạo hoặc quản lý ứng dụng.

Tại đây, cần cung cấp những thông tin theo yêu cầu của nền tảng như mô tả ứng dụng, hình ảnh giới thiệu, thông tin quyền riêng tư và các khai báo liên quan.

Sau khi tải bản build lên, nhóm có thể lựa chọn hình thức kiểm thử hoặc phát hành được hỗ trợ.

Google Play có thể thực hiện quá trình kiểm tra và xét duyệt trước khi phân phối.

Các yêu cầu có thể thay đổi theo thời gian, loại tài khoản và loại ứng dụng. Vì vậy, khi thực sự phát hành, cần kiểm tra hướng dẫn mới nhất của Google Play Console.

15. Phát hành ứng dụng Flutter trên iOS

Đối với iOS, quá trình phát hành có những khác biệt so với Android.

Ứng dụng iOS thường được build và ký bằng công cụ của Apple trên môi trường macOS có Xcode phù hợp.

Một số thành phần quan trọng gồm:

Bundle Identifier: Định danh của ứng dụng iOS.

Signing Certificate: Chứng chỉ phục vụ quá trình ký ứng dụng.

Provisioning Profile: Thành phần liên quan đến cấu hình và quyền phân phối trong những trường hợp áp dụng.

App Store Connect: Nền tảng quản lý ứng dụng, bản build và quá trình phát hành.

Trong Flutter, có thể sử dụng:

flutter build ipa --release

Lệnh này phục vụ quá trình tạo bản build iOS phù hợp khi môi trường Xcode và signing đã được cấu hình đúng.

Sau đó, bản build có thể được tải lên App Store Connect bằng công cụ được Apple hỗ trợ.

Tương tự Android, việc tải bản build lên không có nghĩa ứng dụng đã được phát hành ngay lập tức.

Ứng dụng có thể cần trải qua quá trình kiểm tra và xét duyệt.

16. TestFlight là gì?

TestFlight là dịch vụ của Apple hỗ trợ phân phối những bản ứng dụng thử nghiệm.

Ví dụ, trước khi phát hành chính thức, nhóm phát triển muốn mời một số người dùng thử chức năng đặt hàng.

Nhóm có thể phân phối bản thử nghiệm qua TestFlight theo những điều kiện được Apple hỗ trợ.

Người kiểm thử sử dụng ứng dụng và gửi phản hồi.

Nhờ đó, nhóm có thể phát hiện những lỗi chỉ xuất hiện trên thiết bị thực tế.

Trên Android, Google Play cũng có các hình thức kiểm thử như internal testing và closed testing.

Những cơ chế này giúp kiểm tra bản phát hành trước khi đưa đến toàn bộ người dùng.

17. Staged Rollout là gì?

Staged Rollout là phương pháp phát hành một phiên bản đến một phần người dùng trước khi mở rộng phạm vi.

Ví dụ, nhóm phát triển không muốn đưa bản cập nhật đến toàn bộ người dùng ngay lập tức.

Thay vào đó, nhóm có thể phát hành đến một tỷ lệ nhỏ người dùng theo khả năng hỗ trợ của nền tảng.

Sau đó, theo dõi crash, lỗi API và phản hồi.

Nếu phiên bản hoạt động ổn định, nhóm có thể mở rộng phạm vi phát hành.

Nếu phát hiện lỗi nghiêm trọng, nhóm có thể tạm dừng hoặc điều chỉnh quá trình phát hành theo những cơ chế được nền tảng hỗ trợ.

Staged Rollout giúp hạn chế phạm vi ảnh hưởng của một số lỗi nhưng không bảo đảm có thể thu hồi ngay bản ứng dụng đã được cài đặt.

18. Rollback là gì?

Rollback là việc quay lại phiên bản phần mềm trước đó khi phiên bản mới gặp vấn đề.

Đối với Backend, rollback có thể được thực hiện bằng cách triển khai lại phiên bản trước nếu kiến trúc và dữ liệu cho phép.

Tuy nhiên, đối với ứng dụng di động, rollback phức tạp hơn vì người dùng có thể đã cài đặt bản mới trên thiết bị.

Không thể mặc định rằng tất cả thiết bị sẽ tự động quay về phiên bản cũ.

Trong nhiều trường hợp, nhóm cần chuẩn bị bản cập nhật sửa lỗi hoặc sử dụng cơ chế kiểm soát tính năng từ xa đã được thiết kế trước.

Vì vậy, việc kiểm thử và phát hành theo giai đoạn rất quan trọng.

19. Khả năng tương thích giữa Flutter và Backend

Một ứng dụng Flutter thường kết nối với Backend thông qua REST API.

Tuy nhiên, Frontend và Backend không phải lúc nào cũng được cập nhật cùng lúc.

Ví dụ, Backend đã thay đổi cấu trúc JSON nhưng một số người dùng vẫn đang sử dụng phiên bản Flutter cũ.

Nếu ứng dụng cũ không xử lý được dữ liệu mới, có thể xuất hiện lỗi Deserialization.

Vì vậy, Backend cần xem xét khả năng tương thích với những phiên bản ứng dụng đang được sử dụng.

Ví dụ, khi bổ sung trường dữ liệu mới, nên cân nhắc liệu ứng dụng cũ có thể bỏ qua trường đó hay không.

Khi thay đổi một trường quan trọng, nhóm phát triển cần có kế hoạch chuyển đổi.

Một số hệ thống sử dụng API Versioning:

/api/v1/products
/api/v2/products

Tuy nhiên, API Versioning không phải giải pháp duy nhất.

Nhóm phát triển cũng có thể sử dụng những thay đổi tương thích ngược và quy trình chuyển đổi theo từng giai đoạn.

Điều quan trọng là không nên mặc định mọi người dùng đều cập nhật ứng dụng ngay khi phiên bản mới được phát hành.

20. Theo dõi ứng dụng sau khi phát hành

Sau khi ứng dụng xuất hiện trên cửa hàng, công việc phát triển chưa kết thúc.

Người dùng có thể sử dụng nhiều loại thiết bị, phiên bản hệ điều hành và điều kiện mạng khác nhau.

Vì vậy, nhóm cần theo dõi hoạt động thực tế.

Firebase Crashlytics

Hỗ trợ ghi nhận và phân tích crash hoặc một số lỗi trong ứng dụng.

Firebase Analytics

Hỗ trợ phân tích hành vi và các sự kiện sử dụng.

Backend Monitoring

Theo dõi hoạt động API, thời gian phản hồi và những lỗi phía máy chủ.

Logging

Ghi nhận thông tin kỹ thuật cần thiết để điều tra sự cố.

Store Reviews

Giúp nhóm phát triển tiếp nhận phản hồi của người dùng trên cửa hàng ứng dụng.

Ví dụ, nếu sau khi phát hành phiên bản mới, tỷ lệ crash tăng bất thường, nhóm cần điều tra và xác định nguyên nhân.

Không nên cho rằng ứng dụng được cửa hàng phê duyệt đồng nghĩa với việc mọi chức năng đều hoàn toàn ổn định.

21. Bảo mật khi phát hành ứng dụng

Trước khi phát hành, nhóm cần kiểm tra những vấn đề bảo mật quan trọng.

Ứng dụng nên sử dụng HTTPS phù hợp để giao tiếp với Backend.

Không nên lưu mật khẩu cơ sở dữ liệu hoặc private key trong code Flutter.

Những thông tin nhạy cảm không nên xuất hiện trong log.

Backend phải kiểm tra xác thực và phân quyền đối với những API quan trọng.

Ví dụ, dù Flutter không hiển thị nút xóa sản phẩm cho người dùng thường, Backend vẫn phải xác minh quyền khi nhận yêu cầu xóa sản phẩm.

Điều này quan trọng vì ứng dụng phía client không phải môi trường đáng tin cậy tuyệt đối.

Người khác có thể phân tích ứng dụng hoặc gửi HTTP Request trực tiếp đến Backend mà không thông qua giao diện Flutter.

22. App Release & Deployment kết hợp với CI/CD

CI/CD có thể tự động hóa nhiều bước trong quá trình phát hành.

Ví dụ:

Commit Code → Analyze → Test → Build → Lưu Artifact → Phân phối thử nghiệm → Phê duyệt → Phát hành

Khi sử dụng Flutter Flavors, pipeline có thể build những phiên bản phù hợp với development, staging hoặc production.

Đối với Android, pipeline có thể tạo AAB và sử dụng cơ chế phân phối được hỗ trợ.

Đối với iOS, pipeline cần môi trường và thông tin signing phù hợp.

Tuy nhiên, những bước liên quan đến phát hành chính thức vẫn cần tuân thủ quy trình của Google Play và App Store.

23. Ví dụ thực tế: Phát hành ứng dụng MilkStore

Giả sử nhóm phát triển đã hoàn thành ứng dụng bán hàng MilkStore.

Ứng dụng có các chức năng đăng nhập, xem sản phẩm, giỏ hàng, đặt hàng, lịch sử đơn hàng và nhận thông báo FCM.

Trước khi phát hành, nhóm chạy Unit Test để kiểm tra tính tiền, giảm giá và validation.

Tiếp theo, chạy Widget Test để kiểm tra màn hình đăng nhập và giỏ hàng.

Sau đó, sử dụng Integration Test để kiểm tra luồng đặt hàng.

Nhóm tiếp tục sử dụng Flutter DevTools để kiểm tra hiệu năng và những lỗi phát sinh.

Khi các bước kiểm tra đạt yêu cầu, nhóm build bản staging để phân phối cho người kiểm thử.

Sau khi xác nhận các chức năng hoạt động đúng, nhóm chuẩn bị bản production.

Bản production sử dụng API Base URL, Firebase Project, application ID và thông tin signing phù hợp.

Tiếp theo, nhóm tạo bản build Android hoặc iOS và đưa lên nền tảng phân phối.

Sau khi phát hành, nhóm tiếp tục theo dõi crash, hiệu năng và phản hồi của người dùng.

Ví dụ này cho thấy Release & Deployment là giai đoạn kết hợp nhiều kiến thức đã học trong Flutter.

24. Những sai lầm thường gặp

Sai lầm đầu tiên là build Release nhưng quên thay API Base URL.

Sai lầm thứ hai là không cập nhật version hoặc build number phù hợp.

Sai lầm thứ ba là quản lý khóa ký không an toàn.

Sai lầm thứ tư là chỉ kiểm thử trên một thiết bị.

Sai lầm thứ năm là không kiểm tra khả năng tương thích với Backend.

Sai lầm thứ sáu là bỏ qua những yêu cầu về quyền riêng tư và chính sách cửa hàng.

Sai lầm thứ bảy là không theo dõi crash sau phát hành.

Sai lầm cuối cùng là cho rằng phát hành thành công đồng nghĩa với việc ứng dụng không cần bảo trì nữa.

25. Kết luận

App Release & Deployment là quá trình chuẩn bị, xây dựng, ký, kiểm thử và phân phối ứng dụng đến người dùng hoặc môi trường sử dụng phù hợp.

Trong Flutter, quá trình này liên quan đến Release Build, quản lý phiên bản, APK, AAB, IPA, App Signing và những nền tảng như Google Play hoặc App Store.

Một quy trình phát hành tốt không chỉ tạo ra bản build thành công mà còn phải bảo đảm ứng dụng sử dụng đúng môi trường, có cấu hình phù hợp và tương thích với Backend.

Sau khi phát hành, nhóm phát triển cần tiếp tục theo dõi lỗi, hiệu năng và phản hồi người dùng.

Có thể nói, App Release & Deployment là giai đoạn đưa sản phẩm từ môi trường phát triển đến thực tế sử dụng, đồng thời đặt nền tảng cho việc bảo trì và cập nhật lâu dài.

26. Tài liệu tham khảo

• Flutter Android Deployment: https://docs.flutter.dev/deployment/android
• Flutter iOS Deployment: https://docs.flutter.dev/deployment/ios
• Flutter Continuous Delivery: https://docs.flutter.dev/deployment/cd
• Android App Bundle: https://developer.android.com/guide/app-bundle
• Google Play App Signing: https://support.google.com/googleplay/android-developer/answer/9842756
• App Store Connect: https://developer.apple.com/app-store-connect/
• TestFlight: https://developer.apple.com/testflight/