Apps tilbyr spennende jobbmuligheter for deg med tung spisskompetanse og engasjement for mobile flater. Miljøet er ungt og beslutningsprosesser er raske.

Klikk for mer info

Ny adresse for Apps AS og Apps Consulting er:
Maridalsveien 13e
0178 Oslo

Bedre brukergrensesnitt

Den største og viktigste nyheten i ICS er overhalingen av brukergrensesnittet til Android. Når Google lanserte Android 3.0 “Honeycomb” for tablets så introduserte de også en ny stil for Android som de kalte for “Holo”. Med ICS har Google tatt designspråket fra 3.0 og raffinert det en smule samtidig som de har oppgradert samtlige standard applikasjoner, gui komponenter og generelle funksjoner til en helhetlig pakke. ICS har til og med fått en helt ny systemfont som heter Robotica.

Dette nye grensesnittet er nå raskere, glattere og mer responsivt en 2.3 (den forrige telefonversjonen av Android) da alt nå er tegnet av enhetens grafikkort istedenfor prosessor. Animasjoner vil nå være enklere og mer avanserte samtidig som de vil gå glattere og raskere en tidligere.

Widget systemet er nå kraftigere og har støtte for blant annet skrolling i lister og noe som heter stacks. Dette betyr at du kan ha lister og mer kompliserte widgets på hjemmeskjermen. Widgets kan nå også endres i størrelse så du slipper å ha flere versjoner av widgeten om den du lager er strekkbar. Widgets er nå også enklere å oppdage for brukere da de har fått sitt eget galleri ved siden av applikasjonene under “Widgets” som viser forhåndsvisning av alle widgets på telefonen.

Det skal også nevnes at ICS endelig gir Android støtte for å ta skjermbilder av telefonen, en nyhet som vil gi utviklere og brukere stor glede.

For telefoner og tablets

ICS er for både tablets og telefoner, det vil si at det er samme versjon av Android på telefoner som på tablets, eneste forskjell er hvor store skjermer de har. Å lage applikasjoner som skalerer til alle størrelser vil dermed bli enklere og mulighetene i appene blir større.

NFC blir bedre

Med 2.3 introduserte Android støtte for NFC teknologien. NFC står for Near Field Communication og er kort forklart et system som gjør det mulig å lese enkle brikker, f.eks på en plakat, eller utveksle enkel informasjon med en annen NFC enhet som f.eks en betalingsterminal. NFC krever at du har telefonen nærme det du skal lese av eller kommunisere med.

I ICS introduseres Android Beam som er et system for å dele innhold imellom enheter med NFC. F.eks vil du kunne enkelt dele bilder og andre filer ved å legge telefonen mot en annen telefon, få opp en “bekreft deling” dialog og deretter raskt sende over bildet eller filen til den andre telefonen. Dette systemet bruker også Wi-Fi direct som oppretter en direkte en-til-en WiFi kommunikasjon med andre enheter.

NFC teknologien har mange mulige anvendelser, et spennende prosjekt er Google Wallet i U.S.A der du kan gjøre småkjøp i butikker ved å bruke mobilen din som lommebok. For mer info se her: http://www.google.com/wallet/

Støtte for USB enheter og hardware

Med ICS kan du koble mange standard USB enheter til telefonen din og bruke dem som normalt. F.eks vil du kunne koble til en USB spillkontroller og bruke den for å styre spill på telefonen din. Det finnes også APIer for å kommunisere med hardware som finnes under ADK dokumentasjonen. Dette er et åpent API som lar deg koble hardware til Androiden og kommunisere med den, f.eks koble den til en tredemølle og få avlesning i en app.

Sosialt API

Med det nye sosiale APIet kan din app enkelt integreres med kontaktlisten til brukeren. F.eks om du instalerer LinkedIn appen vil du kunne se et LinkedIn ikon under kontakter som har LinkedId og du vil enkelt kunne legge til nye LinkedIn kontakter. Dette systemet gjør sosiale apper mer kraftige og gjør det mulig med enda større deling av data på tvers av personer og applikasjoner.

