Apple ile Giriş Zorunlu mu? Guideline 4.8 Reddi ve Çözümü

Ret mesajını yeni aldıysanız önce sakin kalın, çünkü bu ret genellikle kodun birkaç gününü alan, çözümü belli bir sorundur. Aşağıdaki sırayı izlerseniz hem düzeltmeyi hem de yanıtı tek turda toparlarsınız.

1. Ret mesajındaki guideline numarasının 4.8 olduğunu ve hangi ekranı işaret ettiğini not edin.
2. Uygulamanızdaki tüm giriş ve kayıt yollarını listeleyin: e-posta, Google, Facebook, telefon numarası ve diğerleri.
3. Uygulamanızın aşağıdaki muafiyetlerden birine girip girmediğini dürüstçe kontrol edin.
4. Muafiyet yoksa Apple ile giriş ya da üç gizlilik özelliğini karşılayan başka bir servis ekleyin.
5. Yeni düğmeyi diğer giriş düğmeleriyle aynı ekranda ve en az onlar kadar görünür konumlandırın.
6. Yeni derlemeyi yükleyin ve inceleme yazışmasında neyi değiştirdiğinizi kısa ve net anlatın.

Bu yazı yalnızca 4.8 reddine odaklanıyor. Genel ret nedenlerinin geniş bir dökümü için uygulamanızın neden reddedildiğini anlatan rehberimize bakabilirsiniz.

Guideline 4.8 metni tam olarak ne istiyor?

Kuralın yürürlükteki metnini Apple App Review Guidelines sayfasında bulursunuz. Metne göre üçüncü taraf ya da sosyal bir giriş servisiyle kullanıcının birincil hesabını kuran veya doğrulayan uygulama, eşdeğer bir seçenek olarak başka bir giriş servisi de sunmalı. Örnek olarak Facebook Login, Google Sign-In, Log in with X, Sign In with LinkedIn, Login with Amazon ve WeChat Login sayılıyor.

Eklediğiniz ikinci servis ise şu üç özelliğin hepsini taşımalı:

• Veri toplamayı kullanıcının adı ve e-posta adresiyle sınırlar.
• Kullanıcıya hesap kurarken e-posta adresini gizli tutma imkânı verir.
• Uygulamanızdaki etkileşimleri izin almadan reklam amacıyla toplamaz.

Dikkat ederseniz metin Apple ile giriş adını doğrudan zorunlu tutmuyor; özellik tanımlıyor. Kuralın eski hâli Sign in with Apple seçeneğini adıyla istiyordu, güncel metin ise üç ölçütü karşılayan herhangi bir servise kapı açıyor. Bununla birlikte, bu üç ölçütü bugün en net biçimde karşılayan seçenek yine Sign in with Apple. Kural zaman içinde değiştiği için güncel metni her zaman resmi sayfadan kontrol edin.

Birincil hesap ne demek ve neden önemli?

Apple, birincil hesabı kullanıcının kendini tanıtmak, oturum açmak ve uygulamanızın özelliklerine ve ilişkili hizmetlerine erişmek için uygulamanızda kurduğu hesap olarak tanımlıyor. Yani kural, uygulamanın ana kapısını ilgilendiriyor.

Örneğin bir fotoğraf düzenleme uygulaması düşünün. Kullanıcı Google ile kaydolup kendi projelerine erişiyorsa bu Google girişi birincil hesabı kuruyor; dolayısıyla 4.8 devreye giriyor. Öte yandan aynı uygulama yalnızca "fotoğrafı Google Drive'a kaydet" işlevi için Google bağlantısı istiyorsa bu bağlantı birincil hesap değil, bir entegrasyon sayılıyor.

Bu ayrımı netleştirmek yanıtınızı da güçlendirir. İnceleme ekibine "Google bağlantısı yalnızca dosya aktarımı içindir, hesap oluşturmaz" gibi somut bir açıklama yazabilirsiniz. Ancak bu açıklamanın uygulamadaki gerçek akışla birebir örtüşmesi gerekir; aksi halde ikinci incelemede aynı ret tekrar gelir.

