Ich verwalte Next.js-Anwendungen seit Version 9. Einige dieser Apps laufen immer noch in der Produktion und bedienen Millionen von Anfragen. Andere? Sie wurden zu Upgrade-Alpträumen, weil jemand (okay, manchmal ich) die Wartung sechs Monate lang vernachlässigt hat und sich plötzlich mit 47 größeren Versions-Bumps, drei veralteten APIs und einer CVE konfrontiert sah, die das Security-Team um den Schlaf brachte.

Next.js entwickelt sich schnell. Das Framework veröffentlichte große Releases ungefähr alle sechs Monate während 2024 und 2025, und 2026 setzt dieses Tempo fort. Wenn Sie Ihr Next.js-Projekt nicht aktiv verwalten, sammeln Sie technische Schulden an, die schneller wachsen als erwartet. Dieser Leitfaden behandelt alles, was ich über die Erhaltung gesunder Next.js-Anwendungen gelernt habe – von wöchentlichen Abhängigkeitsprüfungen bis zu jährlichen Migrationen großer Versionen. Und wenn Sie bereits wissen, dass Sie Hilfe brauchen, reichen Sie Ihre RFP ein und wir schauen uns das an.

Inhaltsverzeichnis

Warum Next.js-Wartung wichtiger ist als Sie denken

Lassen Sie mich Ihnen einige Zahlen nennen. Laut dem Snyk 2025 State of Open Source Security Report hat das durchschnittliche JavaScript-Projekt 49 direkte Abhängigkeiten und über 500 transitive Abhängigkeiten. Jede einzelne ist eine potenzielle Angriffsfläche. Die mittlere Zeit zwischen Veröffentlichung einer Sicherheitslücke und dem Erscheinen eines Exploits in der Wildnis sank 2025 auf 7 Tage. Sieben Tage.

Next.js führt speziell Wartungsüberlegungen ein, die Vanilla-React-Apps nicht haben:

  • Server-seitiges Rendering-Angriffsfläche – Ihre Next.js-App führt Code auf einem Server aus, nicht nur im Browser. Eine anfällige Abhängigkeit auf der Serverseite ist viel gefährlicher als eine in einem Browser isolierte.
  • API-Routen und Server Actions – Dies sind vollständige Backend-Endpunkte. Sie benötigen die gleiche Sicherheitssorgfalt wie jede Express- oder Fastify-API.
  • Build-Pipeline-Abhängigkeiten – SWC, webpack/Turbopack, PostCSS-Prozessoren und Bildoptimierung haben alle ihre eigenen Abhängigkeitsbäume.
  • Middleware-Ausführung – läuft in vielen Bereitstellungen am Edge, mit seinem eigenen Satz von Kompatibilitäts- und Sicherheitsüberlegungen.

Über die Sicherheit hinaus gibt es die SEO-Seite. Googles Core Web Vitals sind ein Ranking-Faktor, und Next.js-Performance-Rückgänge durch veralteten Code können Ihre Suchsichtbarkeit direkt beeinflussen. Wir haben Clients bei Social Animal gesehen, die nur durch ein Upgrade von Next.js 13 auf 15 und das Beheben akkumulierter Performance-Probleme 15-20% des verlorenen organischen Traffics zurückgewonnen haben.

Einen Wartungsplan erstellen, der tatsächlich funktioniert

Die wichtigste Erkenntnis, die ich nach der Verwaltung von Dutzenden Next.js-Projekten gewonnen habe: Wartung ist einfacher, wenn sie langweilig und routinemäßig ist. In dem Moment, in dem sie ein „Projekt" wird, ist es bereits überfällig.

Hier ist der Plan, den ich verwende:

Häufigkeit Aufgabe Zeitaufwand
Wöchentlich Dependabot/Renovate PRs überprüfen, Patch-Updates mergen 30-60 Min
Alle zwei Wochen npm audit ausführen und Erkenntnisse beheben 30 Min
Monatlich Minor-Versionen aktualisieren, Changelog auf Breaking Changes überprüfen 2-4 Std
Vierteljährlich Ungenutzte Abhängigkeiten prüfen, Bundle-Größe überprüfen, Node.js aktualisieren 4-8 Std
Pro Release Migration großer Next.js-Versionen 8-40 Std
Jährlich Vollständige Sicherheitsprüfung, Abhängigkeitsüberholung, Infrastrukturüberprüfung 16-40 Std