Men hva med Android fragmentering?

Siden forskjellige Android versjoner har store markedsandeler hver kan det være lett å tenke at funskjonene og mulighetene i Android 4.0 ikke vil være tilgjengelig for apper eller utviklere i lang tid fremover. Dette stemmer ikke da Android er utviklet med tanke på bakover og fremover kompabilitiet. Det er mange muligheter for utviklere å bruke 4.0 funksjoner samtidig som applikasjonen støtter telefoner med Android 1.6. Dette er et tema jeg ønsker å komme tilbake til, men jeg nevner raskt noen strategier:

• Sjekk ut distribusjonen av dagens Android versjoner her og velg et minstenivå som er hennsiktsmessig for din app
• Se hvilke funksjoner du trenger eller må ha i appen og start på den versjonen av Android som har disse funksjonene
• Bruk refleksjon og versjonssjekking i appen for å ha forskjellige nivåer av funksjonalitet i applikasjonen
• Lag flere versjoner av samme app som er myntet på forskjellige versjoner av Android, publisert som en app da Android Market støtter flere versjoner på samme oppføring

Den siste løsningen er ganske ekstrem og mest aktuell for krevende applikasjoner som f.eks spill der det vil være ønskelig å lage versjoner som krever mer eller mindre fra telefonene. Det viktigste poenget her er at Android fragmentering er ikke et problem, det er en utfordring å ta hensyn til når man designer og lager en Android applikasjon. Det er også et poeng at det vil være mulig allerede i desember å lage applikasjoner som drar nytte av funksjonene i Android 4.0 Ice Cream Sandwich i din applikasjon.

1. Beta testing på iOS
2. Beta testing på Android

Når Apps AS er ferdig med utviklingsfasen av en Android app, er den klar til å bli testet av kunden. Vi vil da “pakke” appen til en fil som vi sender ut til de som skal teste appen. Denne filen (appen) har filendelsen .apk (eks: kronespillet-1.0.apk). Så snart du har mottatt denne filen (ofte på e- post) må appen installers på Android håndsettet ditt. Dette kan gjøres på ulike måter, og du må finne den måten som passer/ virker for deg.

Dersom har en gammel versjon av appen liggende på håndsettet ditt, avinstaller denne før du installerer ny.

Installer fra telefonens Gmail klient

Dersom du bruker gmail til å lese e-post på telefonen din, kan du installere betaen direkte fra gmail.

Dette trenger du:

• Android appen “tAttachApkInstaller” (lastes ned gratis fra Android Market): https://market.android.com/details?id=jp.co.taosoftware.android.attachapkinstaller

1. Åpne e-post med beta

Som oftest vil du få tilsendt betaen til din e-post adresse. Åpne denne e-posten på telefonen du ønsker å teste med.

2. Åpne beta fil og installer

Sørg for at du har installert appen “tAttachInstaller” (gratis på Market).

a) I e- posten, åpne beta fila som er vedlagt. Du vil da få en dialog “Fullfør handling med”.

b) Velg “tAttachApkInstaller”.

Fullfør installeringen slik du er vant til fra Android Market. Appen skal da være installert og klar til beta- testing.

Installer fra PC/ MAC

Dette trenger du:

• USB- kabel av typen som fulgte med telefonen
• Android appen “Astro File Manager” (lastes ned gratis fra Market): https://market.android.com/details?id=com.metago.astro

1. Lagre .apk fil på din PC/ MAC

Lagre beta fila (.apk) som du har mottatt på en lett tilgjengelig plass på datamaskinen.

2. Koble håndsettet til PC/ MAC

Bruk USB- kabelen som fulgte med telefonen din og koble håndsettet til datamaskinen din. Du vil da få en melding om at USB er tilkoblet.

