Home » Programmering » Scor kassen på App Store
Scor kassen på App Store

Scor kassen på App Store

Share

Der er store muligheder i iOS-branchen. Læs hvordan du udvikler apps, der giver kroner på kontoen

Det er en smal sag at udvikle til iOS App Store. Hvis vi siger, at en latterlig investering på 2.500 kroner er nok til at lukke op for et marked med 150 millioner forbrugere, burde enhver kvik udvikler spidse ørene.

Og hvis vi tilføjer, at mange af disse forbrugere er Apple-fans, som er opsatte på at skille sig af med deres penge i et forsøg på at købe software, der kan berettige prisen på deres hardware, begynder det måske at dæmre for dig, hvorfor der i øjeblikket findes 300.000 iPhone-apps og 60.000 iPad-apps, to et halvt år efter at App Store blev lanceret. App Stores størrelse er forbløffende, og den har over dobbelt så mange apps som alle konkurrenterne lagt sammen.

[pt id=’2015611′ size=’large’ link=’file’ html_attrs=’title=”App Store er verdens største softwarebutik og her kan din app ligge.”‘]

I denne artikel hjælper vi dig med at kickstarte dit eget udviklingsarbejde på App Store, og vi håber, at det kan opmuntre dig at høre, at en af os gik fra 0 apps til nu at have 20 godkendte apps, der er til salg. Det er sket i løbet af halvandet år.

Det giver en stadig stigende indtægt, der kun kan blive større i takt med, at Apple sælger mere hardware. Hvis du vil med på vognen, kræver det kun en ide, en Mac (til kodearbejdet) og denne guide. Lad os komme i gang!

Kravene

Når man skal lave software til iOS- enheder – det vil sige iPads og iPhone Touches – skal du kun bruge én softwarepakke: iOS SDK fra Apple.

Den omfatter fire hovedkomponenter: udviklingsmiljøet Xcode, hvor du skal skrive al din kode; Interface Builder, der er et drag and drop-designsystem til grænseflader; biblioteker og headerfiler til at skrive din kode i Objective C (iPhones oprindelige sprog) og iOS Simulator, der gør det muligt at køre en virtuel iPhone eller iPad på din Mac.

Vi bør understrege, at det kun kan lade sig gøre på en Mac, for iOS SDK kan ikke fås til nogen anden platform. Man er faktisk henvist til at bruge Apples hardware, software og udviklingsværktøjer.

Det er grunden til, at mange mennesker omtaler iOS-udvikling som en ”indhegnet have” – Apple våger nidkært over, hvem der laver apps, og hvad der kommer i butikken.

Mac-kravene er en forhindring, som man ikke kan overvinde, men det er til at leve med. Selvom du er en passioneret elsker af Windows eller Linux, er en Mac et glimrende køb. Vi ser sjældent mere robuste eller driftsikre pc’er.

Hvis du har tænkt dig kun at arbejde i simulatoren, behøver du ikke at betale Apple noget for en testenhed eller en udviklerkonto – du kan gå direkte til http://developer.apple.com/ios og få adgang til de gratis værktøjer.

Hvis du senere beslutter dig for, at du har lavet en app, som du vil sælge, bør du anskaffe en iPod Touch til afprøvning (1.799 kroner) og oprette en kommerciel iOS-konto (99 dollars/året). Hvis din app til 6 kroner kun sælger 500 eksemplarer – hvis blot 0,00033 procent køber den – har du tjent pengene ind. Alt andet er profit.

Når du har oprettet din konto, skal du downloade den seneste SDK. I skrivende stund er det Xcode 3.2.5 med iOS SDK 4.2. Denne pakke indeholder alt det, du skal bruge for at lave iPhone- og iPad-apps. Installationen er meget enkel: Klik ’Next’, indtil kopieringsprocessen begynder. Vent så cirka 30 minutter, mens magien indfinder sig, og så er du klar.

Opbyg dit projekt

Vi er ikke interesserede i at undervise dig i teori her. Vi vil hellere vise dig, hvordan du laver et rigtigt projekt, så du kan udvide det med dine egne tilpasninger og lave dit eget supplement til App Store. Vi laver en enkel huskeseddel, der er baseret på nogle af de grundlæggende brugerfladeelementer, der knytter sig til iOS-apps.

Først skal du fyre op under Xcode – den finder du i mappen ’Developer à Applications’ på din harddisk. Der kommer et velkomstskærmbillede. Luk det, og vælg ’New à New project’ i menuen.

