Tại sao tôi xây dựng Screenshots Live: Câu chuyện của một nhà phát triển whitelabel
Quản lý 20 ứng dụng whitelabel với các cửa hàng và thương hiệu khác nhau đã dạy tôi một điều: tự động hóa ảnh chụp màn hình App Store không nên đau đớn như vậy. Đây là câu chuyện tại sao tôi xây dựng Screenshots Live.
Vấn đề: 20 ứng dụng, 20 thương hiệu, hàng trăm ảnh chụp màn hình
Vài năm trước, tôi làm việc với tư cách là nhà phát triển tại một startup nơi chúng tôi xây dựng ứng dụng di động whitelabel. Một codebase duy nhất, nhưng 20 khách hàng khác nhau — mỗi khách hàng có thương hiệu, màu sắc, logo và danh sách App Store riêng. Mỗi khách hàng cần bộ ảnh chụp màn hình được trau chuốt riêng cho App Store và Google Play.
Nếu bạn từng xuất bản ứng dụng, bạn biết quy trình: Apple muốn ảnh chụp màn hình cho mọi kích thước thiết bị (6,7", 6,5", 5,5", iPad Pro, iPad...), Google Play muốn bộ riêng, và nếu bạn hỗ trợ nhiều ngôn ngữ, nhân tất cả lên lần nữa. Bây giờ nhân điều đó với 20 khách hàng.
Chúng tôi đang nói về hàng ngàn ảnh chụp màn hình cần được tạo, đóng khung trong mockup thiết bị, gắn thương hiệu với đúng màu sắc và tải lên — trong mỗi chu kỳ phát hành.
Những gì chúng tôi có: Ảnh chụp tự động trong pipeline
Bản thân các ảnh chụp thô không phải là vấn đề. Phần đó chúng tôi đã giải quyết. Các bài test UI của chúng tôi, chạy trong pipeline GitLab CI, sẽ khởi chạy mỗi biến thể ứng dụng, điều hướng qua các màn hình chính và chụp ảnh màn hình tự động. snapshot của Fastlane (iOS) và screengrab (Android) đảm nhận công việc nặng.
Vậy chúng tôi có hàng trăm file PNG thô nằm trong artifacts của pipeline sau mỗi lần build. Tuyệt. Nhưng ảnh chụp thô không đưa lên App Store được. Chúng cần được xử lý — đặt bên trong khung thiết bị, với nền phù hợp thương hiệu khách hàng, phủ lên text marketing và xuất đúng kích thước pixel mà mỗi store yêu cầu.
Những điểm đau
1. Nút thắt cổ chai Designer
Designer của chúng tôi rất tài năng, nhưng yêu cầu họ cập nhật thủ công file Figma cho 20 thương hiệu mỗi lần phát hành là điều vô lý. Họ mất nhiều ngày chỉ để đổi ảnh chụp và điều chỉnh màu sắc. Và nếu khách hàng thay đổi thương hiệu giữa chu kỳ? Bắt đầu lại.
2. Không có thời gian xây dựng công cụ nội bộ
Chúng tôi là startup. Mỗi sprint đều đầy tính năng, sửa lỗi và yêu cầu khách hàng. Xây dựng dịch vụ xử lý ảnh chụp nội bộ — với hệ thống template, render khung thiết bị, chồng text và xuất theo từng store — là dự án kéo dài nhiều tháng mà chúng tôi không thể biện minh. Chúng tôi cần ship sản phẩm, không phải công cụ.
3. Công việc thủ công không mở rộng được
Trong một thời gian, chúng tôi thử cách tiếp cận bán thủ công: designer tạo template, script xử lý hàng loạt, và ai đó kiểm tra thủ công rồi tải lên. Nhưng điều này liên tục hỏng. Font bị sai, khung không căn chỉnh, text tràn bằng tiếng Đức nhưng ổn bằng tiếng Anh. Mỗi trường hợp đặc biệt trở thành tình huống khẩn cấp.
4. Tích hợp Pipeline là mảnh ghép còn thiếu
Chúng tôi muốn quy trình tự động hoàn toàn: code được push, pipeline chạy test, ảnh chụp được capture, ảnh chụp được xử lý với branding đúng, và Fastlane tải lên store. Mảnh ghép còn thiếu luôn là bước xử lý. Không có dịch vụ nào chúng tôi có thể gọi từ CI pipeline qua API.
Cách chúng tôi giải quyết
Sự thất vọng này chính xác là lý do Screenshots Live tồn tại. Ý tưởng rất đơn giản: một dịch vụ xử lý lấy ảnh chụp thô, áp dụng template do designer tạo với khung thiết bị và branding, và trả về hình ảnh sẵn sàng cho store — tất cả qua một lệnh gọi API đơn giản phù hợp với mọi pipeline CI/CD.
Tích hợp GitLab + Fastlane
Đây là pipeline của chúng tôi sau khi tích hợp Screenshots Live:
- Giai đoạn Build & Test: GitLab CI build ứng dụng cho mỗi biến thể whitelabel. Test UI chạy và capture ảnh chụp thô sử dụng Fastlane
snapshot/screengrab. - Giai đoạn xử lý Screenshot: Một script đơn giản lặp qua các ảnh chụp, gọi Screenshots Live với đúng template ID và tham số branding cho mỗi khách hàng, và tải về hình ảnh đã xử lý.
- Giai đoạn Upload: Fastlane
deliver(iOS) vàsupply(Android) tải ảnh chụp đã xử lý lên các store tương ứng.
Toàn bộ quy trình — từ push code đến ảnh chụp sẵn sàng cho store — trở nên hoàn toàn tự động. Không cần designer tham gia cho các bản phát hành thường xuyên. Không cần QA thủ công layout ảnh chụp. Không có tình huống khẩn cấp khi khách hàng yêu cầu phát hành hotfix lúc 5 giờ chiều thứ Sáu.
Điều gì đã thay đổi
Tiết kiệm thời gian
Điều trước đây mất designer 2-3 ngày mỗi chu kỳ phát hành giờ không mất thời gian con người. Pipeline xử lý mọi thứ. Với 20 ứng dụng phát hành hai tuần một lần, đó là khoảng 40-60 ngày designer tiết kiệm mỗi năm — thời gian designer có thể dành cho thiết kế sản phẩm thực sự thay vì lắp ráp ảnh chụp lặp đi lặp lại.
Nhất quán
Mỗi ảnh chụp, cho mỗi khách hàng, cho mỗi kích thước thiết bị, tuân theo cùng một template. Không còn vấn đề "phiên bản iPhone 15 Pro Max có text hơi lệch". Các template pixel-perfect, và được áp dụng nhất quán mỗi lần.
Sự độc lập của Designer
Designer có thể cập nhật template bất cứ khi nào — khung thiết bị mới, text marketing cập nhật, thiết kế theo mùa — mà không cần sự can thiệp của developer. Họ cập nhật template trong trình chỉnh sửa trực quan, và lần chạy pipeline tiếp theo tự động sử dụng nó.
Onboarding khách hàng
Thêm khách hàng whitelabel mới đã chuyển từ "lên lịch 2 ngày thiết kế" thành "tạo biến thể template mới với màu thương hiệu và logo của họ". Pipeline lo phần còn lại.
Tại sao chúng tôi công bố nó
Sau khi sử dụng nội bộ và thấy nó tiết kiệm bao nhiêu thời gian, chúng tôi nhận ra đây không phải vấn đề riêng của mình. Mọi nhà phát triển ứng dụng xuất bản lên App Store hoặc Google Play đều phải đối mặt với việc tạo ảnh chụp. Nhà phát triển whitelabel khó khăn nhất, nhưng ngay cả đội phát triển một ứng dụng với hỗ trợ đa ngôn ngữ cũng gặp vấn đề nhân bội tương tự.
Vì vậy chúng tôi dọn dẹp nó, xây dựng API với tài liệu, thêm trình chỉnh sửa template mà người không phải developer cũng dùng được, và mở ra. Nếu bạn đang mất hàng giờ tạo thủ công ảnh chụp App Store, hoặc pipeline của bạn có khoảng trống giữa "capture ảnh chụp" và "tải lên store", Screenshots Live lấp đầy khoảng trống đó.
Chúng tôi xây dựng nó vì chúng tôi cần nó. Chúng tôi chia sẻ nó vì chúng tôi biết bạn cũng cần nó.