TestFlight: testa din iPhone-app innan du skickar in den

Vad är TestFlight och vad används det till?

TestFlight är Apples tjänst för att installera din app på riktiga iPhones innan den släpps på App Store. Du skickar en build till App Store Connect, bjuder in testare, och de installerar den med appen TestFlight, som är gratis på App Store. Det finns två typer av testare: interna, upp till 100 personer i ditt team, utan granskning från Apple, och externa, upp till 10 000 personer, inbjudna via e-post eller publik länk, efter en betagranskning av din första build. Varje build går att testa i 90 dagar.

Kriterium	Interna testare	Externa testare
Max antal	100	10 000
Tillgång till ditt konto	Ja, med en roll	Nej
Inbjudan	Läggs till i den interna gruppen	E-post eller publik länk
Apples betagranskning	Ingen	På den första builden
För vem	Du, en delägare, någon nära	Vänner, första användarna

För att använda TestFlight behöver du ett betalt Apple Developer-konto: tjänsten är inte tillgänglig med ett gratiskonto. Resten av guiden förutsätter att du har ett, inom standardprogrammet: Apples Enterprise-program ger inte tillgång till TestFlight.

I mina appar går varje build som skickas med EAS Submit genom TestFlight och min iPhone innan den skickas till granskning. Det är där jag hittar problemen som inte syns under utvecklingen.

Skicka en build till TestFlight

En build är en kompilerad och signerad version av din app: är den felsignerad avvisar Apple den vid uppladdningen med ITMS-90034. För att den ska dyka upp i TestFlight måste du skicka den till App Store Connect. Med Expo kör du eas build --platform ios och sedan eas submit --platform ios, med en tillräckligt ny build-image för att slippa ITMS-90725. Enligt Expos dokumentation dyker builden upp i TestFlight när Apple har behandlat den, oftast inom 10 till 15 minuter. Du kan göra allt detta från en PC: guiden publicera en iOS-app utan Mac går igenom hela kedjan.

Två detaljer ställer ofta till det första gången:

• Build-numret måste ändras vid varje uppladdning. Apple avvisar två builds med samma nummer för samma version. Med EAS aktiverar du automatisk uppräkning och slipper tänka på det.
• Frågan om kryptering. Så länge du inte har svarat på frågan om krypteringsanvändning fastnar builden med statusen saknad efterlevnadsinformation (Missing Compliance). Du kan svara varje gång i App Store Connect, eller deklarera det en gång för alla i appens konfiguration.

Interna testare: ditt team, utan väntan

Interna testare är användare av ditt App Store Connect-konto med en tilldelad roll. Apple tillåter upp till 100, och var och en kan installera appen på flera enheter, upp till 30.

Den stora fördelen: ingen betagranskning. Så fort builden är färdigbehandlad, utan automatiska fel som ITMS-90717, lägger du till den i din interna grupp och den är tillgänglig. Det är rätt grupp för dig själv, och för en delägare eller någon nära som du ger tillgång till ditt konto.

Begränsningen: de måste läggas till som användare av ditt App Store Connect-konto. Det passar inte för okända personer.

Externa testare och betagranskning

Externa testare behöver ingen tillgång till ditt konto. Du kan bjuda in upp till 10 000, via e-post eller publik länk. Det är rätt grupp för vänner, första användare, en community.

I gengäld kontrollerar Apple builden innan den öppnas för dem. När du lägger till den första builden av en version i en extern grupp går den till betagranskning. Senare builds av samma version kräver inte nödvändigtvis en fullständig granskning.

Innan du skickar in ber App Store Connect om testinformation:

• en beskrivning av betan, som talar om för testarna vad de ska titta på;
• en e-postadress för feedback;
• dina kontaktuppgifter, så att Apple kan nå dig.

Betagranskningen är inte App Store-granskningen. En build som godkänts i TestFlight kan fortfarande avvisas vid publiceringen.

Betagranskningen kontrollerar att builden följer reglerna, men den slutliga granskningen tittar också på din produktsida, dina prenumerationer, dina juridiska texter och hela upplevelsen. Ha de vanliga avslagsorsakerna i bakhuvudet, som jag går igenom i varför Apple avvisar en app.

