Share
Du har jobbet uker eller måneder på ditt første iOS-program, og du er klar til å sende inn ditt mesterverk til Apples App Store. Hvordan gjør du dette? Er din søknad klar for innsending? Jeg er sikker på at noen av disse spørsmålene har kommet inn i tankene dine på et eller annet tidspunkt.
Er det å sende inn et søknad så enkelt som å sende Apple din applikasjon er binær? Ikke helt. Med denne opplæringen vil jeg gi deg et detaljert kart for å få søknaden din sendt til Apples App Store.
Selv om App Store-gjennomgangsprosessen er en svart boks for det meste, betyr det ikke at du ikke kan forberede deg selv og din søknad om Apples gjennomgangsprosess. Apple gir retningslinjer som hjelper deg å holde deg innenfor de noen ganger usynlige grensene for hva som er og ikke er tillatt i App Store.
Første gang du sender inn et søknad til App Store, er det spennende og nervepirrende samtidig. Selv for erfarne iOS-utviklere, er det å sende inn et program til App Store ofte en stressende bedrift fordi det er noe de fleste utviklere ikke gjør daglig.
Gjennom hele denne artikkelen antar jeg at du er en registrert iOS-utvikler, noe som betyr at du er registrert i Apples iOS-utviklerprogram og har lov til å sende inn søknader om publisering i App Store. For å sende inn et iOS-program til App Store, må du være en registrert iOS-utvikler. Rødt flagg? Ikke bekymre deg. Du kan registrere deg i Apples iOS-utviklerprogram ved å gå til Apple Developer-siden og klikke på Registrere knapp.
En applikasjon er ikke nødvendigvis klar når du har skrevet den siste koden eller implementert den endelige funksjonen til programmets spesifikasjon.
Har du testet søknaden din på en eller flere fysiske enheter? Har du profilert søknaden din om hukommelseskort og ytelsesproblemer? Krasjer søknaden din fra tid til annen?
Familien av iOS-enheter har vokst vesentlig gjennom årene, og det er viktig å teste søknaden din på så mange iOS-enheter som du kan legge hendene på. Vanlige problemer inkluderer ikke optimalisering av et program for bestemte skjermstørrelser. IOS-simulatoren er et flott verktøy, men det kjører på din Mac, som har mer minne og prosessorkraft enn telefonen i lommen..
Apples gjennomgangsprosess er ikke lufttett, men det er svært i stand til å identifisere problemer som kan påvirke søknadens brukeropplevelse. Hvis søknaden din krasjer fra tid til annen, eller det blir treg etter ti minutter, har du noe arbeid å gjøre før du sender det til App Store.
Selv om Apples gjennomgangsteam ikke ser problemet, vil brukerne. Hvis folk som bruker søknaden din, ikke er fornøyd, vil de forlate dårlige anmeldelser på App Store, noe som kan skade salg eller hemme nedlastinger.
Som jeg tidligere nevnte, gir Apple utviklere med en rekke dokumenter som er en stor hjelp i utviklingsprosessen av søknaden din.
Dokumentene du bør være oppmerksom på, er retningslinjene for iOS Human Interface og retningslinjene for App Store. Til tross for tilgjengeligheten av disse dokumentene, ser det ut som at få utviklere tar seg tid til å bla dem, enn si les dem. Det bør ikke være en overraskelse at enkelte søknader derfor avvises, selv om årsaken til avslaget er tydelig fremgått i disse dokumentene.
Selv om du ikke har tenkt å lese retningslinjene for IOS Human Interface eller App Store Review Guidelines, er det viktig å vite noen av reglene de snakker om. Ta en titt på den korte listen under for å få en ide om hva søknaden din bør og ikke skal gjøre.
Din søknad:
Husk at dette er en liten delmengde av retningslinjene som følger med de nevnte dokumentene. Flertallet av reglene og retningslinjene er trivielle, men noen er ikke, og du kan til og med krenke noen av dem ved et uhell.
La meg gi deg et eksempel. Før Apple begynte å bruke egne kart (for lenge siden), brukte MapKit-rammen Googles kart. Dette var klart for brukeren på grunn av den lille Google-logoen nederst i venstre hjørne av hvert kart. Men hvis en del av søknadens brukergrensesnitt dekkes eller skjuler Googles logo, vil søknaden din bli avvist. Denne regelen virker trivial, men det er en regel som lett brytes hvis du ikke er forsiktig. Selv automatiserte tester vil ikke dekke deg i dette tilfellet.
Før du kan begynne å tenke på å sende inn søknaden din til App Store, må du forsikre deg om at du har en App ID, et gyldig distribusjonsbevis og en gyldig provisjonsprofil. La meg vise deg hva dette medfører.
Hver applikasjon trenger en app-ID eller en applikasjonsidentifikator. Det finnes to typer applikasjonsidentifikatorer: an eksplisitt app-ID og a jokertegn-ID. En jokertegn-ID kan brukes til å bygge og installere flere applikasjoner. Til tross for bekvemmeligheten til et jokertegn-ID, er en eksplisitt App-ID nødvendig hvis søknaden din bruker iCloud eller bruker andre iOS-funksjoner, for eksempel spillsenter, Apple Push Notifications eller i App Purchase.
Hvis du ikke er sikker på hva App ID passer best for prosjektet, anbefaler jeg at du leser teknisk notat QA1713 for mer informasjon om emnet.
For å sende inn et søknad til App Store, må du opprette en iOS-provisjonsprofil for distribusjon. For å opprette en slik provisjonsprofil må du først opprette et distribusjonsbevis. Prosessen for å opprette et distribusjonsbevis ligner veldig på å skape et utviklingssertifikat. Hvis du har testet søknaden din på en fysisk enhet, er du sannsynligvis allerede kjent med etableringen av et utviklingssertifikat.
Hvis du trenger å oppdatere minnet, foreslår jeg at du leser Apples veiledning, Kode Signing Apps, om signering av sertifikater og provisjonsprofiler. Prosessen er ikke vanskelig når du forstår hvordan de ulike stykkene av puslespillet passer sammen.
Når du har opprettet en app-ID og et distribusjonsbevis, kan du opprette en iOS-provisjonsprofil for å distribuere søknaden din via App Store.
Husk at du ikke kan bruke samme provisjonsprofil som du bruker for ad hoc-distribusjon. Du må opprette en egen provisjonsprofil for distribusjon av App Store. Hvis du bruker en jokertegn-ID for prosjektet, kan du bruke samme provisjonsprofil for flere applikasjoner.
Med App ID, distribusjonsattest og provisjonsprofil på plass, er det på tide å konfigurere målets bygginnstillinger i Xcode. Dette betyr å velge målet fra listen over mål i Xcode Prosjektnavigator, åpner Bygg innstillinger fanen øverst, og oppdatering av innstillingene i signering seksjon. Du må sette inn Kodesignering til Automatisk.
Selv om kodesigneringsprosessen er ganske enkel når du forstår det, er det noe som reiser opp mange utviklere. Jeg kjenner ikke en eneste kakaoutvikler som ikke har kjørt inn på kodesigneringsproblemer på et tidspunkt i sin karriere. Når du har fjernet denne hindringen, er resten av innleveringsprosessen ganske enkel.
Det er nyttig å tenke litt om programmets distribusjonsmål. Hvert mål i et Xcode-prosjekt har et distribusjonsmål, som angir minimumsversjonen av operativsystemet som programmet kan kjøre på.
Det er opp til deg å angi distribusjonsmålet, men husk at å endre distribusjonsmålet er ikke noe du kan gjøre uten konsekvenser når søknaden din er i App Store. Hvis du øker distribusjonsmålet for en oppdatering av programmet, kan brukere som allerede har kjøpt programmet, men ikke oppfyller det nye distribusjonsmålet, ikke kjøre oppdateringen..
Det blir veldig problematisk når en bruker laster ned en oppdatering via iTunes (ikke enheten), erstatter den forrige versjonen på datamaskinen, og oppdager da at den nye oppdateringen ikke kjører på enheten.
Jeg har to veldig enkle tips med hensyn til søknadens distribusjonsmål:
Du vet sikkert at et programikon er en viktig del av hvert iOS-program, men du må sørge for at søknaden din sendes med de riktige størrelsene på illustrasjonen. Ta en titt på tabellen nedenfor:
Bildestørrelse (px) | Filnavn | Brukes for | App Store | Ad hoc |
|---|---|---|---|---|
512x512 | iTunesArtwork | Appliste i iTunes | Ikke ta med | Valgfritt, men anbefalt |
1024x1024 | iTunesArtwork @ 2x | Appliste i iTunes for enheter med netthinnen | Ikke ta med | Valgfritt, men anbefalt |
120x120 | Hjemmeskjerm på iPhone / iPod Touch med netthinnen | Må | Må | |
180x180 | Hjemmeskjerm på iPhone med netthinnen HD-skjerm | Valgfritt, men anbefalt | Valgfritt, men anbefalt | |
76x76 | Ikon-76.png | Hjemmeskjerm på iPad | Må | Må |
152x152 | Hjemmeskjerm på iPad med netthinnen | Valgfritt, men anbefalt | Valgfritt, men anbefalt | |
167x167 | Hjemmeskjerm på iPad Pro | Valgfritt, men anbefalt | Valgfritt, men anbefalt | |
40x40 | Ikon-Small-40.png | Spotlight | Valgfritt, men anbefalt | Valgfritt, men anbefalt |
80x80 | Spotlight på enheter med netthinnen | Valgfritt, men anbefalt | Valgfritt, men anbefalt | |
120x120 | Spotlight på enheter med netthinnen HD-skjerm | Valgfritt, men anbefalt | Valgfritt, men anbefalt | |
29x29 | Ikon-Small.png | innstillinger | Anbefales hvis du har en innstillingsbunt, valgfritt ellers | Anbefales hvis du har en innstillingsbunt, valgfritt ellers |
58x58 | Innstillinger på enheter med netthinnen | Anbefales hvis du har en innstillingsbunt, valgfritt ellers | Anbefales hvis du har en innstillingsbunt, valgfritt ellers | |
87x87 | Innstillinger på enheter med netthinnen HD-skjerm | Anbefales hvis du har en innstillingsbunt, valgfritt ellers | Anbefales hvis du har en innstillingsbunt, valgfritt ellers |
Det sier seg selv at du ikke trenger å inkludere et programikon for iPad / iPad Mini-enheten, hvis søknaden din bare gjelder iPhone / iPod Touch-enheten, og omvendt.
Hver applikasjon kan ha opptil fem skjermbilder og tre forhåndsvisninger, og du må angi minst én. Hvis du utvikler en universell applikasjon, må du gi separate skjermbilder for hver enhet.
Det er viktig å bruke litt tid på å tenke på skjermbilder. Programmets skjermbilder er ofte det eneste kunden kan bruke til å bestemme om man skal kjøpe eller laste ned søknaden eller ikke.
Hva mange utviklere ikke vet er at skjermbildene ikke behøver å være faktiske skjermbilder. Den harde regelen er at størrelsen på hvert skjermbilde må være det for målestøttens skjermstørrelse. Mange selskaper er kreative med denne regelen. Ta en titt på skjermbildene til Where's My Water?, For eksempel, som inkluderer etiketter som fremhever viktige funksjoner i appen. Ved å bruke denne strategien kan du lage skjermbilder mye mer attraktiv og overbevisende.
Før du sender inn søknaden din, er det en god ide å ha søknadens metadata tilgjengelig. Dette inkluderer:
Hvis du sender inn en oppdatering, kan du også gi informasjon til Hva er nytt i denne versjonen seksjon.
Krever programmet at brukerne logger på? Deretter må du også gi Apple en test- eller demo-konto for å forsikre deg om at gjennomgangsteamet umiddelbart kan logge på og bruke søknaden din uten å måtte først registrere deg for en konto.
Innleveringsprosessen har blitt mye lettere i disse dager. Du kan nå validere og sende inn et søknad ved hjelp av Xcode, for eksempel. Først må du imidlertid opprette applikasjonen din i iTunes Connect.
Gå til iTunes Connect, logg inn med iOS-utviklerkontoen din, og klikk Administrer appene dine til høyre. Klikk på Legg til ny app øverst til venstre, velg iOS-app, og fyll ut skjemaet.
De Appnavn, som må være unikt, er navnet på søknaden din som det vil vises i App Store. Dette kan være annerledes enn navnet som vises under applikasjonsikonet på startskjermen, men det anbefales å velge samme navn.
De SKU nummer er en unik streng som identifiserer søknaden din. Jeg bruker vanligvis programmets buntidentifikator.
Den siste informasjonen er Bundle ID av søknaden din. Dette betyr å velge (jokertegn eller eksplisitt) App ID som du opprettet tidligere fra rullegardinmenyen.
I neste trinn angir du programmets pris og tilgjengelighet. Apple jobber med prisnivåer, slik at du ikke trenger å spesifisere en pris for hvert land som Apple opererer i. Du kan også angi hvilke butikkene søknaden din burde eller ikke skulle være tilgjengelig for..
Informasjonen du skriver inn i dette trinnet, kan endres når programmet ditt er i App Store. Med andre ord kan du endre pris og tilgjengelighet for et program uten å måtte sende inn en oppdatering. Du kan enkelt gjøre dette ved å velge Priser og tilgjengelighet fanen til venstre for appens iTunes Connect-side.
Vi har allerede dekket programmets metadata. Det eneste aspektet jeg ikke har snakket om ennå, er søknadens vurdering. Basert på søknadens innhold og funksjonalitet, blir det gitt en vurdering. Denne rangering er ikke bare nyttig for å fortelle brukere om programmets innhold og funksjoner, men brukes også av operativsystemet for foreldrekontrollfunksjonene.
Det anbefales på det sterkeste at du ikke prøver å slå ut klassesystemet. Apple er godt klar over denne strategien og vil avvise søknaden din hvis den ikke er enig med vurderingen du har satt. Det er mange andre ting her du kanskje må justere basert på appen din, men vi vil ikke gå over dem siden de er ganske selvforklarende. For å gjøre dette, gå til App Informasjon fanen i venstre rute.
For å sende inn appen din, må du opprette en arkiv. Du kan bare opprette et arkiv ved å bygge programmet på en generisk enhet. Hvis du velger iOS Simulator i aktiv skjema, vil du legge merke til at Arkiv alternativet i Xcode er Produkt menyen er gråtonet ut. Koble en iOS-enhet til Mac, velg den i den aktive skjermen, og velg Arkiv fra Xcode er Produkt Meny.
Hvis alt gikk bra, burde du nå ha et arkiv, og Xcode's Organizer skal automatisk åpne og vise deg arkivet du nettopp har laget.
Velg arkivet fra listen og klikk på Last opp til App Store ... knappen til høyre. Applikasjons binæret lastes deretter opp til Apples servere.
I løpet av denne prosessen blir søknaden din også validert. Hvis det oppstår en feil under valideringen, vil innleveringsprosessen mislykkes. Valideringsprosessen er veldig nyttig, da den vil fortelle deg om det er noe galt med din søknad binære som ellers ville føre til en avvisning fra App Store gjennomgangsteamet.
Hvis innleveringsprosessen gikk uten problemer, blir søknadens status endret til Venter på gjennomgang. Det tar flere dager for Apple å vurdere appen din, og tiden det tar, har en tendens til å svinge over tid.
Lykke til!
Innleveringsprosessen er ganske lang for en ny applikasjon, men det er mye mindre tungt å sende inn en oppdatering til App Store. Husk at innleveringsprosessen er mye mer involvert hvis søknaden din er lokalisert på forskjellige språk, da søknadens metadata også må være lokalisert. Men lokalisering av søknaden din er vel verdt innsatsen, da det ofte resulterer i høyere salg og positiv tilbakemeldinger fra kunder.
Hvis du vil lære mer om Swift og iOS-utvikling, sjekk ut noen av våre dybdegående kurs her på Envato Tuts+.
Accentsconagua