Tag Archives: phonegap

adobe, design, development, flash, professional, software development

Flash developers fret as Adobe doubles down on PhoneGap

 

Adobe has announced Experience Manager Apps for Marketers and Developers. This comes in two flavours: Experience Manager Apps is for marketers, and PhoneGap Enterprise is for developers. The announcements are unfortunately sketchy when it comes to details, though Andre Charland’s post has a little more:

  • Better collaboration – With our new PhoneGap Enterprise app, developer team members and business colleagues can view the latest version of apps in production, development and staging

  • App editing capabilities – Non-developer colleagues can edit and improve the app experience using a simple drag-and-drop interface from the new Adobe Experience Manager apps; this way developers can focus on building new features, not on making updates.

  • Analytics & optimization – Teams can immediately start measuring app performance with Adobe Analytics; we’re also planning to incorporate functionality so teams can start A/B testing their way to higher app engagement and monetization using Adobe Target.

  • Push notifications – Engage your customers on-the-go with push notifications from Adobe Campaign

  • Support and training – PhoneGap Enterprise comes with SLA and support so customers can be rest assured that Adobe PhoneGap has their back.

Head over to the PhoneGap Enterprise site and you get nothing more than a “Get in touch” button.

image

Announcement-ware then. Still, enough to rile Flash and AIR (Adobe Integrated Runtime) developers who feel that Adobe is abandoning a better technology for app development. Despite the absence of the Flash runtime on Apple iOS, you can still build mobile apps by compiling the code with a native wrapper.

Adobe… this whole thread should make you realize what an awesome platform and die hard fans you have in AIR. Even after all that crap you pulled with screwing over Flex developers, mitigating Flash to just games, retreating it from the web, killing AS4 and god knows what else you’ve done to try to kill the community’s spirit. WE STILL WANT AIR!

says one frustrated developer.

Gary Paluk has also posted on the subject:

I have invested 13 years of my own development career in Adobe products and evangelized the technology over that time. Your users can see that there is a perfectly good technology that does more than the new HTML5 offerings and they are evidently frustrated that you are not supporting developers that do not understand why they are being forced to retrain to use inferior technologies.

Has Adobe in fact abandoned Flash and AIR? Not quite; but as this detailed roadmap shows, plans for a next-generation Flash player have been abandoned and Adobe is now focused on “web-based virtual machines,” meaning I guess JavaScript and other browser technologies:

Adobe will focus its future Flash Player development on top of the existing Flash Player architecture and virtual machine, and not on a completely new virtual machine and architecture (Flash Player "Next") as was previously planned. At the same time, Adobe plans to continue its next-generation virtual machine and language work as part of the larger web community doing such work on web-based virtual machines.

From my perspective, Adobe seemed to mostly lose interest in the developer community after its November 2011 shift to digital marketing, other than in an “apps for marketing” context. Its design tools on the other hand go from strength to strength, and the transition to subscription in the form of Creative Cloud has been brilliantly executed.

adobe, google, intel, open source, professional, software development, Web

Intel fights back against iOS with free tools for HTML5 cross-platform mobile development

3 Comments

Today at its Software Conference in Paris Intel presented its HTML5 development tools.

image

There are several components, starting with the XDK, a cross-platform development kit based on HTML5, CSS and JavaScript designed to be packaged as mobile apps using Cordova, the open source variant of PhoneGap.

There is an intriguing comment here:

The XDK is fully compatible with the PhoneGap HTML5 cross platform development project, providing many features that are missing from the open source project.

PhoneGap is Adobe’s commercial variant of Cordova. It looks as if Intel is doing its own implementation of features which are in PhoneGap but not Cordova, which might not please Adobe. Apparently code that Intel adds will be fed back into Cordova in due course.

Intel has its own JavaScript app framework, formerly called jqMobi and now called Intel’s App Framework. This is an open source framework hosted on Github.

There are also developer tools which run as an extension to Google Chrome, and a cloud-based build service which targets the following platforms:

  • Apple App Store
  • Google Play
  • Nook Store
  • Amazon Appstore for Android
  • Windows 8 Store
  • Windows Phone 8

And web applications:

  • Facebook
  • Intel AppUp
  • Chrome Store
  • Self-hosted

The build service lets you compile and deploy for these platforms without requiring a local install of the various mobile SDKs. It is free and according to Intel’s Thomas Zipplies there are no plans to charge in future. The build service is Intel’s own, and not related to Adobe’s PhoneGap Build, other than the fact that both share common source in Cordova. This also is unlikely to please Adobe.

