React Native Academy · Lektion

Feinschliff, Tests und Veröffentlichung in beiden Stores

Schreiben Sie Unit-Tests für zentrale Hooks, fügen Sie einen Maestro-E2E-Ablauf für den kritischen Pfad hinzu, optimieren Sie das Bundle, erstellen Sie Store-Assets und reichen Sie die App sowohl im App Store als auch bei Google Play ein.

Lektion 4 von 413 Schritte

Feinschliff, Tests und Veröffentlichung in beiden Stores ist eine kostenlose React Native Academy-Lektion auf CoddyKit. Dies ist Lektion 4 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des React Native Academy-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der React Native Academy-Kurs umfasst insgesamt 4 Lektionen.

Die letzte Etappe: Optimieren, testen, veröffentlichen

Die letzte Phase jedes App-Projekts erfordert am meisten Disziplin: die Optimierung der Details, die Benutzern tatsächlich auffallen, das Schreiben von Tests, die Regressionen verhindern, bevor sie die Produktion erreichen, und die Durchführung des Einreichungsprozesses für beide Stores. Jeder dieser Schritte wirkt zunächst schnell erledigt, dauert aber genauso lange wie die Entwicklung der Funktionen – planen Sie entsprechend Zeit ein. Eine sorgfältig optimierte App mit angemessener Testabdeckung kann mit Zuversicht veröffentlicht werden.

UI-Feinschliff: Einheitliche Abstände und Typografie

Der Feinschliff beginnt mit Design-Tokens – einer zentralen Quelle für Abstände, Schriftgrößen, Schriftstärken, Eckenradien und Farben. Definieren Sie diese in einer Datei theme.ts und importieren Sie sie überall, anstatt über die Bildschirme verteilt padding: 16 fest zu codieren. Einheitlichkeit sorgt dafür, dass eine App hochwertig wirkt: Wenn alle Schaltflächen dieselbe Höhe haben, alle Überschriften dieselbe Schrift verwenden und alle Karten denselben Schatten aufweisen, wirkt die Benutzeroberfläche bewusst gestaltet.

// src/theme.ts
export const theme = {
  colors: {
    primary: '#007AFF',
    background: '#F2F2F7',
    surface: '#FFFFFF',
    text: '#000000',
    textSecondary: '#8E8E93',
    error: '#FF3B30',
    success: '#34C759',
  },
  spacing: {
    xs: 4, sm: 8, md: 16, lg: 24, xl: 32
  },
  typography: {
    largeTitle: { fontSize: 34, fontWeight: '700' },
    title: { fontSize: 22, fontWeight: '600' },
    body: { fontSize: 17, fontWeight: '400' },
    caption: { fontSize: 12, fontWeight: '400' },
  },
  borderRadius: { sm: 8, md: 12, lg: 16, full: 999 },
};

Barrierefreiheitsprüfung

Barrierefreiheit ist sowohl eine gesetzliche Anforderung als auch ein Qualitätsmerkmal. Prüfen Sie Ihre App auf: Accessibility-Labels für alle Symbolschaltflächen (accessibilityLabel), Mindestgrößen für Touch-Ziele von 44×44pt unter iOS und 48×48dp unter Android, korrekte Accessibility-Rollen (accessibilityRole='button' für antippbare Elemente) sowie Farbkontrast (mindestens 4,5:1 für Fließtext). Verwenden Sie den iOS Accessibility Inspector oder Android TalkBack, um das Verhalten des Screenreaders zu testen.

// Accessible icon button
<TouchableOpacity
  onPress={handleDelete}
  accessibilityLabel='Delete habit'
  accessibilityRole='button'
  accessibilityHint='Permanently removes this habit and its history'
  style={{ padding: 12 }}  // Ensures 44pt touch target with 20pt icon
>
  <Ionicons name='trash-outline' size={20} color='#FF3B30' />
</TouchableOpacity>

// Screen reader text for images
<Image
  source={{ uri: habit.icon }}
  accessibilityLabel={`${habit.name} habit icon`}
  accessible={true}
/>

Unit-Tests für zentrale Hooks schreiben

