Tag Archives: phonegap

adobe, development, mobile, open source, professional, software development

PhoneGap is at version 1.0

I’ve just spotted that PhoneGap has reached version 1.0. The release was announced at PhoneGap day in Portland, on Friday 29th July.

I have spent some time trying out various cross-platform mobile development tools. PhoneGap is among the most interesting and popular, and is also open source and free to use. If you believe that using the browser engine as an application runtime is the most sensible route to cross-platform mobile applications, then PhoneGap is the leading contender. It wraps your application to look like a native app, and also provides ways to call the native API when necessary.

PhoneGap received a boost when Adobe built it into Dreamweaver 5.5. I tried it out and was impressed with the design environment, but I am not sure how serious Adobe is about PhoneGap since there is no documentation on how to package your PhoneGap app for release, and my post has comments from puzzled users. My solution was to export the project to Eclipse and the standard PhoneGap tools, which misses part of the value of having it integrated into Dreamweaver.

Adobe installs PhoneGap into the Dreamweaver directory, so another issue is how to take advantage of the latest version if you are using Adobe’s tools. Overall I would suggest that using the PhoneGap SDK and Eclipse is a better option, though there is no problem with bringing in Dreamweaver for parts of the design.

I interviewed Nitobi president André Charland about PhoneGap earlier this year.

adobe, development, iphone, mobile, professional, software development

Hands On with RunRev LiveCode: rapid development for iOS, Android, Mac and Windows

3 Comments

RunRev LiveCode is a cross-platform development tool for Mac, Windows, Linux, Web, Apple iOS and, from this month, Google Android.

image

It is an individualistic tool inspired by Apple’s original (but now obsolete) HyperCard and HyperTalk, in which the building blocks of your application are stacks and cards. A stack is like a window, and a card is like a panel overlaid on that window. Unlike HyperCard, LiveCode is not a virtual card stack where each card can represent a record in a database; it is simply a means of building a graphical user interface.

A key attraction of LiveCode is that it now supports the two dominant smartphone platforms. I have been looking at a number of different approaches to mobile development, most recently PhoneGap; how does LiveCode compare to the competition? In order to get some hands on experience I set out to create my simple calculator application in LiveCode.

Coming almost new to LiveCode, I found that building this application took longer than it had done in PhoneGap, which uses HTML and JavaScript. I created a new stack and dragged some buttons onto it easily enough, but found that the approach to coding took some getting used to. There are lots of tutorials, but I found the easiest way to learn was to read through chunks of the user guide [pdf], which does a better job of explaining how to code.

One annoyance is that each object, such as a button, has its own script window, which appears as a tab in the editor. Although my calculator is simple, it does have a fair number of buttons, so you end up constantly switching between tabs. If you amend some code, you have to remember to click Apply before the change takes effect. If you forget, you run the application and puzzle over why it seems to be running an old version. The environment is strongly GUI-centric; you will not like it if you are an enthusiast for Model-View-Controller architecture.

The environment is dynamic, so you can test the stack you are working on at any time simply by switching it to browse mode. This is why it is called Live Code. In this respect it is similar to the Live View in Adobe’s DreamWeaver.

image

I had to get used to writing:

put firstNumber * secondNumber into theResult

instead of

theResult = firstNumber * secondNumber

I was impressed by LiveCode’s ability to change types on the fly and to work out correctly whether you wanted to do something with a string value or a numeric value.

The language is more English-like than most languages, though I am not sure if it really easier. The language minimises use of punctuation which helps readability. Cases in switch statements fall through, C style, unless you remember to include break statements, which is traditionally a common source of bugs.

I got my calculator working on Windows. I tried building for what RunRev calls Web, but was put off by the plug-in requirement:

image 

I then moved the project to a Mac to try it on iOS. Everything still worked, but I spent some time resizing the stack and repositioning the buttons to look half-way reasonable on an iPhone. I may be missing some tricks here, but scaling and positioning controls does not seem to be a strong point for LiveCode.

LiveCode does feel that bit more at home on a Mac, reflecting its origins.

image

I was impressed with how easy it was to build the app for iOS. The way cross-platform works in LiveCode is that you open a dialog called Standalone Application Settings. There is a tab for each supported platform, in which you specify options specific to each platform. The options for iOS are extensive, including supported devices, hardware access requirements, orientation options, external libraries and so on. You can then test immediately on the simulator. For on-device testing, you use the Organizer in Xcode to copy the compiled app across.

image