Der wöchentliche Rhythmus

Jeden Montagmorgen überprüfe ich die automatisierten PRs, die Tools wie Renovate oder Dependabot geöffnet haben. Patch-Updates (1.2.3 → 1.2.4) werden nach Bestehen von CI gemergt. Das dauert maximal 30 Minuten und verhindert die Situation „200 veraltete Pakete".

# Schnelle Gesundheitsprüfung, die ich jede Woche durchführe
npx npm-check-updates --target patch
npm audit --audit-level=moderate
npx next info

Der monatliche Deep Dive

Einmal im Monat schaue ich mir Minor-Version-Bumps an. Diese können neue Funktionen enthalten, sollten aber bestehende APIs nicht unterbrechen. Betonung auf „sollten". Lesen Sie immer die Changelogs.

# Nach Minor-Updates suchen
npx npm-check-updates --target minor

# Vorschau, was sich ändern würde
npx npm-check-updates --target minor --format group

Ich gruppiere zusammenhängende Updates. @next/font separat von next zu aktualisieren, ist Ärger programmiert. Sie sollten synchron vorankommen.

Abhängigkeits-Upgrades: Der Schritt-für-Schritt-Prozess

Hier machen die meisten Teams es falsch. Sie führen npm update aus, beten und pushen. Hier ist, was ich eigentlich mache:

Schritt 1: Verstehen Sie, was Sie haben

Bevor Sie etwas aktualisieren, kennen Sie Ihre Abhängigkeitslandschaft.

# Alle veralteten Pakete mit Details auflisten
npm outdated

# Abhängigkeitsbaum für ein bestimmtes Paket generieren
npm ls react-dom

# Nach Duplikaten in Ihrer Sperrdatei suchen
npx depcheck

Schritt 2: Kategorisieren Sie Updates nach Risiko

Nicht alle Updates sind gleich. Ich sortiere sie in Eimer:

Risikostufe Beispiele Ansatz
Niedrig Patch-Updates, nur Dev-Abhängigkeiten, Typ-Definitions-Updates Sammeln und mergen
Mittel Minor-Version-Bumps in Runtime-Abhängigkeiten, Next.js-Patch-Updates Einzeln aktualisieren, vollständige Test-Suite ausführen
Hoch Große Version-Bumps, Next.js Minor/Major-Updates, React-Updates Dedizierter Branch, gründliches Testen, gestaffelte Einführung
Kritisch Sicherheits-Patches für Runtime-Abhängigkeiten Same-Day-Update, Notfall-Prozess

Schritt 3: Erstellen Sie einen isolierten Branch

Für alles über Patch-Updates:

git checkout -b deps/update-2026-05

# Bestimmte Pakete aktualisieren
npm install next@latest react@latest react-dom@latest

# Build sofort ausführen – nicht warten
npm run build

# Test-Suite ausführen
npm test

# Auf Type-Fehler prüfen, wenn TypeScript verwendet wird
npx tsc --noEmit

Schritt 4: Überprüfen Sie das Runtime-Verhalten

Wir sind auf das Problem bei einem Client-Projekt letzten Jahres gestoßen: Der Build war erfolgreich, Tests waren grün, und alles sah auf dem Papier in Ordnung aus. Dann begannen Server Components, Hydration-Mismatches in der Produktion zu werfen, weil eine Abhängigkeit in einem Minor-Update ihr Ausgabeformat geändert hatte. Ein bestandener Build und bestandene Tests bedeuten nicht, dass alles funktioniert.

Ich mache immer:

  1. Führe den Dev-Server aus und klicke manuell durch kritische Pfade
  2. Überprüfe, ob Server Components immer noch richtig rendern (Hydration-Mismatches lieben es, sich zu verstecken)
  3. Überprüfe, dass API-Routen erwartete Responses zurückgeben
  4. Teste Middleware-Verhalten, besonders Auth-Flows
  5. Überprüfe, dass die Bildoptimierung immer noch funktioniert (die next/image-Komponente ist über Updates hinweg kaputt gegangen)