Hangi uygulamalar Guideline 4.8'den muaf?

Resmi metin, ek giriş servisinin gerekmediği beş durumu sayıyor. Kendi uygulamanızın bunlardan birine girdiğini düşünüyorsanız gerekçeyi bu maddelere dayandırın:

• Uygulamanız yalnızca şirketinizin kendi hesap kurma ve giriş sistemini kullanıyor.
• Uygulamanız alternatif bir uygulama pazarı ya da böyle bir pazardan dağıtılan bir uygulama ve hesap, indirme ve ticaret için pazara özgü bir giriş kullanıyor.
• Uygulamanız, kullanıcının mevcut bir eğitim veya kurumsal hesapla giriş yapmasını şart koşan bir eğitim, kurumsal ya da iş uygulaması.
• Uygulamanız kullanıcıyı devlet ya da sektör destekli bir vatandaş kimlik sistemi veya elektronik kimlikle doğruluyor.
• Uygulamanız belirli bir üçüncü taraf hizmetin istemcisi ve kullanıcı içeriğine erişmek için doğrudan e-posta, sosyal medya ya da benzeri hesabına giriş yapmak zorunda.

Pratikte en çok yanlış anlaşılan madde birincisi. "Yalnızca" kelimesi burada belirleyici; kendi sisteminizin yanına tek bir Google düğmesi eklediğiniz anda bu muafiyetten çıkarsınız.

Kendi e-posta ve şifre sisteminiz tek başına yeterli mi?

Uygulamanızda yalnızca kendi e-posta ve şifre kaydınız varsa ek bir servis eklemenize gerek yok. Sorun, kendi sisteminizin yanında bir sosyal giriş sunduğunuzda başlıyor.

Bu durumda pek çok ekip "zaten e-postayla kayıt seçeneği var, eşdeğer seçenek o" diye düşünüyor. Ancak resmi metin, eşdeğer seçeneği üç gizlilik özelliğine sahip "başka bir giriş servisi" olarak tarif ediyor ve kendi e-posta formunuzun bu tarife girip girmediğini açıkça söylemiyor. Bu nedenle bu savunmanın kabul edileceğine dair güvenilir bir dayanak yok.

Bizim önerimiz şu: tartışmaya girmek yerine Apple ile giriş eklemek çoğu projede daha kısa yol. Böylece hem ret döngüsünden çıkarsınız hem de kullanıcıya şifre gerektirmeyen bir seçenek sunarsınız. Ayrıca kendi e-posta kaydınızı kaldırmanız gerekmiyor; üç seçenek yan yana durabilir.

Eğer yine de kendi akışınızın şartı karşıladığını savunacaksanız, üç özelliği tek tek nasıl sağladığınızı yazılı olarak açıklamaya hazır olun. Yine de sonucun inceleme ekibinin yorumuna bağlı olduğunu unutmayın.

Hangi giriş seçenekleri 4.8 şartını karşılar?

Aşağıdaki tablo, sık kullanılan giriş yollarını kuralın gözüyle karşılaştırıyor. Tablo bir yorumdur; kesin karar her zaman inceleme ekibindedir.

Tablodaki en riskli satır dördüncüsü. Özellikle küçük ekipler bu kombinasyonla yayına çıkıyor ve ilk incelemede ret görüyor.

Apple ile giriş eklemek neden genellikle en kısa yol?

Teoride üç ölçütü karşılayan başka bir servis de seçebilirsiniz. Ancak bir servisin bu ölçütleri karşıladığını kanıtlamak sizin sorumluluğunuzda kalır. Sign in with Apple ise e-postayı gizleme seçeneğini zaten kullanıcıya sunduğu için inceleme ekibinin ek açıklama istemesi daha az olası.

Üstelik iOS tarafında entegrasyon sistem çerçevesiyle geliyor. Kullanıcı Face ID veya cihaz parolasıyla tek dokunuşta hesap açıyor; dolayısıyla kayıt formunu doldurmadan uygulamaya giriyor. Bu da kayıt adımındaki kaybı azaltmanıza yardımcı olabilir.

