IAP im Apple Review wirft Fehler

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • IAP im Apple Review wirft Fehler

    Moin zusammen,

    ich versuche gerade, meine aktuelle App durch das Review zu bekommen. Neben einem Problem mit dem IAP hat Apple die App nun zurückgewiesen: "Your app contains references to test, trial, demo, beta, pre-release or other incomplete content". Klar, warum auch nicht: Es ist eine Freemium-App, die dem potentiellen Käufer Beispiel-Daten bietet, damit dieser leichter testen kann. Angeblich würde dies gegen die Guidelines 2.2 verstossen. Dort steht aber nur:

    Apple Store Guidelines schrieb:

    Demos, betas, and trial versions of your app don’t belong on the App Store – use TestFlight instead.
    Also ist von der App selber die Rede, nicht von Beispiel-Content. Ich werde wohl in den Daten "Demo" gegen "Sample" austauschen und die - sechzehn? - Screenshots neu machen, um endlose Diskussionen zu vermeiden. Ach ja, überflüssig zu sagen, dass ich eine andere App haben, die auch Beispieldaten unter dem Titel "Demo" beinhaltet ... seit Jahren und x Reviews ohne Probleme.

    Ergo: Apple Reviewer kennen ihre eigenen Richtlinien nicht und die Abnahmekriterien sind willkürlich.

    Mattes, genervt und jetzt IAP am Debuggen...
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • So, ich habe der Ablehnung bzgl. "Demo Content" nun mit o. g. Begründung widersprochen.

    Ausserdem kann ich die IAP-Problematik beim besten Willen nicht nachvollziehen - weder mit Sandbox-User im Debug-Mode, noch mit meinem Account per TestFlight. Das Problem scheinen die letzten Tage mehrere zu haben, siehe Apple Developer Foren.
    Ich habe hier um einen erneuten Test und nähere Informationen gebeten, sonst habe ich keine gute Idee zum Debuggen mehr. Mist, das kostet nun wieder Zeit ... ich hab's zwar nicht eilig, aber dieses Hin-und-her mit dem Review-Team nervt einfach.

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • Ja, der ReviewProzess... hatte ein Kontakt-Tagebuch programmiert. Darf es nicht veröffentlichen. Nur als Gesundheitsorganisation, weil es ja COVID19 relevante Daten sind... dann hiess es, geht doch, wenn ich alle COVID-Bezüge entferne. Gesagt getan. Abgelehnt. Aus Spass habe ich alle großen Krankenkassen angeschrieben, sowie diverse Gesundheitsministerien. Leider allesamt unbeantwortet. Dann habe ich Apple nochmal gefragt, aber erneut: Nein.

    So ist das halt ... aber definitiv gibt es immer wieder Reviewer, die einfachh gar nicht gucken, w as man da so einreicht, sondern wie schon angedeutet auf einzelne Worte anspringen :(

    Viel Erfolg!
    volker
  • Der IAP-Kram macht mir mehr Sorgen. Eben noch einmal Code reviewed und getestet: Datt klappt ... Keine Ahnung, was die Reviewer für eine Umgebung haben. Mich machen einfach die Beiträge im Developer-Forum nervös, zumal ich vor ein paar Wochen auch Hickups während der Entwicklung hatte, die dann wie magisch ohne Code-Änderungen verschwanden.

    Meiner Meinung dreht Apple am IAP-Backend und dann klemmt die Sandbox manchmal. Mist, wenn das beim Review geschieht.

    Aber vielleicht habe ich doch einen Bock geschossen, dann brauche ich aber mehr Infos und nicht nur ein Screenshot, der zeigt, dass die Transaktion "An unknown error occurred" vom Store-Backend bekommt.

    Wenn ich nur nicht so ungeduldig wäre, Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • MCDan schrieb:

    Hast Du vielleicht ein finishTransaction: bei einer SKPaymentTransaction mit transactionState = SKPaymentTransactionStateFailed vergessen?
    Bin sofort losgerannt, um nachzusehen, aber ... doch, habe ich:

    Quellcode

    1. case SKPaymentTransactionStateFailed:
    2. {
    3. if (transaction.error.code == SKErrorPaymentCancelled)
    4. {
    5. DebugLog(@"Transaction cancelled: %@ (%@)", @(transaction.transactionState), transaction.error);
    6. }
    7. else
    8. {
    9. DebugLog(@"Transaction failed: %@ (%@)", @(transaction.transactionState), transaction.error);
    10. dispatch_async(dispatch_get_main_queue(),
    11. ^{
    12. [[[STSGlobalAlertController alloc] initWithError:transaction.error] showAndAbort:FALSE];
    13. });
    14. }
    15. [queue finishTransaction:transaction];
    16. break;
    17. }
    Alles anzeigen
    Trotzdem Danke, es ist auf jeden Fall eine der zwei Stellen, an welcher der Reviewer den Fehlerdialog mit o. g. Meldung angezeigt bekommen könnte ... die andere ist request:didFailWithError:.

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • MCDan schrieb:

    Ich prüfe einfach vor einem addPayment: in [SKPaymentQueue defaultQueue] ob es ggf. transactions mit transactionState = SKPaymentTransactionStateFailed gibt und rufe dann einfach finishTransaction: auf.
    Das habe ich nun auch implementiert, obwohl ja eigentlich der transactionObserver diese Transaktionen mit der o. g. Routine abhandeln würde. Im Sandbox-Test habe ich vor einem IAP auch keine fehlgeschlagenen Transaktionen mehr in der paymentQueue ... aber bei mir klappt's ja auch.

    Allerdings ist mir etwas anderes interessantes aufgefallen: Falls ein IAP unterbrochen wird (z. B. AGB-Änderungen), wird erst einmal eine Transaktion im Status SKPaymentTransactionStateFailed geschickt, erst nach Akzeptieren der neuen Bedingungen kommt eine weitere Transaktion mit SKPaymentTransactionStatePurchased. So weit, so gut und erwartet. Aber: Das error-Objekt der ersten Transaktion ist ein unbekannter Fehler Error Domain=SKErrorDomain Code=0 "Ein unbekannter Fehler ist aufgetreten" ... während das underlyingError-Objekt die Infos bzgl. AGB-Änderung enthält.

    Bisher zeigte ich immer den Haupt-Fehler an, das würde die nicht sprechende Meldung beim Reviewer erklären - was auch immer bei ihm los ist. Nun habe ich meinen globalen Error-Dialog so geändert, dass er nach einem underlyingError schaut ... vielleicht werde ich so schlauer

    Quellcode

    1. NSDictionary *userInfo = error.userInfo;
    2. NSError *underlyingError = [userInfo objectForKey:NSUnderlyingErrorKey];
    3. if (underlyingError)
    4. {
    5. error = underlyingError;
    6. NSLog(@"Found underlying error: %@", error);
    7. }
    Nun noch viele Log-Ausgaben eingefügt und hoffen auf's nächste Review, Mattes

    P.S.: Habe den Titel des Postings sprechender gemacht, da es nun doch mehr um IAP als meinen allgemeinen Frust geht.
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • Endlich: "Ready for Sale"... :)

    Was habe ich geändert:
    1. Ein finishTransaction für evt. fehlgeschlagene Transaktionen vor einem In-App-Purchase ... sollte nicht vorkommen können, aber wer weiß.
    2. Sprechendere Fehlermeldungen durch Nutzung des underlyingError ... vielleicht hatte der Reviewer ja einen dieser Fälle, auf jeden Fall eine gute Idee, aber keine echte Fehlerbehebung.
    3. NSLog-Ausgaben, um im Falle einer Ablehnung wenigstens etwas zum Analysieren zu haben - das macht 100% keinen Unterschied.
    4. Eine Nachfrage, ob - falls kein Receipt gefunden wird - ein Refresh (mit eventuellem Passwort-Prompt) durchgeführt werden soll. Bisher habe ich das immer ungefragt gemacht, zumal dieser Fall nur bei Ausführen in Xcode oder TestFlight auftreten dürfte. Aber Apple's TN 2413 empfiehlt hier eine Nachfrage und gemäß Apple Developer Forum hatte ein Entwickler ziemlich Stress deswegen. Übrigens kann ich besagte TN nur empfehlen...
    Also wie ihr seht nichts, was wirklich ein Fehlverhalten der App behoben hätte. Entweder ist es wirklich ein Problem bei Apple gewesen, das nun nicht mehr auftritt, oder der Reviewer hat anhand sprechender Meldungen besser reagieren können oder es ist einfach ein anderer Reviewer mit anderen Maßstäben / einem anderen Environment.

    Egal, ich freue mich, dass der Spuk - bis zum nächsten Update - vorbei ist. Vom "Demo-Problem" war übrigens nach meinem Einspruch keine Rede mehr - ob deshalb oder weil es einfach "unterging", kann ich nicht sagen.

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.