Testen Sie die von der Benutzeroberfläche unabhängige Geschäftslogik mit Unit-Tests – Berechnungen, Hooks mit simulierten Abfragen und Hilfsfunktionen. Die Berechnung der Streak ist ein idealer Kandidat: Testen Sie Sonderfälle wie ein leeres Array, einen einzelnen Tag, eine Lücke in der Mitte und den Fall, dass der heutige Tag nicht abgeschlossen wurde. Verwenden Sie @testing-library/react-native zusammen mit renderHook, um benutzerdefinierte Hooks zu testen, die den React-Status und Effects verwenden.

// src/utils/__tests__/streaks.test.ts
import { calculateStreak } from '../streaks';

describe('calculateStreak', () => {
  it('returns 0 for empty completions', () => {
    expect(calculateStreak([])).toBe(0);
  });

  it('returns 1 when only today is completed', () => {
    const today = new Date().toISOString().split('T')[0];
    expect(calculateStreak([today])).toBe(1);
  });

  it('returns correct streak for consecutive days', () => {
    const dates = ['2026-06-21', '2026-06-20', '2026-06-19'];
    // Mock today as 2026-06-21 in tests
    expect(calculateStreak(dates)).toBe(3);
  });

  it('stops at a gap', () => {
    // Today=21, gap at 20, then 19
    const dates = ['2026-06-21', '2026-06-19'];
    expect(calculateStreak(dates)).toBe(1);
  });
});

Komponententests mit React Native Testing Library

Schreiben Sie Komponententests für die am häufigsten verwendeten UI-Elemente: dafür, dass die HabitCard den Namen des Habits und die Streak rendert, dass der CheckInButton seinen Status beim Drücken umschaltet und dass das OfflineBanner nur im Offline-Modus erscheint. Simulieren Sie Abhängigkeiten wie Supabase und React Query an der Testgrenze, damit die Komponenten isoliert und ohne echte Netzwerkaufrufe getestet werden.

// src/components/__tests__/HabitCard.test.tsx
import { render, fireEvent } from '@testing-library/react-native';
import { HabitCard } from '../HabitCard';

const mockHabit = {
  id: '1', name: 'Morning Run', icon: 'run',
  color: '#007AFF', streak: 5
};

it('renders habit name and streak', () => {
  const { getByText } = render(<HabitCard habit={mockHabit} onPress={() => {}} />);
  expect(getByText('Morning Run')).toBeTruthy();
  expect(getByText('5 days')).toBeTruthy();
});

it('calls onPress when tapped', () => {
  const onPress = jest.fn();
  const { getByTestId } = render(
    <HabitCard habit={mockHabit} onPress={onPress} testID='habit-card' />
  );
  fireEvent.press(getByTestId('habit-card'));
  expect(onPress).toHaveBeenCalledTimes(1);
});

Maestro E2E: Test des kritischen Pfads

Schreiben Sie einen Maestro-Flow für den kritischen Benutzerpfad: anmelden, einen Habit erstellen, den Check-in durchführen, die Aktualisierung der Streak überprüfen und abmelden. Damit werden Integrationsfehler erkannt, die Unit-Tests übersehen – etwa bei gleichzeitigem Zusammenspiel von Navigationsstatus, Netzwerkaufrufen und UI-Status. Führen Sie den Flow bei jedem CI-Build auf einem echten Simulator oder Gerät aus, bevor Sie den Build in den nächsten Test-Track hochstufen.

# maestro/critical-path.yaml
---
appId: com.yourcompany.habittracker
---
- launchApp:
    clearState: true
- tapOn: 'Sign In'
- inputText: 'test@example.com'
- tapOn: 'Password'
- inputText: 'TestPass123!'
- tapOn: 'Sign In'
- waitForAnimationToEnd
- assertVisible: 'My Habits'
- tapOn: 'Add Habit'
- inputText: 'Morning Run'
- tapOn: 'Save'
- waitForAnimationToEnd
- assertVisible: 'Morning Run'
- tapOn:
    id: 'check-in-btn-1'
- waitForAnimationToEnd
- assertVisible: '1 day'  # Streak shows 1 day
- tapOn: 'Settings'
- tapOn: 'Sign Out'
- assertVisible: 'Sign In'