Öte yandan entegrasyonun sunucu tarafı, gizli e-posta aktarımı ve hesap silme akışı gibi ayrıntıları var. Bu parçaları ilk seferde doğru kurmak zaman alıyor ve bir eksiklik yeni bir ret nedeni olabiliyor. Ekibinizde bu deneyim yoksa mobil uygulama geliştirme desteğiyle giriş akışını baştan sona birlikte ele alabiliriz. Eğer altyapıyı kendiniz kuracaksanız, sonraki bölümler hangi noktalara dikkat etmeniz gerektiğini sırasıyla anlatıyor.

Apple ile giriş düğmesini nereye ve nasıl koymalısınız?

Apple'ın Sign in with Apple tasarım yönergeleri düğme için açık kurallar koyuyor. Düğmeyi belirgin gösterin, diğer giriş düğmelerinden küçük yapmayın ve kullanıcıyı onu görmek için kaydırmaya zorlamayın.

• Düğme metni olarak yalnızca "Sign in with Apple", "Sign up with Apple" ya da "Continue with Apple" ifadelerini kullanın.
• Görünüm için siyah, beyaz ve kenarlıklı beyaz seçeneklerinden arka planınıza uyanı seçin.
• Siyah düğmeyi koyu arka planda, beyaz düğmeyi ise kontrastı yetersiz açık zeminde kullanmayın.
• Seçtiğiniz metin varyantını tüm giriş ve kayıt ekranlarında tutarlı biçimde uygulayın.

Uygulamada en sık gördüğümüz hata, Apple düğmesini "diğer seçenekler" menüsünün altına saklamak. Örneğin Google düğmesi tam genişlikte dururken Apple seçeneği küçük bir ikon olarak kalıyorsa inceleme ekibi bunu eşdeğer sunum saymayabilir. Bu yüzden iki düğmeyi aynı boyutta ve aynı ekranda alt alta yerleştirin.

Ad ve e-posta bilgisini nasıl istemelisiniz?

Apple ile giriş akışında ad ve e-posta kapsamlarını isteyebilirsiniz. Kullanıcı ise adını düzenleyebilir, farklı bir iletişim e-postası seçebilir ya da e-postasını gizleyebilir. Gizlemeyi seçerse Apple, iletileri kullanıcının gerçek adresine yönlendiren benzersiz bir aktarma adresi üretir.

Tasarım yönergeleri bu tercihe saygı duymanızı açıkça istiyor. Yani kullanıcı aktarma adresini paylaştıktan sonra ondan kişisel e-postasını istemeyin. Ayrıca şifre de istemeyin, çünkü yöntemin temel faydası kullanıcının yeni bir şifre oluşturmak zorunda kalmamasıdır.

• Doğum tarihi gibi ek veri gerekiyorsa isteği en aza indirin ve zorunlu mu, isteğe bağlı mı olduğunu belirtin.
• İsteğe bağlı bilgiyi vermeyen kullanıcının hesabına ve özelliklere erişimini engellemeyin.
• Ad ve e-posta bilgisini aldığınız anda sunucunuzda güvenle saklayın; sonraki girişlerde bu bilgiye yeniden ulaşamayabilirsiniz.

Son madde pratikte çok önemli. Geliştirici topluluğunda yaygın deneyim, bu bilgilerin genellikle yalnızca ilk yetkilendirmede gelmesi. Bu nedenle ilk yanıtı kaydetmeyen bir sunucu, kullanıcıyı isimsiz bir hesapla bırakabilir.

Gizli e-posta aktarma servisini nasıl ayarlarsınız?

Kullanıcı e-postasını gizlediğinde size aktarma adresi gelir. Bu adrese sipariş onayı ya da şifre dışı bildirim göndermek istiyorsanız Apple tarafında hazırlık yapmanız gerekir. Apple'ın gizli e-posta aktarma servisi yardım sayfasına göre gönderim yaptığınız her alan adını veya alt alan adını kaydetmeli ve doğrulamalısınız.

