Share
Du har arbetat veckor eller månader på din första iOS-applikation, och du är redo att skicka in ditt mästerverk till Apples App Store. Hur gör du det här? Är din ansökan redo för inlämning? Jag är säker på att några av dessa frågor har kommit i åtanke på ett eller annat ställe.
Skickar en ansökan så enkelt som att skicka Apple din ansökans binära? Inte riktigt. Med denna handledning kommer jag att förse dig med en detaljerad karta för att få din ansökan skickad till Apples App Store.
Även om App Store-granskningsprocessen är en svart låda för det mesta betyder det inte att du inte kan förbereda dig själv och din ansökan om Apples granskningsprocess. Apple ger riktlinjer som hjälper dig att hålla dig inom de ibland osynliga gränserna för vad som är och är inte tillåtet i App Store.
Första gången du skickar in en applikation till App Store är det spännande och nervhäftande samtidigt. Även för erfarna iOS-utvecklare är inlämning av en applikation till App Store ofta ett stressigt företag eftersom det är något som de flesta utvecklare inte gör dagligen.
I hela den här artikeln antar jag att du är en registrerad iOS-utvecklare, vilket innebär att du är inskriven i Apples iOS-utvecklarprogram och får lämna in ansökningar om publicering i App Store. För att skicka in en iOS-applikation till App Store måste du vara en registrerad iOS-utvecklare. Röd flagga? Oroa dig inte. Du kan anmäla dig till Apples iOS Developer Program genom att besöka sidan Apple Developer och klicka på Skriva in knapp.
En ansökan är inte nödvändigtvis klar när du har skrivit den sista raden av kod eller genomfört den sista funktionen i programmets specifikation.
Har du testat din ansökan på en eller flera fysiska enheter? Har du profilerat din ansökan om minnesläckor och prestanda? Kraschar din ansökan från tid till annan?
Familjen av iOS-enheter har ökat väsentligt genom åren, och det är viktigt att testa din ansökan på så många iOS-enheter som du kan lägga på dina händer på. Vanliga problem inkluderar inte att optimera en applikation för vissa skärmstorlekar. IOS-simulatorn är ett bra verktyg, men det körs på din Mac, vilket har mer minne och bearbetningseffekt än telefonen i fickan.
Apples granskningsprocess är inte lufttätt, men det är mycket kapabelt att identifiera problem som kan påverka din applikations användarupplevelse. Om din ansökan kraschar från tid till annan eller det blir långsamt efter tio minuters användning, har du lite arbete innan du skickar det till App Store.
Även om Apples granskningsteam inte ser problemet, kommer dina användare att göra det. Om de personer som använder din ansökan inte är nöjda lämnar de dåliga recensioner på App Store, vilket kan skada försäljningen eller hämma nedladdningarna.
Som jag nämnde tidigare tillhandahåller Apple utvecklare ett antal dokument som är en stor hjälp under din ansökans skapande och utvecklingsprocess.
Dokumenten som du bör vara medveten om är riktlinjerna för iOS Human Interface och App Store Review Guidelines. Trots tillgängligheten av dessa dokument verkar det som att få utvecklare tar sig tid att bläddra i dem, än mindre läsa dem. Det bör inte vara en överraskning att vissa ansökningar avvisas, även om orsaken till avslaget klart framgår av dessa dokument.
Även om du inte avser att läsa riktlinjerna för iOS Human Interface eller App Store Review Guidelines, är det viktigt att veta några av de regler som de pratar om. Ta en titt på den korta listan nedan för att få en uppfattning om vad din ansökan borde och borde inte göra.
Din ansökan:
Tänk på att detta är en liten delmängd av riktlinjerna som ingår i ovannämnda dokument. Majoriteten av reglerna och riktlinjerna är triviala, men vissa är inte, och du kan till och med bryta mot dem av misstag.
Låt mig ge dig ett exempel. Innan Apple började använda egna kartor (för länge sedan), använde MapKit-ramarna Googles kartor. Detta var tydligt för användaren på grund av den lilla Google-logotypen i nedre vänstra hörnet av varje karta. Om någon del av din applikations användargränssnitt omfattas eller döljs i Googles logotyp, skulle din ansökan bli avvisad. Denna regel verkar trivial, men det är en regel som lätt bryts om du inte är försiktig. Även automatiserade tester kommer inte att täcka dig i det här fallet.
Innan du kan börja tänka på att skicka in din ansökan till App Store måste du se till att du har ett App-ID, ett giltigt distributionscertifikat och en giltig provisioningprofil. Låt mig visa dig vad det här medför.
Varje applikation behöver ett app-ID eller en ansökningsidentifierare. Det finns två typer av programidentifierare: an explicit app-id och a jokertecken App ID. Ett jokertecken App ID kan användas för att bygga och installera flera applikationer. Trots bekvämligheten med ett joker-ID-ID, är ett explicit App-ID nödvändig om din ansökan använder iCloud eller använder andra iOS-funktioner, till exempel Game Center, Apple push notifications eller i App Purchase.
Om du inte är säker på vad App ID bäst passar ditt projekt rekommenderar jag att du läser teknisk anteckning QA1713 för mer information om ämnet.
För att skicka in en ansökan till App Store måste du skapa en iOS-provisionprofil för distribution. För att skapa en sådan provisioningprofil måste du först skapa ett distributionscertifikat. Processen för att skapa ett distributionsbevis ligner mycket på att skapa ett utvecklingscertifikat. Om du har testat din ansökan på en fysisk enhet är du förmodligen redan bekant med att skapa ett utvecklingscertifikat.
Om du behöver uppdatera minnet föreslår jag att du läser Apples guide, Kodsignering av dina Apps, om signering av certifikat och provisioning profiler. Processen är inte svår när du förstår hur de olika pusselbitarna passar ihop.
När du har skapat ett app-id och ett distributionscertifikat kan du skapa en iOS-provisionprofil för att distribuera din applikation via App Store.
Tänk på att du inte kan använda samma provisioneringsprofil som du använder för ad hoc-distribution. Du måste skapa en separat provisioningprofil för distributionen av App Store. Om du använder ett joker-ID-ID för ditt projekt kan du använda samma provisioneringsprofil för flera applikationer.
Med App ID, distributionsbevis och provisioning-profil på plats är det dags att konfigurera ditt måls byggnadsinställningar i Xcode. Det innebär att välja målet från listan över mål i Xcode s Project Navigator, öppnar Bygg inställningar fliken högst upp och uppdatera inställningarna i Signering sektion. Du måste ställa in Kodsignering till Automatisk.
Även om kodsigneringsprocessen är ganska enkel när du förstår det, är det något som går upp på många utvecklare. Jag känner inte till en enda kakaoutvecklare som inte har kollat på kodsigneringsproblem någon gång i sin karriär. När du har klarat den här hindren är resten av inlämningsprocessen ganska lätt.
Det är användbart att tänka lite om programmets implementeringsmål. Varje mål i ett Xcode-projekt har ett implementeringsmål, vilket anger den minsta versionen av operativsystemet som programmet kan köras på.
Det är upp till dig att ställa in installationsmålet, men kom ihåg att modifiering av implementeringsmålet inte är något du kan göra utan konsekvenser när din ansökan finns i App Store. Om du ökar installationsmålet för en uppdatering av din ansökan kan användare som redan har köpt din applikation men inte uppfyller det nya implementeringsmålet inte köra uppdateringen.
Det blir verkligen problematiskt när en användare hämtar en uppdatering via iTunes (inte enheten), ersätter den tidigare versionen på sin dator och upptäcker sedan att den nya uppdateringen inte körs på sin enhet.
Jag har två mycket enkla tips när det gäller din applikations implementeringsmål:
Du vet säkert att en applikationsikon är en viktig del av varje iOS-applikation, men du måste se till att din ansökan skickas med rätt storlek på bilden. Ta en titt på tabellen nedan:
Bildstorlek (px) | Filnamn | Används för | App Store | Ad hoc |
|---|---|---|---|---|
512x512 | iTunesArtwork | Applistan i iTunes | Inkludera inte | Valfritt men rekommenderat |
1024x1024 | iTunesArtwork @ 2x | Applistan i iTunes för enheter med näthinnan | Inkludera inte | Valfritt men rekommenderat |
120x120 | Startskärm på iPhone / iPod Touch med näthinnan | Nödvändig | Nödvändig | |
180x180 | Startskärm på iPhone med näthinnan HD-skärm | Valfritt men rekommenderat | Valfritt men rekommenderat | |
76x76 | Ikon-76.png | Startskärm på iPad | Nödvändig | Nödvändig |
152x152 | Hemskärm på iPad med näthinnan | Valfritt men rekommenderat | Valfritt men rekommenderat | |
167x167 | Startskärm på iPad Pro | Valfritt men rekommenderat | Valfritt men rekommenderat | |
40x40 | Ikon-Small-40.png | Strålkastare | Valfritt men rekommenderat | Valfritt men rekommenderat |
80x80 | Spotlight på enheter med näthinnan | Valfritt men rekommenderat | Valfritt men rekommenderat | |
120x120 | Spotlight på enheter med näthinnan HD-skärm | Valfritt men rekommenderat | Valfritt men rekommenderat | |
29x29 | Ikon small.png | inställningar | Rekommenderas om du har en inställningsbunt, valfritt annars | Rekommenderas om du har en inställningsbunt, valfritt annars |
58x58 | Inställningar på enheter med näthinnans display | Rekommenderas om du har en inställningsbunt, valfritt annars | Rekommenderas om du har en inställningsbunt, valfritt annars | |
87x87 | Inställningar på enheter med näthinnan HD-skärm | Rekommenderas om du har en inställningsbunt, valfritt annars | Rekommenderas om du har en inställningsbunt, valfritt annars |
Det står självklart att du inte behöver inkludera en applikationsikon för iPad / iPad Mini-enheten, om din ansökan endast riktar sig till iPhone / iPod Touch-enheten och vice versa.
Varje applikation kan ha upp till fem skärmdumpar och tre förhandsgranskningar, och du måste tillhandahålla minst en. Om du utvecklar en universell applikation måste du tillhandahålla separata skärmdumpar för varje enhet.
Det är viktigt att spendera lite tid på att tänka på skärmdumparna. Din applikations skärmdumpar är ofta det enda en kund kan använda för att bestämma om du vill köpa eller ladda ner din ansökan eller inte.
Vad många utvecklare inte vet är att skärmdumparna inte behöver vara faktiska skärmdumpar. Den hårda regeln är att storleken på varje skärmdump måste vara den för skärmstorleken på målenheten. Många företag är kreativa med denna regel. Ta en titt på skärmbilderna av Where's My Water?, Till exempel, som inkluderar etiketter som markerar viktiga funktioner i appen. Genom att använda denna strategi kan du göra skärmdumpar mycket mer attraktiva och övertygande.
Innan du skickar in din ansökan är det en bra idé att få din applikations metadata till hands. Detta inkluderar:
Om du skickar en uppdatering kan du också ge information för Vad är nytt i denna version sektion.
Behöver din ansökan användarna logga in? Då behöver du också ge Apple ett test- eller demokonto för att se till att granskningsgruppen direkt kan logga in och använda din ansökan utan att behöva anmäla dig för ett konto.
Inlämningsprocessen har blivit mycket enklare idag. Du kan nu validera och skicka in en ansökan med hjälp av Xcode, till exempel. Först måste du skapa din applikation i iTunes Connect.
Besök iTunes Connect, logga in med ditt iOS-utvecklarkonto och klicka på Hantera dina appar till höger. Klicka på Lägg till ny app högst upp till vänster, välj iOS App, och fyll i formuläret.
De App-namn, vilket måste vara unikt, är namnet på din ansökan som den kommer att visas i App Store. Det kan vara annorlunda än det namn som visas under din applikationsikon på startskärmen, men det rekommenderas att du väljer samma namn.
De SKU nummer är en unik sträng som identifierar din ansökan. Jag brukar använda programmets buntidentifierare.
Den sista informationen är Paket ID av din ansökan. Det här betyder att du väljer det (jokertecken eller explicit) App ID som du skapade tidigare från rullgardinsmenyn.
I nästa steg anger du programmets pris och tillgänglighet. Apple arbetar med prisnivåer så att du inte behöver ange ett pris för varje land som Apple verkar i. Du kan också ange i vilka butiker din ansökan borde eller borde vara tillgänglig.
Informationen som du anger i det här steget kan ändras när din ansökan är live i App Store. Med andra ord kan du ändra pris och tillgänglighet för en applikation utan att behöva lämna en uppdatering. Du kan enkelt göra det genom att välja Prissättning och tillgänglighet fliken till vänster på appens iTunes Connect-sida.
Vi har redan täckt programmets metadata. Den enda aspekt som jag inte har pratat om än är din ansökans betyg. Baserat på din ansökans innehåll och funktionalitet får du betyg. Denna klassificering är inte bara användbar för att berätta för användarna om programmets innehåll och funktioner, men används också av operativsystemet för föräldrakontrollfunktionerna.
Det rekommenderas starkt att du inte försöker slänga ut värderingssystemet. Apple är väl medveten om denna strategi och kommer att avvisa din ansökan om den inte överensstämmer med det betyg du ställt. Det finns många andra saker här som du kanske behöver justera baserat på din app, men vi kommer inte att gå över dem eftersom de är ganska självförklarande. För att göra detta, gå till Appinformation fliken i den vänstra rutan.
För att skicka in din app måste du skapa en arkiv. Du kan bara skapa ett arkiv genom att bygga din applikation på en generisk enhet. Om du väljer iOS-simulatorn i det aktiva systemet kommer du att märka att arkiv alternativet i Xcode s Produkt Menyn är gråtonad. Anslut en iOS-enhet till din Mac, välj den i det aktiva systemet och välj arkiv från Xcode s Produkt meny.
Om allt gick bra borde du nu ha ett arkiv och Xcode's Organizer öppnar automatiskt och visar det arkiv du just skapat.
Välj arkivet från listan och klicka på Ladda upp till App Store ... knappen till höger. Applikations binär laddas sedan upp till Apples servrar.
Under denna process valideras din ansökan också. Om ett fel uppstår under valideringen misslyckas inlämningsprocessen. Valideringsprocessen är mycket användbar eftersom det kommer att berätta om det är något fel med din ansökan binära som annars skulle resultera i ett avslag från App Store granskningsteamet.
Om inlämningsprocessen gick utan problem ändras din ansökans status till Väntar på granskning. Det tar flera dagar för Apple att granska din app och den tid det tar tenderar att fluktuera över tiden.
Lycka till!
Inlämningsprocessen är ganska lång för en ny applikation, men att skicka en uppdatering till App Store är mycket mindre besvärlig. Tänk på att inlämningsprocessen är mycket mer involverad om din ansökan är lokaliserad på olika språk eftersom din applikations metadata också behöver vara lokaliserad. Att lokalisera din ansökan är dock värt ansträngningen eftersom det ofta resulterar i högre försäljning och positiv feedback från kunder.
Om du vill lära dig mer om Swift och iOS-utveckling, kolla in några av våra fördjupade kurser här på Envato Tuts+.
Accentsconagua