🧤 Aufruf von Web-Inhalten

Unsere Apps können Websites innerhalb einer sogenannten WebView laden – das ist im Grunde eine Browser-Engine innerhalb der nativen App. Beim Aufruf einer URL kann sich die App gegenüber dem Webserver als Client identifizieren, sodass der Server die ausgelieferte Website anpassen oder Tracking-Tools App-Traffic eindeutig erkennen können.

Im Folgenden werden die wichtigsten Optionen beschrieben, wie solche App-zu-Web-Interaktionen umgesetzt und optimiert werden können.

Option 1: User Agent

Zur Identifizierung von Geräten und Clients gibt es einen etablierten Industriestandard: den User-Agent-String. Er ist ein Feld im HTTP-Header und zeigt an, welche App oder welches Gerät die Anfrage stellt.

Normalerweise wird dieser Wert vom Browser gesetzt. Wenn jedoch unsere native App die Anfrage stellt, können wir zusätzliche, individuelle Informationen im User-Agent mitgeben, damit Ihr Webservice die App eindeutig erkennen und darauf reagieren kann.

Beispiel:

💡 USER_AGENT;role=director

Auf diese Weise kann Ihr Webservice den Zugriff auf bestimmte Inhalte steuern oder Inhalte personalisieren – ähnlich wie bei regulären Web-Logins. Wir können beliebige Informationen zu dem Nutzenden, seinen Produkten und Rechten weiterreichen.

Option 2: Custom URL

Wenn Sie lieber eine URL-basierte Lösung bevorzugen, können Sie auch ein dediziertes URL-Schema für die Nutzung in der App definieren.

Beispiel:

ihredomain.de/app/123

anstatt

ihredomain.de/123

Sobald ein solches Schema vereinbart ist, kann die App automatisch den Zusatz /app (oder ein anderes Merkmal) an Ihre URLs anhängen, die innerhalb der WebView geöffnet werden.

Wenn Nutzer:innen die URL teilen, entfernt die App diesen Zusatz automatisch, sodass der geteilte Link sauber und öffentlich bleibt.

Diese Methode ist einfach, sicher und lässt sich besonders leicht in gängigen CMS-Systemen (z. B. WordPress) umsetzen.

Option 3: User-Daten

Wenn Ihre App einen Login beinhaltet, besteht die Möglichkeit, bei eingeloggten Nutzer:innen spezifische Benutzerdaten an die Website zu übergeben. Dadurch kann der Webserver Inhalte dynamisch anpassen – etwa, um bestimmte Funktionen oder Premium-Inhalte freizuschalten.

Wir können alle Benutzerdaten übermitteln, die in unserem User-Management-System oder per SSO verfügbar sind (z. B. eindeutige IDs, E-Mail-Adressen oder Rollen).

Beispiel mit UTM-Parametern:

https://domain.com/articles/hello-world?utm_source=4.0.0&utm_medium=app&utm_campaign=reader

Alternativ kann die App anstelle eines Headers auch ein Cookie setzen – ähnlich wie im Browser. Das Cookie kann beliebige Werte (z. B. eine User-ID) speichern und auf bestimmte URLs oder Domains beschränkt werden.

Option 4: Session Cookie via API

In fortgeschrittenen Setups besteht die Möglichkeit, ein Session-Cookie oder Browser-Token über eine eigene API von Ihrem Backend an die App zu übertragen und direkt in der WebView zu verwenden.

In diesem Fall identifiziert sich die App nicht nur selbst, sondern übernimmt die aktive Browsersitzung des Nutzers. Dadurch erkennt die Website den Nutzer sofort als eingeloggt – ohne dass ein zusätzlicher Login-Schritt erforderlich ist.

Funktionsweise:

1. Ihr Backend stellt eine API bereit, die sowohl Benutzerdaten als auch einen Browser-Session-Token (z. B. JWT oder Cookie-Äquivalent) zurückgibt.

2. Die tchop-App empfängt diesen Token über die API.

3. Der Token wird in die WebView injiziert, sodass der Webinhalt geladen wird, als wäre der Nutzer bereits im Browser authentifiziert.

Voraussetzungen und Hinweise:

• Es ist ein individuelles API-Endpoint erforderlich, das sowohl die Benutzerdaten als auch den gültigen Browser-Token liefert.

• Eine sichere Handhabung des Tokens ist essenziell – er sollte verschlüsselt, kurzlebig und domaingebunden sein.

• Diese Option ist ideal für Enterprise-Umgebungen, die eine vollständig integrierte Web- und App-Login-Erfahrung ermöglichen möchten.

  
  

Einrichtung

Die Einrichtung ist unkompliziert und erfolgt in wenigen Schritten:

1. Anforderungen definieren

• Informationen im User-Agent (beliebiger Textstring)

• User-Daten (z. B. eindeutige ID oder E-Mail)

• Cookie, falls dieses statt eines Headers verwendet werden soll

• Optional: Browser-Token über eine API

2. Implementierung

• Wir konfigurieren die App, um die entsprechenden Felder oder Tokens in die Requests einzubetten (per Update oder Einstellung auf unserer Plattform).

• Sie implementieren die Logik auf Ihrer Website – je nach gewünschtem Anwendungsfall und technischer Machbarkeit.

3. Test & Rollout

• Wir liefern eine aktualisierte App-Version zum Testen.

• Sie prüfen, ob Ihre Website korrekt auf App-Anfragen reagiert.

Was Sie damit erreichen können

Diese Logik eröffnet vielfältige Einsatzmöglichkeiten:

• Bereitstellung von Inhalten ohne Paywall für App-Nutzer:innen

• Ausblenden der Kopfzeile oder anderer UI-Elemente auf mobilen Websites

• Unterdrückung von Cookie-Bannern, Newsletter-Overlays oder Werbung

• Anpassung von Anzeigen oder Modulen speziell für App-Traffic

• Nahtlose Login-Erlebnisse zwischen App und Website

Was konkret machbar ist und wie aufwendig die Umsetzung wird, hängt natürlich von Ihrer Webarchitektur, Ihrem Server und Ihrem User-Management-System ab.