Wenn Sie gerade die Anforderungen dieser Art Arbeit bestimmen und ein Team hinter sich brauchen, senden Sie uns Ihre RFP und wir können den richtigen Ansatz gemeinsam herausfinden.

Schritt 5: Überwachen Sie nach der Bereitstellung

Mergen Sie nicht und vergessen Sie nicht. Beobachten Sie Ihr Error Tracking (Sentry, LogRocket) und Performance-Überwachung 48 Stunden nach der Bereitstellung von Abhängigkeitsupdates.

Sicherheitshärtung für Next.js im Jahr 2026

Sicherheit in Next.js hat sich erheblich weiterentwickelt. Das Server Actions-Modell, das in Next.js 14 eingeführt wurde und sich durch 15 und 16 bewährt hat, hat die Angriffsfläche vollständig verändert. Hier ist, worauf Sie sich gerade konzentrieren sollten.

Server Action-Sicherheit

Server Actions sind im Wesentlichen öffentliche API-Endpunkte. Behandeln Sie sie so.

// SCHLECHT – keine Validierung, keine Auth-Prüfung
'use server'
export async function deleteUser(userId: string) {
  await db.user.delete({ where: { id: userId } })
}

// GUT – validiert, authentifiziert, autorisiert
'use server'
import { z } from 'zod'
import { auth } from '@/lib/auth'

const deleteUserSchema = z.object({
  userId: z.string().uuid(),
})

export async function deleteUser(rawData: unknown) {
  const session = await auth()
  if (!session?.user) throw new Error('Unauthorized')
  
  const { userId } = deleteUserSchema.parse(rawData)
  
  // Überprüfe, dass der Benutzer die Berechtigung hat, diesen bestimmten Benutzer zu löschen
  if (session.user.role !== 'admin') throw new Error('Forbidden')
  
  await db.user.delete({ where: { id: userId } })
  revalidatePath('/admin/users')
}

Sicherheits-Header

Ihre next.config.js (oder next.config.ts im Jahr 2026 – TypeScript-Konfiguration ist seit Next.js 15 stabil) sollte Sicherheits-Header setzen:

// next.config.ts
import type { NextConfig } from 'next'

const securityHeaders = [
  { key: 'X-DNS-Prefetch-Control', value: 'on' },
  { key: 'Strict-Transport-Security', value: 'max-age=63072000; includeSubDomains; preload' },
  { key: 'X-Frame-Options', value: 'SAMEORIGIN' },
  { key: 'X-Content-Type-Options', value: 'nosniff' },
  { key: 'Referrer-Policy', value: 'strict-origin-when-cross-origin' },
  { key: 'Permissions-Policy', value: 'camera=(), microphone=(), geolocation=()' },
]

const config: NextConfig = {
  async headers() {
    return [
      {
        source: '/(.*)',
        headers: securityHeaders,
      },
    ]
  },
}

export default config

Content Security Policy

CSP ist in Next.js schwieriger, weil Inline-Scripts für Hydration verwendet werden. Der Nonce-basierte Ansatz funktioniert am besten:

// middleware.ts
import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'

export function middleware(request: NextRequest) {
  const nonce = Buffer.from(crypto.randomUUID()).toString('base64')
  const cspHeader = `
    default-src 'self';
    script-src 'self' 'nonce-${nonce}' 'strict-dynamic';
    style-src 'self' 'nonce-${nonce}';
    img-src 'self' blob: data:;
    font-src 'self';
    object-src 'none';
    base-uri 'self';
    form-action 'self';
    frame-ancestors 'none';
    upgrade-insecure-requests;
  `
  
  const response = NextResponse.next()
  response.headers.set('Content-Security-Policy', cspHeader.replace(/\s{2,}/g, ' ').trim())
  response.headers.set('x-nonce', nonce)
  return response
}

npm Audit Workflow

Führen Sie nicht einfach npm audit aus. Verarbeiten Sie die Ergebnisse systematisch:

# JSON-Report für Tracking generieren
npm audit --json > audit-report.json

# Was möglich ist, automatisch reparieren
npm audit fix

# Für hartnäckige Probleme, die Major-Bumps benötigen
npm audit fix --force  # seien Sie vorsichtig damit

# Bestimmte Pakete auf bekannte Sicherheitslücken prüfen
npx is-my-node-vulnerable

