35 Stimmen

Checkliste für die Vorabversion vor der Erstellung der endgültigen Version für den App Store

Sind Sie neugierig, welche Praktiken die Leute gelernt haben, bevor sie ihre endgültige Version erstellen und beim App Store einreichen? Abgesehen von der Umstellung von Debug auf Release und dem Auskommentieren von Aufrufen zu NSLog, welche anderen grundlegenden und/oder nicht so grundlegenden Dinge sollten wir im Auge behalten?

31voto

progrmr Punkte 73486

Dies ist eine gute Frage, und ich möchte einige der Antworten wiederholen und einige meiner eigenen hinzufügen. Ich habe diese Antwort zu einem Gemeinschafts-Wiki gemacht, Sie können sie gerne ergänzen.

  1. Löschen Sie die App von Ihrem Gerät, schalten Sie WiFi und Mobilfunkdaten aus, installieren und testen Sie die App. Funktioniert sie ordnungsgemäß (so weit wie möglich ohne Internet)? Weist sie den Benutzer zumindest darauf hin, dass eine Netzwerkverbindung erforderlich ist (falls dies der Fall ist), oder stürzt sie ab?

  2. Wenn Sie CLLocationManager verwenden: Löschen Sie die Anwendung, installieren Sie sie neu und führen Sie sie aus, aber erlauben Sie der Anwendung nicht, Standortdaten zu haben. Verhält sich die App gut oder stürzt sie ab? Weist sie den Benutzer zumindest darauf hin, dass sie ohne Standortdaten nicht ausgeführt werden kann (falls dies eine Voraussetzung ist)? Funktioniert die App auf einem iPod Touch, der die Geo-Ortung nur über WiFi durchführt?

  3. Starten Sie die Anwendung im Simulator und führen Sie für jeden View-Controller die folgenden Schritte aus: (a) Wählen Sie im Menü des iPhone-Simulators "Hardware" --> "Speicherwarnung simulieren", (b) navigieren Sie nun durch Ihre App zu anderen View-Controllern und prüfen Sie, ob alles funktioniert, (c) wiederholen Sie den Test für einen weiteren View-Controller.

  4. Wenn Sie ältere Firmware unterstützen (z. B. iOS 3.1.3), installieren Sie Ihre App auf einem Gerät mit 3.1.3 und testen Sie sie dort (wenn Sie kein Gerät haben, verwenden Sie den 3.2-Simulator).

  5. Starten Sie Ihre App während eines Telefonats oder wenn Personal Hotspot aktiv ist. Sind alle Bildschirmlayouts korrekt (die Statusleiste ist 40px hoch statt 20)? Wurden die unteren 20 Pixel der Ansicht vom Bildschirm verdrängt oder wurde die Größe korrekt angepasst?

  6. Wenn Sie in Ihrer Anwendung einen Anruf annehmen, wird dieser dann ordnungsgemäß beendet und fortgesetzt? Werden während des Telefonats keine Töne mehr von Ihrer App abgespielt?

  7. Starten Sie Ihre App während der Musikwiedergabe, läuft die Musik weiter? Mischen sich Ihre Sounds richtig oder wird die Musik angemessen ausgeblendet?

  8. Testen Sie die Leistung auf einem langsameren Geräte mit begrenztem RAM wie: iPhone 3G (128MB RAM, 412Mhz CPU) oder iPod Touch (1. oder 2. Generation).

  9. Führen Sie den statischen Clang-Analysator aus und beheben Sie jede Warnung (oder verstehen Sie sie zumindest).

  10. Vergewissern Sie sich, dass NSZombiesEnabled in den Umgebungsvariablen auf NO steht (Vorsicht: Ich bin nicht sicher, ob dies immer noch ein Problem ist)

17voto

Chris Garrett Punkte 4644

Ein paar Dinge:

Ich empfehle, keine Build-Konfiguration mit dem Namen "Distribution" zu erstellen, wie es Apple vorschreibt, weil ich oft Ad-hoc-Builds für Betatester erstelle. Ich erstelle zwei Build-Konfigurationen, eine mit dem Namen "Ad Hoc" und eine mit dem Namen "AppStore", damit ich nicht verwirrt bin. Der einzige Unterschied zwischen den beiden ist das Vorhandensein der Datei Entitlements.plist für den Ad Hoc-Build. Auf diese Weise kann ich so genau wie möglich testen, was ich bei Apple einreichen werde.

Die meisten Entwickler sind Optimisten. Deshalb arbeiten wir am Wochenende an einer App, von der wir wissen, dass sie uns zum Millionär machen wird. Bevor Sie sie jedoch einreichen, seien Sie ein Pessimist. Stellen Sie sich vor, was alles schief gehen kann, und überprüfen Sie es noch einmal.

Gehen Sie nicht von etwas aus. Gehen Sie nicht davon aus, dass die winzig kleine Änderung, die Sie an der App vorgenommen haben, sich nicht auf andere Dinge auswirkt. Murphys Gesetz besagt, dass diese winzige Änderung dazu führen wird, dass Ihre App auf allen iPod Touches oder so abstürzt. Testen, testen, testen Sie gründlich zwischen der letzten Code-Bearbeitung und der Appstore-Einreichung. Wenn Sie eine winzige Änderung vornehmen müssen, wiederholen Sie sie, bis sie perfekt ist.