a) Trykk på meldingen “USB tilkoblet” e.l. En dialog vil dukke opp som spør om du ønsker å “montere” telefonen.

b) Trykk på “Monter”.

Håndsettet ditt skal nå være koblet til datamaskinen og du er klar til å overføre appen til telefonen.

3. Overfør appen fra PC/ MAC til telefonen

På datamaskinen din vil hånsettet ditt dukke opp som tilkoblet device (slik som minnepenner etc. bruker å dukke opp). Overfør beta fila (som du lagret i pkt. 1) til håndsettet.

4. Installer appen

a) Åpne appen “Astro File Manager” (gratis på Market). Men denne kan du browse filene på håndsettet ditt.

b) Åpne mappen “sdcard” (kan i noen få tilfeller ha et annet navn). Inne i denne mappa vil du finne applikasjonen du overførte fra datamaskinen.

c) Trykk på appen (.apk fil).

d) En dialog vil dukke opp. Trykk på valget “Open App Manager”. I den påfølgende skjermen, trykk på knappen “Install”.

Fullfør installeringen slik du er vant til fra Android Market. Appen skal da være installert og klar til beta- testing.

1. Beta testing på iOS
2. Beta testing på Android

Når utviklingen av en iPhone/ iPad app er ferdig, bruker Apps AS et “system” ved navn TestFlight til å distribuere appen til kunder for testing. TestFlight forenkler vesentlig distribusjonen av beta- tester til folket.

1. Registrer deg som bruker på TestFlight

Når det er tid for beta testing vil du fra Apps AS motta en link til et registreringsskjema som du bruker til å registrere deg i TestFlight.

Slik ser registreringsskjemaet ut (illustrasjonseksempel)

2. Registrer håndsett i TestFlight

Så snart du har registrert deg i TestFlight, vil du motta en email fra TestFlight: “Welcome to TestFlight”. Åpne denne emailen på iPhone/ iPad du ønsker å beta teste med.

a) Trykk på “Login” knappen. En webside vil åpnes.

b) Trykk på “Register Device” knappen. Et nytt vindu vil åpnes.

c) Trykk på “Installer” knappen. Et beskjed “Installer profil” vil dukke opp

d) Trykk “Installer nå”.

Dersom du blir bedt om å oppgi en kode, skriv inn koden du bruker til å låse opp håndsettet ditt med.

Dersom du ønsker å beta teste med flere håndsett, repeterer du dette steget (pkt. 2) for alle disse håndsettene.

3. Installer beta på håndsettet ditt

Når Apps AS har klargjort appen for testing, vil du få en email fra TestFlight som inviterer deg til å delta i beta testingen. Denne emailen har tittel “Appnavn 1.1.1 (27) is now available” eller lignende. Åpne denne mailen på håndsettet ditt.

a) Trykk på “Install” knappen. En nettside vil åpne seg.

b) Trykk på “Install” knappen. En beskjed “testflightapp.com vil installere <<Din app>>” vil dukke opp.

c) Trykk “Installer”. Appen vil nå bli installert på telefonen.

Appen skal nå bli installert på telefonen din.

En av de mest omtalte og spennende nyhetene i iOS 5 er iCloud. Kort sagt er iCloud en tjeneste som gir oss automatisk lagring og synkronisering av data mellom Apple enheter (iPhone, iPad, Mac, iPod Touch).

For forbrukeren betyr dette at alt som tidligere ble sikkerhetskopiert til datamaskinen når man synkroniserte med iTunes nå blir automatisk lagret i skyen. For oss utviklere betyr iCloud nye muligheter (og noen begrensninger).

Lagring og synkronisering

