Von Web zu Native – Wann lohnt sich eine iOS-App statt PWA? (2026)

~16 Min. Lesezeit · Veröffentlicht am 22. Januar 2026

Vor einem halben Jahr hätte ich bei der Frage „Brauchen wir eine native App?" reflexartig geantwortet: „Versuch's erst mit einer PWA." Das war meine sichere Zone – Web-Technologien, die ich kenne, beherrsche und vertrete. Dann habe ich angefangen, iOS-Apps mit Swift und SwiftUI zu entwickeln. Nicht weil PWAs plötzlich schlecht wären, sondern weil ich verstehen wollte, wo die Grenzen wirklich liegen.

Dieser Artikel ist das Ergebnis dieser Erfahrung: Ein ehrlicher technischer Vergleich aus der Perspektive eines Webentwicklers, der beide Welten kennt – ohne Dogmen, ohne Fanboy-Rhetorik, mit konkreten Entscheidungskriterien.

PWA vs. Native – Die technischen Fakten

Der Vergleich zwischen PWA und nativer iOS-App läuft oft auf zwei vereinfachte Aussagen hinaus: „PWAs sind günstiger" und „Native Apps sind besser". Beides stimmt – und beides ist falsch, wenn man nicht genauer hinsieht.

Code-Beispiel: Offline-Handling

Der Unterschied wird bei Offline-Funktionalität konkret:

// PWA: Service Worker für Offline-Cache
self.addEventListener('fetch', (event) => {
  event.respondWith(
    caches.match(event.request)
      .then(response => {
        // Cached response oder Netzwerk-Request
        return response || fetch(event.request);
      })
      .catch(() => {
        // Fallback bei fehlender Verbindung
        return caches.match('/offline.html');
      })
  );
});

// Daten-Sync bei Rückkehr online
self.addEventListener('sync', (event) => {
  if (event.tag === 'sync-data') {
    event.waitUntil(syncDataToServer());
  }
});

// iOS Native: Core Data für Offline-Persistenz
import CoreData

class DataManager {
    let container = NSPersistentContainer(name: "MyApp")
    
    init() {
        container.loadPersistentStores { description, error in
            if let error = error {
                print("Core Data failed: \(error)")
            }
        }
    }
    
    func saveEntry(_ content: String) {
        let context = container.viewContext
        let entry = Entry(context: context)
        entry.content = content
        entry.timestamp = Date()
        
        try? context.save() // Sofort lokal gespeichert
        syncToServerWhenOnline(entry) // Background-Sync
    }
}

Bei der PWA musst du manuell Caching-Strategien definieren und Sync-Mechanismen bauen. Bei iOS ist Offline-Persistenz Teil der Platform – du nutzt einfach Core Data und das System handled Sync, Merge-Konflikte und Background-Updates.

Wann PWA ausreicht – 5 klare Szenarien

Progressive Web Apps sind keine „Notlösung für kleines Budget". Sie sind die richtige Wahl für bestimmte Projekttypen – und oft sogar die bessere.

Wann Native iOS sinnvoll ist – Die harten Kriterien

Es gibt Projekte, bei denen PWA technisch an ihre Grenzen stößt. Nicht weil PWA „schlecht" wäre, sondern weil bestimmte Features nur in nativen Apps möglich sind.

Use Cases wo Native iOS gewinnt

Die Kostenfalle – Realistische Zahlen

Die Frage „Was kostet eine App?" ist ähnlich wie „Was kostet ein Auto?" – es kommt drauf an. Aber hier sind realistische Spannen basierend auf meinen eigenen Projekten und Erfahrungen:

Hybrid-Ansätze – Der Mittelweg?

Es gibt einen dritten Weg: Hybrid-Frameworks die Web-Code in Native-Apps wrappen.

Meine Erfahrung: Capacitor ist der pragmatischste Weg für Webentwickler. Du baust eine PWA (die standalone funktioniert) und kannst sie bei Bedarf in Native-Wrapper packen. React Native und Flutter sind eher „eigene Plattformen" – du baust nicht wirklich Web, sondern in einem Cross-Platform-Framework.

Entscheidungshilfe – Die 5-Fragen-Methode

Der pragmatische Weg – Stufenplan

Die meisten Projekte müssen nicht mit „Native oder Web?" starten. Es gibt einen smarten Mittelweg:

Phase 1: MVP als PWA (4–8 Wochen)

• Baue die Kern-Features als Progressive Web App
• Teste mit echten Usern: Wird die App genutzt? Welche Features fehlen?
• Sammle Daten: Welche Browser/Geräte? Welche Features werden gebraucht?
• Validiere den Markt: Lohnt sich der Invest in Native überhaupt?

Phase 2: Hybrid-Wrapper (2–4 Wochen)

