Die Darstellung und Kontrolle komplexerer grafischer Elemente zum Beispiel für Charts oder virtuelle Geräte ist mangels Unterstützung für Flash, OpenGL, Java und SVG nur über das Canvas-Element möglich, das aber gut in Javascript und DOM eingebunden ist und auch in OS-X-Widgets Verwendung findet.
Fehler in Webapplikationen zu finden, ist aufgrund der Wechselwirkungen zwischen HTML, CSS, Javascript und serverseitig laufender Software oft eine Qual. Eine Plattform mit so vielen (notwendigen) Eigenheiten wie der mobile Safari erleichtert es dem derart geplagten Entwickler nicht, da bewährte Hilfen wie Firebug nur begrenzt einsetzbar sind.
Glücklicherweise hat Apple dem iPhone-Browser eine Debug-Konsole spendiert, die sich im Entwicklerabschnitt der Safari-Einstellungen aktivieren lässt. Safari blendet dann unterhalb der URL-Zeile eine Leiste mit der Anzahl der erkannten HTML-, CSS- und Javascript-Fehler ein, die nach Antippen in eine nützliche Fehlerliste mit Zeilennummern verzweigt. Buttons am unteren Rand erlauben es, nur HTML-, CSS- und Javascript-Fehler anzuzeigen. Auch Dinge wie die Laufzeitausgabe von Variablen sind damit möglich: die Zeile console.log(“var=“ + var) schreibt zum Beispiel den Namen und Inhalt der Variablen var in die Konsole. Außerdem gibt es error()-, warn()- und info()-Methoden, die die Ausgabe in der Konsole mit passenden Icons verzieren.
Als Steve Jobs dem ungläubigen Publikum bei der Vorstellung des iPhone verkündete, dass er sich bei Applikationen für das „Jesus Phone“ auf die Web-2.0-Idee verlässt, gab es nur wenige begeisterte Gesichter. Betrachtet man die Anzahl der Apple-eigenen Webseiten, die das iPhone berücksichtigen (bis auf minimale Anpassungen der Darstellung praktisch keine) und bezieht das Anfang 2008 erschienene native SDK in die Überlegungen ein, stellt sich die Frage: Wozu der Aufwand?
Auf der nächsten Seite: Benutzbarkeit