«Wir brauchen eine App» ist keine Anforderung. Es ist eine Antwort auf eine Frage, die vorher niemand gestellt hat.

In den meisten Fällen, die bei uns landen, steht hinter dem Satz ein echtes Ziel: Kunden sollen wiederkommen, ein Ablauf soll aufs Handy, Mitarbeitende sollen unterwegs arbeiten können. Alle drei Ziele lassen sich mit einer App erreichen. Zwei davon meistens auch ohne — schneller und für einen Bruchteil des Aufwands.

Dieser Beitrag zeigt, zwischen was du tatsächlich wählst, welcher Test die Entscheidung trägt, und an welcher Stelle Schweizer Unternehmen etwas anderes rechnen müssen als deutsche.

Die drei Dinge, zwischen denen du wirklich wählst

Der Begriff «App» deckt drei verschiedene Bauweisen ab. Sie sehen auf dem Handy fast gleich aus und unterscheiden sich in Kosten, Zeit und Möglichkeiten erheblich.

Native App. Für iOS und Android getrennt gebaut, aus dem App Store oder Play Store installiert. Vollzugriff auf die Hardware — Kamera, Bluetooth, NFC, Standort im Hintergrund, Biometrie. Der grösste Aufwand, das grösste Können.

Web-App. Läuft im Browser, kein Store, kein Download. Eine Codebasis für alle Geräte, jede Änderung sofort bei allen Nutzern. Zugriff auf die Hardware nur so weit, wie der Browser ihn erlaubt.

PWA (Progressive Web App). Eine Web-App, die sich zum Startbildschirm hinzufügen lässt und sich danach wie eine installierte App verhält: eigenes Symbol, kein Browserrahmen, eingeschränkter Offline-Betrieb, auf beiden Plattformen auch Push-Nachrichten. Technisch bleibt sie eine Website.

Warum die Reihenfolge dieser Liste kein Zufall ist

Die Grenze verläuft nicht zwischen «richtig» und «Behelf». Sie verläuft dort, wo dein Anwendungsfall Hardware braucht, die der Browser nicht hergibt.

Von unten nach oben gelesen ist die Liste ein Ausbaupfad: Jede Stufe baut auf der vorigen auf, und keine davon wird beim Weitergehen weggeworfen. Von oben nach unten gelesen ist sie eine Absteigeleiter — und die geht nur mit einem Neubau.

Der Test, der die Entscheidung in zwei Minuten trifft

Drei Fragen. Wer alle drei mit Nein beantwortet, braucht keine native App — und spart sich zwei Codebasen, zwei Store-Konten und zwei Freigabeprozesse.

1. Braucht der Kernnutzen Hardware, die der Browser nicht erreicht? Bluetooth-Kopplung mit einem Messgerät, NFC zum Auslesen von Karten, Standortverfolgung im Hintergrund, Gesichts- oder Fingerabdruckerkennung als Anmeldung. Wenn ja: native App.

2. Muss die Anwendung ohne Netz vollständig funktionieren? Nicht «es wäre schön». Vollständig — auf einer Baustelle ohne Empfang, im Untergeschoss, im Tunnel. Eine PWA kann Daten zwischenspeichern und nachreichen. Eine vollständige Offline-Anwendung mit grossem lokalem Datenbestand ist nativ verlässlicher.

3. Öffnen deine Nutzer das Ding mehrmals pro Woche? Das ist die Frage, an der die meisten App-Ideen sterben, und sie hat nichts mit Technik zu tun.

Ein Symbol auf dem Startbildschirm ist nur dann ein Vorteil, wenn jemand es regelmässig antippt. Bei einer Anwendung, die dreimal im Jahr gebraucht wird, ist der Store-Umweg eine Hürde, kein Kanal. Für seltene Kontakte leistet eine gut gebaute Website mehr — dazu passt der Beitrag zur conversionstarken Website.

Dreimal Nein heisst: Web-App oder PWA. Und in dem Fall ist die schnellere Lösung nicht der Kompromiss, sondern die richtige Wahl.

Was eine native App kostet, das niemand einrechnet

