App Store Connect API: ürün başına 350 yazma işlemi

App Store Connect’te otomatik yenilenen abonelik tek satır gibi görünür: bir ürün kimliği, fiyat ve süre. Formu doldurursunuz, ürün oluşur.

Ancak o satır tek kayıt değil. App Store Connect API ile oluştururken bir kayıt grafiği kurarsınız. Kendi araç denememde ürün başına yaklaşık 350 yazma işlemi ile karşılaştım.

Bu sayıyı, bir araç geliştirip deneme uygulamasında çalıştırdığım için biliyorum. Yeni uygulama, iki ürün, on bir mantıksal eylem: API çağrıları dört dakika on bir saniye sürdü. Aşağıdaki sayılar bu doğrulama çalışmasının kaydı; her kurulum için süre vaadi değil.

Formun arkasında bir kayıt grafiği var

Bir abonelik oluşturmak şu sırayı gerektiriyor:

1. Abonelik grubu
2. Grubun yerelleştirmesi — dil başına bir kayıt
3. Abonelik — ürün kimliği, referans adı ve süre
4. Aboneliğin yerelleştirmesi — dil başına görünen ad ve açıklama
5. Satışa açık bölgeler
6. Fiyat — bölge başına bir satır
7. Varsa tanıtım teklifi veya ücretsiz deneme

İlk dört adım az sayıda çağrı. Yükü büyüten, bölge ve fiyat kayıtları.

Kullanılabilirlik ve fiyat bölge bazında

Deneme sırasında Apple’ın 175 satış bölgesini kullandım. “Her yerde 4,99 dolar” tek bir kayıt değil: kullanılabilirlik ve bölgesel fiyatlarla ifade ediliyor.

İki ürün için istediğiniz on bir mantıksal eylem, yüzlerce kayda dönüşüyor. Bunları API üzerinden veya arka planda çağrı yapan tarayıcı formuyla oluşturmanız gerekiyor. İşlemin birkaç dakika sürmesi yalnızca API’nin yavaşlığıyla açıklanamaz; yaptığınız işin hacmi büyük.

Fiyatta tavuk ve yumurta sorunu

Apple’da keyfî bir ondalık fiyat yazmıyorsunuz. Bölgelere uyarlanmış bir fiyat noktası merdiveninden seçim yapıyorsunuz. Sorun şu: API, fiyat noktalarını yalnızca zaten var olan ürünler için listeliyor.

Yeni bir ürünün 4.99 fiyatını, ürün oluşmadan önce kendi merdivenine karşı doğrulayamazsınız. Önce ürünü oluşturmanız, sonra kullanılabilir fiyatları sorgulamanız gerekir.

Bu yüzden asc-subs, planın o satırında sınırı açıkça söyler:

⚠ "com.example.app.weekly" does not exist in App Store Connect yet, so it has
  no price point ladder to check 4.99 against

Önceden kesin bir fiyat vadeden bir araç, henüz doğrulayamadığı bir şeyi doğruymuş gibi sunabilir. Plan çıktısındaki belirsizlik de işin parçası.

Ücretsiz denemeler de bölge bazında: benim hatam

Tanıtım teklifi de fiyat gibi bölge başına bir kayıt olarak tutuluyor.

Bunu ilk uygulamamda yanlış kurdum. Deneme oluştururken tek bir temel bölge verdim; tüm dünyaya uygulanacak bir teklif için bunun yeterli olduğunu düşündüm. Sonuçta deneme yalnızca ABD’de vardı:

GET /v1/subscriptions/{id}/introductoryOffers?filter[territory]=USA → 1 row
                                             …filter[territory]=TUR → 0 rows
                                             …filter[territory]=DEU → 0 rows

Komut ✓ create-intro-offer … P3D yazıp başarıyla kapandı. Birim testleri geçti. Çağrı şekli doğruydu; testlerdeki varsayım yanlıştı. Apple’ı taklit eden test, bu gerçeği kendi başına gösteremez.

Bu yüzden araçları gerçek hizmette doğrulayıp gözlemi kaydetmek gerekiyor. Yedi kontrol, beş geçiş, bir hata ve henüz denenmemiş bir yol doğrulama dosyasında yer alıyor. Test sayısı ile sağlayıcı doğrulaması farklı kanıtlar.

Kalıcı olan üç şey

İlk API çağrısından önce bilin:

Ürün kimlikleri tekrar kullanılamıyor. com.example.app.wekly gibi bir yazım hatası kalıcı olur. Deneysel ürünlere ayrı ad alanı verin.

POST /v1/apps yok. Uygulama kaydı oluşturma adımı tarayıcıda yapılır. Görünürlük için kullandığınız 160 karakterlik metadata da ayrı bir hazırlık işi.

Buradaki akışta silme işlemi yok. Abonelik kaldırmak, abonesi olan bir ürün hakkında karar vermektir. Oluşturma işlemlerini geri alınabilir taslaklar gibi ele almayın.

İlk abonelik grubunu yeni bir uygulama sürümüyle birlikte göndermek de planınızı etkiler. Bu bağımlılığı her şeyi hazırladıktan sonra keşfetmek yerine baştan kontrol edin.

Birden fazla uygulama yayımlıyorsanız

Tek uygulamada kurulum bir öğleden sonrayı alabilir. Asıl maliyet dördüncü uygulamada ortaya çıkar. Her uygulama aynı ekranları, her dil mevcut ürünler için aynı yerelleştirme işini tekrar ettirir.

“Üç uygulamaya Almanca ekleyelim” tarayıcıda küçük bir değişiklik olmayabilir. Tekrarlanan ekranlar arasında fark çıktısı ve önceden inceleme imkânı yoktur.

İstenen durumu dosyada tanımlamak, Apple’daki mevcut durumla karşılaştırmak ve farkı uygulamak bu yüzden işe yarar. asc-subs bunu yapıyor: plan farkı gösteriyor, push o farkı uyguluyor, pull mevcut uygulamayı onu yeniden oluşturabilecek dosyaya dönüştürüyor. MIT lisanslı; çalışma zamanı bağımlılığı yok.

Aracı, birden fazla uygulamada bu işi elle tekrar ettiğim için geliştirdim. Yüzlerce yazma işlemi kaybolmuyor. Yalnızca her seferinde sizin dikkatinizi tüketen bir işe dönüşmekten çıkıyor.