Bundle-Größe optimieren

Analysieren und minimieren Sie vor der Einreichung das JS-Bundle. Verwenden Sie react-native-bundle-visualizer, um große Abhängigkeiten zu identifizieren. Häufige Einsparungen sind: moment.js (280KB) durch date-fns (Tree-Shaking-fähig, etwa 5KB pro Import) ersetzen, nicht verwendete Icon-Pakete entfernen (importieren Sie nur die verwendeten Icons) und Lazy Loading (React.lazy + Suspense) für umfangreiche Bildschirme wie Einstellungen oder Onboarding einsetzen, die Benutzer nach dem ersten Start nur selten besuchen.

# Analyze bundle
npx react-native-bundle-visualizer

# Opens a visual treemap in browser showing:
# - node_modules breakdown by size
# - Your source code size
# - Duplicate modules

# Common large packages to replace:
# moment (280KB) -> date-fns tree-shaking
# lodash (full, 70KB) -> lodash-es specific imports
# FontAwesome all icons -> import only used icons

# Result: each 100KB reduction = ~50KB gzip reduction
# = faster first install + lower Play/App Store size

Store-Assets erstellen

Erstellen Sie vor der Einreichung die erforderlichen Store-Assets: App-Icon (1024×1024 für iOS, adaptives Icon für Android), Startbildschirm (alle Größenvarianten über die Splash-Konfiguration von Expo), Screenshots (mindestens 3–6 pro erforderlicher Gerätegröße) und eine Feature-Grafik (1024×500 für Android). Verwenden Sie ein Designtool wie Figma mit Plugins für Geräterahmen, um professionell wirkende Screenshots zu erstellen, ohne dafür einen Marketingdesigner zu benötigen.

// app.json — icon and splash configuration
{
  'expo': {
    'icon': './assets/icon.png',        // 1024x1024 PNG
    'splash': {
      'image': './assets/splash.png',
      'resizeMode': 'contain',
      'backgroundColor': '#007AFF'
    },
    'ios': {
      'icon': './assets/icon.png'
    },
    'android': {
      'icon': './assets/icon.png',
      'adaptiveIcon': {
        'foregroundImage': './assets/adaptive-icon.png',
        'backgroundColor': '#007AFF'
      }
    }
  }
}

Finalen Produktions-Build erstellen

Starten Sie die EAS-Produktions-Builds für beide Plattformen. Überprüfen Sie vor dem Build, ob Versionsnummer und Versionscode korrekt sind – nachträgliche Änderungen erfordern einen neuen Build. Führen Sie beide Builds parallel aus, um Zeit zu sparen. Sobald beide abgeschlossen sind, laden Sie sie zu TestFlight und zum internen Testen in der Play Console hoch, um vor der Einreichung zur Prüfung einen letzten Smoke-Test mit exakt dem Produktions-Binary durchzuführen.

# Verify versions before building
cat app.json | grep '"version"'
# -> "version": "1.0.0"
# -> "versionCode": 1
# -> "buildNumber": "1"

# Build both platforms in parallel
eas build --platform ios --profile production &
eas build --platform android --profile production &
wait

# Or use the combined command:
eas build --platform all --profile production

# After builds complete, check status:
eas build:list --status finished --limit 2

Produktions-Build per Smoke-Test prüfen

Installieren Sie vor der Einreichung zur Prüfung das exakt für die Produktion erstellte Binary auf einem echten Gerät. Laden Sie die iOS-Datei .ipa zu TestFlight und die Android-Datei .aab zum internen Testen in der Play Console hoch. Testen Sie den Registrierungsablauf, die Kernfunktion, Push-Benachrichtigungen und den Kaufablauf (falls zutreffend) von Grund auf – gehen Sie niemals davon aus, dass sich die Entwicklungsversion genauso verhält wie der Produktions-Build. Produktions-Builds verwenden andere Signatur-, Minifizierungs- und ProGuard-Einstellungen, durch die Fehler sichtbar werden können, die in der Entwicklung nicht aufgetreten sind.

// Pre-submission smoke test checklist:

// Install production build on physical device
// (not simulator — push notifications require real device)