You can start a new app in the browser, using a wizard.

image

Intel also has an iOS to HTML5 porting tool in beta, called the App Porter Tool. The aim is to convert Objective C to JavaScript automatically, and while the tool will not convert all the code successfully it should be able to port most of it, reducing the overall porting effort.

Given that the XDK supports Windows 8 modern apps and Windows Phone 8, this is also a route to porting from iOS to those platforms.

Why is Intel doing this, especially on a non-commercial basis? According to Zipplies, it is a reaction to “walled garden” development platforms, which while not specified must include Apple iOS and to some extent Google Android.

Note that both iOS and almost all Android devices run on ARM, so another way of looking at this is that Intel would rather have developers work on cross-platform apps than have them develop exclusively for ARM devices.

Zipplies also says that Intel can optimise the libraries in the XDK to improve performance on its processors.

You can access the HTML5 development tools here.

open source, professional, software development

Adobe Brackets: a different type of HTML and JavaScript code editor. Interview with Adobe’s Adam Lehman.

1 Comment

On Adobe’s Tools and Services page there is an intriguing remark about the company’s plans for a code editor. “We think there’s a need for a different type of code editor – we’re working on something and will have more to share soon.”

image

That something is Brackets, a code editor written in HTML and JavaScript (which means, as with all the best tools, that you can code Brackets in itself).

Advertisement

Although Brackets is written in HTML and JavaScript, it is not yet a web application. Instead, it runs on the desktop using Google’s Chromium Embedded Framework (CEF), which lets you embed the Chrome (strictly, the Chromium) browser engine in a desktop application. In the case of Brackets, the wrapper is lightweight, the intention being that in future Brackets may be fully browser-hosted. The consequence though is that currently you need Google Chrome installed and it only runs on Windows and Mac.

The project is open source under the MIT license; anyone can grab the code from Github. Brackets also depends on another open source project, CodeMirror, which is a JavaScript editor component for browsers. I installed it on Windows and soon had it up and running. Note that you should pull brackets_app if you want to run it, as this brings down the Brackets code as well.

image

I spoke to Brackets Product Manager Adam Lehman. “This might be the first project we started with the intent of being open source from day one,” he said.

“Our general intent is that we wanted to provide an editor that web developers felt that they could own. In the past we might have built something in Eclipse, and there would have been this giant gap between the person who knew HTML, JavaScript and CSS, and then having to write a Java-based Eclipse plug-in to extend the editor.

“When we start talking to developers, they’re going back to just text editors, things that don’t do much more than edit and manage a document, and as complex as HTML and JavaScript apps are getting these days, it seemed crazy that our tools weren’t keeping up with us. So the idea was to start this project, add a little bit of our own ideas, and have the community supply their own ideas.”

But how does Adobe intend to use Brackets in its own products, and what is the business model?

“We believe there are two spaces for the editor market. There is the larger IDE, but there’s also these lightweight text editors. We’re finding that the traditional JavaScript and HTML developer, CSS developer, was heading towards the lightweight text editor and not towards the larger IDE. We don’t see Dreamweaver and Brackets as direct competitors because they service two different tastes. It wasn’t a matter of could we add a feature here or there that was going to get people to use Dreamweaver. It was that difference between our larger tool and a much lighter weight tool. That’s where Brackets come in.”

How then will Brackets tie in with other Adobe products?

“That’s the key for Brackets. We wanted to see if we could innovate in the space and we also wanted to have a common language that we could start targeting. When you say, I want to open up an editor from Adobe Edge and start coding, we needed to define what that editor would be, so Brackets would come into that.

“We’re also saying we need to do better tooling around PhoneGap. A lot of people are fine with the command line, but we want to take a step beyond that and so Brackets is the obvious place where we’ll start to build an extension where we can tie into PhoneGap Build, or extensions around the PhoneGap APIs.

“We’ve got a lot of ideas around using Brackets to bring a lot of our HTML efforts together, not only our core HTML products but also a lot of the W3C and WebKit work that we’re doing. Brackets is a great place to put tooling, that isn’t quite ready for mass consumption yet, but we could actually build extensions for something like Shaders where those people who are interested in it can get in and start playing around with it.

“The beauty of building on the web platform is that we can go wherever the web platform goes.”

