(iOS + StoreKit) Czy mogę wykryć, kiedy jestem w piaskownicy?

Question

Mam zakupy w aplikacji działające bez zarzutu i wybieram trasę weryfikacji serwera. Serwer musi wiedzieć, czy jestem w piaskownicy, czy nie, więc na razie wysyłam tylko "& sandbox = 1" parametr. Oczywiście, gdy jest już dostępna pełna wersja aplikacji, nie będę wysyłał tego parametru.

Wolałbym nie mieć tego na twardym dysku w mojej aplikacji, ponieważ to spowoduje, że testowanie będzie trudne w przyszłości, i jest jeszcze jedna (duża) rzecz do zapamiętania, aby się zmienić przed przesłaniem kompilacji do Apple.

Czy istnieje sposób, w jaki mogę zapytać StoreKit, czy jestem w piaskownicy, abym mógł wtedy określić, czy muszę wysłać ten parametr do mojego serwera? Alternatywnie, czy istnieje jakaś inna najlepsza praktyka do obsługi sprawdzania poprawności serwera?

Myślisz o tym więcej, czy powinienem najpierw zawsze sprawdzić system na żywo, a następnie sandbox? Jeżeli identyfikatory jabłek są rozdzielone między systemami live i sandbox, czy nie byłoby to szkodliwe?

Dzięki.

Answer 1

Po trochę kopanie Znalazłem to z Apple Technical Note TN2259:

Jak mogę sprawdzić moje pokwitowanie (iOS)?

Zawsze najpierw sprawdź paragon z adresem produkcyjnym; przejdź do weryfikacji za pomocą adresu URL obszaru izolowanego, jeśli otrzymasz kod statusu 21007. Stosując to podejście, nie musisz przełączać się między adresami URL podczas testowania lub przeglądania aplikacji w piaskownicy lub na żywo w sklepie App Store.

Wygląda na to, że powinienem całkowicie zmieścić parametr &sandbox i po prostu to zrobić. Naprawdę musiałem szukać tej odpowiedzi, więc zamieszczam ją tutaj, mając nadzieję, że ktoś inny ją obejrzy!

Answer 2

Napotkałem ten sam problem, w którym moja aplikacja została odrzucona, ponieważ "produkcyjna" wersja mojej aplikacji, którą przedłożyłem, została zakodowana na stałe, aby połączyć się ze skryptem PHP na moim serwerze, który potwierdza wpływy prawdziwym serwerem AppStore (podczas gdy moja development build wskazuje na inny skrypt PHP, który waliduje paragony za pomocą serwera sandbox). Jednak po kilku wymianach z inżynierami Apple dowiedziałem się, że używają kont użytkowników w piaskownicy do testowania złożonych aplikacji, co tłumaczy, dlaczego dostali błąd.

Zamiast warunkowo budować moją aplikację, aby wskazywała na jeden lub drugi skrypt, użyję pojedynczego skryptu, który najpierw spróbuje serwera produkcyjnego, a następnie powróci do serwera piaskownicy, jeśli otrzyma kod statusu 21007, jak wyjaśniono powyżej !

Wielkie dzięki!

Answer 3

Zawsze najpierw sprawdź paragon z adresem produkcyjnym; przejdź do weryfikacji za pomocą adresu URL obszaru izolowanego, jeśli otrzymasz kod statusu 21007.

Niestety, notatka techniczna nie wspomina o tym, że jest ważna tylko w przypadku subskrypcji automatycznego odnawiania!

Jako In-App Purchase Programming Guide wspomina poniżej tabeli 7-1:

Ważne niezerowych kody stanu tutaj zastosowanie tylko podczas odzyskiwania informacji o subskrypcji automatycznego przedłużenia. Nie używaj tych kodów statusu podczas testowania odpowiedzi na inne produkty.

W przypadku nieodnawialnych subskrypcji serwer produkcyjny nie zwraca kodu statusu, ale prawidłowy odbiór.

Jeśli jesteś zmuszony do używania nieodnawialnych wersji i możesz wdrożyć własną logikę utraty ważności subskrypcji, możliwe jest wysłanie wersji aplikacji na serwer i śledzenie, które wersje są obecnie rozwijane, możesz przekierować na serwer sandbox.itunes, aby zweryfikować pokwitowania w stosownych przypadkach i naśladować czas wygaśnięcia x-minut subskrypcji (tak jak sandbox.itunes ma na celu automatyczne odnawianie) do rozwoju na twoim serwerze.