[pt id=’2015612′ size=’large’ link=’file’ html_attrs=’title=”Xcode er dit primære udviklingsmiljø til iPhone. Nogle kan lide det de fleste kan ikke lide det men desværre har vi ikke noget valg.”‘]

Xcode er dit primære udviklingsmiljø til iPhone. Nogle kan lide det, de fleste kan ikke lide det, men desværre har vi ikke noget valg.

Apple tilbyder syv applikationsskabeloner, men den nyttigste til at begynde med (navnlig fordi den rummer en anselig mængde kode, der allerede er skrevet til dig) er den navigationsbaserede applikation. Vælg den, giv den navnet ’TaDaList’, og gem den på din desktop.

En navigationsbaseret app giver dig en brugerflade, der svarer til settings-app’en – du får en titelbjælke øverst og en række muligheder at vælge imellem. Uanset hvad du vælger, kommer der en ny skærm ind fra højre. Du kan gå tilbage til det forrige skærmbillede ved at klikke på en ’Back’-knap – det er meget enkelt og nemt at lære.

Du kan se den enkle applikationsskabelon, som Apple har lavet til dig, ved at trykke [Command]+[Y]. Så kan du opbygge og køre din app i simulatoren. Du kan se Apples blå bjælke øverst (den er tom, fordi vi endnu ikke har skrevet noget der) plus informationsoversigten (igen tom, fordi vi ikke har fortalt app’en, hvad der skal være der).

Definer items

Før vi skriver items ind i huskesedlen, skal vi definere, hvad disse begreber er, og hvor de ligger. Tænk først over, hvad vi skal gemme hvert item i huskesedlen som, og hvordan de med fordel kan gemmes som en gruppe. Du bør ende med to hovedpunkter:

For det første er et item i huskesedlen, såsom ”Giv katten mad” eller ”Tag magten i hele verden”, kun en streng. I Objective C er der to slags strenge: ’NSString’ og ’NSMutableString’. Den eneste forskel på de to er, at den sidstnævnte kan ændres, efter at den er blevet oprettet.

For det andet er samlingen af items meget enkel. Efterhånden som de bliver tilføjet, skal vi anbringe dem enten ved begyndelsen eller slutningen af vores eksisterende liste.

Brugerne skal kunne læse dem i den rækkefølge, de foretrækker. Det lægger op til et ret almindeligt array, selvom der er to at vælge imellem – ’NSArray’ og ’NSMutableArray’. Du kan forhåbentlig selv regne forskellen ud.

I dette projekt vil vi bruge den muterbare version af begge disse klasser. Vi skal bruge muterbare strenge, fordi brugerne skal kunne redigere dele af huskesedlen, og den nemmeste måde at gøre det på er at lade dem redigere delene på deres plads.

Vi skal også bruge et muterbart array, for ellers ville brugerne ikke kunne tilføje og fjerne dele. Lad os begynde med arrayet. Vi skal bruge en meget enkel programmeringsteknik i Objective C, der hedder ’Properties’. Syntaksen er lidt vidtløftig, og vi anbefaler derfor, at du lærer den udenad så hurtigt som muligt.

Egenskaber

Vores huskeseddel skal gemmes i et ’NSMutableArray’, og den korrekte måde at oprette det ’NSMutableArray’ på er med en egenskab. Det er en net del af Objective C-syntaksen, der betyder ”Når jeg prøver at få værdien, skal du køre denne metode, men når jeg prøver at indstille værdien, skal du køre denne metode i stedet”.

Det hele drejer sig om værdier, i modsætning til at indstille værdierne direkte. Det er naturligvis irriterende at skulle skrive to metoder for at få og indstille hver værdi, og derfor har Objective C en speciel syntaks, der kan generere disse metoder for os, når koden bliver kompileret.

Hvis du en dag vælger at skrive din egen, skal du blot bede den om at holde op med at autogenerere de metoder, som du vil erstatte. Det er nemt nok.

Allerførst skal vi fortælle Objective C, at vi vil have et ’NSMutableArray’ til vores begreber. I RootViewController.h – definitionsfilen for vores tabeloversigt – skal vi modificere klassens definition således:

@interface RootView-
Controller:
UITableViewController {
NSMutableArray *items;
}

@property (nonatomic,
retain)
NSMutableArray *items;
@end

