Hành trình (đưa ứng dụng đầu tiên) đến với Apple Store của tôi

74

Câu chuyện kéo dài 3 tháng về Apple Review Rejections.

Năm ngoái, tôi đã có bước tiến lớn trong sự nghiệp của mình: mua được 1 chiếc Macbook, bắt đầu học Swift & lập trình ứng dụng iOS

Sau 3 tháng*, tôi đã submit ứng dụng đầu tiên lên App Store: Không thể tự hào hơn!

*Disclaimer: Tôi là 1 kỹ sư phần mềm, nên hành trình của bạn có thể sẽ khác.

Swift là 1 ngôn ngữ ấn tượng và, sau khi hiểu được thực tế là tôi không thể biết mọi thứ về Cocoa Touch, tôi đã không ngừng lập trình và ra mắt ứng dụng của mình.

Nhưng tôi đã sai.

The App

Đây là phần mô tả ngắn gọn về ứng dụng Stream for Twitter mà tôi đã submit:

Stream for Twitter sẽ mang đến cho bạn những Tweets mới LIVE (trực tiếp) từ khắp nơi trên thế giới: chỉ cần nhập bất cứ thứ gì mà bạn quan tâm và để Stream làm hết tất cả! (Bạn có thể xem đoạn video 50s về ứng dụng tại đây).

Lần đầu tiên bị từ chối

Bạn có thể thấy email ngắn ở trên không? Đây là cách mà Apple tử tế sử dụng để cho bạn biết câu trả lời Không, ứng dụng vẫn chưa vào được App Store đâu.

Ứng dụng của tôi khá đơn giản nên tôi khá ngạc nhiên khi tỉnh giấc với 1 lời từ chối như thế trong hộp thư.

Hóa ra, App Review Team thậm chí còn không test app, mà đã từ chối nó với lý do khá ngớ ngẩn là trong phần giới thiệu ứng dụng, giữa các ví dụ so sánh Twitter khác, tôi đã để cụm “iOS vs. Android”

3.1 Các ứng dụng hoặc metadata (siêu dữ liệu) đề cập đến tên của bất kì platform mobile nào khác sẽ bị reject

App Store Review 3.1 Guideline cũng nói rõ ràng là: xảy ra việc từ chối này hoàn toàn là do lỗi của tôi. May mắn là tôi không cần phải thay đổi binary (hệ nhị phân) của ứng dụng, chỉ cần sửa đoạn miêu tả và submit app lại thôi!

Lần thứ 2 bị từ chối

Lần này, App Review Team đã “triệu hồi” quy định trong App Store Review 14.3 Guideline (dưới chương Personal attacks):

14.3 Các ứng dụng hiển thị user generated content (các ứng dụng cho phép người dùng tự sản xuất ra nội dung) phải có 1 method để lọc lại những nội dung chống đối, 1 cơ chế để người dùng báo cáo nội dung phản cảm và khả năng chặn những người dùng lừa gạt dịch vụ.

Ứng dụng của tôi không cho phép người dùng sản xuất bất kì nội dung nào: nó chỉ cho phép bạn thưởng thức nội dung của Twitter (bạn có thể báo cáo/ đánh dấu/ chặn bất cứ người nào/ nội dung nào mà bạn muốn)

Mặc dù tôi phải làm những gì tôi được yêu cầu, nhưng nếu Stream chỉ sử dụng mỗi dữ liệu real time, nó sẽ trở nên vô dụng.

Nếu 1 người dùng phải báo cáo 1 Tweet, thì tweet đã cũ rồi: nó sẽ không bao giờ xuất hiện trên Stream nữa!

Tôi có cảm giác Guideline 14.3 đã không áp dụng được vào ứng dụng của mình, nên tôi đã viết 1 kháng cáo với những lý do bên dưới:

Bài học rút ra: nếu ứng dụng của bạn sử dụng nội dung mà người dùng có thể sản xuất được, hãy làm theo cơ chế đáng dấu (flag)/ điều chỉnh (moderator)/ chặn (block), dù nội dung đó không được tạo ra trong ứng dụng của bạn.

May mắn cho tôi là Twitter API đã cung cấp mọi thứ tôi cần:

  1. Cơ chế Report/Flag;
  2. Filter nội dung phù hợp;
 
Đến lúc submit lần nữa rồi!

Lần từ chối thứ 3

Trong lúc đang đợi review, tôi đã thêm vào app nhiều tính năng hơn, thậm chí là in-App Purchases không tiêu thụ (non-consumable) được.

Tồi tệ là chính những in-App Purchases khiến ứng dụng bị từ chối lần nữa.