Med iCloud kan vi som utviklere lagre og synkronisere data fra en app på en enhet til den samme appen på en annen enhet. Et godt eksempel kan være en notat-app som jeg har installert på både iPhone’n og iPad’en min.  Når jeg legger til eller endrer et notat på telefonen, vil iCloud få beskjed om dette, og automatisk gi beskjed til appen på nettbrettet. Når jeg da senere åpner appen på nettbrettet vil jeg kunne se endringene jeg gjorde på telefonen tidligere.

Konflikter – et nytt hinder

En ny utfordring som kommer på grunn av dette er hva som skjer om vi har to konflikterende versjoner av det samme dokumentet. Om jeg legger til “melk” i et handlelistenotat på telefonen samtidig som en annen i familien legger til “egg” i det samme notatet på nettbrettet, vil vi ha to likeverdige versjoner av dokumentet som likevel er forskjellige.

Man må derfor ta hensyn til versjonskontroll og kombinering av to likeverdige versjoner. Man har flere mulige måter å håndtere dette på. Den enkleste måten er å automatisk forkaste den gamleste versjonen, og istedet bruke den nyeste. I vårt tilfelle vil det være uønsket, da en av de to elementene vi la til i listen vil forsvinne. Vi kan eventuellt prøve å se på likheter i dokumentet, og enten legge til begge endringene (både “egg” og “melk”), eller vise brukeren de to forskjellige dokumentene, og spørre hvordan brukeren vil at vi skal kombinere dokumentene. Uansett løsninsstrategi er det noe man må tenke gjennom når man designer appen. Det er også anbefalt at man viser brukeren hvilken status dokumentet har (lagret/synkronisert – ikke lagret/offline – i konflikt).

Lagring er begrenset – ta hensyn til brukeren

Et annet problem med iCloud som man må ta høyde for uansett om man bruker det direkte i appen eller ikke er at iCloud tar backup av selve appen og dokumentmappen til appen. Dokumentmappen er den vanligste plassen å lagre data som appen bruker. Siden iCloud har begrenset med plass er det viktig for brukerne at app utviklerne tar hensyn til den begrensete plassen, og passer på å ikke fylle dokumentmappen til appen med unødvendig data.

Apple anbefaler at man kun lagrer data i dokumentmappen som ikke kan genereres eller lastes ned på nytt. Alt som kan genereres eller lastes ned på nytt burde lagres i Cache mappen istedet. Et problem med det er at cache mappen automatisk tømmes når plassen på enheten begynner å bli liten. Fordelen er at man ikke bruker opp iCloud lagringsplassen til brukeren, da Cache mappen ikke lagres i skyen.

Spørsmålet er da hva man skal gjøre med data som man ikke ønsker å laste ned igjen, eller i det minste ønsker å ha kontroll over at ikke automatisk slettes. Et godt eksempel kan være artikler man laster ned fra nettet som man vil ha med på en lang flytur hvor man ikke har internett. Om man samtidig fyller resten av enheten med annen media, kan det være at enheten blir så full at Cache mappen blir slettet, og man ender opp med å miste artiklene sine. Dette vil føre til en veldig dårlig opplevelse for brukeren, uten at utvikleren har gjort noe “galt”. Dette kommer til å bli en større problemstilling fremover, med mindre Apple endrer policy på dette (eller legger til en plass man kan mellomlagre data uten å miste kontroll over når det skal slettes).

Konklusjon

iCloud er et kraftig system som kommer til å gjøre livet for iOS og Mac brukere mye enklere i fremtiden. Om man skal synkronisere data mellom andre plattformer en OSX og iOS, så må man ennå lage egne systemer, men så lenge man bare ønsker synkronsiering over disse plattformene så er iCloud alt man trenger. Det er også lurt å merke seg at iCloud kun synkroniserer mellom instanser av en app på en og samme konto. iCloud kan med andre ord ikke erstatte en webservice som skal koordinere data mellom flere brukere. For forbrukeren er det viktigste uansett at Apple tar vare på dataen din, slik at du har tilgang på den samme informasjonen uansett hvilken (Apple) enhet du er på, og at Apple tar vare på dataen din om enheten skulle gå tapt.