Det ser umiddelbart ud, som om vi deklarerer vores ”begrebs”-array to gange, men der en forskel: Den første deklaration laver variablen, så den kan bruges overalt inden i klassen, men den anden deklaration ændrer den til en egenskab, således at den kan bruges overalt i vores kode.

Hertil kommer, at nøgleordet »retain« fortæller Objective C, at hvis den genererer koden for os, skal den holde objektet i live, indtil vi siger noget andet. Vi siger »hvis den genererer koden«, fordi det kommer senere. Skift til filen RootViewController.m, og indsæt denne linje kode umiddelbart under »@implementation RootViewController«:

@synthesize items”;

Det er det, der udløser kodegenereringen – med den enkelte linje vil Objective C omdanne vores ”@property” til to metoder, der begge udfører hukommelsesstyring for os automatisk.

Der mangler dog en sidste del. Brugen af retain holder items-objektet i live, indtil vi vælger noget andet. Hvis du aldrig gør det, bliver den hukommelse aldrig frigivet – selvom du ikke kan få adgang til den længere. Derfor bør man altid frigive hukommelse, som man har tilbageholdt. Gå til bunden af filen RootViewController.m, og led efter ”dealloc”-metoden. Lav den om, så den ser sådan ud:

– (void)dealloc {
[items release];
[super dealloc];
}

Når man sender release-besked-en til et objekt – og det er det, den- ne kode gør – fører det i dette til- fælde til, at der bliver frigivet hukommelse. Det er faktisk lidt mere kompliceret end som så, men det virker godt nok lige nu.

Udfyld tabellen

Nu da vi har deklareret en items-array, kan vi oprette nogle items og vise dem i tabellen. Men først skal vi lave det items-array. Og takket være de forbløffende kræfter, der ligger i magasintelepati, læser vi dine tanker: »Tøv en kende … har vi ikke lige skrevet noget kode, der gør alt det?« Ikke helt, faktisk. Vi skrev kode til at deklarere variablen, så den er til rådighed – nu skal vi til at bruge den.

Se også:  Nu kan du køre Android-apps på Windows-computeren

Tæt på toppen af RootViewController.m er beskeden »viewDidLoad« blevet kommenteret ud. Fjern »/*« og »*/« for at ukommentere den, og tilføj:

Self.items = [NSMutab-
leArray
ArrayWithCapacity:10]

Når det er på plads, er vores array parat til at blive brugt. Blad lidt ned i filen, og led efter metoden ’numberOfRowsInSection’ – den bestemmer, hvor mange rækker der fremkommer i tabellen i din brugerflade.

Hvor mange? Det er nemt nok – lige så mange, som der er items i items-arrayet. Lige nu har standard-metodeimplementeringen ’return 0’, hvilket betyder ’0 rækker’. Lav det om, så antallet af items i ’items’ bliver returneret:

return [items count];

Nu skal vi ændre den måde, tabelrækker bliver oprettet på, så de viser teksten for det korrekte huskeseddel-item. Ligesom med andre metoder omfatter Apples skabelon allerede kode, der kan gøre det meste af dette arbejde – du skal faktisk kun tilføje en linje, der siger ”indstil denne rækkes tekstmærkat til, hvad der måtte være i dit items-array ved den position”.

Halvvejs nede i filen RootViewController.m er metoden, og du burde kunne se, at den modtager en parameter, der hedder ’indexPath’. Den fortæller, hvilken række vi skal indlæse. Lige under den kommentar, der lyder »configure the cell«, skriver du:

Cell.textLabel.text =
[self.itemsobjectAt-
Index: indexPath.row];

Det bruger rækkens position som nævnt i ’indexPath’ til at kigge i items-arrayet og knytte den korrekte tekst til tabelrækken. Men hvis du kører app’en, gør den stadig intet, selv efter al denne kode. Det skyldes heldigvis, at vi ikke har nogen items i arrayet, og derfor skal vi føje en knap til navigationsbjælken foroven, der giver brugere mulighed for at tilføje nye items.

Tilføj nye items

Det er i virkeligheden to opgaver. At tilføje en knap og at skrive koden, så den reagerer på, at der bliver trykket på knappen. Den første opgave er meget enkel – i metoden ’viewDidLoad’ skal du indsætte denne kodelinje:

self.navigationItem.
leftBarButtonItem =
[[[UIBarButtonItem
alloc] initWithBar-
ButtonSystemItem:UI-
BarButtonSystemItemAdd
target:self action@-
selector(addTapped))]autorelease];

