Cursor + Navigation
Ein Hamburger-Menü und ein Website-Header sind der schnellste Weg, eine Cursor-App wie ein Lesezeichen wirken zu lassen, und genau das bewerten Reviewer unter Guideline 4.2. WebViewGold ergänzt auf iOS eine native Tab-Leiste oder Sidebar und auf Android eine Material-Bottom-Navigation oder einen Drawer, jeweils in einer einzigen Datei konfiguriert, während deine Web-App weiter das Routing übernimmt.
Ab $109 einmalig pro Plattform, oder unser Team erledigt alles ab $698.
Alle vier laden beim Antippen eine URL deiner Web-App in der Haupt-WebView, an deinem Routing ändert sich also nichts. Wähle pro Plattform ein primäres Muster.
Setz showNavFooter in Config.swift auf true und beschreibe drei bis fünf Tabs in FooterBar.json: ein Label (name), ein SF Symbol (sf_symbol) und die URL, die der Tab öffnet (redirection_link), dazu colour mit dark oder light für die ganze Leiste.
Setz enableSidebar auf true und füll Sidebar.json mit denselben Feldern. Ein schwebender Button öffnet ein natives Slide-Menü, praktisch, wenn du mehr Bereiche hast, als in eine Tab-Leiste passen. Die Sidebar funktioniert allein oder zusammen mit dem Footer (Sidebar-Doku).
ENABLE_NAVIGATION_FOOTER in Config.java ergänzt eine Bottom-Navigation in Material 3. Einträge, Icons und Labels kommen aus res/menu/menu_drawer.xml; Google empfiehlt drei bis fünf Ziele auf oberster Ebene. Hell- und Dunkelmodus folgen automatisch dem System.
ENABLE_NAVIGATION_DRAWER ergänzt einen schwebenden Menü-Button, der einen Material-Drawer öffnet, gesteuert von derselben Menüdatei. Bottom-Navigation und Drawer lassen sich kombinieren, zum Beispiel die Hauptbereiche unten und Einstellungen, Hilfe und rechtliche Seiten im Drawer.
Füge das in Cursor ein, um die Web-App-Seite umzusetzen. Prüfe das Ergebnis, veröffentliche und teste dann in der WebViewGold-App.
Diese Web-App läuft im nativen Wrapper von WebViewGold, der eine native Tab-Leiste bereitstellt. Ihr User Agent enthält "WebViewGold". 1. Lies die Router-Konfiguration und wähle die vier oder fünf Routen der obersten Ebene. Schreib docs/native/FooterBar.json (colour plus ein layout-Eintrag pro Tab mit name, sf_symbol und redirection_link auf https://app.yourdomain.com) und liste dieselben Einträge als Android-Menüeinträge für res/menu/menu_drawer.xml auf. 2. Erstelle lib/native.ts mit isNativeApp() und lass den Website-Header, das Hamburger-Menü und die Linkspalten im Footer weg, wenn es true ist. 3. Ergänze im Header jeder Detailroute einen BackButton mit Fallback auf die übergeordnete Route. 4. Füge einen Playwright-Test hinzu, der einen User Agent mit "WebViewGold" nutzt, jede Tab-URL direkt öffnet, Status 200 erwartet und prüft, dass der Website-Header nicht gerendert wird. 5. Ergänze in .cursor/rules: In der App ist die native Tab-Leiste die einzige Navigation; füge nie eine Web-Bottom-Navigation hinzu. Nenn mir jede Datei, die du geändert hast.
WebViewGold hat uns die kürzeste und effizienteste Time-to-Market ermöglicht, die jemals möglich war, verglichen mit allen anderen App-Plattformen, die wir in den letzten 5 Jahren ausprobiert haben. Ich weiß nicht, warum ich euch nicht schon früher entdeckt habe, aber ich bin wirklich, wirklich froh, dass ich es getan habe. Wir nähern uns derzeit fast 6000 App-Downloads im iOS App Store & Google Play Store ohne Probleme!
| Native Leiste (WebViewGold) | Tab-Leiste in der Web-App | Website-Header mit Hamburger-Menü | |
|---|---|---|---|
| Sieht aus wie | Das System: SF Symbols auf iOS, Material 3 auf Android | Was immer du gestaltest, passend zu deiner Marke | Eine mobile Website |
| Wo du sie änderst | FooterBar.json, Sidebar.json, menu_drawer.xml; kommt mit einem Store-Update | In deiner Web-App, live mit jedem Deploy | In deiner Web-App |
| Home-Indikator und Safe Area | Nativ gelöst | Braucht Padding mit env(safe-area-inset-bottom) | Oft vom Home-Indikator verdeckt |
| Was ein Tippen bewirkt | Lädt die Tab-URL in der WebView (ein Seitenaufruf) | Clientseitiger Routenwechsel; sofort, der Zustand bleibt erhalten | Öffnet erst ein Menü, dann die Seite |
| Am besten für | Drei bis fünf feste Hauptbereiche | Bereiche, die sich oft ändern, Badges und Zähler | Nur die Website; in der App ausblenden |
Rund 30 Minuten für beide Plattformen, plus ein neuer Build.
Typisch sind Start, eine Hauptliste oder Suche, ein Posteingang oder eine Erstellen-Aktion und das Konto. Alles andere lebt innerhalb dieser Bereiche. Jedes Ziel braucht eine eigene URL in deiner Cursor-App, die beim direkten Aufruf den richtigen Bildschirm öffnet, nicht nur über Klicks innerhalb der App.
Setz showNavFooter auf true und leg pro Tab einen Eintrag mit name, sf_symbol (zum Beispiel house, magnifyingglass, tray, person.crop.circle) und dem vollständigen redirection_link auf deiner Produktionsdomain an. Stell colour passend zu deinem Theme ein. Referenz: iOS-Dokumentation.
Setz ENABLE_NAVIGATION_FOOTER (Leiste unten) oder ENABLE_NAVIGATION_DRAWER (seitlicher Drawer) in Config.java auf true, definiere Einträge, Icons und Labels in res/menu/menu_drawer.xml und weise jedem Eintrag seine URL zu, wie in der Android-Dokumentation beschrieben.
Leg in Config.swift (useragent_iphone, useragent_ipad) und Config.java (USER_AGENT) einen eigenen User Agent mit einem Token wie „WebViewGold“ fest und lass deine Cursor-App das Header-Menü, den Hamburger-Button und die Linkspalten im Footer nicht mehr rendern, sobald sie ihn erkennt. Zwei Navigationssysteme auf einem Bildschirm sind die häufigste Design-Anmerkung.
iPhones haben keinen System-Zurück-Button. Tabs öffnen die Bereiche; Seiten, die man von dort erreicht, brauchen einen sichtbaren Zurück-Pfeil im Header. Lass enableswipenavigation eingeschaltet, damit auch die Wischgeste vom linken Bildschirmrand auf iOS zurückführt; Android-Nutzer haben zusätzlich die System-Zurück-Geste.
Tippe jeden Tab direkt nach dem Start an, nach dem Login und nachdem die Session abgelaufen ist. Ein Tab, der zur Login-Seite umleitet, sollte den Nutzer danach zu genau diesem Tab zurückbringen, nicht zum Dashboard.
Ersetze die URLs durch die Routen deiner Cursor-App auf deiner Produktionsdomain. Sidebar.json hat dieselbe Struktur. Prüfe die Icon-Namen in Apples App „SF Symbols“.
{
"colour": "light",
"layout": [
{ "redirection_link": "https://app.yourdomain.com/", "sf_symbol": "house", "name": "Start" },
{ "redirection_link": "https://app.yourdomain.com/search", "sf_symbol": "magnifyingglass", "name": "Suche" },
{ "redirection_link": "https://app.yourdomain.com/inbox", "sf_symbol": "tray", "name": "Posteingang" },
{ "redirection_link": "https://app.yourdomain.com/account", "sf_symbol": "person.crop.circle", "name": "Konto" }
]
}Kein einzelnes Feature ist Pflicht. Guideline 4.2 fragt, ob die App mehr bietet als eine neu verpackte Website, und 4.0, ob sie den Design-Konventionen von iOS folgt. Eine native Tab-Leiste ist für beides eines der deutlichsten Signale, besonders zusammen mit Push-Benachrichtigungen und einem ordentlichen Offline-Bildschirm, aber sie ersetzt keine mobilfreundliche Web-App.
Bei der nativen Leiste nicht: FooterBar.json, Sidebar.json und menu_drawer.xml stecken im Build. Die Seiten hinter den Tab-URLs aktualisieren sich mit jedem Deploy. Ändern sich deine Bereiche oft, bau die Tab-Leiste stattdessen in deiner Web-App und zeig sie nur in der App.
Ja. Jeder Tab lädt seine URL in der WebView, also muss dein Hosting jede Route mit der App beantworten (ein SPA-Fallback auf index.html) und dein Router beim direkten Aufruf den richtigen Bildschirm öffnen. Teste das, indem du eine Tab-URL in einen frischen Browser-Tab einfügst.
Nimm den Footer für drei bis fünf Hauptbereiche. Ergänze die iOS-Sidebar oder den Android-Drawer für Nebenziele wie Einstellungen, Hilfe und rechtliche Seiten. Wiederhole dieselben Links nicht in beiden.
Behalte es für die Website und lass es in der App per User-Agent-Prüfung weg. In der App übernimmt die native Leiste; ein zweites Menü-Icon im Header verwirrt Nutzer und Reviewer.
Gleiches Ergebnis, unterschiedlich viel Arbeit auf deiner Seite. Alle drei kommen mit Genehmigungsgarantie und 24/7 Support von echten Menschen.
$109 pro Plattform, einmalig
Die WebViewGold-Lizenz: ein fertiges Xcode- oder Android-Studio-Projekt. URL einfügen, Name und Icon setzen, Features einschalten, bauen und einreichen. Kostenlose Updates für immer.
Pakete auf der Hauptseite ansehen$349 pro Lizenz, einmaliges Add-on
Kein Mac, kein Xcode, kein Android Studio: Du konfigurierst im Browser, wir bauen beide Apps in der Cloud und übergeben sie an App Store Connect und die Play Console.
So funktioniert der Cloud Builder Kostenlose Demo ausprobieren$698 pro Plattform $798
Schick uns deine URL und dein Icon. Unser Team konfiguriert, baut und liefert deine App innerhalb von 72 Stunden, White-Label, inklusive Quellprojekten. Beide Plattformen für $1,158.
Full-Service-Details Powered by
Winter-Sale-Preise gültig bis 31. Dezember 2026.
App Store & Google Play Genehmigungsgarantie – oder Geld zurück innerhalb von 14 Tagen
Lieber abgeben? Full Service: Wir konfigurieren, bauen und liefern innerhalb von 72 Stunden, ab $698 pro Plattform. Fragen? Chatte mit uns – 24/7.
Erstattungen erfolgen zu den in unseren FAQ genannten Bedingungen: eine nicht inhaltsbedingte Ablehnung durch Apple und/oder Google, geltend gemacht innerhalb von 14 Tagen nach dem Kauf.