Oppdatering:
Macrumors melder at apple har løst problemet med hvor man skal lagre data, men som ikke skal synkroniseres med iCloud. Dette ved å la utvilkere spesifisere hvilke filer som skal ikke skal synkroniseres, men beholdes på enheten selv i situasjoner med lav lagringsplass.

http://www.macrumors.com/2011/11/02/apple-posts-ios-5-0-1-beta-for-developers/

“We think the open vs. closed is just a smokescreen to try and hide the real issue, which is: What’s best for the customer? Fragmented vs. integrated. We think Android is very very fragmented and becoming more fragmented by the day.”

Mens TweetDeck teamet har en litt annen vinkling på det:

“We were really shocked to see the number of custom roms, crazy phones and general level of customization/hackalicious nature of Android. From our perspective it’s pretty cool to have our app work on such a wide variety of devices and Android OS variations.”

Det er ikke til  å stikke under en stol at Steve Jobs og TweetDeck utviklerene kommer fra forskjellige synspunkt. Steve synes synd på sluttbrukere som må forholde seg til mer en ett type produkt, på samme måte som at det finnes forskjellige datamaskiner, macer og biler antar jeg. TweetDeck utviklerene syntes det er stas å se applikasjonen sin kjøre på så mange forskjellige typer mobiltelefoner og versjoner av Android. Men hva er egentlig Android fragmentering og hvor stort er dette problemet?

Hva Android fragmentering er og hva det betyr

Android er et mobil operativssystem eid av Mobile Handset Alliance og utviklet i stor grad av Google som er en viktig del-eier av MHA. Operativsystemet er såkallt åpen-kildekode og det er for mobilprodusentene svært få restriksjoner og krav til å kunne kjøre Android, strengt tatt ingen. Det finnes visse rettningslinjer og minimumskrav for å være såkallt kompatibel og disse blir fulgt av de store Android aktørene som HTC, Sony-Ericsson, LG, Samsung og fler. Men faktum er enkelt og greit at Android kjører på en mengde forskjellige telefoner med forskjellig CPU, skjerm, kvalitet, pris fra en rekke forskjellige produsenter. Mange produsenter velger også å lage sine egne varianter av Android som betyr at de legger litt ekstra funksjonalitet og grafisk grensensnitt på toppen av Android for å gi det et personlig preg og i noen tilfeller for å utfylle mangler ved Android. Hva betyr dette for applikasjoner, apps, på Android?

Det betyr at når man lager apps for Android så må man tenke på to ting:

1. Hardware
2. Android versjon

For hardware så vil det være viktigst når man skal lage spill og applikasjoner som krever kraftig cpu, gpu, stor skjerm osv. For de aller fleste apps så vil det være viktigst å ta hensyn til skjermstørrelse og Android versjon. Skjermstørrelsen er viktig da man vil presentere applikasjonen på en fornuftig måte på forskjellige skjermer og Android versjon for å vite hvilket SDK nivå applikasjonen skal baseres på. Det er disse faktorene som er vesentlige for en Android app, selv om en HTC Desire kjører Sense og en Samsung Galaxy S9000 kjører Touchwiz så er de begge ganske så like i og med at de kjører Android 2.2 og har store skjermer med HDPI oppløsning.

Når man lager en app så er det viktig å bestemme seg for hvilke mobiler du vil at appen skal kjøre på, dette kan du basere på tall fra Google om hvilke versjoner og skjermstørrelser som faktisk er i bruk i dag da de faktisk gir ut statistikk for dette. Google har faktisk tenkt på dette med forskjellige skjermer og telefoner så Android 1.6 og oppover gir en rekke gode verktøy for å optimalisere en og samme applikasjon mot alle typer nesten alle typer Android hardware. Foreløpig så mangler det skikkelige verktøy for å lage apps for tablets, men dette skal være på vei i enten Android 2.3 eller 3.0. Når du klekker ut din app så må du allikevel gjøre en vurdering på om det du vil oppnå lar seg gjøre på en X10 Mini eller om HTC Legend og oppover burde være et “minimum”. For de fleste apps vil det være mulig å tilrettelegge for alle typer androids.