Den gør flere ting på en gang: »self.navigationItem.leftBarButton« betyder, at vi indstiller den venstre knap (hver navigationsbjælke kan have en knap til venstre og en til højre). »UIBarButtonItem alloc« opretter den nye knap, og »initWithBarButtonsSystemItem« opretter knappen ved hjælp af »UIBarButtonSystemItemAdd«.

Det betyder, at den bliver vist med et +-symbol. »Target:self« betyder, at når der bliver trykket på knappen, bliver den besked, der siger det, sendt til RootViewController.m. »@selector(addTapped)« er den måde, som RootViewController.m får at vide, at der bliver trykket på knappen – metoden »addTapped« bliver kørt. Og »autorelease« tæller ned, når det gælder brugen af knappen. Den bliver dog ikke frigivet, fordi »leftBarButton« holder den tilbage.

[pt id=’2015626′ size=’large’ link=’file’ html_attrs=’title=”Hvis det lykkes dig at få din app på topti på Apples lister får du større salg. Det lønner sig at være dygtig.”‘]

Hvis det lykkes dig at få din app på topti på Apples lister, får du større salg. Det lønner sig at være dygtig.

Den enkelte kodelinje skaber en ny knap med et +-symbol og sætter den til at kalde »addTapped« i RootViewController.m, når der bliver trykket på den, hvorefter den bliver føjet til sin navigationsbjælke.

Vi har endnu ikke metoden addTapped, men det er ikke kompliceret – der skal blot oprettes en ny ’NSMutableString’ med noget standardtekst i, og så skal tabellen genindlæses, så den kommer frem. Læg denne nye metode et sted i din RootViewController.m-fil:

-(void)addTapped {
[self.items
addObject:
[NSMutableString
stringWithString:
@”New Item”]];
[self.tableView
reloadData];
}

Som du kan se, skal man blot bruge metoden addObject for at tilføje et objekt til et NSMutable Array, selvom det følgende kan virke lidt forvirrende – den skaber en ny ’NSMutableString’ ud af en simpel tekststreng. Bemærk, at alle NSStrings i Objective C skal begynde med ”@”, så man kan skelne dem fra almindelige C-karakterkonstanter.

Hvis du kører app’en nu, kan du tilføje nye rækker ved at trykke på [+]-knappen. Den gør dog stadig ingen gavn, for man kan faktisk ikke redigere noget. Lad os komme i gang med det.

Af sted ind i IB

Nu er vi i gang med den sidste del af vores projekt. Der resterer kun en ting: Vi skal kunne redigere items på vores huskeseddel. Når et nyt item bliver tilføjet, skaber vi det som en muterbar streng og føjer det til vores samling. Alt, hvad vi nu mangler, er en mere enkel brugerflade, så vi kan redigere items.

Højreklik på ’Classes’, og vælg ’Add à New File’. Vælg ’UIViewController subclass’, og sørg for, at tjekboksene nedenunder er fravalgt, bortset fra den, der er markeret ’With XIB for user interface’ – det er den del, der giver os mulighed for at trække og slippe brugerfladeelementer, når vi har brug for dem.

[pt id=’2015625′ size=’large’ link=’file’ html_attrs=’title=”Husk at lave nogle flotte billeder hvis du gerne vil have din app på iTunes’ forside.”‘]

Husk at lave nogle flotte billeder, hvis du gerne vil have din app på iTunes’ forside.

Når du bliver bedt om et navn, skal du kalde det EditController – det er det, vi skal bruge til at redigere items på huskesedlen, og Xcode opretter EditController.h, EditController.m og EditController.xib for os. Det er den sidste, vi er interesserede i – det er en xml-fil, der kan redigeres af Interface Builder, så dobbeltklik på den for at åbne den i IB.

Interface Builder

Interface Builder består af fire hovedvinduer: ’Library’, der viser alle de brugerfladekomponenter, man kan bruge; ’Workspace’, der er den grafiske layoutvisning, hvor du kan lave dine mesterværker inden for brugerflade; ’Document Window’, der viser en træbaseret udgave af dit layout; og ’Inspector’, som er det sted, hvor du kan indstille forskellige egenskaber for din brugerflade.

Lige nu skal vi bruge ’Work-space’. Se i ’Document Window’ efter ’View’ (den er under ejeren af ’File’), og dobbeltklik på den for at fremkalde ’Workspace’. Det er et stort, tomt hvidt område med en lille grå iPhone-statusbjælke foroven. Du skal gå til ’Library’-vinduet og trække et ’Text View’ ind i det hvide område.

