Pre-release checklist przed zbudowaniem ostatecznej wersji dla App Store

Kilka rzeczy:

Właściwie zalecam Nie tworzenie konfiguracji build o nazwie "Distribution", jak określa Apple, ponieważ często tworzę build ad hoc dla beta testerów. Tworzę dwa build konfiguracje, jeden o nazwie Ad Hoc i jeden o nazwie AppStore, więc nie jestem zdezorientowany. Jedyną różnicą między nimi jest obecność uprawnień.plik plist do budowy Ad Hoc. W ten sposób mogę przetestować tak dokładnie, jak to możliwe, co będę przesyłać do Apple.

Najbardziej deweloperzy są optymistami. Dlatego pracujemy w weekendy, aby stworzyć aplikację, która po prostu wiemy, że zrobi z nas milionera. Zanim jednak złożysz wniosek, bądź pesymistą. Wyobraź sobie wszystko, co może pójść źle, i sprawdź to jeszcze raz.

Niczego nie zakładaj. Nie zakładaj, że ta mała zmiana, którą wprowadziłeś w aplikacji, nie wpłynie na nic innego. Prawo Murphy ' ego mówi, że ta mała zmiana spowoduje awarię Twojej aplikacji na wszystkich dotknięciach iPoda lub czegoś takiego. Test, test, test dokładnie między ostateczną edycją kodu a zgłoszeniem do Appstore. Jeśli musisz dokonać drobnej zmiany, powtarzaj, aż będzie idealna.

Pamiętaj, że jeśli aplikacja nie ulegnie awarii dla 99,9% użytkowników, to 1 na każde 1000 pobrań spowoduje 1-gwiazdkową ocenę.

Używam analizatora statycznego Clang, wycieków i alokacji obiektów podczas tworzenia, ale na wszelki wypadek wykonuję dodatkowe uruchomienie tych narzędzi przed przesłaniem.

Jeśli nie masz starszego urządzenia, pobierz, ponieważ wydajność 3GS jest znacznie lepsza i możesz pominąć kilka ważnych problemów z wydajnością.

Przetestuj aplikację z następującymi konfiguracjami, jeśli dotyczy sieć lub Lokalizacja:

• iPod Touch
• iPhone 3G
• iPhone 3GS
• iPhone w trybie samolotowym
• iPhone z Wi-Fi
• iPhone z EDGE
W tym celu należy skontaktować się z Działem obsługi klienta.]}

Zamiast przełączyć się na Release, przełączyłem się na"Distribution". Jest to kopia wydania, ale tak zostałem nauczony przez jakiś Apple doc i iPhoneDeveloperTips .

Ważne punkty:

Po ostatecznej kompilacji, ale zanim pospieszysz się, aby spakować aplikację, otwórz pakiet za pomocą zawartości Show Package Findera. Ze względu na jakiś błąd w MacOS, który mnie ugryzł w wersjach przed Snow Leopardem( i może nadal tam być), Jeśli za szybko się zip (za pomocą Findera Kompresuj lub archiwum), niektóre zasoby nie zostały jeszcze wypłukane do pliku. Gdy wykonasz pokazanie zawartości pakietu, zawartość zostanie zaktualizowana. Sposób, w jaki zauważysz ten problem, polega na tym, że rozmiar skompresowanej aplikacji będzie wynosić od piątej do dziesiątej lub mniej oczekiwanego rozmiaru. Możesz sobie pomyśleć: "hej, to narzędzie zip naprawdę świetnie się kompresuje", ale tak nie jest. Ten problem pojawiłby się w tym momencie, a nie podczas testowania głównie ponieważ robisz" Wyczyść wszystko " budować i wszystkie zasoby i Zawartość pakietu aplikacji zaczynają się puste, a następnie są wypełnione przez Xcode. I z jakiegoś powodu, nawet po Xcode jest zrobione tworzenie pliku, zawartość nadal nie są faktycznie tam, jeśli kompresować, ale będzie tam, jeśli spojrzał na nich (rodzaj odwrotnej Heisenberg). Uważaj.

Kolejnym obszarem, nad którym spędzam dużo czasu, jest wykonanie ładnej kopii zapasowej źródeł, po wprowadzeniu wszystkich najnowszych zmian do SVN, stworzył nową gałąź i otagował plik. Lubię też, aby mój numer wersji pasował do mojego SVN build/commit number, więc zawsze wiem, która wersja SVN pasuje do mojego wydania. Mam te dwa numery wersji w moich informacjach.plist i może być wyciągnięty przez użytkownika aplikacji, gdy naciśnie i dla informacji. Na przykład aktualne informacje.pist zawiera:

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

Istnieją różne przemyślenia na temat korzystania z CFBundleVersion. To mój sposób. Przydatne jest również narzędzie wiersza poleceń, agvtool.

Po zbudowaniu aplikacji, po skompresowaniu, aby nie wprowadzać żadnych zmian w skompresowanej wersji, sprawdź plik aplikacji i upewnij się, że jest podpisany odpowiednim certyfikatem dystrybucji, a nie Twoim adhoc. Nauka korzystania z narzędzia wiersza poleceń, codesign , jest pomocna w tego rodzaju sprawdzaniu i debugowaniu. Dokonując skompresowanej kopii pierwszy, upewnij się, że nie jesteś w żaden sposób zamiar zmienić ostateczną kopię, że Xcode wręczył ty i że będziesz przesyłać do itunesconnect, jeśli wszystko wygląda dobrze.

Inne rzeczy do zapamiętania to ikona aplikacji, różne inne ikony i grafika, których potrzebujesz do sklepu iTunes, informacje.plist i fakt, że gdy przesyłanie aplikacji nie powiedzie się z tajemniczym Komunikatem o błędzie, zwykle ma to związek z brakiem jednego z tych elementów w skompresowanym pliku, który budujesz (te elementy, które należą do pakietu aplikacji).

Zajrzyj do tego dokumentu listy kontrolnej @ Github

Https://github.com/bapu/AppReleaseCheckList