v0 + Share Extension
Ein Lesezeichen-Tool, eine Rezeptsammlung oder ein Moodboard ist nur dann wirklich nützlich, wenn Speichern mit einem Tipp erledigt ist. Mit WebViewGold erscheint deine v0-App im Share Sheet von iOS und Android, und alles, was der Nutzer teilt (ein Link, ein Text, ein Foto), kommt in deiner Web-App als JavaScript-Variable sharedData an. Dein Code entscheidet, was dann passiert: ein Formular vorausfüllen, den Inhalt in deinem Backend speichern oder einen Editor öffnen.
Ab $109 einmalig pro Plattform, oder unser Team erledigt alles ab $698.
Nutzer tippen in Safari, Fotos oder einer anderen App auf Teilen und wählen deine App aus. WebViewGold übergibt den Inhalt in der JavaScript-Variable sharedData an deine Web-App: Texte und Links als reinen Text, Bilder als Base64-Strings.
Kommentiere die vorbereiteten Intent-Filter in der AndroidManifest.xml ein (ACTION_SEND für text/plain und image/*, ACTION_SEND_MULTIPLE für mehrere Bilder), und das App-Icon erscheint im Teilen-Dialog von Android. Gleiche Variable, gleiche Verarbeitung: sharedData.
Prüfe beim Laden der Seite, ob sharedData gesetzt ist, unterscheide Links, Texte und Bilder und leite den Nutzer zu einem vorausgefüllten Speichern-Bildschirm. Gespeichert wird erst, wenn dein eigener Code den Inhalt in Next.js Route Handlers und Server Actions, Postgres über Neon oder Supabase ablegt, so behält der Nutzer die Kontrolle.
Füge das in v0 ein, um die Web-App-Seite umzusetzen. Prüfe das Ergebnis, veröffentliche und teste dann in der WebViewGold-App.
Füge diesem Next.js-App-Router-Projekt einen Share-Target-Ablauf für die native WebViewGold-App hinzu. 1) Erstelle components/share-inbox.tsx als Client Component, gemountet in app/layout.tsx; wenn navigator.userAgent mein WebViewGold-Token enthält und window.sharedData definiert ist, klassifiziere den Wert in useEffect (http-URL = Link, langes Base64 = Bild, sonst Text), überspringe ihn, wenn sessionStorage bereits denselben Wert enthält, speichere ihn als pendingShare und ruf router.push("/save") auf. 2) Erstelle app/save/page.tsx (Client) mit einer Vorschau und den Buttons Speichern / Abbrechen. 3) Erstelle app/api/link-preview/route.ts, das eine URL serverseitig mit 5 Sekunden Timeout abruft und title, description und og:image zurückgibt. 4) Verkleinere Bilder auf einem Canvas auf maximal 1600 px und lade sie mit Client-Uploads von @vercel/blob über app/api/blob/upload/route.ts hoch. 5) Erstelle app/api/saves/route.ts, das { userId, kind, url, text, blobUrl } für den angemeldeten Nutzer in eine Tabelle saves einfügt und anonyme Anfragen ablehnt. 6) Ohne Session leitest du mit callbackUrl=/save zur Anmeldung weiter und behältst pendingShare. 7) Sichere jeden Zugriff auf window ab, damit das Server-Rendering sharedData nie anfasst.
Mein iOS WebView wurde endlich genehmigt. Danke!!
Ein Teilen-Ziel lohnt sich, wenn ein Tipp etwas speichert, das der Nutzer sonst kopieren, die App wechseln und wieder einfügen müsste. Typische Aufgaben:
Einen Artikel aus Safari oder Chrome teilen, die App holt Titel und Vorschaubild auf dem Server, der Nutzer vergibt ein Tag und tippt auf Speichern.
Ein Rezeptlink, ein Restaurant aus einer Karten-App, eine Produktseite: gespeichert in einer Sammlung, einer Reiseplanung oder einer Wunschliste statt in einer chaotischen Notizdatei.
Ein Belegfoto in den Ausgaben-Tracker, ein Screenshot in den Bug-Report, ein Raumfoto ins Moodboard oder ins Inventar. Das Bild kommt als Base64 an, bereit zum Hochladen.
Eine Stellenanzeige oder einen Profil-Link in einen Tracker oder ein CRM teilen und direkt in einem vorausgefüllten Formular „Neuer Eintrag“ landen, die URL bereits ausgewertet.
Markierter Text aus jeder App wird zur Notiz, zur Lernkarte oder zum Prompt für dein KI-Feature, mit angehängtem Quell-Link, wenn der geteilte Text einen enthält.
Rund eine Stunde, das meiste davon für den Speichern-Bildschirm in deiner Web-App.
Entscheide, was ein geteilter Inhalt in deiner v0-App auslöst: einen Link speichern, ein Foto anhängen, eine Notiz beginnen. Eine klare Aktion funktioniert besser als ein Menü voller Optionen.
Folge der iOS-Dokumentation, um die Share Extension im WebViewGold-Xcode-Projekt einzuschalten, und installiere den Build dann auf einem echten iPhone. Das Share Sheet listet nur Erweiterungen installierter Apps, der Simulator eignet sich zum Testen also kaum.
Behalte in der AndroidManifest.xml nur die Filter, die du wirklich verarbeitest: text/plain für Links und Text, image/* für ein Foto, SEND_MULTIPLE für mehrere (Android-Dokumentation). Ein Teilen-Ziel, das Bilder annimmt und dann ignoriert, hinterlässt einen schlechten ersten Eindruck.
Prüfe beim Laden und nach einer kurzen Verzögerung noch einmal typeof sharedData !== "undefined". Werte, die mit http beginnen, sind Links; lange Base64-Strings sind Bilder (JPEG-Daten beginnen mit /9j/, PNG mit iVBORw0KGgo); alles andere ist Text, eventuell mit einer URL darin.
Ist der Nutzer abgemeldet, leg das geteilte Element in sessionStorage ab, schick ihn durch deinen Login und stell den Speichern-Bildschirm danach wieder her. Lass einen geteilten Inhalt nie stillschweigend verschwinden.
Wandle Bilder in einen Blob um, verkleinere sie und lade sie hoch, hol Link-Titel auf dem Server, speichere den Datensatz in Next.js Route Handlers und Server Actions, Postgres über Neon oder Supabase und zeig dann einen klaren Erfolgszustand (ein Aufruf von successhaptic:// passt hier gut).
Framework-unabhängig; ruf checkSharedContent() auf, sobald deine App gemountet ist. Ersetze YourAppToken durch den eigenen User Agent, den du in Config.swift (useragent_iphone, useragent_ipad) und Config.java (USER_AGENT) festgelegt hast.
var inApp = navigator.userAgent.indexOf("YourAppToken") !== -1;
function classifyShared(raw) {
var value = String(raw).trim();
var b64 = value.replace(/^data:image\/[a-z+]+;base64,/i, "");
if (/^https?:\/\//i.test(value)) return { kind: "link", url: value };
if (b64.length > 1000 && /^[A-Za-z0-9+\/=\s]+$/.test(b64.slice(0, 4000))) {
return { kind: "image", base64: b64, mime: b64.indexOf("iVBORw0KGgo") === 0 ? "image/png" : "image/jpeg" };
}
var link = value.match(/https?:\/\/\S+/);
return { kind: "text", text: value, url: link ? link[0] : null };
}
function base64ToBlob(b64, mime) {
var bin = atob(b64.replace(/\s/g, ""));
var bytes = new Uint8Array(bin.length);
for (var i = 0; i < bin.length; i++) bytes[i] = bin.charCodeAt(i);
return new Blob([bytes], { type: mime });
}
function checkSharedContent() {
if (!inApp || typeof sharedData === "undefined" || !sharedData) return false;
var fingerprint = String(sharedData).length + ":" + String(sharedData).slice(0, 64);
if (sessionStorage.getItem("lastShare") === fingerprint) return false; // schon verarbeitet
sessionStorage.setItem("lastShare", fingerprint);
sessionStorage.setItem("pendingShare", JSON.stringify(classifyShared(sharedData)));
window.location.href = "/save"; // dein vorausgefüllter Speichern-Bildschirm
return true;
}
window.addEventListener("load", function () {
if (!checkSharedContent()) setTimeout(checkSharedContent, 1000);
});Ein Teilen-Ziel gehört zu den nativen Integrationen, die ein Safari-Tab auf iOS nicht bieten kann, und ist damit ein starkes Argument für Guideline 4.2. Ein paar Regeln gehören dazu.
Zeig den Teilen-Ablauf in einem Screenshot und erwähne ihn auf Englisch in den Review-Notizen („Share a link from Safari to save it“). Reviewer rechnen nur Features an, die sie auch finden.
Erweiterungen sollten echte Funktionen enthalten, in deinem Marketingtext zutreffend beschrieben sein und weder Marketing noch Werbung oder In-App-Käufe enthalten. Halte den Teilen-Ablauf bei einer sauberen Speichern-Aktion.
Erweiterungen sollten zu Inhalt und Funktion der App passen. Eine Rezept-App, die Rezeptlinks annimmt, passt; ein Teilen-Ziel, das nur die Startseite öffnet, nicht.
Geteilte Fotos und Links können personenbezogene Daten enthalten. Lade nur hoch, was der Nutzer bestätigt hat, beschreib es in deiner Datenschutzerklärung und gib es in App Privacy (Fotos, Nutzerinhalte) und im Data-safety-Formular von Google Play an.
Ja. iOS nutzt eine Share Extension, Android Share Intents; in beiden Fällen übergibt WebViewGold den Inhalt in derselben JavaScript-Variable an deine Web-App, sharedData, ein einziger Handler deckt also beide Plattformen ab.
Texte und Links sowie Bilder, die als Base64-Strings ankommen. Android hat außerdem einen vorbereiteten Intent-Filter für mehrere Bilder auf einmal. Andere Dateitypen wie PDFs gehören nicht zur dokumentierten API.
Auf Android kann sich eine installierte PWA in Chromium-basierten Browsern über die Web Share Target API als Teilen-Ziel registrieren. Auf iOS bietet Safari nichts Vergleichbares für Web-Apps, deshalb führt der Weg ins Share Sheet des iPhones über eine native Share Extension.
Halte das geteilte Element in sessionStorage fest, schick den Nutzer durch den Login und bring ihn danach mit dem Inhalt zurück zum Speichern-Bildschirm. Ein geteilter Inhalt, der nach dem Login verloren geht, ist der häufigste Bug in diesem Ablauf.
Kein einzelnes Feature tut das. Sie ist eine starke, sichtbare native Funktion; zusammen mit Push-Benachrichtigungen, Offline-Verhalten und einem app-typischen Layout zeigt sie, dass deine v0-App mehr ist als eine Website.
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.