1. Uygulamanızın e-posta gönderdiği tüm alan adlarını ve alt alan adlarını listeleyin.
2. Bu kaynakları Apple Developer hesabınızdaki ilgili bölümden kaydedin.
3. Giden e-postaları SPF ve mümkünse DKIM ile doğrulayın; Apple ikisini birlikte kullanmayı öneriyor.
4. Gönderen alan adının kayıtlı alan adıyla birebir eşleştiğini kontrol edin.
5. Test hesabıyla aktarma adresine bir ileti gönderip ulaşıp ulaşmadığını doğrulayın.

Kaynaklardan birini kaydetmeyi unutursanız aktarma adresine giden iletiler geri döner. Örneğin pazarlama e-postalarını ayrı bir alt alan adından gönderiyorsanız onu da ayrıca eklemelisiniz. Bu adım doğrudan 4.8 reddine neden olmaz, ancak kullanıcı deneyimini bozar ve destek taleplerini artırır.

Hesap silmede Apple ile giriş belirteçleri ne olur?

Hesap oluşturmayı destekleyen uygulamalar, kullanıcıya uygulama içinden hesap silme imkânı da sunmak zorunda. Bu kuralın ayrıntılarını Apple'ın zorunlu hesap silme kuralı yazımızda anlattık; burada yalnızca Apple ile giriş ayağına değiniyoruz.

Apple'ın hesap silme rehberindeki sık sorulan sorulara göre Sign in with Apple kullanan uygulamalar, hesap silindiğinde Sign in with Apple REST API üzerinden kullanıcı belirteçlerini iptal etmeli. Ayrıca hesaplardaki değişiklikleri işlemek için sunucudan sunucuya bildirim uç noktalarını kullanmanız öneriliyor.

Dolayısıyla Apple ile giriş eklerken silme akışını da birlikte planlayın. Sunucunuz, iptal işlemi için gereken belirteçleri giriş sırasında güvenle saklamalı. Aksi halde silme düğmesine basan kullanıcının Apple tarafındaki yetkisi açık kalabilir ve bu durum ikinci bir ret nedeni olabilir.

Uygulama açılışında kimlik durumunu neden kontrol etmelisiniz?

Kullanıcı, Apple hesabı ayarlarından uygulamanızın erişimini istediği zaman kaldırabilir. Apple'ın örnek kodu bu nedenle uygulama açılırken kayıtlı kullanıcı kimliğinin durumunu sorguluyor.

Durum yetkili ise uygulama normal akışına devam ediyor. Yetki kaldırılmışsa ya da kimlik bulunamıyorsa uygulama giriş ekranını yeniden gösteriyor. Böylece erişimi kaldırılmış bir kullanıcı eski oturumla içeride kalmıyor.

İnceleme sırasında bu kontrolün eksikliği her zaman ret nedeni olmaz. Yine de inceleme ekibinin test cihazında beklenmedik bir oturum davranışı görmesi, "uygulama düzgün çalışmıyor" türünde ayrı bir geri bildirime yol açabilir. Bu tür eksiklik ve tamamlanmamışlık retleri için Guideline 2.1 reddi yazımıza göz atabilirsiniz.

Apple ile giriş başka platformlarda nasıl ele alınmalı?

Birçok uygulama iOS, Android ve web üzerinde aynı hesap sistemini paylaşıyor. Bu durumda iOS'ta Apple hesabıyla kaydolan kullanıcının diğer platformlarda hesabına nasıl ulaşacağını önceden düşünmelisiniz.

Apple, web için de Sign in with Apple akışı sunuyor; ancak bu akışın kurulum ayrıntılarını Apple Developer belgelerinden ayrıca kontrol etmeniz gerekiyor. Ayrıca kullanıcı e-postasını gizlediyse, diğer platformda e-postayla eşleştirme yapmanız mümkün olmayabilir. Bu yüzden hesapları e-posta yerine Apple'ın verdiği kalıcı kullanıcı kimliğiyle eşleştirmeyi tercih edin.