Min erfaring med Android fragmentering

Jeg har en hobby app som heter “Busstider” som sjekker busstidene i Trondheim. Når jeg ga ut siste versjon for en måneds tid siden så implementerte jeg Google Analytics sporing for å samle inn (anonym såklart) data på hva slags Android brukere jeg har. Jeg ville vite:

• Android versjoner
• Skjermstørrelser
• Bruk av funksjoner

Jeg har nå fått inn mine resultater og for Android versjoner er de som følger:

Android versjoner for Busstider 30. okt – 28. nov

For Android OS versjon så var jeg positivt overrasket å se at Android 2.2 (siste versjon) dominerer min brukerbase med ca. 55% med 2.1 på solid andreplass og 1.6 på tredje. 1.5 har så lavt tall at det nå er klart at 1.5 for min del er ute og jeg tipper at 1.6 er ute om ikke så lenge. Å lage en app som krever Android 1.6 er med andre ord uproblematisk og straks vil 2.1 være et minimum.

Skjermstørrelser for Busstider 30. okt – 28. nov

Med skjermstørrelser så får man dobbelt sett med data, ett sett for portrett visning og ett sett for landskap avhengig av om brukeren har brukt det ene eller begge. Tallene viser at jeg kan gjøre følgende antagelser av min brukerbase sine telefontyper:

• 54% har store skjermer (HTC Desire, Samsung Galaxy S900)
• 20% har medium skjermer (HTC Legend, Samsung Spica)
• 20% har små skjermer (X10 Mini, HTC Tattoo)

Disse tallene viser at jeg burde optimalisere applikasjonen min for små skjermer og ikke minst støtte landskapsmodus. Dette er nå neste prioritet for videre utvikling av Busstider. Alt i alt så er jeg fornøyd med min Busstider applikasjon med tanke på at den fungerer på flere forskjellige telefoner. Utviklingen av Busstider har jeg gjort med emulatorer og min egen HTC Hero med Android 2.1.

Konklusjon

Er Android fragmentert? Ja, Android operativssystemet kjører på en mengde forskjellige type telefoner fra forskjellige produsenter og disse kjører igjen forskjellige versjoner av Android. Pr. 01.12.2010 så er 83% av telefonene på 2.1 eller høyere mens 1.5 er nede på 6.3%, tallene er hentet herfra og er basert på Android Market bruk fra hele verden.

Er det et problem at Android er fragmentert? Nei det er ikke et problem. Men det krever at man gjør det arbeidet som trengs for at din applikasjon skal fungere på Android 1.6, 2.1 og 2.2 , eller du kan velge at appen skal kreve 2.1 som minimum. Man må også ta hensyn til forskjellige typer telefoner og skjermstørrelser. Dette er riktignok litt mer arbeid en å utvikle mot 1 iPhone 2 iPhones og 1 iPad, men til gjengjeld når da applikasjonen din ut til en stor og variert gruppe telefoner og brukere. Dette er rett og slett en av utfordringene ved å utvikle for Android, det er IKKE et stort problem for Android plattformen eller din eventuelle Android app. For min Busstider applikasjon har det vært enkelt og smertefritt å gjøre appen funksjonell på forskjellige telefoner og det er gøy å se at den fungerer både på bittelille X10 Mini og mye større Galaxy Tab. Skulle du som leser dette være en Android utvikler så anbefaller jeg deg disse nettsidene for mer om Android skjermstørrelser og kompabilitet:

1. Supporting different screen sizes and densities
2. Android Compability