The good news is that the app ran well, much better than than the PhoneGap/jQuery Mobile version, though it did not look as nice and in fairness the other app’s performance issues are likely more to do with jQuery Mobile than PhoneGap itself.

Although I found it a bit of a hassle getting started, nevertheless I was able to build a working app for Windows, Mac and iOS in a few hours, so I should not complain.

Of course there is a lot more that LiveCode can do. It has database libraries, graphical effects, an embedded web browser on some platforms, XML and text processing support, and more. It is also extensible; there is probably not much that cannot be achieved with sufficient effort.

I have not tried the Android support as my version does not include it; though I did notice that the Android options dialog is basic compared to what is available for iOS.

My first impression of LiveCode is positive, but with reservations. It looks to me like a viable and productive route to cross-platform development, or you might use it just as a quick route to app development for iOS, but I did not enjoy working in the IDE which feels quirky and unsophisticated compared to other modern IDEs. My little app works well though, and that suggests it would be worth trying it for something more advanced.

development, mobile, professional, software development, web authoring

Mobile developers follow the users; PhoneGap most popular cross-platform toolkit says survey

2 Comments

Web Directions has published a State of Mobile Web Development based on input from around 1300 professional web developers. Note that this is a survey of web developers not app developers, which must skew the results if you are interested in the overall app picture, but it is still interesting.

One result deals with developer platform decisions. What are the factors that count when choosing a platform to develop for? New and minority mobile platform players will study this with interest, since getting a large number of developers on board is a high priority.

Here is the ranking of factors based on how many developers consider each one “Very important”:

  1. Number of potential users of your app: 68.55%
  2. Platform capabilities: 60.36%
  3. Ease of development: 58.55%
  4. Worldwide reach of marketplace: 40.02%
  5. Assistance in marketing your app: 23.40%

The message for the likes of Microsoft, HP and RIM is that the best way to attract developers is to sell lots of cool devices. Ease of development matters, but not as much as a large market.

Another section asks which toolkits are preferred if you are developing native apps with web technologies (note the exact question):

  1. PhoneGap 47.6%
  2. Appcelerator 26.5%
  3. Other 15.6%
  4. Adobe AIR 7.8%
  5. Apparatio 1.2%
  6. Rhomobile 1.2%

The sample here is rather small, with only 79 of the 1300 using PhoneGap, for example. I also quibble with the definitions here. Rhomobile’s Rhodes framework compiles Ruby to native code and I doubt it counts in the category “developing native apps with web technologies”. I am even sure whether AIR belongs alongside PhoneGap and Appcelerator, since AIR is Flash whereas the other two are HTML 5. Incidentally, Appcelerator is the company name and what should appear here is Titanium, which is the name of the cross-platform toolkit. Apparat.io is in private beta so its low take-up is not surprising.

Still, it is a good result for the top two. If you are interested in these toolkits don’t miss my recent interviews with André Charland at Nitobi (PhoneGap) and Jeff Haynie at Appcelerator.

adobe, apple, iphone, professional, software development

Building a PhoneGap app for iPhone with Adobe Dreamweaver CS5.5

3 Comments

After trying out Adobe’s new Dreamweaver CS5.5 for building a PhoneGap app for Google Android, I was keen to try the same for Apple iOS. In particular, I wanted to see if the performance problems with jQuery Mobile and PhoneGap on Android were also an issue on iOS.

This turned out to be more complex than I had imagined. Bear in mind that I have not done a lot of previous iOS development; but I reckon that makes me a good test case for Adobe’s market here. Ideally you should be able to use Dreamweaver alone to build your app and make a fortune on Apple’s popular app store.

I installed Dreamweaver CS5.5 without any issues and copied my Calculator example from PC to Mac. I am not going to repeat the steps that were the same as for Android; read my earlier post. I will mention that I puzzled over the setting for the IOS Developer Tools Path. After trying various sub-directories I eventually discovered that simply entering /Developer here works. One of the issues I have with this stuff is that clicking Help generally does not help. I resorted to watching one of Adobe’s videos and checking out the screen there.

My app worked fine though and I was able to run it up in the iPhone simulator. However I really wanted to test it on the device itself. The problem: this is all you get in Dreamweaver in terms of application settings:

image

I have not yet found any documentation from Adobe concerning what to do once your PhoneGap app is ready for on-device testing, though there may be some somewhere.

My solution was to download a separate install of PhoneGap, picking the latest version which is 0.9.5. Then I downloaded Xcode 4 and the latest iOS SDK; I had not previously installed this as I have only just signed up for Apple’s paid developer program.