Initial prototypes of Brackets ran entirely in the browser, which would be interesting for future versions of Adobe’s Creative Cloud as well as other scenarios, but Lehman said this got mixed reactions.

“While we believe that the future of development is heading towards the cloud, and the general consensus from developers is the same, we also heard that it is not ready yet. We decided to focus on a desktop version first, with the idea that towards the end of this year or beginning of next year we’ll start to supplement with other targets, whether it be in the cloud or  a tablet, or embedded in a tool like Edge,”

says Lehman. He adds that a browser-hosted Brackets could end up integrated with the PhoneGap Build site. PhoneGap Build is a service for compiling cross-platform HTML and JavaScript into mobile apps for a variety of devices.

Since Brackets is built on Google’s Chrome/Chromium platform, what are the implications for cross-browser compatibility?

“There’s two pieces to it. There’s our container that Brackets runs in, and that is running on Chromium.

“The other part is that we have this live preview system which is tied directly to Chrome on the desktop. We happened to just start with Chrome, mostly because there is a remote debugging API that’s pretty fleshed out there.

“With Firefox and Internet Explorer, it’s a little bit different. We talked to Mozilla and they’re just now starting to work on that remote debugging API and trying to get it inline with where Chrome is, so we’re expecting to hear from them in August that they actually might have an API where we can start to build that same functionality, which is our intent.

“We’ve already started engaging with Microsoft about Internet Explorer. Right now their remote debugging API is somewhat private and in the form of a COM object which is not ideal coming from a JavaScript perspective, but we’ve showed them what we’re after, and we’ve started discussion of what a remote API from IE might look like that didn’t require COM. We’re exploring those options. Those are our priorities right now.

“If we build a cloud-based version then it’s going to be a question of what browsers this is going to run in. Our intent is to run in the modern major browsers. We aren’t building anything that’s Chrome-specific, we’re doing our best to stay as browser-agnostic as we can, but we are likely to require a more modern browser. We feel it would be OK to require the latest versions of Firefox, IE or Chrome.”

I asked Lehman whether Brackets might be useful for server-side as as client-side code. He said that Brackets is focused on the client, though a community extension is under way for node.js. He adds that since Brackets is fully extendable, others may do plug-ins for languages such as PHP.

Why is Brackets at Github and not Apache?

“We have a lot of people at Adobe who work for Apache now, and we talked to them before we released Brackets. Our sense is that Apache might be too much of a turn-off for the individual contributor, who just wants to hack and fix a bug and submit it back,”

Lehman told me. Although there are external contributors, all the committers are currently at Adobe, though there are plans for adding external committers by the end of the year. “We don’t want this to be 100% Adobe controlled.”

When will Brackets get to version 1.0?

“We’re being as agile as we can. Every bit we add, it comes closer to being a 1.0 for somebody. The things that I think are missing that you would expect out of a core editor are around code-completion for CSS and JavaScript, and solid and advanced search and replace. In the web world, that’s how we refactor code. We’re hoping to drive those in by November time. But we are on 2.5 week sprints and things change rapidly.”

I also asked about plans for a mobile app version of Brackets. Lehman says that is planned for next year, though the community is working on getting a Linux version working and support for ChromeOS.

Brackets is a fascinating project on several levels. What stands out is how far Adobe has moved from being the Flash company. A few years back Adobe came up with a system for having Flash applications run on the desktop and on mobile devices: Adobe AIR. It also invested in Eclipse and came up with the Flash Builder IDE.

Now here is Adobe with an open source project for a desktop application built from HTML, JavaScript, and a third-party open source browser engine; and in place of mobile AIR it has PhoneGap.

It is a big change, most of which has become publicly known in less than a year, signalled by the repositioning of Flash and AIR versus HTML in September 2011, and the abandonment of Flash for Mobile in November 2011.

As for Brackets itself, it is well worth a look though probably not a tool you want to use for real work just yet. In a few months though, that may well change.

Postscript: Brackets reminds me of another Adobe, or rather Macromedia, HTML code editor. That was HomeSite, an excellent text-based tool that Adobe discontinued in 2009; active development ceased years before that.

adobe, mobile, software development

PhoneGap 2.0 released with WebView, Windows Phone support

Adobe has released PhoneGap 2.0, its framework for creating cross-platform mobile apps using HTML and JavaScript. Using PhoneGap, you can wrap a web application as a native app, taking advantage of the browser control available in all the major mobile platforms.