Für Pakete, bei denen der Fix noch nicht verfügbar ist, verwenden Sie npm audit-Overrides in package.json:

{
  "overrides": {
    "vulnerable-transitive-dep": ">=2.1.1"
  }
}

Automatisierte Tools und CI/CD-Integration

Automatisierung trennt Teams, die gut warten, von Teams, die das nicht tun. Hier ist mein Stack für 2026:

Renovate Bot-Konfiguration

Ich bevorzuge Renovate gegenüber Dependabot für Next.js-Projekte. Es ist konfigurierbarer und handhabt Monorepos besser.

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:recommended"],
  "schedule": ["every weekend"],
  "packageRules": [
    {
      "matchPackageNames": ["next", "react", "react-dom", "@types/react", "@types/react-dom"],
      "groupName": "React + Next.js core",
      "automerge": false
    },
    {
      "matchUpdateTypes": ["patch"],
      "matchPackagePatterns": ["eslint", "prettier", "@types/"],
      "automerge": true,
      "automergeType": "branch"
    },
    {
      "matchPackagePatterns": ["*"],
      "matchUpdateTypes": ["major"],
      "enabled": true,
      "automerge": false,
      "labels": ["major-update", "needs-review"]
    }
  ],
  "vulnerabilityAlerts": {
    "enabled": true,
    "labels": ["security"]
  }
}

CI-Pipeline für Abhängigkeitsupdates

Ihre CI sollte mehr tun, als Tests auszuführen, wenn sich Abhängigkeiten ändern:

# .github/workflows/dependency-check.yml
name: Dependency Update Validation
on:
  pull_request:
    paths:
      - 'package.json'
      - 'package-lock.json'

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '22'
          cache: 'npm'
      - run: npm ci
      - run: npm run build
      - run: npm test
      - run: npm audit --audit-level=high
      - name: Bundle size check
        run: npx size-limit
      - name: Lighthouse CI
        uses: treosh/lighthouse-ci-action@v12
        with:
          configPath: './lighthouserc.json'

Socket.dev für Supply-Chain-Sicherheit

Ich habe Socket.dev in jedem Projekt hinzugefügt, das ich verwalte. Es erkennt Dinge, die npm audit verpasst, wie Pakete, die plötzlich Netzwerk-Calls oder Dateisystem-Zugriff in neuen Versionen hinzufügen. Es hat zwei verdächtige Updates in Projekten, an denen ich im letzten Jahr gearbeitet habe, erkannt.

Umgang mit großen Next.js-Versionsmigrationen

Migrationen mit großen Versionen verdienen ihr eigenes Kapitel, weil sie die zeitaufwendigste und riskanteste Wartungsaufgabe sind.

Der Migrations-Spielplan

  1. Lesen Sie den offiziellen Migrationsleitfaden vollständig durch, bevor Sie Code schreiben. Vercel veröffentlicht detaillierte Codemods und Leitfäden für jede größere Version.

  2. Führen Sie zuerst die Codemods aus. Next.js bietet automatisierte Codemods, die die meisten Umbenennungen und API-Änderungen handhaben:

npx @next/codemod@latest upgrade

  1. Compiler-Fehler beheben. Nach dem Codemod TypeScript-Kompilierung ausführen und beheben, was kaputt ist.

  2. Testen Sie Server Components und Client Components-Grenzen. Hauptversionen ändern oft das Standardverhalten um Komponententypen.

  3. Überprüfen Sie Daten-Abruf-Muster. Der Wechsel von getServerSideProps zu Server Components war die größte Breaking Change von Next.js überhaupt (Next.js 13). Nachfolgende Versionen haben diese Fläche weiterhin verfeinert.

  4. Aktualisieren Sie Ihre Bereitstellungskonfiguration. Vercel handhabt dies automatisch, aber wenn Sie selbst hosten oder eine andere Plattform verwenden, müssen Sie Ihre Dockerfile, Build-Scripts oder Serverless-Konfiguration aktualisieren.

Versionsspezifische Notizen für 2026

Migration Wichtigste Änderungen Geschätzter Aufwand (mittlere App)
Next.js 14 → 15 Async Request APIs, React 19, Turbopack stabil 16-24 Std
Next.js 15 → 16 Aktualisierte Caching-Defaults, React Compiler-Integration 8-16 Std

