iOS App im App Store veröffentlichen: Der komplette Guide für 2026

TL;DR – Die Kurzfassung

Eine iOS-App im App Store zu veröffentlichen ist ein mehrstufiger Prozess. Hier die wichtigsten Schritte auf einen Blick:

Das Wichtigste vorab: Der Prozess ist gut dokumentiert, aber voller versteckter Stolperfallen — besonders beim Code Signing und App Store Review. Dieser Guide zeigt Ihnen jeden Schritt und wie Sie die häufigsten Fehler vermeiden.

---

1. Apple Developer Account einrichten

Was Sie brauchen

Um eine App im App Store zu veröffentlichen, benötigen Sie ein Apple Developer Program-Konto. Das ist nicht dasselbe wie eine Apple ID — es ist ein kostenpflichtiges Programm mit jährlicher Gebühr.

Der Enrollment-Prozess Schritt für Schritt

Für Einzelunternehmer (Individual):

1. Gehen Sie zu developer.apple.com/programs
2. Melden Sie sich mit Ihrer Apple ID an
3. Verifizieren Sie Ihre Identität — Apple nutzt seit 2024 die automatische ID-Erkennung über ein iPhone oder iPad
4. Bezahlen Sie die Jahresgebühr von 99 €
5. Warten Sie auf die Bestätigung (meist innerhalb von 48 Stunden)

Für Unternehmen (Organization):

Der Prozess ist aufwändiger, da Apple die Existenz Ihres Unternehmens verifiziert:

1. D-U-N-S Nummer besorgen — Das ist eine eindeutige Unternehmenskennzahl von Dun & Bradstreet. In Österreich haben die meisten im Firmenbuch eingetragenen Unternehmen bereits eine. Falls nicht: Kostenlos beantragen unter dnb.com, Dauer: 5–14 Werktage.
2. Enrollment starten auf developer.apple.com/programs
3. Firmendetails angeben — Name exakt wie im Firmenbuch, D-U-N-S Nummer, Firmenadresse
4. Signing Authority bestätigen — Die Person, die den Account erstellt, muss rechtlich befugt sein, im Namen des Unternehmens zu handeln (Geschäftsführer, Prokurist)
5. Apple verifiziert — Apple ruft im Rahmen der Prüfung unter Umständen bei Ihrem Unternehmen an. Die Nummer wird aus dem D-U-N-S-Eintrag gezogen.
6. Bestätigung — Dauer: 2–7 Werktage, in Einzelfällen bis zu 4 Wochen

Tipp: Starten Sie den Enrollment-Prozess frühzeitig — mindestens 2 Wochen vor dem geplanten Launch. Besonders die D-U-N-S-Verifizierung kann dauern.

Häufige Probleme beim Enrollment

• Firmenname stimmt nicht mit D-U-N-S überein: Apple vergleicht den Namen zeichengenau. „Musterfirma GmbH" und „Musterfirma Gesellschaft m.b.H." sind für Apple zwei verschiedene Unternehmen.
• D-U-N-S Nummer nicht gefunden: In Österreich kann es sein, dass Ihre Nummer noch nicht im Apple-System eingespielt ist. Warten Sie 2–3 Tage nach der Beantragung.
• Verification-Anruf verpasst: Apple ruft einmal an. Wenn niemand abhebt, wird der Prozess verzögert. Informieren Sie Ihre Telefonzentrale.

---

2. Code Signing: Certificates & Provisioning Profiles

Code Signing ist der Bereich, an dem die meisten Entwickler — und besonders Einsteiger — verzweifeln. Es ist Apples System, um sicherzustellen, dass nur autorisierte Entwickler Apps auf echte Geräte installieren und im Store veröffentlichen können.

Warum Code Signing so kompliziert ist

Apple verwendet ein mehrstufiges Kryptografie-System mit drei Komponenten, die zusammenspielen müssen:

Development vs. Distribution

Es gibt zwei völlig getrennte Signing-Umgebungen:

Development Signing:

• Zum Testen auf eigenen Geräten
• Development Certificate + Development Provisioning Profile
• Geräte müssen einzeln im Developer Portal registriert sein (max. 100 pro Gerätetyp und Jahr)
• Signierte Apps laufen nur auf registrierten Geräten

Distribution Signing:

• Für den App Store und TestFlight
• Distribution Certificate + Distribution Provisioning Profile
• Keine Geräte-Registrierung nötig — Apple verwaltet die Verteilung
• Ein Unternehmen hat maximal 3 Distribution Certificates gleichzeitig

Der Certificate-Prozess (manuell)

1. Certificate Signing Request (CSR) erstellen — In der Mac Schlüsselbundverwaltung: Schlüsselbundverwaltung → Zertifikatassistent → Zertifikat einer Zertifizierungsinstanz anfordern
2. CSR hochladen im Apple Developer Portal unter Certificates, Identifiers & Profiles
3. Certificate herunterladen und per Doppelklick in den Schlüsselbund importieren
4. Provisioning Profile erstellen — App ID auswählen, Certificate auswählen, bei Development: Geräte auswählen
5. Profil in Xcode laden — Xcode → Settings → Accounts → Download Manual Profiles

Warum das in der Praxis zum Problem wird

• Certificates sind an einen Mac gebunden. Der Private Key existiert nur im Schlüsselbund des Macs, auf dem der CSR erstellt wurde. Neuer Mac = neues Certificate, außer Sie exportieren den Key manuell.
• Ablaufdaten. Certificates laufen nach einem Jahr ab, Provisioning Profiles ebenfalls. Vergessen Sie die Erneuerung, builden Ihre Apps plötzlich nicht mehr.
• Teamarbeit. In einem Team braucht jeder Entwickler ein eigenes Development Certificate. Distribution Certificates sollten zentral verwaltet werden — und genau das geht oft schief.
• Revocation-Chaos. Wenn jemand versehentlich ein Certificate widerruft, werden alle davon abhängigen Provisioning Profiles ungültig.

Die Lösung: Automatic Signing und Expo/EAS

Xcode Automatic Signing (seit Xcode 8):

• Xcode verwaltet Certificates und Profiles automatisch
• Funktioniert gut für einfache Projekte und kleine Teams
• Unter Xcode → Target → Signing & Capabilities → „Automatically manage signing" aktivieren

Expo EAS Build (unsere empfohlene Lösung):

• EAS Build erstellt und verwaltet Certificates und Profiles in der Cloud
• Kein Mac zum Builden nötig — der Build läuft auf Apples M1/M2-Servern bei Expo
• eas credentials zeigt und verwaltet alle Signing-Credentials
• Besonders für React-Native-Projekte die mit Abstand angenehmste Lösung

# EAS Build für iOS — Certificate-Management inklusive
eas build --platform ios

# Credentials anzeigen und verwalten
eas credentials --platform ios

Unser Tipp: Wenn Sie nicht gerade einen triftigen Grund für manuelles Signing haben, nutzen Sie Automatic Signing in Xcode oder noch besser EAS Build. Es erspart Ihnen Stunden an Debugging.

---

3. App für den Store vorbereiten: App Store Connect

Bevor Sie Ihre App einreichen können, müssen Sie sie in App Store Connect (ehemals iTunes Connect) anlegen und umfangreiche Metadaten pflegen.

App Store Connect einrichten

1. Gehen Sie zu appstoreconnect.apple.com
2. Klicken Sie auf „Apps" → „+" → „Neue App"
3. Füllen Sie die Grunddaten aus: Name, Primärsprache, Bundle ID, SKU

Screenshots — Die technischen Anforderungen

Apple verlangt Screenshots für verschiedene Gerätegrößen. Seit 2024 sind nur noch drei Formate erforderlich:

Pro Geräteklasse: Mindestens 2, maximal 10 Screenshots. Wir empfehlen 5–6 Screenshots — genug, um alle Features zu zeigen, ohne die Aufmerksamkeit zu verlieren.

Best Practices für Screenshots:

• Zeigen Sie den Mehrwert Ihrer App, nicht nur die UI
• Verwenden Sie kurze, aussagekräftige Texte als Overlay
• Der erste Screenshot ist entscheidend — er erscheint in den Suchergebnissen
• Erstellen Sie Ihre Screenshots auf echten Geräten oder im Simulator, nicht als Mockups
• Tools wie Fastlane Frameit oder Screenshots Pro helfen bei der Gestaltung

App Preview Videos

Optional, aber empfehlenswert: Bis zu 3 kurze Videos (15–30 Sekunden) pro Lokalisierung. Videos autoplayen in den Suchergebnissen und erhöhen die Conversion Rate nachweislich um 20–30 %.

Beschreibung und Keywords

App Name: Max. 30 Zeichen. Muss einzigartig im App Store sein. Verwenden Sie Ihren Markennamen plus ein beschreibendes Keyword.

Subtitle: Max. 30 Zeichen. Kurze Beschreibung — erscheint direkt unter dem App-Namen in den Suchergebnissen.

Keywords: Max. 100 Zeichen, kommagetrennt. Apple nutzt diese für die Suche (nicht öffentlich sichtbar). Verwenden Sie keine Wörter, die bereits im App-Namen oder Subtitle stehen — die werden automatisch indexiert.

Beschreibung: Max. 4.000 Zeichen. Die ersten 2–3 Zeilen sind am wichtigsten, da der Rest erst nach Tippen auf „Mehr" sichtbar wird. Strukturieren Sie mit kurzen Absätzen.

Promotional Text: Max. 170 Zeichen. Wird über der Beschreibung angezeigt und kann jederzeit ohne neues Review geändert werden — ideal für Aktionen oder saisonale Hinweise.

Altersfreigabe (Age Rating)

Apple verwendet einen Fragebogen, um die Altersfreigabe zu bestimmen. Sie beantworten Fragen zu:

• Gewaltige oder verstörende Inhalte
• Anzügliche Inhalte
• Glücksspiel
• Alkohol, Tabak, Drogen
• User Generated Content
• Unbeschränkter Internetzugriff

Wichtig für österreichische Unternehmen: Die Apple-Altersfreigabe ersetzt nicht die PEGI-Einstufung für Spiele oder die Jugendschutz-Anforderungen nach dem österreichischen Jugendschutzgesetz. Für reine Business-Apps ist das in der Regel aber kein Thema.

Datenschutz-Angaben (App Privacy)

Seit iOS 14 verlangt Apple detaillierte Angaben darüber, welche Daten Ihre App sammelt. Diese erscheinen als „App Privacy Label" im Store.

Sie müssen für jede Datenkategorie angeben:

• Welche Daten (Name, E-Mail, Standort, Nutzungsdaten, etc.)
• Wofür (App-Funktionalität, Analytics, Werbung, etc.)
• Ob die Daten mit dem Nutzer verknüpft werden
• Ob die Daten zum Tracking verwendet werden

Tipp: Erstellen Sie die Privacy Labels parallel zur Entwicklung, nicht erst beim Einreichen. Wenn Sie Analytics-Tools (Firebase, Mixpanel) oder Crash-Reporting (Sentry) einsetzen, müssen diese deklariert werden.

---

4. TestFlight: Beta-Testing richtig machen

TestFlight ist Apples offizielle Plattform für Beta-Tests. Es ist kostenlos, in App Store Connect integriert und der empfohlene Weg, Ihre App vor dem Launch zu testen.

Internal Testing vs. External Testing

So richten Sie TestFlight ein

1. Build hochladen:

# Via Xcode
Product → Archive → Distribute App → App Store Connect

# Via EAS Build (empfohlen)
eas build --platform ios --profile production
eas submit --platform ios

2. Internal Tester einladen:

• App Store Connect → Ihre App → TestFlight → Internal Testing
• Gruppe erstellen → Teammitglieder hinzufügen
• Build der Gruppe zuweisen → Tester erhalten E-Mail-Einladung

3. External Tester einladen:

• External Testing → Neue Gruppe erstellen
• Tester per E-Mail oder öffentlichem Link einladen
• Beta App Review abwarten (meist innerhalb von 24 Stunden)
• Tester installieren TestFlight aus dem App Store und lösen den Einladungscode ein