New features in PhoneGap 2.0 include Windows Phone support, WebView which lets you embed a PhoneGap fragment into a larger native application, improved tooling and a unified JavaScript API across all platforms called Cordova-JS.

The Mac tooling has been improved and no longer depends on Xcode templates. Instead, you create a new project at the command line. However, you do need Lion or Mountain Lion to use PhoneGap.

The associated Apache Cordova project is “nearing graduation from incubation”, according to Adobe’s release.

image

adobe, mobile

Adobe Dreamweaver CS6, PhoneGap Build, and HTML5 app tooling

1 Comment

I am looking forward to trying out Adobe’s new Creative Suite 6 but have not yet got my hands on it. However one thing I am watching with interest is the work Adobe is doing to integrate PhoneGap developing into the suite, in particular in Dreamweaver.

PhoneGap lets you build native mobile apps for several mobile platforms using HTML and JavaScript, by embedding the browser engine on the device.

There was PhoneGap support in Dreamweaver CS 5.5, but it was curiously broken. It always makes a debug build for Android, for example, and it does not offer enough control of the build settings to be useful. Dreamweaver CS 5.5 is useful for designing a PhoneGap app, but you need to use the command line or Eclipse-based tools to finish it off.

The big new is that Adobe has integrated Dreamweaver CS 6 with PhoneGap Build, a cloud service where you upload your source files and download the resulting build. There are details of the new integration here. You can build for iOS, Android, BlackBerry, webOS and Symbian. A nice touch is that you can use a QR code to download the app to a connected mobile device.

There are a few puzzles though.

1. The Help says:

You cannot use PhoneGap Build and Dreamweaver without a PhoneGap Build service account. Accounts are free and easy to set up.

They are free to set up, but not to use:

image

Do Creative Cloud subscribers get some use of the service included? I am finding out and will report.

2. Build is a great service and lets you support platforms without having to install the SDK; but compiling locally has advantages too. It seems that local builds are no longer supported. Here is the relevant part of the Dreamweaver CS 5.5 Site menu:

image

and here it is in Dreamweaver CS 6 (from a video):

image

This is confirmed by David Powers, who has an excellent overview of what is new in Dreamweaver CS6 and writes:

The way that Dreamweaver CS6 supports building native apps for iOS, Android, and other mobile operating systems using HTML, CSS, JavaScript, and the PhoneGap framework has changed completely. It no longer installs the Android software development kit (SDK) and emulator. Nor can the Mac version hook directly into Xcode and the iOS simulator. Instead, there’s a new panel that uploads your files to PhoneGap Build, an online service that automatically packages applications for iOS, Android, webOS, Symbian, and BlackBerry. Using PhoneGap Build is much easier than working with a simulator, because the Dreamweaver panel displays a QR code that lets you load the app directly onto your testing device. However, you need to build the configuration file manually in XML, and there’s no longer any code hinting in Dreamweaver for PhoneGap plugins. So, although the integration of PhoneGap Build is a definite improvement, it feels as though the engineering team didn’t have time to polish some important details.

3. PhoneGap Build in Dreamweaver CS 6 supports 5 mobile platforms:

image

but the PhoneGap team has also announced support for Windows Phone 7

I would expect that Windows Phone 7 support will be added to Dreamweaver CS6.

4. Adobe had a change of heart with respect to supporting Build in Dreamweaver CS 5.5. This was released as an extension at the end March, then pulled a few days later:

Adobe regrets to inform the Dreamweaver Community that the PhoneGap Build extension for Dreamweaver CS5.5 (released last week) is no longer available for download. For a number of reasons, we have had to pull the extension from public availability.

The functionality of the extension, which integrates PhoneGap Build with Dreamweaver, will be available in the upcoming version of Dreamweaver CS6.

A shame, since PhoneGap support in Dreamweaver CS 5.5 does not work properly and fixing this for existing users would have been nice.

5. Finally, while PhoneGap support in Dreamweaver is welcome, Dreamweaver is primarily a web design tool and not ideal for app development. It seems Adobe shares this view:

Code

We think there’s a need for a different type of code editor – we’re working on something and will have more to share soon.

Adobe has the resources to come up with something great for HTML5 and JavaScript developers – here is hoping that it does.

mobile, open source, software development, web authoring

Appcelerator Titanium gets Mobile Web SDK, cloud services