Tất cả Stream in-App Purchases đều không tiêu thụ được: khi người dùng mua một lần, giao dịch này có thể được “mua” miễn phí (lần nữa) không giới hạn, tùy theo nhu cầu của người dùng.

Về phần mình, tôi luôn muốn có ít yếu tố UI nhất có thể: vì những in-App Purchase này có thể được “mua lại” miễn phí, tôi đã không dùng nút Restore.

Sau khi giải thích logic như trên, App Review đã trả lời thế này:

Bài học rút ra: Chính là button Restore!

Lần này, thật đáng tiếc là reviewer đã đề xuất tôi request 1 review khẩn cấp (theo form Expedited Review Request) sau khi tôi đã submit binary (hệ nhị phân) với button Restore.

Thực thi button restore là thay đổi nhanh chóng nhất mà tôi từng làm: tôi chỉ cần kéo 1 button vào storyboard và viết 3 dòng code, kết nối UIButton với UIViewController class liên quan.

Dường như Expedited Review Team đã không có lòng trắc ẩn như reviewer trước. Tôi phải đợi thêm 1 vòng App Reviews nữa.

Lần từ chối thứ tư

Tôi thực sự đã chứng kiến ứng dụng của mình được đưa vào preview trước khi đi ngủ, thậm chí còn có linh cảm tốt rằng khi thức dậy sẽ thấy ứng dụng được chấp thuận. Nhưng, tôi chỉ còn biết mơ tiếp…

Lần này, Reviewer nghĩ anh ta/cô ta cần vài xác thực đặc biệt từ Twitter thì mới dùng được ứng dụng, nên anh ta/ cô ta đã mail như vầy:

Sau khi giải thích về tài khoản của Twitter, ứng dụng được review lần nữa và… nó đã được chấp nhận!

Bực 1 nỗi là tôi đã thay đổi quan điểm về tên ứng dụng. Cách duy nhất để thay đổi tên hiện tại chính là:

Tên ứng dụng đã được thay đổi. Submit nào!

Lần từ chối thứ 5

Reviewer (theo tôi là mới được Apple tuyển vào làm) đang sử dụng iPad và anh ta đã không thể chuyển màn hình xác thực của Twitter: đó là màn hình hiển thị khi bạn khởi động Stream lần đầu.

Vấn đề không quá rõ ràng vì những screenshots mà Reviewer cắt ra không chính xác và thông điệp của rất mập mờ.

Sau 1 vài tin nhắn trao đổi, tôi bắt đầu sử dụng Stream trong iPad: ứng dụng được review lần nữa và sau đó được chấp nhận!

Bài học rút ra: Đừng cho rằng tất cả mọi người trong App Review Team đều hiểu rõ họ đang làm cái gì.

Kết luận

Sau khi lập trình ứng dụng chỉ trong 3 tháng, tôi đã tận hưởng thêm 3 tháng bị từ chối trước khi chính thức ra mắt ứng dụng trên Apple Store.

Suốt những tháng đó, tôi đã học ra rất nhiều, về cảm giác khó chịu và cả đam mê đã đồng hành cùng tôi suốt hành trình này.

Nếu bạn có thể đến được bước này, tôi muốn gửi bạn 1 vài lời khuyên cho lần submit tới (sau tất cả, thật mỉa mai là tôi đã trở thành chuyên gia trong chuyện này):

  • Thỉnh thoảng, hãy đọc App Store Review Guidelines: tốn không nhiều thời gian nhưng sẽ giúp bạn tránh được vài lần bị reject
  • Khi submit 1 ứng dụng mới, sử dụng fields App Review Information để hướng dẫn các reviewers và cho họ biết những thứ đã bị thay đổi/chỉnh sửa/cập nhật so với phiên bản trước

  • Trong trường hợp bạn đang submit 1 ứng dụng mới sau 1 lần bị reject, sử dụng trường Notes để chỉ rõ những gì bạn đã làm để vượt qua lần reject trước
  • Lịch sự: khi reviewers từ chối app của bạn, hãy cảm ơn họ và lịch sự hỏi thêm thông tin (nếu cần) hoặc họ cho biết bạn đang giải quyết (các) vấn đề với lần submit mới. Tôi đã làm việc với các reviewers rất lịch sự và thân thiện, họ vui vẻ giúp đỡ tôi giải quyết các vấn đề
  • Kiên nhẫn: ra mắt 1 ứng dụng sẽ trở thành 1 gánh nặng với bạn vì Apple đặt ra những tiêu chuẩn rất cao và đây cũng là lý do tại sao Store của Apple không chật chội như những đối thủ khác

Chúc bạn may mắn với trong lần submit app lần tới!

Nguồn: IDE Academy via Medium