Örnek senaryo: React Native ile tek kod tabanından iki platforma çıkan bir ekip, Android tarafında Apple girişini hiç planlamamış olabilir. Böyle bir durumda iOS'ta kaydolan kullanıcı Android'de hesabına giremez. Ortak kod tabanı yaklaşımının artılarını ve eksilerini React Native rehberimizde ele aldık. Android'deki politika süreçleri için ise Google Play politika ihlali yazımız yol gösterir.

Guideline 4.8 reddine nasıl yanıt vermelisiniz?

Ret mesajına yanıtı App Store Connect'teki inceleme yazışması üzerinden verirsiniz. Yanıtın amacı, inceleme ekibinin değişikliği hızlıca doğrulamasını sağlamaktır. Bu nedenle uzun savunmalar yerine kısa, somut ve test edilebilir bilgiler yazın.

1. Önce kodu düzeltin ve yeni bir derleme yükleyin; yalnızca mesajla yanıt vermek çoğu durumda yetmez.
2. Yanıtta hangi giriş seçeneğini eklediğinizi ve hangi ekranda bulunduğunu belirtin.
3. Gerekirse ekran görüntüsü ya da kısa bir ekran kaydı ekleyin.
4. İnceleme notlarında test hesabının bilgilerini güncel tutun.
5. Muafiyet iddia ediyorsanız hangi maddeye dayandığınızı açıkça yazın.

Örnek yanıt şu çizgide olabilir: "Giriş ekranına Google girişiyle aynı boyutta Sign in with Apple düğmesi ekledik. Yeni derlemede ilk açılışta iki seçenek alt alta görünüyor." Bu kadar kısa bir açıklama, uzun bir metinden çoğu zaman daha işe yarar.

Muafiyet iddia ediyorsanız ne yazmalısınız?

Uygulamanız gerçekten muafiyet kapsamındaysa kod değiştirmeden yanıt verebilirsiniz. Ancak bu yanıtın kanıta dayanması gerekir.

Örneğin kurumsal bir uygulama geliştiriyorsanız kullanıcıların yalnızca şirketin mevcut kurumsal hesabıyla giriş yapabildiğini, uygulama içinde bireysel kayıt olmadığını yazın. Benzer biçimde e-kimlik kullanan bir uygulamada hangi kimlik sisteminin kullanıldığını belirtin. Üçüncü taraf hizmet istemcisi olan bir uygulamada ise kullanıcının içeriğe ancak o hizmetin hesabıyla erişebildiğini anlatın.

İnceleme ekibi açıklamanızı yeterli bulmazsa iki yolunuz kalır: değişikliği yapmak ya da Apple'ın resmi itiraz kanalı olan App Review Board'a başvurmak. İtirazın da bir garantisi yok; kararı Apple veriyor. Bu yüzden itiraz metninde yalnızca doğrulanabilir bilgileri kullanın ve kuralın resmi metnine atıf yapın.

Apple ile giriş entegrasyonunda en sık hangi hatalar yapılıyor?

Ekiplerin ret sonrasında aceleyle yaptığı entegrasyonlarda bazı hatalar tekrar tekrar karşımıza çıkıyor. Aşağıdaki listeyi yeni derlemeyi göndermeden önce kontrol listesi olarak kullanabilirsiniz:

• Apple düğmesini yalnızca kayıt ekranına koyup giriş ekranında unutmak.
• Apple ile giriş yaptıktan sonra kullanıcıdan yine de şifre ya da kişisel e-posta istemek.
• İlk yetkilendirmede gelen ad ve e-postayı sunucuda saklamamak.
• Gizli e-posta aktarma servisi için gönderim alan adlarını kaydetmemek.
• Hesap silme akışında Apple belirteçlerini iptal etmemek.
• Düğme metnini "Apple ile bağlan" gibi yönergelerde olmayan bir ifadeyle değiştirmek.
• Uygulama açılışında kimlik durumunu kontrol etmemek.

Bu hataların bir kısmı doğrudan 4.8 kapsamında değil. Yine de aynı inceleme turunda farklı bir guideline ile ret almanıza yol açabilir; dolayısıyla hepsini tek seferde düzeltmek zaman kazandırır.

Apple ile giriş gizlilik etiketlerini ve veri toplamayı nasıl etkiler?

