Những gì bạn có thể thay đổi mà không cần phiên bản ứng dụng mới: Apple so với Google
Trước khi động vào danh sách trên chợ ứng dụng, có một câu hỏi đáng để trả lời trước: chỉnh sửa này có khiến bạn phải nộp lại toàn bộ hồ sơ, hay có thể lặng lẽ đi ra mà không cần ồn ào? Nếu đoán sai, bạn sẽ hoặc bị kẹt trong hàng chờ xét duyệt mà không lường trước, hoặc tưởng thay đổi đã lên rồi trong khi nó vẫn đang chờ duyệt. Hai chợ ứng dụng trả lời câu hỏi này theo hai hướng trái ngược nhau, và chính sự khác biệt đó là lý do khiến việc đồng bộ danh sách giữa hai bên trở nên phiền phức.
Đây là bản chi tiết, thẳng thắn theo từng trường — bắt đầu bằng bảng so sánh, sau đó là lý do đằng sau quy tắc của từng chợ để bạn có thể đoán trước những trường hợp bảng này chưa nói rõ.
Bảng so sánh
Mọi trường thông tin phổ biến trong danh sách, và yêu cầu của từng chợ khi bạn thay đổi nó. "Phiên bản / bản phát hành mới" nghĩa là chợ ứng dụng coi chỉnh sửa này là một phần của hồ sơ bạn phải gửi; "được xét duyệt" nghĩa là có một lượt kiểm tra thủ công hoặc tự động chạy trước khi nó được công khai.
| Biểu tượng ứng dụng | Biểu tượng chính nằm trong bản build — thay đổi nó cần một bản build mới. Được xét duyệt cùng bản build đó. | Biểu tượng trên cửa hàng là một tài sản trong danh sách. Không cần bản phát hành mới. Được xét duyệt. |
Có hai điều nổi bật lên. Apple dồn gần như mọi thứ qua một bản ghi phiên bản. Google để cả danh sách tự do di chuyển một mình. Không chợ nào bỏ qua xét duyệt đối với những tài sản quan trọng — từ "được xét duyệt" xuất hiện ở gần như mọi ô. Vậy câu hỏi thực sự hiếm khi là "cái này có bị xét duyệt không", mà là "chỉnh sửa này có kéo theo cả một hồ sơ nộp hay không."
Apple: bản ghi phiên bản mới không giống bản build mới
Đây là điểm khiến nhiều người nhầm lẫn. Trên App Store, chỉnh sửa ảnh chụp màn hình, tên, phụ đề, trường từ khóa hoặc mô tả sẽ tạo ra một phiên bản mới cho danh sách của bạn. Nghe có vẻ như bạn sẽ phải quay lại Xcode. Không phải vậy. Apple tự động mang metadata hiện tại của bạn sang phiên bản mới, và một thay đổi chỉ liên quan đến metadata không cần mã ứng dụng mới — bạn gắn một bản build (App Store Connect vẫn yêu cầu có một bản build trên phiên bản) và không thay đổi gì về cách ứng dụng hoạt động. Bạn chỉnh sửa các trường đang chờ, gửi đi, và một vòng xét duyệt sẽ bao quát tất cả.
Vậy "không có mã mới, nhưng vẫn được xét duyệt" là cách nghĩ chính xác nhất. Không có bước biên dịch, không có tính năng mới — nhưng chỉnh sửa vẫn đi vào App Review và chờ đến lượt trước khi công khai. Hãy gộp các thay đổi lại: vì một bản ghi phiên bản duy nhất có thể chứa ảnh chụp màn hình mới, mô tả viết lại, phụ đề mới và từ khóa cập nhật cùng lúc, chẳng có lý do gì để tốn riêng một vòng xét duyệt cho từng cái.
Biểu tượng ứng dụng là ngoại lệ thực sự cần một bản build. Biểu tượng chính của bạn được đóng gói vào bản build và lấy ra từ đó, nên một biểu tượng thực sự mới đồng nghĩa với một bản build mới. Điều tương tự cũng đúng với các biểu tượng thay thế — chúng phải được đóng gói sẵn trong ứng dụng để dùng được, nên thêm một biểu tượng là một bản build, không phải chỉnh sửa danh sách.
Hai lối tắt của Apple
Văn bản quảng cáo (promotional text). Đây là trường duy nhất bạn có thể thay đổi mà không cần phiên bản, không cần xét duyệt. Nó dài 170 ký tự, nằm phía trên mô tả, và cập nhật bất cứ khi nào bạn muốn — tiện cho một đợt sale, một thông báo ra mắt, hoặc nội dung mang tính thời điểm. Nó không ảnh hưởng đến thứ hạng tìm kiếm và không thuộc bất kỳ hồ sơ nộp nào, đó chính là lý do nó là thứ nhanh nhất để thay đổi trên chợ ứng dụng. Nếu bạn cần thứ gì đó lên ngay hôm nay, đây là trường có thể làm được điều đó.
Product Page Optimization. PPO cho phép bạn thử nghiệm tối đa ba phiên bản khác nhau của ảnh chụp màn hình, App Preview và biểu tượng so với trang sản phẩm đang hoạt động — mà không cần phát hành phiên bản ứng dụng mới. Đây là điều gần nhất Apple cho phép để thay đổi hình ảnh bên ngoài một hồ sơ nộp thông thường. Có hai điểm cần lưu ý cho công bằng: metadata của phiên bản thử nghiệm vẫn phải được duyệt trước khi thử nghiệm chạy (nên vẫn là xét duyệt, không phải tức thì), và bất kỳ biểu tượng nào bạn muốn thử nghiệm phải đã có sẵn trong bản build hiện tại của ứng dụng. PPO thay đổi những gì khách xem thấy; nó không bỏ qua xét duyệt.
Google Play: xuất bản danh sách mà không cần bản phát hành
Play hoạt động theo hướng ngược lại. Danh sách cửa hàng của bạn — tiêu đề, mô tả ngắn, mô tả đầy đủ, ảnh chụp màn hình, ảnh bìa tính năng, biểu tượng, video quảng bá — có thể chỉnh sửa và xuất bản độc lập, không gắn với bản phát hành ứng dụng mới nào. Bạn thực hiện chỉnh sửa, và chúng xuất hiện trong tổng quan Xuất bản dưới mục thay đổi sẵn sàng gửi xét duyệt. Bạn gửi đi, chúng qua xét duyệt của Google, rồi lên trực tuyến độc lập với bất kỳ bản build nào.
Có vài điều cần giữ cho chính xác để bạn không nói quá. Những thay đổi vẫn được xét duyệt — quy trình xét duyệt của Play cũng chạy trên các chỉnh sửa danh sách, và những yếu tố như tên ứng dụng và biểu tượng đều được kiểm tra, nên đây không phải là một cú hoán đổi tức thì và âm thầm. Và danh sách không thể tồn tại độc lập với một ứng dụng đã phát hành — Play yêu cầu ứng dụng phải có bản phát hành trước đó thì mới có danh sách công khai để chỉnh sửa. Bạn không thể đẩy một trang cửa hàng độc lập cho thứ chưa từng được phát hành. Managed publishing thêm một điểm cần biết nữa — nếu bật tính năng này, các thay đổi đã duyệt sẽ chờ đến khi bạn chủ động xuất bản chúng, đó là một tính năng chứ không phải sự chậm trễ, một khi bạn đã lường trước nó.
Sự bất đối xứng, và lý do nó tốn thời gian của bạn
Đặt hai mô hình cạnh nhau, sự khác biệt trở nên rõ ràng. Apple gắn gần như mọi chỉnh sửa văn bản và hình ảnh vào một bản ghi phiên bản và một vòng xét duyệt, với văn bản quảng cáo và PPO là hai cách duy nhất để đi vòng qua. Google tách hoàn toàn danh sách khỏi bản phát hành, vẫn xét duyệt các chỉnh sửa, và đưa chúng lên theo lịch riêng miễn là ứng dụng đã tồn tại.
Sự bất đối xứng đó âm thầm tốn kém khi bạn vận hành cả hai chợ. Cùng một lần làm mới ảnh chụp màn hình là một hồ sơ nộp bản ghi phiên bản ở chợ này và một cập nhật danh sách độc lập ở chợ kia. Một lần viết lại mô tả là một phiên bản được xét duyệt trên Apple và một thay đổi danh sách được xét duyệt trên Google. Nội dung giống nhau; cơ chế thì không, nên một thay đổi chỉ là một thao tác trên Play lại trở thành một thao tác khác trên App Store — và rất dễ để bạn phát hành ở một bên mà quên bên kia, hoặc tưởng điều gì đó đã lên trên Apple trong khi nó vẫn đang chờ xét duyệt.
Vị trí của Mokbi trong bức tranh này
Sự bất đối xứng giữa hai chợ này chính là lý do một công cụ xuất bản chứng minh được giá trị của mình. Mokbi bắt đầu là một trình chỉnh sửa ảnh chụp màn hình, nhưng một danh sách là văn bản và hình ảnh đi cùng nhau — nên nó thiết kế bộ ảnh chụp màn hình và soạn sẵn nội dung danh sách cho cả hai chợ trong cùng một nơi: tên, phụ đề, trường từ khóa và mô tả trên App Store; tiêu đề, mô tả ngắn và mô tả đầy đủ trên Play. Bạn nhận được đúng các trường mà mỗi chợ thực sự lập chỉ mục, được viết riêng cho chợ đó, thay vì một khối văn bản dán đi dán lại hai lần.
Sau đó nó dịch toàn bộ danh sách — ảnh chụp màn hình và nội dung — sang 50 ngôn ngữ, để một thay đổi bạn làm một lần sẽ vào đúng trường ở mọi thị trường, thay vì bị bỏ lại bằng tiếng Anh trong một danh sách đã được bản địa hóa ở mọi nơi khác. Và nó xuất bản: Mokbi đẩy danh sách hoàn chỉnh thẳng lên Google Play qua Play Developer API, và chuẩn bị sẵn trong App Store Connect, sẵn sàng để gửi — Apple vẫn yêu cầu bước Submit cuối cùng và vòng xét duyệt ở phía họ, đây là quy tắc của Apple và chính là sự bất đối xứng giữa hai chợ mà toàn bộ bài viết này nói đến. Vòng xét duyệt cuối cùng đó cũng chính là nơi đồng hồ trong bài viết này bắt đầu chạy.