Når du har musen over området, kan du se, at dit text-view strækker sig ud og udfylder hele området. Slip, og det bliver lagt der. Ved hjælp af ’Inspector’ sletter du nu al den standardtekst, der er i ’Text View’.

Før vi kan bruge ’Text View’ i vores app, skal vi tilføje det som en egenskab (der følger de samme fire trin som før), og derefter arbejde med det i IB. Lad os begynde med egenskaben. I Xcode modificerer du EditController.h til det her:

#import <UIKit/UIKit.h>
@interface EditControl-
ler : UIVController {
UITextView *textView;
}
@property (nonatomic,
retain) IBOutlet UI-
TextView *textView;
@end

I filen .m skal du tilføje @synthesize textView; under ’@implementation EditController’ og tilføje textView release i metoden ’dealloc’ – ligesom vi gjorde med egenskaben ’items’ i RootViewController.m.

Der er en lille forskel her, og det er ’IBOutlet’. Når IB leder efter noget at forbinde sig med, scanner det din kildekode og søger ’IBOutlet’. Når vi føjer det til vores egenskab, betyder det i grunden ”Det her er noget, vi vil bruge i IB”.

Gem alle filerne i Xcode, og gå så tilbage til IB. Eftersom vi har fortalt IB, at det skal interessere sig for text-view, skal vi nu blot forbinde variablen ’textView’ i klassen ’EditController’ til det text-view, vi trak ind i ’Work- space’-vinduet.

Det gør du ved at lede efter ’File’s owner’ i Document-vinduet, holde [Ctrl] nede og klikke og trække en linje herfra til ’Text View’ og slippe. Nu kommer der en menu med en lis-te over mulige forbindelser, og der bør du kunne se ’textView’. Klik på den, så er du færdig. Gem filen, og luk den.

Vi har allerede startet IB, og der er endnu en ting, vi skal gøre: Vi skal give vores navigationsbjælke en titel. Det gør vi ved at gå ind i Xcode og dobbeltklikke på MainWindow.xib fra mappen ’Resources’.

Når den bliver indlæst i IB, dobbeltklikker du på navigationsbjælken øverst og giver den teksten Ta Da – den bliver også brugt til at generere tilbage-knappen, og den er derfor ret vigtig.

Rediger items

Når vores enkle brugerflade er færdig, består det næste trin i at få den til at komme frem, når der bliver trykket på et af vores items på huskesedlen. Det bliver styret i RootViewController.m i metoden ’didSelectRowAtIndexPath’.

Apple har lagt noget kode derind, som vi kan bruge – ukommenter den, skift de to forekomster af ’DetailViewController’ (med stort D!) og den enkelte forekomst af ’Nib name’ ud med ’EditController’.

Før det bliver kompileret, skal du fortælle Xcode, at du vil trække på filen EditController.h, som du lavede tidligere. Gå til filen RootViewController.h, og tilføj dette lige under den eksisterende #import-linje:

#import”EditControl-
ler.h”

Det styrer oprettelse og visning af redigeringsvinduet, men det viser ikke huskesedlens tekst i visningen. Det skal vi selv gøre ved at indsætte den valgte streng til redigering.

Først skal vi oprette en ’NSMutableString’-egenskab inden i ’EditController’ og kalde den todoitem. Vi har allerede vist, hvordan man færdiggør alle fire trin under oprettelsen af egenskaber. Gentag dem blot her. De interessante dele er, hvordan man viser teksten i huskesedlens item i visningen, og det sker i RootViewController.m. Før kaldet til ’pushViewController’ bliver foretaget i ’didSelect-RoxAtIndexPath’, skal du blot indstille variablen ’todoitem’ sådan:

DetailViewController.
todoitem = [self.items
objectAtIndex:
indexPath.row];

Det bruger ’indexPath.row’, der, som du sikkert husker, fortæller os, hvilken tabel vi har med at gøre – for at trække den korrekte ’NSMutableString’ ud fra arrayet ’items’ og gemme det i ’EditController’.

[pt id=’2015613′ size=’large’ link=’file’ html_attrs=’title=”Når du bruger ’pushViewController’ bliver din nye visning automatisk animeret ind. Titlen på den forrige visning bliver brugt til tilbage-knappen.”‘]