I might have been better sticking with Xcode 3.x, as it turns out that PhoneGap’s support for Xcode 4 is still work in progress. I used Shazron Abdullah’s script which creates an Xcode 4 PhoneGap project from the command line. Then I copied my Calc application and the jQuery mobile directory into the project and opened it in Xcode 4.

Nothing worked and I had to do a number of things to get it to build. Most problems were solved using this guide by Cameron Perry and the comments which follow. Here’s what I recall doing:

  • I removed a red link to PhoneGapLib.xcodeproj and added it back from ~Documents/PhoneGapLib
  • I added i386 to the list of Valid architectures in build settings, for both the PhoneGapLib and my Calc project
  • I added an entry for PHONEGAPLIB to the Xcode 4 Source Trees, set to /Users/username/Documents/PhoneGapLib/ using the full path and not the ~Documents abbreviation.
  • I obtained an ID for my app from Apple’s developer portal and pasted into the project as the Bundle identifier (info section).

At this point the project almost built but I still got two Apple Mach-O Linker errors relating to PhoneGapDelegate:

image

I tried a couple of things to fix this. I added the PhoneGapLib project as a target dependency for Calc, which did no harm but was not a fix. Then I went to the Link Binary with Libraries section of Build Phases and added a reference to libPhoneGapLib.a

image

The odd thing is that libPhoneGapLib.a now appears in my project in red, suggesting something missing, but the project now builds fine; I am sure an Xcode 4 guru can advise.

So here is my app running on a real iPhone 4:

image

I slightly modified the design to fit the iPhone 4 screen.

Now for the bad news: performance is still not really good enough. To be clear, the problem is a slight pause between tapping a button and the number being entered. One bad symptom is that if you are in a hurry and tap several numbers quickly, some may not register. The iPhone 4 runs the app slightly better than my HTC Desire, but I would still not be happy releasing it with this performance – leaving aside the fact that a better calculator app comes free with the iPhone.

I tried specifying a release build in Xcode 4 but it made little difference. I suspect performance could be improved either by not using jQuery mobile, or by configuring it to reduce the richness of the buttons it creates.

Leaving that aside, it seems to me that Adobe has some work to do in making it easier to get from a Dreamweaver project running in the emulator, to an app that you can test on a device and deploy to the app store. Although the steps I took seem arduous, it is not really so bad once you get it working. You could create a much more complex app entirely within Dreamweaver, and then the work involved in moving it to Xcode would be pretty much the same as I had to do for my simple calculator. So I am not going to say that the PhoneGap integration is no use, just that it needs better documentation. Maybe in the next version we will get fuller integration that will do device build and deploy as well as building for the simulator.

adobe, development, javascript, professional, software development, web authoring

Dreamweaver CS5.5 PhoneGap apps: performance issues on Android

1 Comment

This is a follow-on from my earlier post about building a simple PhoneGap app using Adobe Dreamweaver CS5.5. I built it on Windows targeting Android. I liked the development experience up to the point of trying the app: it looks great, but performance is terrible. That is, you tap a button and there is a perceptible pause before the app responds. It is worse in the emulator than on my HTC Desire, but still poor.

I had thought it was a configuration setting – though Dreamweaver makes it rather hard to access the build settings – but I am now wondering if jQuery mobile plus PhoneGap is just too demanding for most Android devices out there right now. Admittedly my Desire is a year or so old now. See this thread for example:

JQuery Mobile on Android is definitely slow. (Tested A2 and A3Pre on Samsung Galaxy S, HTC Desire, ZTE Blade (edit: 2.2 Froyo) – with PhoneGap, stock browser, Opera Mobile)

Something has to be done. The experience is low quality.

It is worth noting that PhoneGap is not yet a version 1.0 release – I was told it may be done by July. Further, you do not have to use jQuery Mobile with it in Dreamweaver; it just happens to provide a great set of user interface widgets. It may be better on Apple iOS; I have not tried that yet.

Nevertheless, this looks like a significant issue if you planning to dive in and deliver Android apps using the tools in the new Dreamweaver.

adobe, professional, software development

Hands on: Building a PhoneGap app with Dreamweaver CS 5.5

25 Comments

One interesting feature in the new Adobe Creative Suite 5.5 is that PhoneGap is integrated into Dreamweaver. What this means is that you can build a mobile app for Google Android or Apple iOS from within Dreamweaver.