Wenn die PWA funktioniert, aber App Store Präsenz wichtig wird:

• Wrappe die PWA mit Capacitor oder Ionic
• Nutze Capacitor-Plugins für erweiterten Hardware-Zugriff
• Liste die App im App Store (mit Web-Code im Kern)
• Beide Versionen parallel: Web + Wrapped Native

# Capacitor Setup (aus bestehender PWA)
npm install @capacitor/core @capacitor/cli
npx cap init "MyApp" "com.example.app"
npx cap add ios

# Build PWA + Sync zu iOS
npm run build
npx cap sync ios
npx cap open ios  # Öffnet Xcode

Jetzt hast du eine App im App Store – aber dein Code ist weiterhin HTML/CSS/JavaScript. Updates deployst du weiterhin als Web, nur Breaking Changes gehen durch den App Store Review.

Phase 3: Native Rewrite (nur wenn validiert)

Erst wenn die App erfolgreich ist UND native Features fehlen, überleg Native:

• ROI ist klar: Du weißt, dass die App genutzt wird und Geld einbringt
• Features sind limitiert: HealthKit, ARKit, Background Tasks fehlen und sind gefragt
• Performance ist kritisch: Komplexe Animationen, große Datenmengen
• Budget ist da: 30.000–60.000 € für Native Rewrite + 2-3 Jahre Maintenance

Dein Stack – Was du als Webentwickler mitbringst

Der Wechsel von Web zu iOS ist keine Raketenwissenschaft. Vieles ist übertragbar:

Transferable Skills

Was neu ist

• Xcode statt VS Code: Andere IDE, aber Konzepte (Debugger, Breakpoints, File-Navigation) sind gleich. Gewöhnungssache.
• Compiled Language: Swift wird kompiliert, nicht interpretiert. Build-Zeiten sind länger, aber Fehler werden früher gefangen.
• iOS Design Guidelines: Human Interface Guidelines sind strikter als Web. Navigation-Patterns, Tab Bars, Swipe-Gestures haben Standards.
• App Store Review: Dein Code wird geprüft. Privacy-Policies, Permissions, Content-Richtlinien müssen eingehalten werden.

// SwiftUI fühlt sich vertraut an für React-Entwickler
import SwiftUI

struct ContentView: View {
    @State private var count = 0  // wie useState()
    
    var body: some View {
        VStack {  // wie div mit flexbox
            Text("Count: \(count)")
                .font(.title)
            
            Button("Increment") {  // onClick equivalent
                count += 1
            }
            .padding()
            .background(Color.blue)
            .foregroundColor(.white)
            .cornerRadius(10)
        }
    }
}

Als Webentwickler hast du den Vorteil: Du verstehst bereits UI-Patterns, State Management, API-Integration. Swift ist nur eine neue Syntax für vertraute Konzepte.

Mein Learning aus 6 Monaten iOS-Entwicklung

Hier ein paar ehrliche Erkenntnisse aus meinem Umstieg von Web zu iOS:

Wo Web-Know-how hilft

• API-Design: RESTful APIs zu bauen ist gleich, egal ob Frontend Web oder iOS ist.
• State Management: Redux-Prinzipien funktionieren 1:1 in iOS (z.B. mit Combine oder SwiftUI @StateObject).
• Testing-Strategien: Unit Tests, Integration Tests, E2E Tests – Konzepte übertragen sich komplett.
• CI/CD: GitHub Actions für iOS ist fast identisch zu Web: Build → Test → Deploy (nur Target ist App Store statt Server).

Wo du umdenken musst

• Navigation: Web hat URLs und Routing. iOS hat Navigation Stacks und Tab Bars. Grundlegend anderes Mental Model.
• Lifecycle: Web-Apps laufen im Browser, iOS-Apps haben AppDelegate und Scene Lifecycle. Background/Foreground sind echte States.
• Permissions: Web fragt „Darf ich Standort nutzen?", iOS sagt „Warum brauchst du Standort? (Pflichtfeld)". Privacy First ist Standard.
• Updates: Web = Deploy = Live. iOS = Deploy → Review → Warten → User muss updaten. Planung ist anders.

Fazit: Es geht nicht um besser oder schlechter

Progressive Web Apps und native iOS-Apps sind Tools für unterschiedliche Jobs. Die Frage ist nicht „Was ist besser?", sondern „Was passt zu meinem Projekt?"

„Eine PWA ist nicht ‚iOS Light' und eine native App ist nicht ‚PWA Pro'. Es sind fundamentally different approaches mit eigenen Stärken und Trade-Offs."

Mehr zur iOS-Entwicklung findest du in meinem Artikel Xcode & SwiftUI – iOS App-Entwicklung. Für Web-Performance lies Core Web Vitals verbessern.