Web-App-Grafiken für Android und iOS: Das musst du beachten
Web-Apps sind eine gute Alternative zur Distribution von Webseiten oder Web-Applikationen auf mobilen Endgeräten jenseits der jeweiligen App-Stores. Zwar hat man mit Frameworks wie Phonegap die Möglichkeit, beeindruckende auf Web-Technologie basierende Apps zu kreieren, die später als „native Apps“ zur Verfügung gestellt werden – nicht immer aber stehen Aufwand und Anwendungsgebiet einer Applikation in einem vernünftigen Verhältnis. Mit Offline-Storage-APIs hast du die Möglichkeit Web-Applikationen auf ein ähnliches Niveau wie eine native Applikation zu bringen, sparst Zeit beim Einreichen der App und kannst schneller Updates zur Verfügung stellen.
Sowohl Android als auch iOS bieten die Möglichkeit, Websites auf dem Homescreen des Smartphones oder des Tablets abzulegen und ermöglichen so Web-Applikationen ohne „Browser Chrome“ drumherum. Aber auch normale Webseiten können auf den Homescreen geholt werden. Mit einigen Zeilen HTML und den entsprechenden Grafiken machst du deine Webseite oder Web-App fit dafür.
HTML-Vorbereitungen
Der erste Schritt, um deine Web-Applikation auf den Homescreen zu holen, liegt im HTML. Zwar können auch Webseiten ohne die untenstehenden Informationen auf dem Homescreen abgelegt werden, das Ergebnis aber wird vom jeweiligen Betriebssystem gesteuert. So wird beispielsweise bei iOS-Geräten ein selbst generiertes Icon und eine auf dem Title-Element basierende Bezeichnung für deine Web-App erstellt. Meist handelt es sich dabei um einen Screenshot, der nur wenig Aussagekraft hat und auch optisch ein eher unzufriedenstellendes Ergebnis erzielt. Auch wird so der Browser-Chrome beim Aufruf der App nicht ausgeblendet, sodass der Benutzer im Prinzip nur ein etwas besser erreichbares Bookmark auf seinem Endgerät erhält.
Mit den nachfolgenden Meta-Informationen teilst du mit, dass deine Web-App auch als solche auf dem Homescreen hinterlegt werden kann.
<meta name="mobile-web-app-capable" content="yes">
<meta name="apple-mobile-web-app-capable" content="yes">
Diese Codezeilen haben starke Auswirkungen auf die Darstellung deiner Web-App, die bei der Gestaltung deiner Applikation berücksichtigt werden sollten.
- Die URL-Leiste fällt weg.
- Es gibt keine Vor- und Zurück-Buttons.
- Es gibt keinen Reload-Button, sodass der Benutzer bei fehlenden Elementen in deiner Web-App darauf warten muss, dass das Betriebssystem irgendwann die Aktualisierung übernimmt.
Chrome für Android unterstützte eine Zeit lang auch die Meta-Informationen „apple-mobile-web-app-capable“, stellt den Support hierfür aber in aktuellen Releases ein. Auch die mobile-web-app-capable-Eigenschaft wird nicht mehr unterstützt. Um auch unter den neueren Android Releases WebApps ohne Browser-Chrome realisieren zu können, muss ein so genanntes Manifest angelegt und eingebunden werden.
<link rel="manifest" href="manifest.json">
Das Manifest beinhaltet den Namen der Applikation, verschiedene Icon-Größen, eine Start-URL für die Web-App sowie die Standard-Ausrichtung der App im JSON-Format. Ein Beispiel für ein solches Manifest findest du weiter im Artikel.
Der Viewport sollte ebenfalls korrekt konfiguriert werden. Beim Einsatz von Responsive Webdesign, was bei der Vielzahl an verschiedenen Viewport-Größen selbstverständlich zu empfehlen ist, könnte die Einstellung folgendermaßen aussehen:
<meta name="viewport" content="width=device-width">
Ansonsten verhält sich deine Applikation so, als ob sie im Browser ausgeführt wird. Zu beachten ist hierbei außerdem, dass die Web-App wegen OS-Restriktionen nur auf dem Android-Homescreen und nicht im Application-Launcher zu sehen sein wird. Auch ist es nicht möglich, mit Chrome für iOS-Web-Applikationen zu installieren.
Web-App-Icons erstellen
Nun benötigt deine Web-App entsprechende Icons. Hierfür müssen eine Vielzahl verschiedener Grafiken angelegt werden. Während bei Apple nach den jeweiligen Geräten gruppiert wird, gibt es bei Android keine entsprechende Tabelle. Die jeweiligen Größen werden in den „Apple Human Interface Guidelines“ und in dem “Chrome Developer Guide“ festgehalten.
Folgende Icon-Größen müssen wir für unsere Web-App unter iOS und älteren Androids berücksichtigen:
Gerät | ab iOS7 | vor iOS 7 | Icon |
iPhone 6 Plus | 180 x 180 Pixel | – | – |
iPhone 6 | 120 x 120 Pixel | – | – |
iPhone 5 | 120 x 120 Pixel | 114 x 114 Pixel | – |
iPhone 4s | 120 x 120 Pixel | 114 x 114 Pixel | – |
Non-Retina iPhone | – | 57×57 Pixel | – |
iPad und iPad mini (Retina) | 152×152 Pixel | 144×144 Pixel | – |
iPad 2 und iPad mini | 76×76 Pixel | 72×72 Pixel | – |
Chrome für Android vor M39 | – | – | 192×192 Pixel |
Android Geräte mit Chrome ab Version M39 benötigen folgende Icon-Größen:
Chrome für Android nach M39 | ||
Gerät | Größe | Faktor |
– | 36×36 | 0,75 |
– | 48×48 | 1,00 |
– | 72×72 | 1,50 |
– | 96×96 | 1,50 |
– | 144×144 | 2,00 |
– | 192×192 | 3,00 |
Web-App-Icons integrieren
Jetzt müssen die Icon-Grafiken in die Web-App integriert werden. Hierfür fügst du den folgenden HTML-Code in den <head>-Bereich deiner Webseite ein. Achte dabei auf die richtigen Pfade, die zu den jeweiligen Grafiken führen.
<!-- non-retina iPhone vor iOS 7 -->
<link rel="apple-touch-icon" href="icon57.png" sizes="57x57">
<!-- non-retina iPad vor iOS 7 -->
<link rel="apple-touch-icon" href="icon72.png" sizes="72x72">
<!-- non-retina iPad iOS 7 -->
<link rel="apple-touch-icon" href="icon76.png" sizes="76x76">
<!-- retina iPhone vor iOS 7 -->
<link rel="apple-touch-icon" href="icon114.png" sizes="114x114">
<!-- retina iPhone iOS 7 -->
<link rel="apple-touch-icon" href="icon120.png" sizes="120x120">
<!-- retina iPad vor iOS 7 -->
<link rel="apple-touch-icon" href="icon144.png" sizes="144x144">
<!-- retina iPad iOS 7 -->
<link rel="apple-touch-icon" href="icon152.png" sizes="152x152">
<!-- retina iPad iOS 7 für iPhone 6 Plus -->
<link rel="apple-touch-icon" href="icon180.png" sizes="180x180">
<!--Android (ältere Versionen)-->
<link rel="shortcut icon" href="196x196.png" sizes="196x196">
Für Android mit Chrome ab Version M39 wird die manifest.json benötigt, welche alle relevanten Informationen zur Applikation enthält.
{
"name": "Web Application Manifest Sample",
"icons": [
{
"src": "launcher-icon-0-75x.png",
"sizes": "36x36",
"type": "image/png",
"density": "0.75"
},
{
"src": "launcher-icon-1x.png",
"sizes": "48x48",
"type": "image/png",
"density": "1.0"
},
{
"src": "launcher-icon-1-5x.png",
"sizes": "72x72",
"type": "image/png",
"density": "1.5"
},
{
"src": "launcher-icon-2x.png",
"sizes": "96x96",
"type": "image/png",
"density": "2.0"
},
{
"src": "launcher-icon-3x.png",
"sizes": "144x144",
"type": "image/png",
"density": "3.0"
},
{
"src": "launcher-icon-4x.png",
"sizes": "192x192",
"type": "image/png",
"density": "4.0"
}
],
"start_url": "index.html",
"display": "standalone",
"orientation": "landscape"
}
Web-App-Styling in iOS
Android-Web-Apps geben den gesamten Bildschirm für deine Web-App frei. iOS behält sich den kleinen Balken, der die Uhrzeit, die Ladestandsanzeige und die Netzbetreiber-Informationen anzeigt, vor. Das Aussehen dieses Balkens kann allerdings ebenfalls gesteuert werden.
<meta name="apple-mobile-web-app-status-bar-style" content="black">
Hier können verschiedene Werte gesetzt werden, um das Aussehen des Statusbalkens zu steuern. Wenn content auf „default“ gesetzt wird, wird die normale Status-Leiste angezeigt. Ist der Wert „black“, hat die Statusleiste einen schwarzen Hintergrund. Beim Wert „black-translucent“, wird der Balken leicht transparent. Sind die Werte auf „default“ oder „black-translucent“ gesetzt, kann der Platz, den der Balken zur Verfügung stellt, von der Webseite genutzt werden. In diesem Fall legt sich der Balken über den Inhalt. Ist der Wert „default“ oder „black“, steht der Platz nicht zur Verfügung. Setzt du diesen Wert nicht, kann das dazu führen, dass der Balken komplett schwarz dargestellt wird. Das verbraucht Platz ohne Informationen zu beinhalten und erzielt einen insgesamt unstimmigen Eindruck.
Web-App-Name unter iOS festlegen
Beim Installieren der Web-App wird das Title-Element der Webseite genutzt. So ist es denkbar schwierig beziehungsweise unmöglich, eine Balance zwischen SEO-Title und einem für den Homescreen geeigneten Titel für die Web-App zu finden.
Während in älteren Chrome-Versionen keine Möglichkeit vorgesehen ist, eine Web-App entsprechend zu benennen, kann bei iOS mit einem zusätzlichen Meta-Tag der Titel für den Homescreen festgelegt werden.
<title>Langer SEO-Name</title>
<meta name="apple-mobile-web-app-title" content="Kurzer name">
Neuere Chrome Versionen regeln die Bezeichnung der WebApp über das Manifest.
Web-App-Startbildschirm in iOS
Für iOS-Geräte ist es außerdem möglich, einen „Startbildschirm“ für die Web-App festzulegen. Hierbei handelt es sich um eine Grafik, die angezeigt wird, während die Applikation geladen wird. Auch in diesem Fall gibt es zahlreiche verschiedene Geräte-Größen zu beachten.
Start Bildschirm | ||
Gerät | Portrait | Landcape |
iPhone 6 Plus | 1242×2208 Pixel | 2208×1242 Pixel |
iPhone 6 | 750×1334 Pixel | 1334×750 Pixel |
iPhone 5 | 640×1096 Pixel | 1096×640 Pixel |
iPhone 4s | 640×920 Pixel | 920×640 Pixel |
Non-Retina iPhone | 320×460 Pixel | 460×320 Pixel |
iPad und iPad mini (Retina) | 1536×2048 Pixel | 2048×1536 Pixel |
iPad 2 und iPad mini | 768 x 1024 Pixel | 1024×768 Pixel |
Android | – | – |
Mit den folgenden Code-Zeilen kannst du die Startbildschirme in deine Web-App implementieren:
<link href="splash/apple-touch-startup-image-320x460.png"
media="(device-width: 320px) and (device-height: 480px)
and (-webkit-device-pixel-ratio: 1)"
rel="apple-touch-startup-image">
<!-- iPhone (Retina) -->
<link href="splash/apple-touch-startup-image-640x920.png"
media="(device-width: 320px) and (device-height: 480px)
and (-webkit-device-pixel-ratio: 2)"
rel="apple-touch-startup-image">
<!-- iPhone 5 -->
<link href="startscreen_640x1096.png"
media="(device-width: 320px) and (device-height: 568px)
and (-webkit-device-pixel-ratio: 2)"
rel="apple-touch-startup-image">
<!-- iPad (portrait) -->
<link href="splash/apple-touch-startup-image-768x1004.png"
media="(device-width: 768px) and (device-height: 1024px)
and (orientation: portrait)
and (-webkit-device-pixel-ratio: 1)"
rel="apple-touch-startup-image">
<!-- iPad (landscape) -->
<link href="splash/apple-touch-startup-image-748x1024.png"
media="(device-width: 768px) and (device-height: 1024px)
and (orientation: landscape)
and (-webkit-device-pixel-ratio: 1)"
rel="apple-touch-startup-image">
<!-- iPad (Retina, portrait) -->
<link href="splash/apple-touch-startup-image-1536x2008.png"
media="(device-width: 768px) and (device-height: 1024px)
and (orientation: portrait)
and (-webkit-device-pixel-ratio: 2)"
rel="apple-touch-startup-image">
<!-- iPad (Retina, landscape) -->
<link href="splash/apple-touch-startup-image-1496x2048.png"
media="(device-width: 768px) and (device-height: 1024px)
and (orientation: landscape)
and (-webkit-device-pixel-ratio: 2)"
rel="apple-touch-startup-image">
Leider werden die Vorschaubilder ausschließlich beim Starten der Web-App angezeigt. Im App-Switcher wird nur ein weißes oder ein schwarzes Feld dargestellt. Lediglich bei einem direkten Aufruf des App-Switcher aus der WebApp heraus wird der aktuelle Zustand der App dargestellt.Bei Android bietet sich keine Möglichkeit, einen Startbildschirm anzulegen, was wohl an den enormen Unterschieden zwischen Android-basierten Geräteklassen liegt.
Fazit
Seit dem letzten Beitrag zu diesem Thema im März vergangenen Jahres hat sich viel in diesem Bereich getan. Durch das iPhone 6 Plus müssen Designer nun eine zusätzliche Icon-Größe zur Verfügung stellen. Durch die neuen Möglichkeiten, die der aktuelle Chrome-Browser für Web-Apps bereithält, können nun auch Titel für die Chrome Web-Apps vergeben und passendere Icons für die Vielzahl verschiedener Android-Geräte ausgeliefert werden. Die Implementation durch ein Manifest ist bei Android deutlich besser gelungen, als bei Apples aufgeblähtem HTML-Ansatz. Auch das Problem mit den weißen Flächen im App-Switcher ist leider noch nicht behoben. Wir sind gespannt, was uns in Zukunft in dieser Angelegenheit erwartet.
Vielleicht auch interessant: Hier findet ihr die besten Quellen für kostenlose Android-Apps
Hey Ilja,
nutzt du Bootstrap als Framework? Ich finde, das läuft gerade auf mobilen Plattformen doch immer etwas schwerfällig. Zumindest bei meinem Android-Gerät kommt es bei mehreren auf Bootstrap basierenden Seiten immer wieder zu Darstellungs-Problemen.
Vielleicht noch als Ergänzung:
WP kann das noch nicht ganz (vielleicht in 8.1) aber die Möglichkeiten in Windows 8.1 gehen sogar noch ein Stück weiter, da ein Website sogar ein wirkliches LiveTile haben kann http://www.hanselman.com/blog/MakeAWindows81PinnedLiveTileForYOURWebsiteInMinutes.aspx
Einige Webseiten mit Live Tile (oder evtl nur mit statischen Logo auf dem Live Tile gibts schon). BBC, TheVerge, oder Drupal…
Das Einzige Problem sind die Mengen an Icons, die für dann 3 OS Systeme erzeugt und im HTML stehen müssen. Allein für iOS ist dies schon sehr unübersichtlich und mühsam…
Hallo Rico,
ich finde Bootstrap ganz angenehm als Grundlage. Ich ziehe eine angepasste Version mit den jeweils benötigten Komponenten und eigenen Code als Erweiterung einigen der bereits vorhandenen Komponenten vor. Jedes Framework hat seine Vor- und Nachteile, aber da muss man wohl durch.
Ein guter Artikel! Wer sich für weitere Infos über den optimalen Einsatz von Bildern und Grafiken in Apps interessiert, für den sind vielleicht die praktischen Tipps einer unserer Developer hilfreich:
http://www.flyacts.com/blog/anforderungskatalog-fuer-die-app-gestaltung-mit-grafiken/
Die interessante Frage kommt wenn man die Storage API zum Beispiel mit emberJS benutzt, also etwas auf der Seite „navigieren“ möchte. History API und Storage API scheinen da noch etwas Nachholbedarf zu haben.
„SEO-Name“… wenn ich das schon wieder les. Für mich haben diese SEO-Leute alle ’ne Schraube locker. Davon ab, ist eine „Webapp“ eben eine App und sollte dann auch wie eine solche eirken und nicht noch halb Webseite sein. Dafür wird sie in der Regel von woanders aus verlinkt und läuft erst nach Installation auf dem Homescreen. Da die Navigation in Webapps zudem völlig auf Javascript basiert, sind sie für Suchmaschinen eh nicht geeignet.