Appcelerator’s Titanium cross-platform development framework has moved up a gear with the announcement of two new features:

  • A set of cloud services, based on those acquired with Cocoafish in February this year. These are now known as Appcelerator Cloud Services (ACS).
  • Support for mobile web applications as well as native

These features are integrated into the Titanium development environment, an Eclipse-based IDE which has evolved from Aptana, a JavaScript tool acquired in early 2011. Start a new project, and ACS support is included by default.

image

The cloud services are hosted on Amazon and comprise the following:

  • Push Notifications
  • User management
  • Photo manipulation and storage
  • Places (rich location storage)
  • Social integration
  • File Storage
  • Check-ins
  • Status updates
  • Chats
  • Friend connections
  • Ratings and Reviews
  • Discussion forums
  • Event planning
  • Messaging
  • Key-Value data storage

“We have a portfolio of additional services rolling out over the next several quarters,” said Jo Ann Buckner, VP of Product Management. There are code examples here. A limited usage of the services is available free, after which it is pay as you go. It is a REST API that you can use from any platform; use of Titanium is not essential.

The other big feature is the Mobile Web SDK. Why is Appcelerator doing this given that it has been pushing native code apps as the way forward for mobile deployment?

“Two reasons,” says Buckner. “The debate has been going on for a long time, is it native, or web? Our position is that it native and mobile web are complementary. We have customers building native apps with Titanium that also want to have a mobile web presence, even for iOS and Android. Some customers will just interact with a mobile web site and never download the application.

“The second is reach beyond iOS and Android.”

Does that mean Appcelerator will not support other platforms such as Blackberry or Windows Phone with its native approach? “This is not a replacement for those efforts. We are investing in support for additional platforms,” says Buckner.

There are differences of course between what you can do in a native app, and what you can do in a web app, and these differences vary according to the target browser. Titanium allows you to write platform-specific code in order to workaround these problems, or to vary the user interface to suit the device. The illustration below shows the new Titanium IDE with an app which targets both Android and the Mobile Web, and you can see the folders on the left which separate common code and platform-specific code (click the image to enlarge).

image

Titanium installs its own web server for testing. Here is an example running in the Android emulator, served from Titanium.

image

When should you do a native app and when a mobile web app? “You’re going to build more than one application,” says Mike King, Appcelerator’s Principal Mobile Strategist. “If you are doing an augmented reality application the native interaction is going to require that to be a native application. You can do a forms-based application as well, and mobile web is going to be a better fit for that. Different use cases require different architectures.”

But why do your mobile web apps in Titanium, when you could use pure HTML 5 tools instead? “It’s about one platform for all of your development requirements, as opposed to one for native and one for HTML 5,” says King.

Titanium is certainly evolving with impressive speed. The latest 2.0.1 IDE is a rich tool, and pop-up help guides you concerning supported platforms for each keyword.

image

Another strong point is the way you can easily write conditional code for tablet form-factors.

The comparison with Adobe PhoneGap is interesting. PhoneGap takes a different approach, supporting native apps but by means of the embedded browser in each device, rather than by building a native user interface. Titanium’s new mobile web support is different in that it runs as a web app in the browser, not as a native app with an embedded browser.

apple, mobile

Apple breaks web storage in iOS 5.1, does not care about web apps?

12 Comments

Many iOS apps which rely on web storage APIs for persistent data have been broken by the recent upgrade to iOS 5.1. The issue affects apps built with PhoneGap or others which use WebKit APIs to store data. The affect for users is that they lose all their data after the upgrade. For example, it sounds like the issue has hit this app:

image

Another developer says:

My statistics show users abandoning ship as their settings are wiped over and over, after each app restart.
This is a critical error that must be patched as soon as possible. Remember there’s also a delay from Apples app approval process to consider.

Put more precisely, WebKit used to store its local databases in Library/WebKit which is a location that the OS regards as persistent and which is backed up to iCloud. In iOS 5.1 this data is stored in Library/Caches which means it is regarded as temporary and likely to be deleted. The W3C Candidate Recommendation says of localStorage:

User agents should expire data from the local storage areas only for security reasons or when requested to do so by the user.

An embedded browser is not quite the same as a web browser though, and if you are using SQLite in Webkit then that falls outside the W3C HTML 5 API since Web SQL is no longer included.

The issue is complicated in that there also seems to be a bug, described here, which causes data to be lost after upgrading an app to a newer version; and there are problems with actual web apps as well as with apps that use an embedded UIWebView.