Wenn Sie immer noch Next.js 13 oder früher ausführen, überdenken Sie ernsthaft, ob eine schrittweise Migration oder ein kompletter Neuaufbau sinnvoller ist. Wir helfen Teams bei dieser Entscheidung bei Social Animal. Manchmal ist die ehrliche Antwort „von vorne anfangen."

Performance-Überwachung als Wartung

Wartung geht nicht nur darum, Abhängigkeiten aktuell zu halten. Es geht darum, Performance-Rückgänge zu erkennen, bevor Ihre Benutzer (und Google) sie bemerken.

Was zu überwachen ist

  • Core Web Vitals: LCP, CLS, INP (Interaction to Next Paint ersetzte 2024 FID). Verwenden Sie Vercel Analytics, Google Search Console oder CrUX-Daten.
  • Build-Zeiten: Wenn Ihre Build-Zeit in drei Monaten verdoppelt wird, stimmt etwas nicht. Verfolgen Sie es in CI.
  • Bundle-Größe: Setzen Sie Budgets mit @next/bundle-analyzer und size-limit.
  • Server-Antwortzeiten: Besonders für Server Components und API-Routen.
  • Fehlerquoten: Spitzen nach Updates deuten auf Rückgänge hin.
# Bundle-Analyse zu Ihrem Projekt hinzufügen
npm install @next/bundle-analyzer

// next.config.ts
import withBundleAnalyzer from '@next/bundle-analyzer'

const config = withBundleAnalyzer({
  enabled: process.env.ANALYZE === 'true',
})({
  // Ihre Konfiguration
})

export default config

Führen Sie ANALYZE=true npm run build monatlich aus und vergleichen Sie die Ergebnisse. Eine allmählich wachsende Bundle-Größe zeigt oft auf eine Abhängigkeit hin, die in einem Minor-Update viel Gewicht hinzugefügt hat.

Wann man neu aufbauen sollte und wann upgraden

Das ist die schwere Frage, die niemand stellen möchte. Hier ist mein Entscheidungsrahmen:

Upgraden Sie bestehenden Code, wenn:

  • Sie 1-2 Hauptversionen hinter sind
  • Ihr Codebase folgt modernen Mustern (App Router, Server Components)
  • Tests decken kritische Pfade ab
  • Das Team versteht die bestehende Codebasis

Erwägen Sie einen Neubau, wenn:

  • Sie 3+ Hauptversionen hinter sind
  • Die App ist immer noch auf Pages Router und Sie benötigen App Router-Funktionen
  • Erhebliche technische Schulden haben sich über Abhängigkeiten hinaus angesammelt
  • Die ursprüngliche Architektur passt nicht zu aktuellen Anforderungen

Erwägen Sie eine Migration zu einem anderen Framework, wenn:

  • Ihre Website ist überwiegend statisch und Next.js ist Overkill (schauen Sie sich Astro an)
  • Sie kämpfen gegen Next.js-Muster, statt mit ihnen zu arbeiten
  • Ihr Team hat Expertise in einem anderen Stack

Wenn Sie eine inhaltsreiche Website mit einem Headless-CMS betreiben, spart manchmal eine Migration zu einer speziell dafür entwickelten Architektur mehr Zeit als die Verwaltung einer Next.js-App, die über ihren ursprünglichen Umfang hinausgewachsen ist. Wir freuen uns immer, die Optionen ehrlich zu besprechen.

Häufig gestellte Fragen

Wie oft sollte ich Next.js-Abhängigkeiten aktualisieren? Patch-Updates sollten wöchentlich erfolgen. Sie sind fast immer sicher und enthalten oft Sicherheits-Patches. Minor-Updates monatlich, nachdem Sie das Changelog überprüft haben. Hauptversionen innerhalb von 2-3 Monaten nach der stabilen Veröffentlichung, sobald das Ökosystem Zeit zum Aufholen hatte. Länger als 6 Monate auf Hauptversionen zu warten, erzeugt erhebliche Upgrade-Schmerzen.