I have just installed the new suite, so decided to give it a try. My project: to create a working calculator app and install it on an HTC Desire (Android 2.2).

I started by creating a new document based on the PhoneGap Mobile Starter.

image

Next, I created a new site with the name “Calc”, in a folder called Calc.

I saved the page as index.html. When I did so, Dreamweaver prompted me to copy a bunch of JQuery Mobile stuff into the folder.

Then I selected “Configure Application Framework…” from the Mobile Applications option on the Site menu.

image

This menu is pretty much all you get for PhoneGap support. The Configure option lets you select the Android SDK or install it. Mine was already installed.

image

If you want to build for iOS, you need to run Dreamweaver on a Mac, though I guess you could code on Windows and build on the Mac using PhoneGap in the normal way.

The next step was to write the application. I mostly used the code view. DreamWeaver has a handy Insert panel which you set to jQuery Mobile. Drag controls from here into your code or design view.

image

Beware: the design view is a bit hopeless for jQuery Mobile apps, unless you have Live view switched on. Here they are side by side:

image

I built probably the world’s worst calculator. Assembling the user interface was easy though. I used a jQuery Mobile Layout Grid for the buttons. I wrote some quick JavaScript with no error handling whatsoever. I used Firefox and its error console for simple debugging.

When I was done, I selected “Application Settings…” from the Mobile Applications menu. Here you can set a few properties including the version and the icon.

image

Build and Emulate from the Mobile Applications menu.

image

This installed the app in the Android emulator. I could run it successfully, though it was mighty slow. You click a button, then after a noticeable pause the app updates to show the value you clicked. However, my app worked.

image

Next, I attached my Desire phone, and copied across the calc-debug-apk package which had been built. I detached the phone and tapped the app. Again success – but the app, while faster than the emulator, is still slow.

image

That is possibly because it is a debug build. But how do you specify a release build? I cannot find a setting for it in Dreamweaver, which seems a striking omission. I am hoping it is possible to tweak the PhoneGap build properties in the generated source, but it looks like I will need to consult the PhoneGap documentation for this.

On the one hand I am impressed. The UI looks nice considering how little time I spent on it, thanks to jQuery mobile. Further, the application works, and I was able to build it entirely in Dreamweaver. The code completion in Dreamweaver’s editor is decent.

On the other hand, documentation is terrible. This article is almost all I can find – beware the dud link to abobe.com:

image

I am not complaining about the PhoneGap docs or the jQuery Mobile docs, but the Adobe docs for using this in Dreamweaver. I hope that more will come.

Update: I spent some more time on this trying to fix the performance issues. The fact of being a debug build should not affect performance as far as I can tell; it merely signs the app with a debug key. I moved the project to the standard Eclipse tools and built it there in case Dreamweaver was messing up the build in some way, but performance is just as bad. More research throws up threads like this one:

I’ve been using Phonegap & JQM on a real device and it is also very slow (HTC Hero, upgraded to 2.1), but it flies on an ipod touch 4th gen. I guess the HTC is just getting old but I’d like to try it on a more modern device.

My initial conclusion then is that a jQuery Mobile/PhoneGap app on an HTC Desire running Android 2.2 will never perform well. It sounds like it might be OK on iOS; I guess I should try that next.

See also my interview with Nitobi president André Charland about PhoneGap.

adobe, mobile, professional, software development, visual studio, Web, web authoring

Native apps better than web apps? That’s silly talk says PhoneGap president

1 Comment

When I attended Mobile World Congress in February one of my goals was to explore the merits of the various different approaches to writing cross-platform mobile apps. One of the key ones is PhoneGap, and I got in touch with Nitobi’s president and co-founder André Charland. As it turned out he was not at that particular event, but he kept in touch and I spoke to him last week.

PhoneGap works by using the installed HTML and JavaScript engine on the device as a runtime for apps. That is not as limiting as it may sound, since today’s devices have high performance JavaScript engines, and PhoneGap apps can be extended with native plug-ins if necessary. But aren’t there inconsistencies between all these different browser engines?

Sure, it’s kinda like doing web development today. Just a lot better because it’s just different flavours of WebKit, not WebKit, Gecko, whatever is in IE, and all sorts of other differentiation. So that’s definitely how it is, but that is being overcome rather quickly I’d say with modern mobile JavaScript libraries. There’s JQuery Mobile, there’s Sencha Touch, there’s DoJo Mobile just released, SproutCore, which is backed by Strobe, which is kinda the core of Apple’s MobileMe.