PhoneGap is fixable in that it can call native APIs and there is work going on to implement this. The danger is that more platform-specific code undermines the cross-platform benefits.

Discussions on the Apple developer forums during the beta period for 1OS 5.1 show that Apple was aware of the issue and that it is by design. The impression given is that Apple was annoyed by the number of apps using web storage to speed up their apps (whether web or native) rather than just storing customer-created content, and felt it was imposing too much burden on the constrained storage space in an iOS device.

It does not help that there is no way to increase the storage in an iPad or iPhone other than by replacing it with a newer one with more memory.

The problem is a real one, but you cannot escape the impression that Apple considers solutions like PhoneGap, or even web apps that behave like local apps, as a kind of workaround or hack that is to be discouraged in favour of apps written entirely with the iOS SDK.

Apple benefits from true native apps as they are more likely to be exclusive to its platform, and must be sold through the App Store with a fee to Apple.

The official Data Storage Guidelines for iOS are here.

adobe, mobile, professional, software development

PhoneGap is Adobe, Cordova is Apache

The hot cross-platform mobile toolkit PhoneGap was created by Nitobi, a company acquired by Adobe last year. Almost at the same time, the project was submitted to Apache as an open source project. However, the Apache project is not called PhoneGap; it was briefly known as Callback and is now called Cordova (the name of the street in Vancouver where Nitobi was based).

A new official log post explains why PhoneGap was renamed at Apache, but also makes the point that the PhoneGap brand will continue.

PhoneGap is a distribution of Apache Cordova. You can think of Apache Cordova as the engine that powers PhoneGap, similar to how WebKit is the engine that powers Chrome or Safari. (Browser geeks, please allow me the affordance of this analogy and I’ll buy you a beer later.)

Over time, the PhoneGap distribution may contain additional tools that tie into other Adobe services, which would not be appropriate for an Apache project. For example, PhoneGap Build and Adobe Shadow together make a whole lot of strategic sense. PhoneGap will always remain free, open source software and will always be a free distribution of Apache Cordova.

Read it carefully, because it is still potentially confusing. Note that PhoneGap “will always remain free, open source software” though it may gain hooks into commercial Adobe tools. At least, that is how I read it.

I would also expect that Adobe will come up with design and development tools for which PhoneGap (or Cordova) is invisible to the user. You will just be able to build for multiple platforms.

The post adds:

Currently, the only difference is in the name of the download package and will remain so for some time.

I will add that there is great brand-awareness of PhoneGap and what it is, and little for Cordova, so if you want to be understood talk about PhoneGap.

adobe, mobile, open source, professional, software development

Adobe acquires PhoneGap company Nitobi

1 Comment

Adobe has announced the acquisition of Nitobi, the company which created and sponsors the open source PhoneGap project for creating cross-platform mobile applications using HTML5 technology.

Apparently this does not affect the plan to donate PhoneGap to the Apache Software Foundation:

We are also excited to announce our donation of the PhoneGap code to the Apache Software Foundation,” said Dave Johnson, chief technology officer, Nitobi. “Adobe has been fully supportive of our decision.

Adobe already offers PhoneGap integration in Dreamweaver 5.5, though I found some gaps in this initial release.

I spoke to Nitobi CEO André Charland earlier this year.

Smart move, though it will be interesting to see how Adobe now balances mobile app development with PhoneGap vs mobile app development with Flash – both of which are cross-platform approaches.

Here at Adobe’s MAX conference in Los Angeles I will be quizzing Adobe about how it plans to evolve its design and development tools to better support PhoneGap.

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

PhoneGap likely to move to Apache Software Foundation

Nitobi’s Brian LeRoux, who works on PhoneGap, has announced the start of a process to move the project to the Apache Software Foundation:

We have initialized the process to contribute PhoneGap to the Apache Software Foundation (ASF). The process is straightforward beginning w/ a submission of a proposal to the ASF that describes the move in detail. We’ve been looking at different options for a foundation contribution since the beginning. Now is the time. PhoneGap is hugely adopted and the IP belongs in an org aligned w/ our goals, philosophy and the web. It will remain free software, licensed as it always has been: Apache/BSD/MIT.

Apparently the name may change thanks to a trademark dispute.

PhoneGap seems to have plenty of momentum and is turning up in a variety of tools, including Adobe DreamWeaver and Embarcadero RAD PHP XE2, to mention two I am aware of.