Når du bruger ’pushViewController’, bliver din nye visning automatisk animeret ind. Titlen på den forrige visning bliver brugt til tilbage-knappen.

Når det trin er overstået, kan vi få teksten til at komme frem i vores brugerflade ved at ukommentere standardmetoden ’viewDidLoad’ i EditController.m og tilføje denne enkelte kodelinje:

Se også:  Her er 8 uundværlige apps til sommerferie-turen - alle er gratis

TextView.text =
todoitem;

Når visningen bliver indlæst – hvilket sker umiddelbart efter kaldet til ’pushViewController’ – indstiller vi ’Text Views’ tekst i overensstemmelse med det item, vi har indsat. Perfekt.

De sidste finpudsninger

På dette tidspunkt kan vi opregne items, tilføje items og åbne redigeringsvinduet, men eventuelle ændringer bliver ikke gemt.

Det er dog nemt at ændre, for man skal blot vente på, at brugeren går tilbage til den forrige visning og derefter hente textView.text og gemme den. Begivenheden ’gå tilbage til forrige visning’ bliver sendt til os i form af ’viewWillDisappear’, som ’EditController’ modtager, når den skal erstattes af en anden visning.

I EditController.m skal du oprette en ’viewWillDisappear’-metode. Følg Apples eksempel, og kald den samme metode på superklassen, før du laver dine egne sager. Det bør se sådan ud:

/-(void)viewWillDis-
appear:(BOOL)animated {
[superviewWillDisap-
pear:animated];
todoitem seString:text-
View.text];
}

Den interessante del her er kaldet til ’setString’, der ændrer indholdet af en ’NSMutableString’ til noget ny tekst. Denne ’NSMutableString’ bliver delt mellem ’EditController’ og ’RootViewController’, hvilket betyder, at vi ændrer vores masterkopi af vores huskeseddel-item.

Der er lige en sidste ting at gøre, før vi kan afslutte dette projekt, nemlig at opdatere vores ’RootViewController’-tabel, når et huskeseddel-item er blevet redigeret. Vi har haft ’viewWillDisappear’ i ’EditController’, og nu skal vi arbejde med dens modstykke, ’viewWillAppear’, i ’RootViewController’.

Igen finder du en udkommenteret version, der allerede er der, i toppen. Alt, hvad du skal gøre, er at fjerne kommentarmærkningerne og tilføje denne enkelte kodelinje til metoden:

[self.tableView reload-
Data];

Vi har dette ’tableView’, fordi vi har arvet det fra ’UITableViewController’. Når du kalder ’reloadData’, genstarter det hele processen med at spørge, hvor mange rækker der er, og hvad disse rækker indeholder.

Det er slutningen på projektet. – Vi har ikke lavet en vældig masse her, men hvis du har fattet alt på disse sider, har du et glimrende grundlag for at arbejde med de centrale dele af iOS-app-udvikling, herunder hukommelse, view-controllers, Interface Builder, strenge og arrays og naturligvis iTunes Connect – det er her, du faktisk kan tjene penge!

[pt id=’2015624′ size=’large’ link=’file’ html_attrs=’title=”Anmeldelser fra brugerne kan give dine apps succes eller fiasko. Bed dine venner om at tilføje en femstjernet anmeldelse for at sætte gang i salget.”‘]

Men der er ingen ide i at lære alt det her, hvis du ikke bruger det. Hvis du vil have al denne abstrakte viden til at lejre sig grundigt i din hjerne og bliver virkelig nyttig, er tiden inde til at gå i gang med at lave din første app.

Det behøver ikke at være en utrolig, indbringende ide, men hvis du finder på noget fremragende og tjener en formue på dine anstrengelser, så husk, hvem der lærte dig det!

1. Før du kan downloade SDK, skal du registreres som iOS-udvikler online på http://developer.apple.com//ios. Klik på linket ’Register’ øverst til højre på siden.

[pt id=’2015620′ size=’large’ link=’file’]

 

2. Når du har fået en konto, skal du blade ned til bunden af forsiden og finde den nyeste iOS SDK-version – her er det Xcode 3.2.5 og iOS SDK 4.2.

[pt id=’2015619′ size=’large’ link=’file’]

 

3. Begynd at downloade
Lav en kop kaffe eller lær et nyt sprog. Det er en download på 3,5GB, og det
tager tid.

[pt id=’2015618′ size=’large’ link=’file’]

 