There’s tons of these things, Zepto.js which is from the scriptaculous guy, Jo which is a framework out of a Palm engineer, the list of JavaScript frameworks coming out is getting longer and longer and they’re getting refined and used quite a bit, and those really deal with these platform nuances.

At the same time, phone manufacturers, or iOS, Android, WebOS, and now RIM, they’re competing to have the best WebKit. That means you’re getting more HTML5 features implemented quicker, you’re getting better JavaScript performance, and PhoneGap developers get to take advantage of that.

says Charland. He goes further when I put to him the argument made by native code advocates – Apple CEO Steve Jobs among them – that PhoneGap apps can never achieve the level of integration, the level of performance that they get with native code. Will the gap narrow?

I think it will go away, and people will look back on what they’re saying today and think, that was a silly thing to say.

Today there are definitely performance benefits you can get with native code, and our answer to that is simply that PhoneGap is a bundle made of core libraries, so at any point in your application that you don’t want to use HTML and JavaScript you can write a native plugin, it’s a very flexible, extensible architecture … So you can do it. We don’t necessarily say that’s the best way to go. Really if you’re into good software development practices the web stack will get you 90%, 95% of the way there, so that apps are indistinguishable from native apps.

Some of the native features we see in iOS apps, they’re reminiscent of Flash home pages of ten years ago, sure you can’t do it in HTML and JavaScript but it doesn’t add any value to the end user, and it detracts from the actual purpose of the application.

The other thing is, a lot of these HTML and JavaScript things, are one step away from being as good in a web stack as they are in native. When hardware acceleration gets into WebKit and the browser, then performance is really just as good.

Charland is also enthusiastic about Adobe’s recent announcement, that PhoneGap is integrated into Dreamweaver 5.5:

Two things are exciting from our perspective. It gives us massive reach. Dreamweaver is a widely used product that ties in very nicely to the other parts of the creative suite toolchain, so you can get from a high-level graphic concept to code a lot quicker. Having PhoneGap and JQuery Mobile in there together is nice, JQuery Mobile is definitely one of the more popular frameworks that we see our community latching on to.

The other thing is that Dreamweaver targets a broader level of developer, it’s maybe not super hard core, either Vi or super-enterprise, Eclipse guys, you know, it’s people who are more focused on the UI side of things. Now it gives them access to quickly use PhoneGap and package their applications, test them, prove their concepts, send them out to the marketplace.

He says Adobe should embrace HTML and Flash equally.

I also asked about Windows Phone support, and given that Microsoft shows no sign of implementing WebKit, I was surprised to get a strongly positive response:

We have something like 80% of the APIs in PhoneGap running on Windows Phone already. That’s open and in the public repo. We are just waiting basically for the IE9 functionality to hit the phone. The sooner they get that out in public, the sooner we can support Windows Phone 7. We have customers knocking at our door begging for it, we’ve actually signed contracts to implement it, with some very large customers. Just can’t there soon enough, really. I think it’s an oversight on their part to not get IE9 onto the phone quicker.

PhoneGap is at version 0.94 at the moment; Charland says 0.95 will be out “in a few weeks” and he is hoping to get 1.0 completed by O’Reilly OSCON in July.

I’ve posted nearly the complete transcript of my interview, so if you are interested in Charland’s comments on building a business on open source, and how PhoneGap compares to Appcelerator’s Titanium, and what to do about different implementations of local SQL on devices, be sure to read the longer piece.

adobe, flash, iphone, mobile, software development, web authoring

Adobe announces Flash Builder for PHP, PhoneGap integration in Dreamweaver

Adobe has stepped up its support for mobile and Flash development with a couple of announcements today.

The first is that Dreamweaver 5.5, part of the new Creative Suite 5.5, has integrated support for PhoneGap.

image

PhoneGap lets you build apps for Apple iOS and Google Android using HTML and JavaScript, taking advantage of the WebKit runtime that is present in these devices. The apps are packaged as native apps and also have access to some device-specific features. This does not mean Adobe is abandoning Flash, but is part of a both/and strategy, which makes sense to me.

There is also a new 4.5 version of Flash Builder which has greatly improved mobile support.

image

 

Flex 4.5 compiles to AIR apps on Android, Blackberry and iOS, as well as desktop Mac, Windows and Linux.

You can debug directly on an Android device connected via USB, or using a new emulator built into Flash Builder:

image

Adobe has also announced Flash Builder 4.5 for PHP, in partnership with Zend. A great feature is that you can debug seamlessly from PHP code on the server to Flex code running in a Flash client, provided you are using Zend server.