Best Practices für Beta-Tests

• Starten Sie mit Internal Testing. Testen Sie zuerst intern mit Ihrem Team, bevor Sie externe Tester einladen.
• Nutzen Sie Gruppen strategisch. Erstellen Sie separate Gruppen für verschiedene Tester-Segmente (z. B. „Kernteam", „Pilotkunden", „Power User").
• Sammeln Sie strukturiertes Feedback. TestFlight erlaubt Screenshots und Textfeedback direkt aus der App. Weisen Sie Tester aktiv darauf hin.
• Testen Sie auf verschiedenen Geräten. Bitten Sie Tester mit älteren iPhones und verschiedenen iOS-Versionen um Feedback.
• Planen Sie 2–4 Wochen ein. Seriöses Beta-Testing braucht Zeit. Planen Sie mindestens 2 Iterationen ein.
• Achten Sie auf die 90-Tage-Grenze. Jeder Build läuft nach 90 Tagen ab. Laden Sie regelmäßig neue Builds hoch.

---

5. Der App Store Review Prozess

Das App Store Review ist die letzte Hürde vor der Veröffentlichung. Apple prüft jede eingereichte App (und jedes Update) manuell — ja, es sitzen echte Menschen dahinter, unterstützt durch automatisierte Tests.

Was Apple prüft

• Funktionalität: Die App muss starten, stabil laufen und tun, was die Beschreibung verspricht
• Design: Mindestmaß an UI-Qualität, keine reinen Web-Wrapper
• Datenschutz: Privacy Labels müssen korrekt sein, Nutzerdaten dürfen nur mit Zustimmung erhoben werden
• Sicherheit: Keine Malware, kein versteckter Code, keine privaten APIs
• Geschäftsmodell: In-App-Käufe müssen über Apples System laufen (die berühmte 30 %-Provision)
• Inhalte: Keine illegalen, beleidigenden oder unangemessenen Inhalte
• Rechtliches: AGB, Datenschutzerklärung müssen verlinkt sein

Wie lange dauert das Review?

Expedited Review beantragen

Wenn ein kritischer Bug Ihre Live-App betrifft, können Sie ein beschleunigtes Review beantragen:

1. Gehen Sie zu developer.apple.com/contact/app-store
2. Wählen Sie „Request an expedited app review"
3. Beschreiben Sie den kritischen Bug und warum es dringend ist
4. Apple entscheidet innerhalb weniger Stunden

Wichtig: Nutzen Sie Expedited Review nur für echte Notfälle. Apple trackt, wie oft Sie es beantragen. Missbrauch führt dazu, dass zukünftige Anfragen abgelehnt werden.

Tipps für ein reibungsloses Review

• Demo-Account bereitstellen: Wenn Ihre App einen Login erfordert, geben Sie Apple im Feld „App Review Information" Testdaten (E-Mail + Passwort). Ohne funktionierenden Login wird Ihre App sofort abgelehnt.
• Notes for Reviewer nutzen: Erklären Sie nicht offensichtliche Features oder Funktionen, die spezielle Hardware erfordern (z. B. Bluetooth-Geräte).
• Alle verlinkten URLs prüfen: Datenschutzerklärung, AGB, Support-URL — alle müssen erreichbar sein und relevanten Inhalt zeigen.
• Auf Vollständigkeit achten: Keine Platzhalter-Texte, keine „Coming Soon"-Bereiche, keine leeren Screens.

---

6. Die 10 häufigsten Rejection-Gründe

Basierend auf Apples veröffentlichten Transparenzberichten und unserer eigenen Erfahrung — hier die Gründe, warum Apps am häufigsten abgelehnt werden, und wie Sie sie vermeiden.

1. Guideline 4.0 — Design: Minimum Functionality

Das Problem: Ihre App bietet zu wenig Funktionalität oder ist im Wesentlichen eine Website in einem App-Wrapper.

Beispiele:

• Eine App, die nur einen eingebetteten Webview zeigt
• Eine App mit einer einzigen Funktion, die genauso gut als Website funktionieren würde
• Eine Marketing-Broschüre als App verpackt

Lösung: Stellen Sie sicher, dass Ihre App einen echten Mehrwert gegenüber einer mobilen Website bietet — Push-Benachrichtigungen, Offline-Funktionalität, Kamera-Integration, etc.

2. Guideline 2.1 — Performance: App Completeness

Das Problem: Die App crashed, hat fehlende Funktionen oder enthält Platzhalter-Inhalte.

Beispiele:

• Buttons, die ins Nichts führen
• „Lorem ipsum"-Text oder Test-Bilder
• Features, die im Screenshot gezeigt, aber nicht implementiert sind

Lösung: Testen Sie Ihre App gründlich vor der Einreichung. Jeder Screen, jeder Button, jeder Flow muss funktionieren.

3. Guideline 5.1.1 — Legal: Privacy — Data Collection and Storage

Das Problem: Die App sammelt Daten ohne angemessene Zustimmung oder die Privacy Labels stimmen nicht mit dem tatsächlichen Verhalten überein.

Beispiele:

• Standortzugriff ohne klare Begründung
• Tracking ohne App Tracking Transparency (ATT) Dialog
• Privacy Labels deklarieren keine Analytics, obwohl Firebase eingebunden ist

Lösung: Implementieren Sie den ATT-Dialog für jegliches Tracking. Stellen Sie sicher, dass Ihre Privacy Labels 100 % korrekt sind. Verwenden Sie NSPrivacyAccessedAPITypes in Ihrem Privacy Manifest (seit 2024 Pflicht).

4. Guideline 2.3 — Performance: Accurate Metadata

Das Problem: Screenshots, Beschreibung oder App-Name stimmen nicht mit der tatsächlichen App überein.

Lösung: Aktualisieren Sie Screenshots nach jeder größeren UI-Änderung. Beschreiben Sie nur Features, die tatsächlich vorhanden sind.

5. Guideline 4.2 — Design: Minimum Functionality (Copycat)

Das Problem: Die App kopiert eine bestehende App ohne nennenswerte eigene Funktionalität.

Lösung: Differenzieren Sie sich klar von Konkurrenz-Apps. Bieten Sie einzigartige Features oder eine deutlich bessere User Experience.

6. Guideline 3.1.1 — Business: In-App Purchase

Das Problem: Digitale Inhalte oder Abonnements werden nicht über Apples In-App-Purchase-System abgewickelt.

Beispiele:

• Ein Link zu einer externen Bezahlseite für Premium-Features
• Aufforderung, auf der Website zu bezahlen, um Features freizuschalten

Lösung: Digitale Güter müssen über Apples IAP-System laufen (Apple behält 15–30 % Provision). Physische Güter und Dienstleistungen (z. B. Uber-Fahrten, Lieferando-Bestellungen) sind ausgenommen. Seit 2024 dürfen Sie in der EU auf externe Bezahlmethoden verlinken — mit Auflagen.

7. Guideline 5.1.2 — Legal: Privacy — Data Use and Sharing

Das Problem: Daten werden an Dritte weitergegeben, ohne dass der Nutzer dem explizit zugestimmt hat.

Lösung: Implementieren Sie ein klares Consent-Management. Besonders relevant für österreichische Apps: DSGVO-Konformität und die ePrivacy-Richtlinie beachten.

8. Guideline 2.5.1 — Performance: Software Requirements

Das Problem: Die App verwendet private APIs oder nicht dokumentierte Funktionen des Betriebssystems.

Lösung: Verwenden Sie nur öffentliche Apple-APIs. Prüfen Sie Third-Party-Libraries auf die Verwendung privater APIs (kommt häufiger vor als man denkt).

9. Guideline 4.8 — Design: Sign in with Apple

Das Problem: Die App bietet Social Login (Google, Facebook), aber kein „Sign in with Apple" als Option.

Lösung: Seit 2020 Pflicht: Wenn Sie irgendeinen Third-Party-Login anbieten, müssen Sie auch „Sign in with Apple" implementieren. Einzige Ausnahme: rein unternehmenseigene Login-Systeme.

10. Guideline 1.2 — Safety: User Generated Content

Das Problem: Die App erlaubt User Generated Content ohne Moderationsmechanismus.

Lösung: Implementieren Sie: Inhalte melden, Nutzer blockieren, Inhalte filtern. Stellen Sie sicher, dass die Moderation dokumentiert und wirksam ist.

Bonus: Die tückischsten Rejections

Manche Ablehnungen kommen erst bei Updates — obwohl der problematische Code schon bei der Ersteinreichung vorhanden war. Apple prüft nicht immer alles gleich gründlich. Verlassen Sie sich also nicht darauf, dass „es beim letzten Mal durchging."

---

7. Nach dem Launch: Updates, Ratings & Analytics

Die Veröffentlichung ist nicht das Ende, sondern der Anfang.

Updates regelmäßig pushen

• Bug-Fix-Updates: So schnell wie möglich, idealerweise innerhalb einer Woche nach dem Report
• Feature-Updates: Alle 4–8 Wochen, um das Ranking in den Suchergebnissen zu verbessern
• iOS-Versions-Updates: Testen und aktualisieren Sie Ihre App innerhalb von 2 Wochen nach jedem großen iOS-Release (September jedes Jahr)

Apple bevorzugt Apps in den Suchergebnissen, die regelmäßig aktualisiert werden. Eine App, die 6 Monate kein Update bekommen hat, verliert sichtbar an Ranking.

Ratings und Reviews managen

• In-App-Review-Prompt: Verwenden Sie SKStoreReviewController.requestReview(), um Nutzer um eine Bewertung zu bitten. Apple erlaubt maximal 3 Prompts pro 365-Tage-Zeitraum pro Nutzer.
• Auf Reviews antworten: Sie können in App Store Connect auf jede Bewertung antworten. Tun Sie das — besonders bei negativen Reviews. Das zeigt, dass Sie aktiv an der App arbeiten.
• Timing ist alles: Bitten Sie um Bewertungen nach einem positiven Erlebnis (z. B. erfolgreicher Abschluss einer Aufgabe), nicht nach dem ersten Start oder einem Fehler.

App Analytics nutzen

App Store Connect bietet integrierte Analytics:

• Impressions: Wie oft Ihre App in den Suchergebnissen erscheint
• Product Page Views: Wie oft Ihre Store-Seite aufgerufen wird
• Conversion Rate: Verhältnis von Views zu Downloads
• Retention: Wie viele Nutzer die App nach 1, 7, 30 Tagen noch nutzen
• Crash-Reports: Automatische Crash-Meldungen über Xcode Organizer

Ergänzen Sie Apples Analytics mit Tools wie Firebase Analytics, Mixpanel oder PostHog für detailliertere In-App-Metriken.

---

8. Kosten-Zusammenfassung

Was kostet es insgesamt, eine iOS-App im App Store zu veröffentlichen?

Minimum für die reine Veröffentlichung: 99 € pro Jahr (Developer Account). Alles andere ist optional oder in den Entwicklungskosten enthalten.

Realistisches Budget für ein KMU: Rechnen Sie mit 99 € (Developer Account) + ca. 29 €/Monat (EAS Build) + Zeit für Screenshots und Metadaten. Die eigentliche Entwicklung ist natürlich der größte Kostenblock — dazu haben wir einen ausführlichen Kostenguide.

---

9. Häufig gestellte Fragen (FAQ)

Brauche ich einen Mac, um eine iOS-App zu veröffentlichen?

Traditionell ja — Xcode läuft nur auf macOS. Mit Expo EAS Build können Sie aber vollständig ohne Mac entwickeln und bauen. Der Build läuft in der Cloud auf Apples Hardware. Sie brauchen dann nur zum initialen Testen ein iPhone oder den iOS-Simulator (der wiederum einen Mac benötigt). Alternativ testen Ihre Kunden via TestFlight.

Wie lange dauert es vom fertigen Code bis zur Veröffentlichung?

Realistisch: 5–10 Werktage. Das setzt sich zusammen aus: TestFlight-Testing (2–5 Tage, je nach Ihrem Testplan), App Store Review (1–3 Tage) und einem Puffer für eventuelle Nachbesserungen. Wenn Sie alle Metadaten und Screenshots schon vorbereitet haben, kann es auch schneller gehen.

Kann Apple meine App ohne Grund ablehnen?

Theoretisch nein — Apple muss immer eine konkrete Guideline angeben. In der Praxis gibt es aber Ermessensspielraum, besonders bei Guidelines wie 4.2 (Minimum Functionality). Sie haben das Recht, gegen jede Ablehnung Einspruch zu erheben (Appeal), und seit 2024 gibt es ein unabhängiges Appeal Board.

Was passiert, wenn mein Developer Account abläuft?

Ihre App bleibt im Store verfügbar, solange sie funktioniert. Sie können aber keine Updates mehr einreichen und keine neuen Apps veröffentlichen. TestFlight-Builds werden deaktiviert. Verlängern Sie also rechtzeitig.

Kann ich eine App für einen Kunden veröffentlichen, ohne dessen Developer Account zu nutzen?

Ja, aber nicht empfehlenswert. Die App gehört dem Account-Inhaber. Wenn Sie als Agentur die App im eigenen Account veröffentlichen und der Kunde wechselt die Agentur, wird der App-Transfer kompliziert. Best Practice: Der Kunde erstellt den Developer Account, und Sie erhalten Zugriff als „Developer" oder „App Manager" über App Store Connect.

Gibt es Alternativen zum App Store für die Verteilung?

Mit dem Digital Markets Act (DMA) der EU erlaubt Apple seit iOS 17.4 in der EU alternative App-Marktplätze. In der Praxis ist der App Store aber nach wie vor der einzig relevante Vertriebskanal. Für interne Firmen-Apps gibt es zudem das Apple Enterprise Program (299 €/Jahr), das die Verteilung ohne App Store ermöglicht.

Muss ich als österreichisches Unternehmen etwas Besonderes beachten?

Die DSGVO gilt selbstverständlich — stellen Sie sicher, dass Ihre Datenschutzerklärung vollständig ist und Ihre App nur mit Zustimmung Daten erhebt. Außerdem: Wenn Sie In-App-Käufe anbieten, beachten Sie die österreichische Umsatzsteuer (20 %) — Apple kümmert sich in der EU um die Abführung, aber Sie brauchen trotzdem saubere Buchhaltung.

---

Fazit: Der Weg in den App Store ist machbar

Die Veröffentlichung einer iOS-App ist kein Hexenwerk — aber auch kein Selbstläufer. Code Signing, App Store Review und die korrekte Vorbereitung der Metadaten erfordern Erfahrung und Aufmerksamkeit.

Die drei wichtigsten Tipps zusammengefasst:

1. Starten Sie den Developer Account früh — besonders als Unternehmen mit D-U-N-S-Verifizierung.
2. Nutzen Sie EAS Build oder Automatic Signing — manuelles Code Signing ist ein vermeidbarer Zeitfresser.
3. Lesen Sie Apples Review Guidelines — die meisten Rejections lassen sich vermeiden, wenn man die Regeln kennt.

---

Sie planen eine iOS-App?

Als App-Entwickler in Wien und Wiener Neustadt begleiten wir österreichische KMU vom ersten Konzept bis zum App Store Launch — und darüber hinaus.

Wir übernehmen den gesamten Prozess: Entwicklung mit React Native und Expo, Code Signing, TestFlight-Setup, App Store Optimierung und die Kommunikation mit Apple bei Review-Problemen.

Weiterführende Seiten:

• iOS App-Entwicklung — Unsere Leistungen im Detail
• App-Entwicklung — Alle App-Services im Überblick
• App-Entwicklung Kosten — Was eine App in Österreich kostet

Jetzt unverbindliches Angebot anfragen →

Oder direkt Kontakt aufnehmen: Zum Kontaktformular →