Bjud in testare via publik länk

Den publika länken är det enklaste sättet att låta folk du inte känner än testa din app. Här är Apples steg, med gränssnittets engelska etiketter:

1. Öppna din app i App Store Connect och gå till fliken TestFlight.
2. Under External Testing väljer du din externa grupp.
3. Klicka på Create Public Link.
4. Välj Open to Anyone för att öppna länken för alla, eller Filter by Criteria för att begränsa den till vissa enheter och iOS-versioner.
5. Om du vill sätter du ett tak för antalet testare med Set Limit.

Sedan delar du länken var du vill: meddelande, sociala medier, e-post. Personen installerar TestFlight-appen, öppnar länken och accepterar inbjudan.

Två saker att veta innan du sprider den brett:

• Sätt ett tak. Om länken sprids mer än tänkt behåller du kontrollen över antalet testare.
• Testare via publik länk är anonyma. App Store Connect visar bara installationsdatum, sessioner och krascher för dem. Vill du veta vem som testat vad är det bättre att bjuda in via e-post.

Hur länge gäller en TestFlight-build?

En build är tillgänglig för testarna i 90 dagar. Efter det går den ut och dina testare kan inte längre öppna den. Om din beta pågår längre skickar du helt enkelt en ny build innan dess.

I praktiken kommer du att skicka nya builds mycket oftare: vid varje viktig rättning. Varje ny build som läggs till i gruppen erbjuds dina testare, som hämtar den i TestFlight-appen.

Samla in feedback från testarna

TestFlight har ett inbyggt feedbacksystem: testaren tar en skärmdump i din app, kan anteckna den och skickar den till dig. Om appen kraschar får du en kraschrapport, och testaren kan lägga till sammanhang. Allt hittar du i App Store Connect.

Det är användbart, men räcker inte för att förstå en specifik krasch. I mina appar lägger jag till Sentry, som rapporterar felet med kodraden som orsakade det, och PostHog, som visar var användarna hoppar av. Båda fungerar i en TestFlight-build precis som i produktion.

Testa prenumerationer i TestFlight

Om din app säljer en prenumeration är TestFlight stället där du kontrollerar att den verkligen fungerar. Köp i en TestFlight-build går via Apples testmiljö: dina testare debiteras inte. Förnyelserna går snabbare: varje prenumeration förnyas en gång per dag, högst sex gånger under en vecka, oavsett verklig längd.

Kontrollera åtminstone att de visade priserna stämmer, att köpet verkligen låser upp appen och att återställningsknappen hittar prenumerationen efter en ominstallation. Jag använder RevenueCat för prenumerationerna i mina appar; hela uppsättningen, från produkterna i App Store Connect till paywallen, beskrivs på sidan in-app-prenumerationer på iOS.

Det här ska du testa innan du skickar till Apple

Det här är listan jag går igenom före varje inskickning till granskning. Varje punkt motsvarar en avslagsorsak eller en krasch som går att undvika.

Första starten

• Radera appen, installera om den från TestFlight och öppna den. Det är vad granskaren kommer att göra.
• Gå igenom hela onboardingen utan att hoppa över något.
• Neka varje behörighet (notiser, kamera, plats) och kontrollera att appen fortsätter att fungera.

Pengarna

• Paywallen visar priser, längd och länkar till användarvillkoren och integritetspolicyn.
• Köpet fungerar, och återställningen också.
• Alla konfigurerade produkter syns för granskaren: guideline 2.1 kräver att köp i appen är kompletta, synliga och fungerande.

Svåra förhållanden

• Flygplansläge och långsamt nätverk: ett tydligt meddelande, inte en vit skärm.
• Den minsta och den största iPhone du stöder: inget avklippt, inget dolt av tangentbordet. Det var en avklippt skärm på en liten iPhone som gav mig ett avslag för Solys.
• Långa texter, om din app är översatt.

Underlaget till granskaren

• Om din app kräver inloggning: ett demokonto i granskningsanteckningarna, med din backend igång. Guideline 2.1 kräver det uttryckligen.
• Granskningsanteckningar som på två meningar förklarar vad appen gör och var huvudfunktionen finns.