Der Entwicklungspreis ist der Teil, über den alle sprechen. Die Positionen darunter sind die, die Projekte im zweiten Jahr aus dem Budget kippen.

  • Zwei Codebasen. iOS und Android sind zwei Produkte. Jede Funktion wird zweimal gebaut, zweimal getestet, zweimal behoben.
  • Store-Gebühren. Das Apple Developer Program kostet USD 99 pro Jahr, der Zugang zur Google Play Console einmalig USD 25. Beide Beträge stehen seit Jahren unverändert — prüfe sie trotzdem vor der Budgetfreigabe, denn Plattformpreise sind keine Naturkonstanten.
  • Provision auf digitale Verkäufe. Verkaufst du digitale Inhalte oder Abos in der App, behalten die Stores einen Anteil ein: 30 Prozent im Standardfall, 15 Prozent für kleinere Anbieter über die Small-Business-Programme beider Plattformen. Für physische Waren und Dienstleistungen fällt sie nicht an — ein Unterschied, der ganze Geschäftsmodelle entscheidet.
  • Freigabe bei jedem Update. Eine Korrektur an einer Web-App ist nach dem Deployment live. Eine Korrektur an einer nativen App durchläuft die Store-Prüfung. Apple gibt an, die Mehrheit der Einreichungen innerhalb von 24 Stunden zu prüfen — das ist schnell, aber es ist nicht sofort, und bei einer Ablehnung beginnt die Runde von vorn.
  • Erzwungene Wartung. Neue iOS- und Android-Versionen erscheinen jährlich. Eine App, die zwei Jahre nicht angefasst wird, verschwindet aus dem Store, bevor sie abstürzt.

Die Position, die am häufigsten fehlt

Von diesen fünf Punkten taucht die erzwungene Wartung in den wenigsten Offerten auf, weil sie erst nach der Abnahme anfällt. Sie ist trotzdem die verlässlichste: Plattformwechsel kommen jährlich, ob dein Budget dafür vorgesehen ist oder nicht. Wer eine native App bestellt, bestellt eine Betriebsaufgabe mit, kein fertiges Werkstück.

Wie sich diese Logik auf Individualsoftware allgemein überträgt, steht im Entscheidungsleitfaden zu individueller Software gegenüber Standardlösungen. Die Kostenfrage bei Weblösungen behandelt der Beitrag dazu, was eine professionelle Website in der Schweiz kostet.

Der Punkt, an dem Apple deine App ablehnt

Der häufigste Grund für eine abgelehnte App eines KMU ist kein Fehler im Code. Es ist die Idee selbst.

Apples App Review Guidelines führen unter Punkt 4.2 die «Minimum Functionality». Der Wortlaut ist eindeutig: Eine App soll Funktionen, Inhalte und eine Oberfläche mitbringen, die sie über eine neu verpackte Website hinausheben.

Wer also seine Website in eine App-Hülle packt, weil «wir sollten im Store sein», bekommt die Ablehnung nicht trotz, sondern wegen dieser Absicht. Und selbst wenn eine solche App durchgeht: Sie liefert dem Nutzer nichts, was der Browser nicht auch geliefert hätte — nur mit einer Installation davor.

Die Frage vor jedem Store-Projekt lautet deshalb: Was kann diese App, das unsere Website nicht kann? Fällt die Antwort nicht in einem Satz, ist die Antwort meistens «nichts».

Der Sonderfall: die App als internes Werkzeug

Anders liegt der Fall bei Anwendungen, die nur eigene Mitarbeitende nutzen. Dafür gibt es Verteilwege ausserhalb des öffentlichen Stores, und die Richtlinie 4.2 zielt nicht auf sie. Wer eine reine Innenanwendung baut, sollte sie deshalb gar nicht erst als Store-Projekt planen — das erspart Prüfverfahren, die für diesen Zweck nie gedacht waren.

Was die Schweiz hier anders rechnet als die EU

An dieser Stelle wird es für Schweizer Unternehmen konkret, und die meisten Ratgeber übersehen es.

Der Digital Markets Act der EU (Verordnung (EU) 2022/1925) hat Apple gezwungen, alternative App-Marktplätze und Sideloading zuzulassen. Diese Öffnung gilt für die EU und den EWR. Die Schweiz gehört zu keinem von beiden. Wer also darauf baut, seine App künftig am Store vorbei zu verteilen, plant mit einer Regelung, die im Inland nicht greift.