4. Når din download er færdig, skal du starte dmg-filen. Nu bør du få præsenteret dette vindue. Dobbeltklik på pakken ’Xcode og iOS SDK’ for at pakke den ud.

[pt id=’2015617′ size=’large’ link=’file’]

 

5. Medmindre du virkelig mangler plads, bør du lade pakkens standardvalg være intakte, så får du stort set det samme udviklingsmiljø som alle andre.

[pt id=’2015616′ size=’large’ link=’file’]

 

6. Du finder Xcode i ’Developer – applications’. Opret et nyt projekt, og find skabelonen ’Navigation-based application’ for at komme i gang med din app.

[pt id=’2015615′ size=’large’ link=’file’]

 

1. Interface Builders brugerflade er delt mellem fire vinduer. Hvis du har tænkt dig at bruge en MacBook på 13” til kodearbejdet, bør du nok tænke om igen. Du vil ikke kunne se det hele.

[pt id=’2015623′ size=’large’ link=’file’]

 

2. Nu skal du trække en ’Text View’-widget fra ’Library’-vinduet ind i dit view-layout – det er fuldt af mumletekst, men du må gerne fjerne den, hvis du vil.

[pt id=’2015622′ size=’large’ link=’file’]

 

3. Lav en forbindelse mellem brugerfladens ’Text View’ og kodevariablen ved at holde [Ctrl] nede og trække en linje fra ’File’s Owner’ til ’Text View’.

[pt id=’2015621′ size=’large’ link=’file’]

 

Når din app er færdig, skal du have den godkendt af Apple, så den kan blive publiceret i App Store. Den proces kræver en vis indsats, for du skal skrive metadata om din app, såsom dens App Store-kategori, pris, aldersgrænse, søgeord og skærmbilleder. Læs mere om godkendelseskravene i næste afsnit.

Når det er gjort, bliver dit største problem sandsynligvis certificering af din fil. Apple vil ikke have folk til at køre en hvilken som helst app på deres telefoner. Derfor har man et system, der kaldes ’provisioning’. Det fungerer sådan: Du fortæller Apple, hvilken app du arbejder på. Det er dit App ID, og du må have så mange, du vil. Hver enhed har en unik identifikation, og din app kan kun køre på dem, du opregner. Du kan have 100 enheder på din konto.

[pt id=’2015614′ size=’large’ link=’file’ html_attrs=’title=”Dette er iTunes Connect den motor bag iTunes som udviklerne bruger til at styre deres software. Hvis du vil publicere dit værk på App Store er det her magien finder sted.”‘]

Til sidst skal du fortælle Apple, hvem du er. Det indebærer oprettelsen af et offentligt/privat nøglepar, der er unikt for dig som udvikler. Det bruger du til at signere dine filer og dermed love, at de kommer fra dig og ingen anden.

Disse tre vilkår udgør tilsammen det, der kaldes en provisioning profile, der betyder, at en profil arbejder for en app på et specifikt sæt af enheder, og at den bliver leveret med de løfter, som du har aflagt. Denne profil bliver brugt til at signere din fil digitalt, og derfor kan man ikke siden ændre den uden at gøre signaturen ugyldig.

Når du har været gennem dette cirkus og har testet, at din app virker på rigtige enheder, skal du uploade den, så Apple kan teste den. Det tager cirka en uge. Efter syv dage bør du altså modtage enten ”Ja, din app er blevet godkendt til salg” eller ”Nej, vi kan ikke godkende din app på grund af XYZ. Bring den venligst i orden.”

Hvis din ansøgning bliver godkendt, bliver din app automatisk indsat i App Store og kan

Apple lader ikke enhver app ligge på App Store, og vi har da også modtaget en del afvisninger via e-mail. Der er forskellige strenge kriterier, som man skal leve op til, hvis man vil have sin app sat til salg.

Først er der det sædvanlige: ingen pornografi, intet hadefuldt materiale og intet ulovligt. Det lyder nemt nok, selvom Apples definition på pornografi går helt ned til kvinder, der er iført strandtøj. Det næste burde være indlysende, men det gælder åbenbart ikke for udviklere: En app må ikke gå ned, og den skal gøre det, der står i beskrivelsen. Lad være med at prøve at snyde.

[pt id=’2015612′ size=’large’ link=’file’ html_attrs=’title=”Xcode er dit primære udviklingsmiljø til iPhone. Nogle kan lide det de fleste kan ikke lide det men desværre har vi ikke noget valg.”‘]