The new Flash Builder products will ship within 30 days. The premium edition is part of the Creative Suite 5.5 bundle – an improvement over Creative Suite 5.0 which only bundled the Standard edition – or available separately, while Flash Builder for PHP is a separate purchase at $399 or €319 for Standard, and $799 or €629 for Premium.

I asked Adobe’s Adam Lehman, Flash Builder produce manager, how developers should decide between PhoneGap and AIR for Mobile, given that both are now in Creative Suite.

They’re coming from two different technical perspectives. If you’re going to come in with your HTML skills and try to build an application that way, PhoneGap is better than trying to go and learn ActionScript and Flex from scratch. But from a performance and functionality perspective we believe we’re offering a lot better solution with Flash Builder and Flex.

The other part of it is that our tooling is superior. The sort of workflow that we showed [Design and develop with round-tripping between Flash Catalyst and Flash Builder] isn’t going to be available on the PhoneGap side with our tooling. Dreamweaver might be able to support different layouts and things like that, but it is not going to be a full-fledged IDE. What you’re getting with the AIR runtime and the full tooling stack is far superior that if you were building the HTML-based PhoneGap app. You can always tell a PhoneGap app, you can tell that it is running in an embedded browser. There’s tons of inconsistencies between the devices because the browsers are very different. There’s a lot of advantages to going AIR where you know that the design is going to look exactly the same. But while we love Flash we’re not zealous about it to ignore the fact that you can build with these other technologies as well.

More information on Flash Builder 4.5 here.

adobe, apple, asus, flash, iphone, mobile, php, professional, software development, web authoring

Adobe announces Flash Builder for PHP, PhoneGap integration in Dreamweaver

Adobe has stepped up its support for mobile and Flash development with a couple of announcements today.
The first is that Dreamweaver 5.5, part of the new Creative Suite 5.5, has integrated support for PhoneGap. PhoneGap lets you build apps for Apple iOS and Google Android using HTML and JavaScript, taking advantage of the WebKit runtime that is present in these devices. The apps are packaged as native apps and also have access to some device-specific features. This does not mean Adobe is abandoning Flash, but is part of a both/and strategy, which makes sense to me.
Adobe has also announced Flash Builder 4.5 for PHP, in partnership with Zend. A great feature is that you can debug seamlessly from PHP code on the server to Flex code running in a Flash client, provided you are using Zend server.
Flex 4.5 compiles to AIR apps on Android, Blackberry and iOS, as well as desktop Mac, Windows and Linux.
The new Flash Builder products will ship within 30 days. The premium edition is part of the Creative Suite bundle or available separately, while Flash Builder for PHP is a separate purchase at $399 or €319 for Standard, and $799 or €629 for Premium.
More news on this and screenshots soon.

apple, mobile, professional, software development, web authoring

Fast JavaScript engine in Apple iOS 4.3 is in standalone Safari only, but why?

3 Comments

Now that Apple iOS 4.3 is generally available for iPhone and iPad, users have noticed something that seems curious. The fast new “Nitro” JavaScript engine only works in the standalone Safari browser, not when a web app is pinned to the home screen, or when a web view is embedded into an app.

This link at mobilexweb.com shows the evidence. Here is the SunSpider test standalone, showing a time of 4098ms, and pinned to the home screen as an app, where it shows 10391.9ms:

image image

The consequence: apps created using WebKit as a runtime, for example using PhoneGap, will not get the benefit of Nitro.

It would be easy to conclude that Apple is deliberately hobbling these apps in order to protect native apps, which can only be installed via Apple’s App Store and are subject to its 30% cut. However that might not be the case. It could be a bug – according to Hacker News it has been reported as such:

To add another note to this, its a bug that Apple seems to know about. I can’t link to it because its marked CONFIDENTIAL across the top of the dev forums, but in short its known about and being investigated.

or it could be a security feature. Using a just-in-time compiler exposes the operating system more than just interpreting the code; perhaps Safari has more protection when running standalone.

Either way, with the increasing interest in WebKit as a de facto cross-platform application runtime for mobile, this particular limitation is unfortunate.

Update: There are also reports of the HTML 5 offline cache not working other than in full Safari:

I’ve tested this by switching apple-mobile-web-app-capable from ‘yes’ to ‘no’ and offline cache works as expected. But whenever it’s switched back to ‘yes’, it’s not working anymore. This occurs when the app is standalone at home screen. As a website, viewed with Safari cache is working as expected.