Ist es sicher, npm audit fix --force zu verwenden? Nein, nicht ohne sorgfältige Überprüfung. Das --force-Flag ermöglicht Major-Version-Bumps in Abhängigkeiten, was Breaking Changes einführen kann. Ich verwende es nur als Ausgangspunkt. Führen Sie es auf einem Branch aus, bauen Sie auf, testen Sie gründlich, und überprüfen Sie jede Änderung in package-lock.json, bevor Sie mergen. Für Produktionsanwendungen ist das manuelle Aktualisieren des spezifischen anfälligen Pakets fast immer sicherer.

Was ist das beste Tool zur Automatisierung von Next.js-Abhängigkeitsupdates? Renovate Bot ist meine erste Wahl für 2026. Es handhabt gruppierte Updates (hält next, react und react-dom synchron), unterstützt Automerge für Low-Risk-Updates und hat exzellente Monorepo-Unterstützung. Dependabot funktioniert für einfachere Setups in Ordnung. Socket.dev ist unabhängig davon, welches Update-Tool Sie verwenden, als zusätzliche Schicht für Supply-Chain-Sicherheit unerlässlich.

Wie handhabe ich Sicherheitslücken in transitiven Abhängigkeiten? Überprüfen Sie zuerst, ob das Aktualisieren der direkten Abhängigkeit, die das anfällige Paket zieht, es behebt. Wenn nicht, verwenden Sie overrides in package.json (npm) oder resolutions (yarn), um eine bestimmte Version zu erzwingen. Als letztes Resort, wenn die Sicherheitslücke in einem Paket ist, das Sie nicht aktualisieren können, evaluieren Sie, ob Sie die Eltern-Abhängigkeit vollständig ersetzen können oder einen Patch mit patch-package hinzufügen.

Sollte ich sofort auf die neueste Next.js-Version upgraden, wenn sie veröffentlicht wird? Nicht für Produktions-Apps. Warten Sie 2-4 Wochen nach einer Hauptversion für die erste Welle von Fehlerbehebungen. Folgen Sie den Next.js GitHub-Issues und der Community auf X/Twitter auf frühe Berichte von Problemen. Für Minor- und Patch-Releases können Sie aggressiver sein. Diese sind normalerweise innerhalb weniger Tage nach der Veröffentlichung sicher.

Wie verwalte ich eine Next.js-App, wenn ich ein Solo-Entwickler bin? Automatisierung ist Ihr bester Freund. Richten Sie Renovate Bot mit Automerge für Patch-Updates ein, konfigurieren Sie CI, um Builds und Tests auf jedem Abhängigkeits-PR auszuführen, und reservieren Sie jeden Monat einen festen 2-Stunden-Block für manuelle Überprüfung. Der von mir aufgeführte Zeitplan skaliert gut nach unten. Die wöchentliche Kontrolle wird zu einem 15-Minuten-Blick auf automatisierte PRs, und der monatliche Deep Dive bleibt bei 2 Stunden.

Welche Node.js-Version sollte ich 2026 mit Next.js verwenden? Next.js 16 erfordert Node.js 18.18 oder später, aber ich würde empfehlen, Node.js 22 LTS auszuführen (das im Oktober 2024 in LTS eintrat und bis April 2027 unterstützt wird). Node.js 20 LTS ist auch in Ordnung. Vermeiden Sie Node.js 18, wenn Sie nicht eine bestimmte Kompatibilitätsanforderung haben. Es erreichtel das End-of-Life im April 2025 und sollte nicht mehr in der Produktion sein.

Lohnt es sich, für professionelle Wartung zu bezahlen, wenn wir Entwickler im Haus haben? Das hängt von der Bandbreite und Expertise Ihres Teams ab. Hausgemachte Entwickler priorisieren Wartung oft nicht, weil Feature-Arbeit sich immer drängender anfühlt. Wenn Ihre Next.js-App geschäftskritisch ist und die Wartung konsequent vernachlässigt wird, stellt eine dedizierte Wartungsvereinbarung mit einem spezialisierten Team sicher, dass sie tatsächlich durchgeführt wird. Wir haben viele Teams gesehen, bei denen die Kosten aufgeschobener Wartung weit übertroffen hätten, was regelmäßige professionelle Wartung gekostet hätte. Bereit, Wartung aufzuschieben zu beenden? Erhalten Sie einen Vorschlag in 48 Stunden und lassen Sie uns herausfinden, was Ihre App braucht.