// Test:
// [ ] Fresh install and sign up flow
// [ ] Sign out and sign in with existing account
// [ ] Core feature: create, complete, view streak
// [ ] Push notification: schedule and receive
// [ ] Background behavior: close and reopen app
// [ ] Deep links from browser/email
// [ ] Offline: airplane mode then restore network
// [ ] Landscape orientation (if not locked)
// [ ] All tabs and major screens load without crash
// [ ] Performance: no jank on FlatList scroll

In beide Stores einreichen

Reichen Sie die App gleichzeitig in beiden Stores ein, damit die Prüfungszeiträume aufeinander abgestimmt sind und Sie auf beiden Plattformen am selben Tag starten können. Verwenden Sie für beide eas submit. Die Prüfung im App Store dauert in der Regel 1–3 Tage, bei Google Play 1–7 Tage für eine erste App (bei Updates geht es schneller). Halten Sie Marketingmaterialien bereit (App-Website, Beiträge in sozialen Medien, Pressemappe), damit Sie den Launch ankündigen können, sobald beide Stores die App genehmigt haben. Überwachen Sie während des Prüfungszeitraums täglich die Prüfungs-Dashboards beider Stores.

# Submit to App Store (TestFlight first, then App Review)
eas submit --platform ios --latest

# Submit to Play Console (internal -> production)
eas submit --platform android --latest

# Or submit both at once:
eas submit --platform all --latest

# After submission:
# iOS: App Store Connect > App > 1.0 Prepare for Submission
#      > Add for Review > Submit to App Review
# Android: Play Console > Production > Create release
#           > Promote internal build > Review > Start rollout

Kurzer Check

Testen Sie Ihr Verständnis der Konzepte zur Entwicklung mobiler Anwendungen mit React Native aus dieser Lektion.

Zusammenfassung der Lektion

In dieser Lektion haben Sie gelernt: wie Sie Ihre App mit Design-Tokens, Accessibility-Labels und Mindestgrößen für Touch-Ziele prüfen und optimieren, wie Sie Unit-Tests für die Streak-Logik und Komponententests mit RNTL schreiben und wie Sie einen Maestro-E2E-Flow für den kritischen Benutzerpfad schreiben und die App im App Store und Play Store einreichen. Herzlichen Glückwunsch – Sie haben den Track zur Entwicklung mobiler Anwendungen mit React Native abgeschlossen! Sie verfügen nun über die Kenntnisse, um qualitativ hochwertige React-Native-Apps für beide Plattformen zu entwickeln, zu testen und zu veröffentlichen.

Kostenlos starten

Lerne JavaScript mit einem KI-Tutor — kostenlos

Schreibe und führe echten Code in deinem Browser aus, bekomme sofortige Hilfe von einem 24/7 KI-Tutor und setze dein Lernen im Web oder in der App fort.

Kurse
30
Lektionen
120

Häufig gestellte Fragen

Ist die Lektion „Feinschliff, Tests und Veröffentlichung in beiden Stores“ kostenlos?

Ja — der vollständige Text von „Feinschliff, Tests und Veröffentlichung in beiden Stores“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des React Native Academy-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der React Native Academy-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „Feinschliff, Tests und Veröffentlichung in beiden Stores“?

Schreiben Sie Unit-Tests für zentrale Hooks, fügen Sie einen Maestro-E2E-Ablauf für den kritischen Pfad hinzu, optimieren Sie das Bundle, erstellen Sie Store-Assets und reichen Sie die App sowohl im… Du übst React Native Academy mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um React Native Academy zu starten?

Keine Vorkenntnisse erforderlich. React Native Academy auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 4 von 4.

Wie lange dauert die Lektion „Feinschliff, Tests und Veröffentlichung in beiden Stores“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser React Native Academy-Lektion Code schreiben und ausführen?

Ja. Jede React Native Academy-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

  1. Architektur und Tech-Stack planen
  2. Authentifizierungsablauf und geschützte Routen
  3. Kernfunktion: Daten-Feed mit Offline-Unterstützung
  4. Feinschliff, Tests und Veröffentlichung in beiden Stores
← Zurück zu React Native Academy