Xcode er dit primære udviklingsmiljø til iPhone. Nogle kan lide det, de fleste kan ikke lide det, men desværre har vi ikke noget valg.

Herefter bliver det mere uklart. Man skal bruge Apples brugerflade korrekt, ens app skal være ”lødig”, man må ikke bruge et funktionskald, som Apple ikke bryder sig om, man må kun bruge webbrowseren WebKit, ens app må ikke kun være markedsføring for et produkt, man fremstiller, den må ikke være smålig, den må ikke omfatte nogen form for russisk roulette og så videre.

Reglerne kan umiddelbart virke forrykte, men med 360.000 apps i omløb er det tydeligvis ikke særlig vanskeligt at efterleve dem.

Hvad er meningen med at lave apps til iOS, hvis du ikke kan tjene penge på dem? Hvis du har løst dit eget behov, har du sikkert gjort enheden mere anvendelig. Derfor er det ikke så vigtigt at tjene penge. På den anden side: Hvis folk vil dig give dig nogle af deres penge for dit hårde arbejde, skulle du så sige nej?

Der er to ting, du skal tænke på, når det gælder penge. Den første er prisen: Mange tror, at 6 kroner er den nye pris, men Apple sælger glad og gerne din app for over 500 pund (cirka 4.200 kroner), hvis du ønsker det. Der er stor forskel på downloadmængden, når det gælder gratis apps og betalingsapps – folk elsker at prøve gratis apps, og du kan derfor overveje at lave en beskåret prøveversion af din app og gøre den gratis.

[pt id=’2015628′ size=’large’ link=’file’ html_attrs=’title=”Så snart pengene begynder at strømme ind vil du opdage at Apples salgstracker ikke er ret god til at overvåge din apps succes. Hvis du seriøst vil følge med i salg og anmeldelser skal du prøver AppViz.”‘]

Så snart pengene begynder at strømme ind, vil du opdage, at Apples salgstracker ikke er ret god til at overvåge din apps succes. Hvis du seriøst vil følge med i salg og anmeldelser, skal du prøver AppViz.

Den anden ting er markedsføring. Apple har salgsoversigter, anbefalede apps, Staff Favourites og andet. Hvis du kommer på en af disse lister, stiger dit app-salg til det tidobbelte. Det er derfor i din interesse at være aggressiv på prisfronten. Kort sagt: Hvis du ikke er på listen over anbefalede apps, bør du satse på en lav pris. Når du er kommet på listen, kan du overveje en højere pris – du ligger der, uanset hvor mange du sælger, og du kan lige så godt tjene nogle flere penge.

Som en hjælp til markedsføringen leverer Apple 50 pr-udgaver af hver app, du laver. Dem kan du give til pressen eller forære væk for at skabe interesse om din app. Disse udgaver får du for hver version af din app. Hvis du udgiver en opdatering, der løser tidligere problemer, får du yderligere 50 udgaver. Husk, at selvom du har haft mange opdateringer og har frigivet alle udgaverne hver gang, taler vi kun om 500 gratis udgaver i et hav af 100 millioner brugere. Vær gavmild.

[themepacific_accordion] [themepacific_accordion_section title=”Fakta”]

Det skal du bruge …

[/themepacific_accordion_section] [themepacific_accordion_section title=”Fakta”]

Retain/release

[/themepacific_accordion_section] [themepacific_accordion_section title=”Fakta”]

Alloc og init

[/themepacific_accordion_section] [/themepacific_accordion]


TAGS
App Store
apps
Guide

DEL DENNE
Share


Mest populære
Populære
Nyeste
Tags

Find os på de sociale medier

Modtag dagligt IT-nyhedsbrev

Få gratis tech-nyheder i din mail-indbakke alle hverdage. Læs mere om IT-UPDATE her

Find os på FaceBook

AOD/AOD.dk

Brogårdsvej 22
DK-2820 Gentofte
Telefon: 33 91 28 33
redaktion@aod.dk

Audio Media A/S

CVR nr. 16315648,
Brogårdsvej 22
DK-2820 Gentofte
Telefon: 33 91 28 33
info@audio.dk
Annoncesalg:
Lars Bo Jensen: lbj@audio.dk Telefon: 40 80 44 53
Annoncer: Se medieinformation her


AOD/AOD.dk   © 2020
Privatlivspolitik og cookie information - Audio Media A/S