Om din app ändå avvisas förklarar sidan app avvisad av Apple hur du svarar utan att förlora en vecka. Och för helhetsbilden av publiceringen, från produktsida till lansering, läs publicera en app på App Store.

Ett testprotokoll att fylla i för din build

Ladda ner protokollet med 16 scenarier i CSV-format. Det skiljer på förberedelse, handling, förväntat resultat och observerat bevis. Importera det i Numbers, Excel eller Google Sheets och fyll i version, enhet och resultat för varje test.

För en påhittad läslogg räcker inte "spara en sida": anteckna sidan 24, stäng appen helt, starta om den och hitta värdet igen. Ett test som inte har körts står kvar som "Att testa". Om din app inte har någon prenumeration skriver du "Ej tillämpligt" för köpscenarierna, med den motiveringen.

Protokollet är en utgångspunkt att anpassa, inte en certifiering. Hitta också App Review-anteckningar och andra gratismallar för att förklara för granskaren det flöde du faktiskt har kontrollerat.

Från TestFlight till App Store

TestFlight är steget där din app blir verklig: den körs på en riktig iPhone, i händerna på riktiga människor. I iOS Kit är det andra steget: bygga appens kärna och testa den på din iPhone med TestFlight, innan du kopplar in prenumerationerna och förbereder publiceringen.

Efter TestFlight kommer Apples granskning: Apple Review Kit samlar min checklista inför inskickningen och anteckningarna till granskaren. Startsidan visar de fyra stegen för att skapa din mobilapp med Claude Code.

Ingen kan garantera att Apple godkänner din app: det är Apple som bestämmer.

Vanliga frågor

Hur testar man sin iPhone-app med TestFlight?

Skicka en build till App Store Connect och lägg sedan till den i en testgrupp. Med Expo kompilerar du den med EAS Build och skickar den med EAS Submit: den dyker upp i TestFlight när Apple har behandlat den, oftast inom 10 till 15 minuter enligt Expo. Dina testare installerar den med TestFlight-appen, som är gratis på App Store. Du behöver ett betalt Apple Developer-konto.

Hur skapar man en TestFlight-länk för att bjuda in testare?

Öppna fliken TestFlight för din app i App Store Connect, välj din grupp under External Testing och klicka på Create Public Link. Välj Open to Anyone eller Filter by Criteria och sätt sedan ett tak med Set Limit. Testare via publik länk är anonyma: vill du veta vem som testat vad är det bättre att bjuda in dem via e-post.

Ersätter TestFlights betagranskning App Store-granskningen?

Nej. Betagranskningen kontrollerar att builden följer reglerna, men den slutliga granskningen tittar också på din produktsida, din åldersgräns (age rating), dina prenumerationer, dina juridiska texter och hela upplevelsen. En build som godkänts i TestFlight kan alltså fortfarande avvisas vid publiceringen. Bara externa testare utlöser en betagranskning, på den första builden av en version: interna testare kräver ingen.

Hur många testare kan man bjuda in på TestFlight?

Du kan bjuda in upp till 100 interna testare och upp till 10 000 externa. De interna är medlemmar i ditt App Store Connect-konto, utan betagranskning, och var och en kan installera appen på upp till 30 enheter. De externa bjuds in via e-post eller publik länk, efter en betagranskning av den första builden. Varje build går att testa i 90 dagar.

Kan man testa en prenumeration i TestFlight utan att debiteras?

Ja, köp i en TestFlight-build går via Apples testmiljö: dina testare debiteras inte. Förnyelserna går snabbare: varje prenumeration förnyas en gång per dag, högst sex gånger under en vecka, oavsett verklig längd. Kontrollera åtminstone de visade priserna, att appen låses upp och återställningen efter en ominstallation. Hela uppsättningen beskrivs på in-app-prenumerationer på iOS.

Vad ska man kontrollera i TestFlight innan man skickar appen till Apple?

Installera om appen från TestFlight, precis som granskaren kommer att göra, och gå igenom hela onboardingen. Neka varje behörighet, testa köp och återställning, och prova sedan flygplansläge samt den minsta och den största iPhone du stöder. Om appen kräver inloggning: förbered ett demokonto i granskningsanteckningarna, med din backend igång.