Apple ile giriş eklediğinizde topladığınız veri türleri değişebilir. Örneğin kullanıcının adı ve e-postası artık bu kanal üzerinden de geliyor. Bu nedenle App Store gizlilik etiketlerinizi yeni akışa göre gözden geçirin.

Etiketlerin nasıl doldurulacağını adım adım App Store gizlilik etiketleri rehberimizde anlattık. Ayrıca kayıt sırasında gereğinden fazla bilgi istemek, 4.8'den bağımsız olarak veri toplama kuralıyla da çakışabilir. Bu konudaki ret türünü Guideline 5.1.1 veri toplama reddi yazımızda ele aldık.

Kısacası giriş akışını değiştirdiğinizde yalnızca düğmeyi değil, gizlilik beyanlarınızı ve kayıt formunuzu da birlikte güncelleyin. Böylece bir reddi çözerken başka bir ret nedeni yaratmamış olursunuz.

Kuralı atlatmaya çalışmak neden risklidir?

Bazı ekipler reddi aşmak için Google düğmesini inceleme süresince gizlemeyi ya da sosyal girişi yalnızca belirli bölgelerde açmayı düşünüyor. Bu tür yöntemler inceleme ekibini yanıltmaya yönelik davranış sayılabilir ve ret yerine daha ağır yaptırımlarla sonuçlanabilir.

Benzer şekilde aynı uygulamayı farklı bir geliştirici hesabından yeniden göndermek de çözüm değil. Apple'ın inceleme kuralları, inceleme sürecini kandırmaya yönelik girişimleri ciddi ihlal olarak görüyor; bu yüzden böyle bir deneme sorunu hesap düzeyine taşıyabilir. Tekrarlanan gönderimlerin yol açtığı ret türü için Guideline 4.3 spam reddi yazımıza bakabilirsiniz.

En güvenli yol, kuralın amacını kabul edip gerçek bir eşdeğer seçenek sunmak. Bu yaklaşım hem inceleme sürecini kısaltıyor hem de kullanıcıya gerçekten daha gizli bir giriş yolu veriyor.

Passkey ve OAuth gibi yöntemler bu kuralla nasıl ilişkilenir?

Sosyal girişlerin çoğu arka planda OAuth 2.0 ve OpenID Connect gibi standartlara dayanıyor. Bu standartların temel mantığını OAuth 2.0 rehberimizde anlattık. Sign in with Apple da benzer bir yetkilendirme akışı kullanıyor, ancak 4.8 açısından önemli olan teknik standart değil, servisin üç gizlilik özelliğini sağlayıp sağlamadığı.

Passkey ise şifresiz giriş için kullanılan bir doğrulama yöntemi. Kendi hesap sisteminizde passkey kullanmak, sisteminizi üçüncü taraf bir giriş servisine dönüştürmüyor. Dolayısıyla yalnızca kendi sisteminiz ve passkey varsa muafiyetin birinci maddesi geçerli kalır. Konuyu passkey nedir yazımızda ayrıntılı bulabilirsiniz.

Öte yandan kendi sisteminize passkey ekleyip aynı ekranda bir Google düğmesi de tutuyorsanız durum değişir. Bu durumda sosyal giriş yine birincil hesap açtığı için 4.8 şartı geçerli olur ve eşdeğer gizlilik odaklı seçeneği eklemeniz gerekir.

Yeni derlemeyi göndermeden önce neleri kontrol etmelisiniz?

Gönderim öncesinde aşağıdaki kısa kontrol listesini ekipçe gözden geçirin. Bu liste, 4.8 reddini ikinci kez almamanız için hazırlandı:

• Sosyal giriş sunan her ekranda Apple seçeneği ya da eşdeğer seçenek görünüyor.
• Apple düğmesi diğer düğmelerden küçük değil ve kaydırmadan görülebiliyor.
• Kayıttan sonra şifre veya kişisel e-posta istenmiyor, ek bilgi isteğe bağlı.
• Aktarma adresine e-posta gönderimi test hesabıyla doğrulandı.
• Hesap silme akışı Apple belirteçlerini iptal ediyor.
• Gizlilik etiketleri yeni giriş akışına göre güncellendi.
• İnceleme notlarında test hesabı ve değişiklik açıklaması güncel.