Og i det hele tatt lese det meste du finner på:

1. Android Developer
2. Reto Meiers blog <- Spesielt Reto Meiers sine “App Surgeries” er geniale for grensesnitt design og funksjonalitet med Android

Under finner du seks enkle steg som beskriver denne prosessen. Det beste ved disse gavene er at alt skjer på internett slik at man kan gjøre alt fra godstolen hjemme i stuen, gavekjøp har aldri vært så enkelt.

For å gi en app i gave gjør du følgende:

1. Velg iTunes Store og deretter App Store i iTunes.
2. Finn en applikasjon du ønsker å gi i gave.
3. Trykk på pilen til høyre for kjøp-knappen.
4. I menyen som kommer fram velger du “Gi i gave” eller “Gift this app”.

5. Etter at du har valgt å gi appen i gave vil du bli bedt om å fylle inn informasjon om mottaker.

6. Når skjemaet er fyllt ut vil du bli tatt til en ny side der du bekrefter bestillingen.

Er du usikker på hva du skal kjøpe kan du alltids starte med sjekke ut vårt utvalg av applikasjoner på App Store.

Før applikasjoner dukker opp på AppStore er det ofte ønskelig å teste en App på flere forskjellige enheter. Til dette formålet har man Ad-Hoc distribusjoner. En Ad-Hoc distribusjon lar oss sende ut en App til testing på enheter som vi har fått registrert UDID til.

For å kunne kjøre en Ad-Hoc distribusjon trenger først enheten man vil installere å være registrert i provisjoneringsprofilen til distribusjonen. Dette gjør vi når vi lager distibusjonen, men vi trenger å kjenne til UDID til alle enheter som skal kunne bruke distribusjonen før vi bygger den. Se guide for å finne din UDID.

Når vi sender ut en Ad-Hoc distibusjon sender vi som oftest ut en «.ipa» fil og en provisjoneringsfil. Den første inneholder applikasjonen, mens den andre trengs for å kunne kjøre distribusjonen.

Hva du trenger:

• Datamaskinen du normalt bruker til å synkronisere med enheten.
• Enheten du vil installere applikasjonen på (og som er registrert i provisjoneringsfilen)
• Filen som inneholder applikasjonen (med «.ipa» filendelse)
• Provisjoneringsfilen (med filendelse «.mobileprovision»)

Installering av applikasjonen

1. Finn frem «.ipa» og «.mobileprovision» filene du har fått av oss.

2. Åpne iTunes, og dra begge filene til «Programmer» under «Bibliotek». Applikasjonen skal da dukke opp i «Programmer» kategorien.

3. Koble til din enhet. Den vil da dukke opp i listen over enheter i venstre marg.

4. Velg «Programmer» siden i høyre vindu. Sjekk at «Synkroniser programmer» er valgt, og at Applikasjonen du vil installere er valgt i listen under.

5. Trykk «Synkroniser» knappen nederst til høyre for å synkronisere enheten, og vent på at iTunes installerer Applikasjonen. Du er nå klar til å teste programmet.

Om du vil installere applikasjonen på flere enheter fra samme applikasjon, gjennta steg 3-5 for hver enhet. (Husk at alle enhetene du vil teste på må være registrert med UDID hos oss før vi sender ut distribusjonen).

PS. Om du skal installere en nyere versjon av applikasjonen på enheten senere, vennligst slett applikasjonen både fra iTunes og enheten før du begynner å installere den nye versjonen.

Edit:

Ø. Syljuåsen kommenterte at det også er mulig å sende ut en Ad-Hoc distribusjon som overskiver en gammel versjon, men beholder data og instillinger fra den gamle distribusjonen. Installasjonen vil da foregå på vanlig måte, bare uten å slette applikasjonen fra iTunes/enheten først. Utviklerne må da passe på å oppdatere Bundle version i *-Info.plist til applikasjonen til et nytt versjonsnummer.