Praktisch heisst das: Für den Schweizer Markt bleibt der offizielle Store der Weg zu iOS-Nutzern, mit allem, was daran hängt — Freigabeverfahren, Richtlinien, Provisionen. Eine Web-App unterliegt keiner dieser Bedingungen, weil sie niemandes Marktplatz braucht.

Was daraus für die Planung folgt

Für dich heisst das nicht «keine App». Es heisst: Rechne die Store-Abhängigkeit als dauerhafte Bedingung ein, nicht als Übergangszustand, der sich mit der nächsten EU-Regulierung von selbst erledigt. Was in Brüssel entschieden wird, ändert an deinem Vertriebsweg in Zürich nichts.

Dazu kommt der Datenschutz. Das revidierte Datenschutzgesetz (DSG, SR 235.1) ist seit dem 1. September 2023 in Kraft und gilt unabhängig davon, ob deine Anwendung im Browser oder im Store läuft.

Eine App verschiebt die Pflichten nicht, sie vervielfacht nur die Orte, an denen du sie erfüllen musst: Store-Datenschutzangaben, Berechtigungsdialoge, lokal gespeicherte Daten auf dem Gerät. Welche Lücken dabei in KMU typischerweise offen bleiben, behandelt der Beitrag zu Cyber-Security in Schweizer KMU.

PWA: was sie heute kann — und was immer noch nicht

Hier lohnt sich Genauigkeit, weil die Aussagen dazu je nach Quelle auseinandergehen.

Was sich messbar geändert hat: Mit iOS 16.4 (März 2023) unterstützt Apple Web-Push-Nachrichten für Web-Apps, die zum Startbildschirm hinzugefügt wurden. Damit ist der am häufigsten genannte Grund gegen PWAs auf iPhones weggefallen. Wer heute noch «PWAs können auf iOS keine Push-Nachrichten» liest, liest einen Stand von vor 2023.

Was weiterhin gilt: Push funktioniert erst nach dem Hinzufügen zum Startbildschirm — ein Schritt, den viele Nutzer nicht von selbst gehen und den du aktiv erklären musst.

Dazu kommt: Der Speicherplatz für Web-Anwendungen ist auf iOS knapper bemessen als auf Android, Hintergrundprozesse sind eingeschränkt. Und tief in der Hardware — NFC, Bluetooth, biometrische Anmeldung im vollen Umfang — bleibt die native App vorn.

Der Streit, den man nicht glätten sollte

Das Web-Lager argumentiert, die Plattform hole auf und der Unterschied sei für die meisten Anwendungen längst unerheblich. Das Native-Lager hält dagegen, dass Bedienqualität und Systemintegration sich nicht nachbauen lassen.

Beide haben für ihren Bereich recht, und für ein Schweizer KMU löst sich der Streit anders auf als für einen Plattformbetreiber: Die Einschränkungen einer PWA auf iOS sind keine technische Notwendigkeit, sondern eine Plattformentscheidung. Sie können sich ändern — sie haben es 2023 getan. Deine Investition in zwei native Codebasen kann sich nicht ändern.

Was für den konkreten KMU-Fall belegt wäre, wäre eine Messung an deinen eigenen Nutzern. Die liegt vor dem Bau nie vor. Genau deshalb ist die günstigere Variante zuerst nicht Geiz, sondern Risikosteuerung.

Cross-Platform: der Kompromiss und sein Preis

Zwischen nativ und Web sitzt eine dritte Bauweise: ein gemeinsamer Code, der auf beiden Plattformen als echte App läuft. Frameworks wie React Native oder Flutter bedienen diesen Weg.

Was du gewinnst: eine Codebasis statt zwei, echter Store-Auftritt, weitgehender Hardware-Zugriff.

Was du bezahlst: eine Abhängigkeit von einem Framework, dessen Entwicklung du nicht steuerst. Bei jedem grossen iOS- oder Android-Update wartest du darauf, dass das Framework nachzieht. Und für alles, was das Framework nicht abdeckt, schreibst du doch wieder plattformspezifischen Code — die zweite Codebasis kommt durch die Hintertür zurück.

Wann der Kompromiss trägt

