# Radera konto i iOS-app: testa flödet före Apple

> Raderingsknapp, kopplad data, prenumeration och ny inloggning: en konkret testplan för att kontrollera flödet innan du skickar appen till App Review.

Originalsida: [Radera konto i iOS-app: testa flödet före Apple](https://devoria.fr/sv/blog/radera-konto-ios-app-testa-flodet)
Författare: [Mehdi Azizi](https://devoria.fr/sv/mehdi-azizi)
Publicerad: 2026-10-02
Innehållet senast granskat: 2026-10-09


## Knappen räcker inte: du måste kontrollera vad som försvinner

Om din app låter användare skapa ett konto kräver Apple att personen kan starta raderingen av kontot inifrån appen. Att bara inaktivera kontot uppfyller inte kravet. Flödet ska vara lätt att hitta och förklara vad som händer. Om en del avslutas på webben ska länken gå direkt till rätt sida. [Källa: Apple om kontoradering](https://developer.apple.com/support/offering-account-deletion-in-your-app).

Jobbet tar alltså inte slut med en röd knapp i inställningarna. Du behöver inventera datan, köra raderingen på serversidan, hantera fel och kontrollera vad användaren ser efteråt. Den här guiden ger en testplan för både produkt och teknik. Data som omfattas av en skyldighet att sparas kräver en hantering anpassad till din verksamhet.

## Börja med en karta över datan

Ta en påhittad läslogg-app som exempel. Den har ett konto, en profil, privata anteckningar och omslagsbilder som användaren laddat upp. Exemplet nedan beskriver en plan att kontrollera, inte en radering som redan körts i en Devoria-app.

- **Inloggningsidentitet:** hur gör du kontot oanvändbart efter raderingen?
- **Profil och anteckningar:** vilka rader tillhör personen och hur raderas de?
- **Lagrade bilder:** vilken process tar bort filerna och referenserna till dem?
- **Cache på telefonen:** rensar skärmen lokal data först när åtgärden faktiskt har lyckats?
- **Tredjepartstjänster:** behöver data kopplad till kontot raderas separat?
- **Data som ska sparas:** vilken, för vilken skyldighet, och hur informeras användaren?

Kartan gör att du slipper upptäcka i efterhand att en bild fortfarande går att nå fast användarposten är borta. Den ger dig också de objekt du ska leta efter i testerna.

## Ett tydligt flöde i fyra lägen

Här är ett förslag för den påhittade appen. Anpassa det efter vad som faktiskt händer i din produkt:

1. **Kontoinställningar.** Ett val "Radera mitt konto" finns alltid tillgängligt.
2. **Bekräftelse.** Skärmen beskriver vilken data som berörs och visar ett avbrytalternativ som är lika begripligt som raderingsknappen.
3. **Bearbetning.** Knappen förhindrar dubbla förfrågningar och gränssnittet visar att åtgärden pågår.
4. **Resultat.** Vid bekräftad framgång visas utloggat läge. Vid fel visas ett användbart meddelande och ett sätt att försöka igen, utan att påstå att kontot är borta.

Om bearbetningen tar tid accepterar Apple ett fördröjt flöde, förutsatt att du informerar personen och bekräftar när det är klart. Appen får inte ge intryck av att raderingen är klar när bara förfrågan har registrerats. Samma [Apple-dokumentation](https://developer.apple.com/support/offering-account-deletion-in-your-app) tar också upp fall med ny autentisering och undantag för starkt reglerade verksamheter.

## Vad du behöver tänka på med Supabase

Att radera en Auth-användare är inte i sig ett bevis på att alla objekt i din produkt har hanterats. Supabase förklarar bland annat att en användare som äger Storage-objekt inte kan raderas förrän det är löst. Dokumentationen påpekar också att radering av en användare inte direkt loggar ut alla redan utfärdade JWT: deras giltighetstid måste tas med i designen. [Källa: hantering av användare i Supabase](https://supabase.com/docs/guides/auth/managing-user-data).

Bygg därför en process på serversidan som kontrollerar vem som gör förfrågan och vilka resurser som tillhör personen. Lita inte på ett id som telefonen skickar fritt för att välja vilket konto som ska raderas. Administratörsrättigheter stannar på serversidan, enligt [Supabase-dokumentationen om nycklar](https://supabase.com/docs/guides/getting-started/api-keys).

För en process i flera steg: bestäm vad ett nytt försök ska göra om ett första steg lyckades och nästa misslyckades. Om filerna till exempel redan är borttagna ska en ny förfrågan inte misslyckas bara för att de saknas. Det är ett scenario du skriver före testet, inte ett beteende du antar.

## Konto och prenumeration: två separata kontroller

En person kan radera sitt konto medan en Apple-prenumeration fortsätter. Apple kräver att du förklarar vad som händer med debiteringen och ger tillgång till hantering av prenumerationen. Planera också för att återkalla tokens på rätt sätt om du använder Sign in with Apple. De här punkterna beskrivs i [Apples riktlinjer om radering](https://developer.apple.com/support/offering-account-deletion-in-your-app).

I din testplan håller du alltså isär att kontot försvinner, läget för betald åtkomst och hanteringen av prenumerationen. Guiden [prenumeration eller engångsköp](https://devoria.fr/sv/blog/prenumeration-eller-engangskop-ios-app) hjälper dig att placera flödet i din affärsmodell.

## Testplanen att köra på ett testbygge

Använd bara ett testkonto och påhittad data. Anteckna bygge, enhet, observerat resultat och begränsningarna för varje kontroll.

1. **Avbryt.** Kontot och datan finns kvar.
2. **Radera ett konto med innehåll.** Slutläget motsvarar den utlovade processen och berörd data är faktiskt borttagen.
3. **Stäng av nätverket.** Appen visar ingen falsk framgång.
4. **Försök igen efter ett delvis misslyckande.** Förfrågan kan gå igenom utan att träffa annan data.
5. **Öppna en andra session.** Gamla åtkomster hanteras enligt den planerade mekanismen.
6. **Skapa ett nytt konto med samma adress, om det är tillåtet.** Gammal privat data dyker inte upp igen.

Lägg till fallen i [Devorias testmall](https://devoria.fr/sv/resources). För att dela dem med testare, följ guiden om [TestFlight](https://devoria.fr/sv/blog/testflight-testa-iphone-app). Att konsolen inte visar några fel ersätter inte en kontroll av datan och flödet.

## Förbered inskicket till App Review

I dina granskningsanteckningar förklarar du var åtgärden finns och hur den testas. Om ett steg beror på en tjänst, se till att den är tillgänglig under granskningen. Använd inte anteckningarna för att lova en funktion som ännu inte finns i bygget du skickar.

Sidan [app avvisad av Apple](https://devoria.fr/sv/expertise/app-nekad-av-apple) hjälper dig att strukturera ett svar när ett problem redan har flaggats. För att förbereda svaret hjälper [Apple Review Kit](https://devoria.fr/sv/kits/review-apple) dig att hitta regeln som citeras, vad den kräver och ett exempel på åtgärd och svar.

Om du förbereder ditt första inskick visar den [gratis diagnosen](https://devoria.fr/sv/diagnostic) vad som återstår och skickar dig min checklista mot avslag från Apple, kontoradering inräknad. Om Apple redan har avvisat din app, [boka en timme med mig](https://devoria.fr/sv/coaching): vi läser meddelandet tillsammans i ett videosamtal.

## Vanliga frågor

### Är kontoradering obligatoriskt i en iOS-app?

Ja, om din app låter användare skapa ett konto: Apple kräver att personen kan starta raderingen inifrån appen. Att bara inaktivera kontot uppfyller inte kravet. Flödet ska vara lätt att hitta och förklara vad som händer. Om en del avslutas på webben ska länken gå direkt till rätt sida.

### Vad ska raderas när en användare raderar sitt konto?

Allt som tillhör personen, inte bara användarposten. Gör en lista: inloggningsidentitet, profil och skapat innehåll, lagrade filer och deras referenser, cache på telefonen, data hos tredjepartstjänster. Notera också vilken data som ska sparas, för vilken skyldighet, och informera personen. Utan den inventeringen kan en bild fortfarande gå att nå fast användarposten är borta.

### Accepterar Apple en kontoradering som inte sker direkt?

Ja. Om bearbetningen tar tid accepterar Apple ett fördröjt flöde, förutsatt att du informerar personen och bekräftar när det är klart. Appen får inte ge intryck av att raderingen är klar när bara förfrågan har registrerats. Vid fel, visa ett användbart meddelande och ett sätt att försöka igen, utan att påstå att kontot är borta.

### Vad händer med prenumerationen när användaren raderar sitt konto?

Apple-prenumerationen kan fortsätta efter att kontot raderats. Apple kräver att du förklarar vad som händer med debiteringen och ger tillgång till hantering av prenumerationen. Om du använder Sign in with Apple, planera också för att återkalla tokens på rätt sätt. I din testplan håller du isär att kontot försvinner, läget för betald åtkomst och hanteringen av prenumerationen.

### Räcker det att radera användaren i Supabase Auth?

Nej, att radera en Auth-användare bevisar inte att alla objekt i din produkt har hanterats. Enligt Supabase-dokumentationen kan en användare som äger Storage-objekt inte raderas förrän det är löst. Att radera en användare loggar inte heller direkt ut alla redan utfärdade JWT. Bygg en process på serversidan som kontrollerar vem som gör förfrågan.

### Hur testar jag kontoradering innan jag skickar till Apple?

Använd ett testkonto och påhittad data på ett testbygge. Kör sex fall: avbryt, radera ett konto med innehåll, stäng av nätverket, försök igen efter ett delvis misslyckande, öppna en andra session, skapa ett nytt konto med samma adress om det är tillåtet. Kontrollera datan och flödet: att konsolen inte visar fel räcker inte. För att dela ditt bygge, följ guiden om [TestFlight](https://devoria.fr/sv/blog/testflight-testa-iphone-app).


## Ditt projekt

[Apple Review Kit](https://devoria.fr/sv/kits/review-apple): Checklistan för App Store-granskning som jag använder, mina rättade avslag, anteckningar till granskaren och två Claude Code-skills som granskar din app. 29 €.

[iOS Kit](https://devoria.fr/sv/kits/ios): Bygg din iPhone-app med Claude Code: startkoden till mina appar, skills som kontrollerar arbetet, samt Apple Review Kit, App Store Screenshots Kit och ASO Kit. 129,99 €.