John Gruber has spotted a library for iPhone web apps, from none other than Apple. This mysterious library, called PastryKit, seems to have flown under the radar as a Google search reveals precious little on it. In similar vein to other efforts, Apple's library provides support for native-feel websites - websites that run in Mobile Safari, but feel like native apps. (That's the objective anyway; some look-and-feel emulators are "good enough", while others get stuck in the uncanny valley).
Now with the same site in regular Safari (on your Mac/PC), open up the Develop Menu (if it's not there, enable it in Preference|Advanced). Choose User Agent > Mobile Safari 3.0 (or probably any other version number). And now you can see it in your browser. From Develop Menu, Web Inspector will let you view the script.
PastryKit accomplishes all three of the aforementioned things — hiding the MobileSafari address bar, providing fixed-position toolbars, and providing scrolling with momentum — by disabling regular scrolling and setting up its own view hierarchy and implementing its own scrolling.
The whole question of native iPhone apps was a hot topic last month after PPK whipped up a storm on the question of web apps replacing iPhone apps. The really interesting thing here is Apple's stance. They launched the iPhone with web intended to be the platform for 3rd party apps, then switched over to native apps and haven't done much to facilitate native-style web apps since then. Is a change coming? As Gruber puts it:
The $64,000 question, though, is whether PastryKit is something Apple intends (or that a team within Apple hopes) to ship publicly. It seems like a lot of effort to build a framework this rich just for this iPhone User Guide, so I’m hopeful the answer is yes. Perhaps something integrated with the next major release of Dashcode? And, perhaps with integrated UI layout tools, along the lines of Interface Builder?
PhoneGap API’s available to Palm devices include geolocation, accelerometer, notification, orientation, sms, telephony, network, file (read only), and a limited selection of device properties (see the PhoneGap Mobile Spec running on the Palm Emulator to the left).
Essentially a JavaScript shim that maps to the various mobile APIs, the PhoneGap API & suite of tools makes it much easier to build mobile apps for the iPhone, Google Android and various versions of Blackberry by leveraging standard web-based technologies. You can now add Palm to the list of mobile devices being supported by the PhoneGap project.
PPK talks up the excitement of mobile web development, then brings the mood down a notch by listing the overwhelming array of browsers to be targeted! Quirksmode says it all. This talk is about quirks in mobile development, and some of the solutions out there.
Mobile CSS Quirks
So many platforms. Take just WebKit; there's iPhone Safari, Android WebKit, Bolt, Iris, different versions, etc. "If someone says my 'app should work in WebKit', laugh in their face. There are just too many versions of WebKit, so as PPK says it, there really is no "WebKit for mobile".
That said, it's good that things are starting to converge towards WebKit. As for the others: Blackberry browser "is dead" as they'll be switching to WebKit; Mozilla is very late to the game; NetFront "is not very good". Windows Mobile 6.5 is a big improvement on 6.1, and with an improved browser, but it's still IE6 based. ('Nuff said.)
There's also a large legacy share, and if users are used to it already, that may be what they want to keep using.
Landscape versus profile mode is an interesting one for those of us desktop developers whose users don't flip their heads around on a regular basis. NetFront has some very surprising and idiosyncratic ways of dealing with it.
The modes don't stop there. There is also mobile versus desktop mode in some browsers; sometimes users can switch these in some obscure corner of their mobile browser preferences. Again, some surprising things happen in Opera and Android. Perhaps of more concern is the difficulty he had diagnosing the situation at first, when Android was showing three divs of the same width in one mode, and not in the other.
@media to the Rescue
Okay, what can we do about all this? Media queries are extremely useful and fairly well supported in modern mobile browsers.
max-width and min-width have subtle issues which PPK is currently researching, but max-device-width and min-device-width give more reliable results. orientation, aspect-ratio, and dpi (also needs research).
Mobile Javascript
Performance-wise, IE Mobile and Blackberry extremely slow. iPhone is middle ground. The really fast browsers are Opera on Samsung and N97, and S60 on Nokia E71 and N97. The bottom line is take your time with mobile Javascript development; you generally can't expect it to "just work"; you'll have to optimise. Also, don't use iframes - they're major performance hogs.
Mobile Connections
Tempting fate, PPK informs us that if someone in the room starts downloading movies, the network gets slower for the rest of us.
Fortunately, browsers give us events to determine when user is going online and offline. Unfortunately, they're doing it wrong. Only Firefox automatically detects offline; all the others require the user to explicitly say "I'm offline now"!
W3C Widgets
In general mobile development, best practice is to put all the core files on the moble phone, and only download the data. But how can we do that with web apps, where the code comes down with the data? W3C widgets offer a solution. You just create a single HTML page with the CSS, Javascript, and images you need; add an icon and config; zip it up; and deploy. PPK reports it works in practice, and works in a "write once, run many" fashion. There are still problems to be sure, but he says it's the best interoperable solution we have today. But still many outstanding platforms: Blackberry (already talking about it), Nokia Maemo, Palm Pre, Android, and of course, iPhone.
Device APIs
Security risks mean critical device APIs will generally remain off limits to general websites for a while. Widgets have a better model, because they're more self-contained and can be verified, although not perfect either.
Posted by Michael Mahemoff at 7:58 am Comment here
Editor's Note:
Michael did a great job jotting down notes at our developer event in London, and we appreciate him taking the time to do a writeup. Some of the notes have been taken out of context, so we wanted to clarify: We started with a talk on the the future of the mobile Web. This talked about the potential of the Web as the platform for devices, and why we were excited to join Palm.
We don't comment on our specific SDK plans, and while we are personally excited about the Web gaining GPU acceleration via technologies like WebGL and CSS Transforms, and we would like to see webOS gain these capabilities to allow web developers to better leverage our fantastic hardware, we were answering a question about our personal opinion on what we'd like to see happen to the platform. We don't believe the term "immediate" was even mentioned by us, and we are sorry that people have read too much into this particular topic.
Ben and Dion have just wrapped up a WebOS talk in London, in conjunction with O2 Litmus. They explained why Palm is using the web as an application platform (might be preaching to the converted on this website!) and covered some of the development issues.
Embracing The Web
Ben and Dion open by discussing a panel Ben was on some years ago with Dave Thomas. Ben answered rich UIs as the most important trend, but Dave held up his mobile and said this is the future of software. And (according to Ben) Dave has been vindicated. Today, we have many, many, devices, and it's tricky for us to target them as both developers (technically) and businesses (commercially).
But what's interesting is the web browsers that have snuck into many of these platforms. The Ajax revolution changed the game for the first time, where you could build real-world web apps. (screenshots: GMail, GMaps, GOffice, Bespin, 280slides.) It's only happening just now, and pretty soon, the web will be a great place not just from portability of the code, but portability of the distribution mechanism.
Tools like Fluid, Mozilla Prism, give us a specialised browser for a web app. On the other end of the spectrum, we have tools like Adobe Air and Appcelerator Titanium that let developers build full-fledged desktop applications.
But why the web? How about other technologies like Silverlight and Flash? Well, the browser really hasn't changed that much (Netscape screenshot). But underneath, the engine has changed dramatically. We're going from the hacky world of the first browsers to one where developers will benefit greatly from the Javascript engines, renderers, and APIs available to us.
For example, with canvas, the ability to do dynamic graphics (nice demos). Likewise, SVGs. Custom typography; Firefox is rolling out support for even obscure features of fonts. Later in the presentation, Ben demonstrates further capabilities: OpenGL and 3D CSS transformations (more nice demos); what Ben calls "the final frontier" of visual interfaces.
Faster Javascript engines are more than just increased performance. As Steven Levy points out, when you increase something's performance by an order of magnitude, you haven't just increased the performance; you've created something new. So we have generational garbage collection, for example, which is a sign of the virtual machines maturing and becoming much faster.
Related to JavaScript speed is threading. We don't have threads and given opinions of the creator of JavaScript, probably never will. But "browsers now have something that's even better than threads": web workers. It's used in different ways; for example, Chrome extensions can run in their own process this way. Another example is running a database server like SQLite in a separate process.
So does the web have the capabilities for today's and tomorrow's applicatons? There's a huge user base and a huge developer based - more developers than any other platform. Some people still think of JavaScript as a toy, but when they get into it, they often realize it's actually quite good, and it's not JavaScript they don't like, but things like browser incompatibilities that are troublesome.
Development Details
Web developers can use the Mojo framework, which provides simple Prototype based APIs. Notifications are HTML controls themselves, so you can put whatever HTML you want inside it. Security-wise, applications can get different powers
Palm wants to sell phones, not proprietary APIs, so it's involved with BONDI and W3C widgets standardisation efforts. One of the things they need to know from us (the developer community) "Palm pays us, but they didn't pay us enough to sell out"; Ben and Dion are developers and they're not going to tell other developers use "our funny proprietary API, you'll love it". However, they can't say when all this will happen, as they're evolving the platform pragmatically and they feel other things might have more immediate impact, e.g. OpenGL support.
The web distribution model is simple - user surfs to a URL! But many people actually want a catalogue, and in fact some app catalogues are becoming spam catalogues. Some even boast about how many apps there are in the catalogue, Ben notes with a wink at the big I. With Palm, developers pay $50 and it helps to avoid the problem. There will be one catalogue, but developers can control which markets they're selling in, and get useful analytics and feeds about its usage. Wanting to reduce the friction for people to buy an app, so would consider (although nothing definite) carrier billing and affiliate links.
Q&A
The developer portal is currently being overhauled. Under consideration are ways to make things more transparent, e.g. bug tracking and planned features.
Ben and Dion anticipate that developers will probably be able to opt in to JavaScript obfuscation (or some other form of obfuscation). As Dion explains, View Source has been really important on the web, so there's a tension and it's likely multiple options will be available.
On ease of use, multitasking has been great; UI latency is still an issue even though the hardware is comparable to 3GS. The problem is the path to the GPU didn't exist, but now with CSS transforms, that will be solved in the future. As far as screen size, where Pixi broke the mold 4 months after the Pre, this happy world of coding to the same screen size on mobiles is going. Ben says it would have been easier for Palm if it wasn't the first phone to break the mould, but reality is the mobile space will break out to big screens, phones, etc etc, so it won't be one fixed resolution or even aspect ratio.
There will be lots of new tools for developing with and they'll be able to work with WebKit. Ben and Dion (not speaking for Palm, they're sure to add) are open to the thought of embracing Flash for native apps and keen to hear people's thoughts on it.
The open source question ... will Palm open source WebOS. Ben says "we (Ben and Dion) would love to do it", but it's not Android working to thousands of phones and it still has to be considered.
Update: Turned out attendees scored free Pre's after the event. Thanks fellas :).
PPK has cried "There is no WebKit on mobile!" as he posts new compatibility tables that test WebKit across desktop and mobile:
I compare 19 WebKits in order to prove that there is no “WebKit on Mobile” and to figure out which one is the best. My hope is that eventually I’m going to gain some insight in the “family tree” of all WebKits.
This page only contains tests of CSS and JavaScript items that work in some WebKits but not in all. Adding more items, all of which are either supported by all or by none of the WebKits, makes no sense — it’s in the items in the table below that the differences between the 19 tested WebKits lie.
I will probably add some HTML5 items to this list later on, provided they’re supported by at least one WebKit (probably Safari or Chrome).
These tests focus solely on compatibility. I say nothing about performance or user interface, and especially on mobile these factors may, in the short run, be more important than compatibility.
Alex Russell responded to the concern that we are in a world of hurt with multiple browsers on mobile just like we are on the desktop. Alex thinks that the core notion of timeliness matters here:
I’m not convinced that the situation is nearly that bad.
The data doesn’t reflect how fast the mobile market changes. The traditional difference between mobile and desktop, after all, has been that mobile is moving at all. If you figure a conservative 24 month average replacement cycle for smartphones, then the entire market for browsers turns over every two years. And that’s the historical view. An increasing percentage of smartphone owners now receive regular software updates that provide new browsers even faster. What matters then is how old the WebKit version in a particular firmware is and how prevalant that firmware is in the real world. As usual, distribution and market share are what matters in determining real-world compatibility, and if that’s a constantly changing secnario, the data should at least reflect how things are changing.
Bikin Chiu of the Gmail Mobile team picks up the HTML5 series with a piece on reducing startup latency.
It starts off by talking about lazily loading code via the old favorites of adding a <script> to the DOM, or XHR+eval, but then it gets beyond the typical and discusses the nuance of mobile + offline caching. The hack that is used, is another oldie.... which is to hide the script and eval it later:
For an HTML 5 application that takes advantage of the application cache to reduce startup latency and to serve the application offline, there are a few caveats one should be aware of. Mobile networks have decent bandwidth, but poor round trip latency, so listing each module as a separate resource in the manifest incurs quite a bit of extra startup latency when the application cache is empty. Also, if one of the module resources fails to be downloaded by the application cache (e.g. disconnected from network), additional error handling code needs to be written to handle such a case. Finally, applications today have no control when the application cache decides to download the resources in the manifest (such a feature is not defined in the current specification of the draft standard). Typically, resources are downloaded once the main page is loaded, but that's not an ideal time since that's when the application requests user data.
To work-around these caveats, we found a trick that allows you to bundle all of your modules into a single resource without having to parse any of the JavaScript. Of course, with this strategy, there is greater latency with the initial download of the single resource (since it has all your JavaScript modules), but once the resource is stored in the browser's application cache, this issue becomes much less of a factor.
To combine all modules into a single resource, we wrote each module into a separate script tag and hid the code inside a comment block (/* */). When the resource first loads, none of the code is parsed since it is commented out. To load a module, find the DOM element for the corresponding script tag, strip out the comment block, and eval() the code. If the web app supports XHTML, this trick is even more elegant as the modules can be hidden inside a CDATA tag instead of a script tag. An added bonus is the ability to lazy load your modules synchronously since there's no longer a need to fetch the modules asynchronously over the network.
On an iPhone 2.2 device, 200k of JavaScript held within a block comment adds 240ms during page load, whereas 200k of JavaScript that is parsed during page load added 2600 ms. That's more than a 10x reduction in startup latency by eliminating 200k of unneeded JavaScript during page load! Take a look at the code sample below to see how this is done.
var lazyElement = document.getElementById('lazy');
var lazyElementBody = lazyElement.innerHTML;
var jsCode = stripOutCommentBlock(lazyElementBody);
eval(jsCode);
}
</script>
In the future, we hope that the HTML5 standard will allow more control over when the application cache should download resources in the manifest, since using comments to pass along code is not elegant but worked nicely for us.
The WebKit Open Source Project provides a JavaScript test Suite dubbed SunSpider. According to the description on the SunSpider home page, “this benchmark tests the core JavaScript language only, not the DOM or other browser APIs. It is designed to compare different versions of the same browser, and different browsers to each other.” We at Medialets have found it to be one of the best attempts to measure real world JavaScript performance in a balanced and statistically sound way.
Medialets ran the SunSpider test suite in the following environments:
Safari 4.0.1 on a 2.0 GHz Intel Core 2 Duo White MacBook.
The MacBook results were used as a baseline for relative comparisons.
Mobile Safari on the iPhone 3G with iPhone OS v2.2.1
Mobile Safari on the iPhone 3G with iPhone OS v3.0
Mobile Safari on the iPhone 3GS with iPhone OS v3.0
The “Browser” app on the T-Mobile G1 with Android OS v1.5 (Cupcake)
The “Web” app on the Palm Pre with Web OS v1.0.2
Each device was fully restored and rebooted immediately before running the test suite. Every attempt was made to assure that no atypical background tasks were executing while the tests were running. The SunSpider tests automatically run five times sequentially and the mean average from all five tests are reported. Network speed and latency have no effect on the results of the test.
We all know to beware of benchmarks, but it does show off how powerful these devices are getting!
Appcelerator has announced a Titanium beta that adds to their desktop vision with new APIs and developer tool but also allows you to create mobile applications using HTML/CSS/JavaScript (and in fact Ruby, Python, ...) that run on iPhone and Android.
You can take a look at what it takes to develop for desktop and mobile in this screencast from Kevin Whinnery:
I instantly thought of PhoneGap and asked Jeff Haynie about the differences. It appears that Titanium Mobile handles the device mapping in a different way. Instead of focusing just on device APIs and giving developers access to those APIs via JavaScript, it goes a little further. The Titanium tool will compile down your code and you will see that native widgets will be used in places. As the mobile version moves forward, they expect to do more of that kind of work, so instead of a WebView + APIs, you have native where you can, and WebView where you can't.
From watching the Titanium Developer tool at work, you can quickly see that it is nicely taking care of you, the Web developer, as you go through the process of dealing with phones. Dealing with the SDKs from Apple and Android can be messy business and the tool really tries to make it much more seamless. The same can be said for the packaging and deployment process.
It is great to see yet another product that comes along to help Web developers take their existing skills and have them work on mobile platforms. Personally, the thought of going to Objective-C land isn't a pleasant one for me, so this and PhoneGap make total sense. If other platforms such as Android and hopefully webOS catch on, then it will make even more sense to go cross platform. Who better to write code on difference devices that Web devs since we have to deal with it every day ;)
Need a visual builder? You could take the upcoming 280 Atlas, use Interface Builder or Atlas itself, and deploy your app to the phone. Great times for the Web platform.
Of course we didn't get there without a few hard knocks. As an evolving standard, HTML5 has been fast-changing target and we've skinned our knees and bruised ourselves along the way. So rather than just deliver the fruit of all those bumps and scratches to end users in our own products, we decided we wanted to write a few blog posts to share what we've learned so that others can take advantage of HTML5 as well.
Great to see the mobile Web continue to merge as just One Web, and I look forward to hearing from the trenches on issues the team ran into, so we can learn from them.
Close to 5pm, and you started to see a huge snaky line making its way to the keynote area where Palm was about to have a reception and short announcement. People were jazzed to hear more about the Pre, and Michael Abbott was there to open up access to developers:
Today, Palm expanded the Mojo SDK program for webOS, announcing that a broad group of developers will be provided with the software development kit to create applications for the Palm Pre phone (as well as other future devices running webOS).
Speaking at the Web 2.0 Expo, Palm’s senior vice president of Applications Software and Services Michael Abbott also highlighted some of the most exciting aspects of webOS -- including a new branded service that lets developers create apps that push live content across the Internet -- and invited the audience to apply for the early access program at the Palm Developer Network website.
The power of webOS lets developers rethink how they develop for mobile devices -- and creates opportunities for new kinds of apps. Abbott highlighted several key features of webOS that open up new avenues for the creative ingenuity of the developer community:
a cards metaphor that simplifies multi-tasking
Palm Synergy to unify information from sources like Google, Facebook, and Exchange
a user-friendly approach to notifications that ensures the user is up to date without distracting them from the task at hand.
An often-overlooked aspect of webOS is that Web applications run natively on the phone. They don’t depend on access to a server, and can run even when there is no access to the Internet. But the full power of webOS is unleashed when the device works together with “the cloud” – the combination of all of the Web sites and services that a user interacts with.
David Kaneda has created jQTouch a "jQuery plugin with native animations, auto list navigation, and default application styles for Mobile WebKit browsers like iPhone, G1, and Pre."
New HTML structure to ease toolbar button variations and improve animations.
Various performance improvements
Added minified code
Started a custom theme, which will be offered alongside the standard Apple theme
Created a new Home Screen icon
Removed some iPhone-dependent code
David also answered some questions for us:
How does it compare to iUI?
It is similar in the way it can load views via built-in HTML or dynamic GET/POST requests, but it uses hardware-accelerated animations, and also includes transitions like slide up and 3D page flip. It also includes code for image preloading, a custom theme, and a much easier setup function which eliminates the need to write META tags for the app icon, viewport settings, etc.
What kind of extended functionality are you looking into
Ultimately, I plan on testing extensively on the G1 and, eventually, the Palm Pre. Other plans include a more robust theming system, and various callback methods to make extending jQTouch even easier.
With PhoneGap, would it just be a script that you can get built in?
I am currently in talks with the PhoneGap crew, and we are planning on including it stock with the kit. We're currently unsure if the script should be ported to XUI or remain based on jQuery.
Peter-Paul Koch (AKA ppk) has truly provided a tremendous service to the development community over the years building one of the most important resources in determining compatibility of web standards among the major browsers, the Compatibility Master Table. This resource is referenced often by developers and publications and is exhaustively granular in its data.
With his focus shifting to the mobile space, PPK continues to serve the community by providing similar data for mobile browsers.
Right now I’m doing basic tests while also figuring out what “basic tests” means in the mobile space. It turns out that I even have to test basic CSS stuff like font-style. Many of my already-existing tests use such typographic CSS to denote whether a browser supports a certain selector or effect; but if a mobile phone doesn’t support the CSS in the first place, my tests will misfire horribly.
His Mobile Compatibility Tables, while still very new and a work in progress, will surely be of tremendous help to the many developers who are now looking to mobile web development as the next big wave.
He's already collected a large amount of information on the following mobile browsers:
Opera Mobile
Opera Mini
WebKit
NetFront
Blackberry
and for the following browser capabilities:
Events including key & click
Basic DOM & Ajax support
Basic font CSS
CSS Media
Focus, blur, scroll
Screen orientation support
Font sizes
If you're a mobile web application developer, I urge you to go visit this great resource and even offer PPK feedback to expand his data.
Ben and I have been promoting PhoneGap as a great solution for Web developers to create applications with the technology they know and love, without having to jump off of the cliff to other proprietary worlds. PhoneGap is still new, but gets more impressive every day.
The team is getting more interested, and put together a video on What is PhoneGap?.
You can see a budding list of existing applications that use PhoneGap already and note that PhoneGap isn't just about the iPhone anymore.... Android and RIM are in the house.