Er trägt dann, wenn du Hardware brauchst, aber keine Funktion, die eine Plattform am Tag ihres Erscheinens exklusiv anbietet. Das trifft auf die meisten KMU-Anwendungen zu: Ein Rapportsystem braucht die Kamera, nicht die neueste Systemschnittstelle aus der letzten Keynote.

Für viele KMU-Fälle mit echtem Hardware-Bedarf ist das trotzdem der vernünftigste Weg. Wie wir ihn im Projekt aufsetzen, steht bei ALPENIQ Labs und speziell bei der Entwicklung mobiler Apps.

Die Reihenfolge, die Geld spart

Fast jedes App-Projekt lässt sich in eine Abfolge bringen, die auf jeder Stufe eine Ausstiegsmöglichkeit hat.

  1. Web-App zuerst. Eine Codebasis, keine Store-Freigabe, sofortige Änderungen. Du erfährst innerhalb von Wochen, ob die Anwendung überhaupt genutzt wird. Siehe Web-Apps.
  2. Zur PWA erweitern, wenn die Nutzung da ist. Startbildschirm-Symbol, Offline-Zwischenspeicher, Push. Kleiner Aufwand auf einer Basis, die schon steht.
  3. Nativ nachziehen, wenn eine der drei Testfragen oben ein Ja ergibt — und du dann Nutzungsdaten hast statt Vermutungen.

Diese Reihenfolge ist auch der Grund, warum wir Projekte gern als MVP aufsetzen: nicht um weniger zu liefern, sondern um die teure Entscheidung mit Daten zu treffen statt im Voraus.

Der Punkt, an dem die Reihenfolge nicht gilt

Wenn die Hardware der Kernnutzen ist — eine App, die ohne Bluetooth-Kopplung schlicht keinen Zweck hat — dann ist die Web-Stufe kein Zwischenschritt, sondern ein Umweg. Baue dann gleich nativ. Der Test oben ist genau dafür da: Er trennt die Fälle, in denen die Reihenfolge Geld spart, von denen, in denen sie welches kostet.

Was die Entscheidung sonst noch beeinflusst

Zwei Punkte, die in der Architekturdiskussion regelmässig untergehen und später den Aufwand bestimmen.

Die Anbindung an deine bestehenden Systeme. Eine App, die ihre Daten nicht aus ERP, CRM oder Warenwirtschaft zieht, erzeugt ein weiteres Datensilo statt eines zu schliessen.

Dieser Teil ist unabhängig von der Bauweise und meistens der grössere Aufwand. Wie er sich lösen lässt, steht im Beitrag zu ERP- und CRM-Integration und bei Integrationen.

Wo ohnehin Abläufe statt Oberflächen das Ziel sind, lohnt vorher ein Blick auf KI-Agenten für Unternehmen — manche «App-Idee» ist in Wahrheit ein Automatisierungsfall.

Wer sie findet. Eine native App ist in der Google-Suche nicht auffindbar, eine Web-App schon. Wenn Sichtbarkeit Teil des Ziels ist, entscheidet die Bauweise mit — und die Ladezeit entscheidet mit darüber, ob jemand bleibt. Dazu passt der Beitrag zur Optimierung der Ladezeit.

In einer Woche zu einer belastbaren Entscheidung

Ein Vorgehen, das ohne Entwicklungsbudget auskommt:

  • Tag 1–2: Den Nutzen aufschreiben. Ein Satz, der beschreibt, was ein Nutzer damit tut. Nicht «digitalisieren», sondern «einen Rapport auf der Baustelle erfassen und beim Verlassen des Funklochs übermitteln».
  • Tag 3: Die drei Testfragen beantworten. Ehrlich, mit jemandem, der die Anwendung später nutzt — nicht im Führungskreis allein.
  • Tag 4: Die Häufigkeit schätzen. Wie oft im Monat öffnet eine Person das? Unter viermal ist der Store-Weg schwer zu begründen.
  • Tag 5: Die Datenquellen auflisten. Woher kommt jedes Feld? Diese Liste sagt mehr über den Aufwand als jede Architekturfrage.

Am Ende steht eine Entscheidung, die auf dem Anwendungsfall beruht statt auf dem Wunsch, ein Symbol im Store zu haben. Das ist der ganze Unterschied — und er kostet nichts ausser einer Woche Nachdenken.