Bu maddelerin hepsine "evet" diyebiliyorsanız yanıtınızı gönderebilirsiniz. Ardından inceleme sonucunu bekleyin ve yeni bir geri bildirim gelirse aynı sakinlikle tek tek ele alın.

Mevcut Google kullanıcılarının hesaplarını nasıl korursunuz?

Uygulamanız bir süredir yayındaysa elinizde Google ya da Facebook ile kaydolmuş kullanıcılar vardır. Sign in with Apple eklediğinizde bu kişilerin bir kısmı yanlışlıkla yeni düğmeye basıp ikinci, boş bir hesap açabilir. Bu da destek taleplerini ve kullanıcı şikâyetlerini artırır.

Bu riski azaltmak için birkaç önlem alabilirsiniz. Öncelikle giriş ekranında kullanıcıya hangi yöntemle kaydolduğunu hatırlatan kısa bir metin gösterin. Ardından hesap ayarlarına "giriş yöntemi bağla" türünde bir seçenek ekleyin; böylece oturum açmış bir kullanıcı Apple hesabını mevcut hesabına bağlayabilir.

Ancak hesapları yalnızca e-posta adresi eşleşiyor diye otomatik birleştirmeyin. Kullanıcı aktarma adresi paylaştıysa eşleşme zaten olmaz; gerçek adres paylaşıldığında bile otomatik birleştirme güvenlik açığı yaratabilir. Bu yüzden bağlama işlemini her zaman oturum açmış kullanıcının bilinçli onayıyla yapın.

Sign in with Apple akışını nasıl test etmelisiniz?

İnceleme ekibi uygulamanızı gerçek bir cihazda ve kendi Apple hesabıyla deneyebilir. Bu nedenle yalnızca simülatörde değil, fiziksel cihazda da uçtan uca test yapın. Özellikle ilk kayıt, çıkış yapıp tekrar giriş, e-postayı gizleme ve hesap silme senaryolarını ayrı ayrı deneyin.

1. Yeni bir test Apple hesabıyla ilk kaydı yapın ve ad ile e-postanın sunucuya ulaştığını doğrulayın.
2. Aynı hesapla çıkış yapıp tekrar girin ve yeni bir hesap açılmadığını kontrol edin.
3. E-postayı gizleme seçeneğiyle kaydolun ve aktarma adresine test iletisi gönderin.
4. Cihaz ayarlarından uygulamanın Apple erişimini kaldırın ve uygulamanın giriş ekranına döndüğünü görün.
5. Uygulama içinden hesabı silin ve belirteç iptalinin sunucu kayıtlarında göründüğünü kontrol edin.

Android sürümünü de aynı dönemde yayına hazırlıyorsanız, orada da test sürecinin kendine özgü şartları var. Örneğin yeni kişisel hesaplar için kapalı test şartını Google Play kapalı test yazımızda anlattık.

Ne zaman profesyonel destek almalısınız?

Basit bir uygulamada Apple ile giriş eklemek birkaç günlük iş olabilir. Ancak birden fazla platform, mevcut kullanıcı tabanı, hesap birleştirme ve e-posta altyapısı devreye girdiğinde iş büyüyor. Özellikle mevcut Google kullanıcılarının hesaplarını bozmadan yeni bir giriş yolu eklemek dikkatli planlama istiyor.

Ekip olarak bu tür ret süreçlerinde önce akışı birlikte haritalıyor, ardından hangi parçanın gerçekten değişmesi gerektiğini belirliyoruz. Hiçbir zaman "kesin onaylatırız" demiyoruz, çünkü kararı Apple veriyor; ancak kuralın gerektirdiği her parçanın eksiksiz kurulmasını sağlayabiliriz. Giriş akışınızı, hesap silmeyi ve inceleme yanıtınızı birlikte ele almak isterseniz uygulama geliştirme hizmeti sayfamızdan bize ulaşabilirsiniz.