Denken Sie daran, dass, wenn die App bei 99,9 % Ihrer Nutzer nicht abstürzt, 1 von 1.000 Downloads zu einer vernichtenden 1-Stern-Bewertung führen wird.

Ich verwende Clang static analyzer, Leaks und Object Allocations während der Entwicklung, aber ich führe einen zusätzlichen Durchlauf dieser Tools vor der Abgabe durch, nur für den Fall.

Wenn Sie kein älteres Gerät haben, sollten Sie sich eines zulegen, da die Leistung des 3GS deutlich besser ist und Sie möglicherweise einige wichtige Leistungsprobleme übersehen.

Testen Sie Ihre Anwendung mit den folgenden Konfigurationen, wenn Netzwerk oder Standort zutreffend sind:

  • iPod Touch
  • iPhone 3G
  • iPhone 3GS
  • iPhone im Flugmodus
  • iPhone mit Wi-Fi
  • iPhone mit EDGE
  • Rufen Sie das Telefon an, während Sie Ihre App verwenden

8voto

mahboudz Punkte 39008

Anstatt zu Release zu wechseln, wechsle ich zu "Distribution". Es ist eine Kopie von "Release", aber so wurde es mir von einem Apple-Doc beigebracht und iPhoneEntwicklerTipps .

Wichtige Punkte:

Nach dem endgültigen Build, aber bevor Sie losstürmen, um Ihre Anwendung zu packen, öffnen Sie das Paket mit der Finder-Funktion Paketinhalt anzeigen. Aufgrund eines Fehlers im MacOS, der mich in Versionen vor Snow Leopard heimgesucht hat (und der vielleicht immer noch vorhanden ist), werden einige Ressourcen noch nicht in die Datei gespült, wenn Sie das Paket zu schnell komprimieren (über den Menüpunkt Komprimieren oder Archivieren im Finder). Wenn Sie den Paketinhalt anzeigen lassen, wird der Inhalt aktualisiert. Sie bemerken dieses Problem daran, dass die Größe Ihrer komprimierten Anwendung zwischen einem Fünftel und einem Zehntel oder weniger der erwarteten Größe liegt. Sie könnten sich denken: "Hey, dieses Zip-Dienstprogramm komprimiert wirklich gut", aber das ist nicht der Fall. Das Problem tritt zu diesem Zeitpunkt und nicht während des Testens auf, weil Sie einen "Clean All"-Build durchführen und alle Ressourcen und Inhalte des App-Bundles zunächst leer sind und dann von Xcode gefüllt werden. Und aus irgendeinem Grund sind die Inhalte auch nach dem Erstellen der Datei durch Xcode nicht wirklich vorhanden, wenn Sie sie komprimieren, aber sie wären vorhanden, wenn Sie sie sich ansehen würden (eine Art umgekehrter Heisenberg). Vorsicht!

Ein weiterer Bereich, in dem ich viel Zeit verbringe, ist die Erstellung eines Backups der Quellen, nachdem ich die letzten Änderungen in SVN übertragen, einen neuen Zweig erstellt und die Datei mit Tags versehen habe. Ich möchte auch, dass meine Versionsnummer mit der SVN-Build/Commit-Nummer übereinstimmt, damit ich immer weiß, welche SVN-Version zu meiner Version passt. Diese beiden Versionsnummern stehen in meiner info.plist und können vom Benutzer der Anwendung abgerufen werden, wenn er auf i zur Information. Eine aktuelle info.pist enthält zum Beispiel:

<key>CFBundleShortVersionString</key>
<string>2.0a1</string>
<key>CFBundleVersion</key>
<string>346</string>

Es gibt verschiedene Überlegungen, wie man die CFBundleVersion verwenden kann. Dies ist mein Weg. Ebenfalls nützlich ist das Kommandozeilenprogramm, agvtool .

Sobald die App erstellt ist, überprüfen Sie die App-Datei, nachdem Sie sie komprimiert haben, damit Sie keine Änderungen an der komprimierten Version vornehmen, und stellen Sie sicher, dass sie mit dem richtigen Distributionszertifikat signiert ist und nicht mit Ihrem Adhoc-Zertifikat. Lernen Sie, das Kommandozeilenprogramm zu verwenden, Codesign ist für diese Art der Überprüfung und Fehlersuche hilfreich. Indem Sie zuerst die komprimierte Kopie erstellen, stellen Sie sicher, dass Sie die endgültige Kopie, die Sie von Xcode erhalten haben und die Sie auf itunesconnect hochladen werden, in keiner Weise verändern, wenn alles gut aussieht.

Andere Dinge, die Sie sich merken sollten, sind das App-Symbol, die verschiedenen anderen Symbole und Grafiken, die Sie für den iTunes Store benötigen, die info.plist und die Tatsache, dass, wenn das Hochladen der App mit einer kryptischen Fehlermeldung fehlschlägt, es in der Regel damit zu tun hat, dass eines dieser Teile in der komprimierten Datei, die Sie erstellen, fehlt (die Teile, die in das App-Paket gehören).

0voto

Baidyanath Punkte 167

Schauen Sie sich dieses Dokument mit Checklisten auf Github an.

https://github.com/bapu/AppReleaseCheckList

CodeJaeger.com

CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.

Powered by:

X