Category Archives: software development

Adobe Edge previewed: another step towards HTML 5

Adobe has released a preview of Edge, a new tool for creating animations in HTML 5, JavaScript and CSS3.

Edge is interesting on two levels. First, HTML 5 lacks strong design tools so a new tool from Adobe is welcome. Edge is a timeline-based tool for creating animations. You import elements such as images, or create text and graphic elements in the tool. Using the timeline, you create keyframes and specify effects. Here is the designer:

image

and you can view the output right here. This is one of Adobe’s samples, created by Sarah Hunt.

image

Under the covers Edge uses the JQuery JavaScript library. Here are the includes for this example:

image

and here are the transition effects on offer:

image

Edge is not complete yet.  A future update will add a JavaScript editor, making this more interesting for application developers. There will be a documented Edge library that will let you customise and I presume interact with the Edge output. One of the possibilities that interests me is data visualisation. Will Edge support this? Adobe is not yet saying, but it would be a natural move.

Adobe already has an HTML design tool, Dreamweaver. Why another one? Or put another way, why is Edge not a new designer for Dreamweaver rather than a new product in its own right?

This is an early preview, and all things are possible. However, Adobe has a tricky positioning task, given that Edge is encroaching on territory that used to belong to Flash, timeline-based animation. In its FAQ [PDF], Adobe distinguishes its products like this:

Product Sample use cases
Adobe Edge Preview 1 Advertising, simple animations and motion design for new compositions or using existing CSS-based page layouts
Adobe Dreamweaver Websites and web applications for desktops, smartphones, and other devices
Adobe Flash Professional Immersive interactive experiences, mobile applications, gaming, premium video, advertising
Adobe Flash Builder Rich Internet Applications (RIAs) and mobile applications

This table fails to mention what must be part of the core rationale for Edge, which is working on Apple iOS, the mobile operating system for iPhone and iPad that does not run Flash content. If you view the demo page above on the iPhone 4 or iPad 2, you will find that it works fine.

Adobe’s distinctions in the table above are not particularly clear. Leaving aside the relative merits of Flash and HTML 5 as technologies, a key question for developers and designers is one of reach. HTML 5 has a reach that extends to iOS and to other devices that do not run Flash in the browser. Flash has a reach that replaces browser-dependency with dependency on Adobe’s runtime, which can be a good thing.

Incidentally, I asked Adobe during a press briefing about mobile support and also browser requirements for Edge content, but there is no official statement on this yet.

Is Adobe moving away from Flash towards standards-based HTML tools? The purpose of a table like the one above is to insist that this is not the case and that Adobe will continue to support both. Nevertheless, Edge is a significant move. A gradual decline in Flash usage in favour of HTML 5 is not necessarily bad for Adobe. Designers will use the same Adobe tools to create content for Edge as they do for Flash.

What about Wallaby, another Adobe experimental project which exports Flash content to HTML, in effect making Flash Professional an HTML 5 authoring tool? Adobe says that Wallaby and Edge are separate projects and there is no plan to have Edge import Wallaby content. Still, you would have thought that, if Wallaby makes it into an official product, some compatibility is inevitable.

image

Edge demo on Apple iPhone 4

GPU Programming for .NET: Tidepowerd’s GPU.NET gets some improvements, more needed

When I attended the 2010 GPU programming conference hosted by NVIDIA I encounted Tidepowerd, which has a .NET library called GPU.NET for GPU programming.

GPU programming enables amazing performance improvements for certain types of code. Most GPU programming is done in C/C++, but Typepowerd lets you run code in .NET, simply marking any methods you want to run on the GPU with a [kernel] attribute:

[Kernel]

private static void AddGpu(float[] a, float[] b, float[] c)

{

// Get the thread id and total number of threads

int ThreadId = BlockDimension.X * BlockIndex.X + ThreadIndex.X;

int TotalThreads = BlockDimension.X * GridDimension.X;

for (int ElementIndex = ThreadId; ElementIndex < a.Length; ElementIndex += TotalThreads)

{

c[ElementIndex] = a[ElementIndex] + b[ElementIndex];

}

}

GPU.NET is now at version 2.0 and includes Visual Studio Error List and IntelliSense support. This is useful, since some C# code will not run on the GPU. Strings, for example, are not supported. Take a look at this article which lists .NET OpCodes that do not work in GPU.NET.

GPU.NET requires an NVIDIA GPU with CUDA support and a CUDA 3.0 driver. It can run on Mac and Linux using Mono, the open source implementation of .NET. In principle, GPU.NET could also work with AMD GPUs or others via a vendor-specific runtime:

image

but the latest FAQ says:

Support for AMD devices is currently under development, and support for other hardware architectures will follow shortly.

Another limitation is support for multiple GPUs. If you want to do serious supercomputing relatively cheaply, stuffing a PC with a bunch of Tesla GPUs is a great way to do it, but currently GPU.NET only used one GPU per active thread as far as I can tell from this note:

The GPU.NET runtime includes a work-scheduling system which can distribute device method (“kernel”) calls to multiple GPUs in the system; at this time, this only works for applications which call device-based methods from multiple host threads using multiple CPU cores. In a future release, GPU.NET will be able to use multiple GPUs to execute a single method call.

I doubt that GPU.NET or other .NET libraries will ever compete with C/C++ for performance, but ease of use and productivity count for a lot too. Potentially GPU.NET could bring GPU programming to the broad range of .NET developers.

It is also worth checking out hoopoe’s CUDA.NET and OpenCL.NET which are free libraries. I have not done a detailed comparison but would be interested to hear from others who have.

Microsoft releases Visual Studio LightSwitch: a fascinating product with an uncertain future

Microsoft has released Visual Studio LightSwitch, a rapid application builder for data-centric applications.

image

LightSwitch builds Silverlight applications, which may seem strange bearing in mind that the future of Silverlight has been hotly debated since its lack of emphasis at the 2010 Professional Developers Conference. The explanation is either that Silverlight – or some close variant of Silverlight – has a more important future role than has yet been revealed; or that the developer division invented LightSwitch before Microsoft’s strategy shifted.

Either way, note that LightSwitch is a model-driven tool that is inherently well-suited to modification for different output types. If LightSwitch survives to version two, it would not surprise me to see other application targets appear. HTML 5 would make sense, as would Windows Phone.

So LightSwitch generates Silverlight applications, but they do not run on Windows Phone 7 which has Silverlight as its development platform? That is correct, and yes it does seem odd. I will give you the official line on this, which is that LightSwitch is not aimed primarily at developers, but is for business users who run Windows and who want a quick and easy way to build database applications. They will not care or even, supposedly, realise that they are building Silverlight apps.

I do not believe this is the whole story. It seems to me that either LightSwitch is a historical accident that will soon be quietly forgotten; or it is version one of a strategic product that will build multi-tier database applications, where the server is either Azure or on-premise, and the client any Windows device from phone to PC. Silverlight is ideal for this, with its modern presentation language (XAML), its sandboxed security, and its easy deployment. This last point is critical as we move into the app store era.

LightSwitch could be strategic then, or it could be a Microsoft muddle, since the official marketing line is unconvincing. I have spent considerable time with the beta and doubt that the supposed target market will get on with it well. Developers will also have a challenge, since the documentation is, apparently deliberately, incomplete when it comes to writing code. There is no complete reference, just lots of how-to examples that might or might not cover what you wish to achieve.

Nevertheless, there are flashes of brilliance in LightSwitch and I hope, perhaps vainly, that it does not get crushed under Microsoft’s HTML 5 steamroller. I set out some of its interesting features in a post nearly a year ago.

Put aside for a moment concerns about Silverlight and about Microsoft’s marketing strategy. The truth is that Microsoft is doing innovative work with database tools, not only in LightSwitch with its model-driven development but also in the SQL Server database projects and “Juneau” tools coming up for “Denali”, SQL Server 2011, which I covered briefly elsewhere. LightSwitch deserves a close look, even it is not clear yet why you would want actually to use it.

image

Living in an App Store world: what are the implications?

A few recent events prompt some reflections on the rise of app stores and the implications for developers and for the IT industry.

One is Apple’s OS X Lion release, available only through the Mac App Store; and the removal of the optical drive on the Mac Mini, making it hard to install shrink-wrap software.

Another is Adobe’s closure of its InMarket service and AIR Marketplace app store. Some app stores are doing better than others.

A third is TechCrunch reporting that book apps such as Nook and Kindle are being hobbled or removed from the Apple iOS store. While I cannot verify this at the moment – I still see the Kindle app in the store, and it still has a link to the Kindle web store – it is in tune with Apple’s announcement in February:

… publishers may no longer provide links in their apps (to a web site, for example) which allow the customer to purchase content or subscriptions outside of the app.

Enforcing this on an app such as Kindle promotes Apple’s own iBooks app and store.

There are lots of app stores out there, though one fewer with the forthcoming closure of AIR Marketplace, but how many of them matter? Here is my pick of the top three:

  • Apple iOS and Mac App Store – arguably two different stores, but since you access them with the same account I bracket them together.
  • Google Android Market – not a lock-in like Apple’s store, but still the primary store for Android.
  • Windows vNext marketplace – how this will work is not yet public, but the existence of a new app store in Windows 8 is widely rumoured and might be expected to tie in with what is already in place for Windows Phone 7.

Perhaps I am overstating the importance of the Windows 8 marketplace, given the failure of the Windows Vista marketplace, but given that Apple has now shown the way I find it hard to see how Microsoft can fail with this one.

Note that an app store is not just a marketing ploy. It is a software deployment and update tool.

App Stores score well in terms of usability. Another advantage is that users have a centralised mechanism for software updates, managed by the operating system. That is good for security, because it is unlikely to be disabled, and good for usability as it should mean fewer third-party updaters like those from Adobe, Oracle Java, Symantec and others.

App Stores typically enforce certain conditions on developers. In essence they must be well-behaved. For examples, the Mac App Store prohibits apps that request escalation to root privileges. Apple also rejects apps that use “deprecated or optionally installed technologies”, including specifically Java and by implication Adobe Flash or other runtimes.

This is great for security. In principle, if you decide that you will only install apps from the App Store, you can be confident that all your apps are well-behaved. On the Mac this is interesting; on Windows it would be a revolution.

What are the business implications though?

  • First, it is a significant source of new revenue for the operating system vendor. It gets a cut of everything.
  • Second, it gives tremendous empowerment to user ratings and reviews. On iOS or Android, if you want an app, you automatically search the app store and take note of factors such as user ratings and popularity. Most of us can figure that if there are few ratings or reviews, the app is not popular.

If you are a software company, getting high ratings and good reviews on app stores is now a key challenge, even more so than it is already with the likes of Amazon.

  • Speaking of Amazon, the third point is that app stores will not be welcomed by software resellers. They are simply being bypassed. Amazon is addressing this with its own App Store for Android; but can it really win against the official Google Android Market? Its MP3 store is better value than Apple’s iTunes, but has smaller market share.

Amazon has other business to fall back on, but specialist software resellers will be watching the growth of app stores nervously. Apple resellers in general are already hurting and diversifying, thanks in part to Apple bypassing them with releases like OS X Lion.

The app store revolution is good for users in many ways, especially as prices seem to end up lower than before, but there are worrying aspects. In particular, the ability of the operating system vendor to tilt the store in its own favour is a concern, and we will hear more complaints about that.

Finally, it is interesting to speculate how this may impact enterprise software deployment. Will Microsoft aim to link its forthcoming Windows app store to other deployment mechanisms such as System Center Configuration Manager? What about volume licensing sales, will resellers be able to keep hold of those? Maybe we will learn more of Microsoft’s story on this at the Build conference in September.

Adobe closes AIR Marketplace, InMarket

Adobe is giving up its efforts to support developers deploying to multiple app stores. The idea of InMarket,  announced at the Adobe MAX Conference in October 2010, was to be a one-stop distribution point for developers seeking to target multiple platforms. Adobe handled distribution and billing. The reason given:

After reviewing our efforts and based on feedback from developers, we have decided that we will deliver the most value by helping developers author and publish their apps on multiple platforms. Given this focus, we have decided to discontinue development and support of Adobe InMarket. We are going to continue to provide support for publishing to different app stores through our tooling. The recent Flash Builder 4.5 and Flash Professional CS5.5 provide support for publishing to multiple mobile platforms including Android and Apple iOS devices.

Adobe is not giving developers much time to adjust. The InMarket URL will terminate on August 31. This is causing some consternation:

I don’t understand how you expect publishers will be able to push an update to all the markets they publish to with enough time to get their user base to update before they’re totally screwed. One month? You do realize that even updates pushed to AppUp can take up to 2-weeks for vetting? This is crazy

That said, the low traffic on the InMarket forum is a clue to what Adobe is closing it down.

InMarket only supported Intel AppUp and AIR Marketplace, which rather misses the point of targeting multiple platforms. Had Adobe been able to offer instant deployment to all the key app stores, including Android Market and Apple’s iOS App Store, it would have been more attractive. Given the complexities of the approval process, it is not surprising that this was hard to achieve. A further complication is that Adobe’s AIR runtime is not allowed on iOS. Apps for iOS have to be packaged as native iOS apps.

What about AIR Marketplace?

When we established Adobe AIR Marketplace three years ago, there were few distribution opportunities for AIR developers. There are now several app stores on desktops, mobile devices and tablets that service AIR developers including Apple App Store, Android Market, BlackBerry App World, Intel AppUp center, Samsung Apps, and Toshiba App Place. We encourage you to use these newer popular app stores to distribute your applications.

This of course describes describes exactly the problem that InMarket was meant to address: the challenge of maintaining support for multiple app stores.

AIR Marketplace is still up and running at the time of writing, and seems to have more life than InMarket:

image

That said, why would any potential customer look specifically for AIR applications? It is a runtime and ideally should be invisible to the user. I was interested to see reference to AIR packagers for Windows, Mac and Android in a recent announcement, suggesting to me that Adobe is de-emphasising AIR as a runtime and making it into something more like a cross-platform development tool.

The strategy behind Mono has shifted: ten years of open source .NET

Yesterday, SUSE and Xamarin announced, in effect, the transfer of all things Mono to Xamarin.

The agreement grants Xamarin a broad, perpetual license to all intellectual property covering Mono, MonoTouch, Mono for Android and Mono Tools for Visual Studio. Xamarin will also provide technical support to SUSE customers using Mono-based products, and assume stewardship of the Mono open source community project.

Xamarin is a startup formed by Mono founder Miguel de Icaza following the acquisition of Novell and SUSE by Attachmate, which ceased Mono development.

Attachmate acquired Novell in November 2010. Mono has been plucked from the abyss with impressive speed.

That said, the strategy behind Mono has shifted. Mono exists because de Icaza liked what Microsoft announced back in 2000 when it introduced C# and the .NET Framework. Microsoft made a show of standardizing the .NET CLI (Common Language Infrastructure), which made PR sense at the time since there was controversy over Sun’s ownership of Java, though nobody really believed that Microsoft knew how to steward an open source development platform or indeed believed that it was really serious about it. History largely justifies that scepticism; but de Icaza called Microsoft’s bluff and forged ahead with Mono, implementing not only the CLI and C# but most of the .NET Framework as well.

The goal of Mono, as I recall, was to bring the benefits of C# and .NET to Linux developers, and to enable developers to move applications freely between Windows and Linux. Apple OS X was also on the radar, though it took longer to become much use. Recalling Mono’s early days, de Icaza said:

Mono to me is a means to an end: a technology to help Linux succeed on the desktop.

Mono worked remarkably well from quite early on, but never quite well enough to persuade mainstream developers it was a sensible choice for applications that would otherwise have run on Windows. It did emerge as a viable and productive toolset and platform for Linux and a number of Mono applications became popular, including Beagle search, Tomboy notes, and F-Spot photo management. Some ASP.NET applications run on Mono; I have one on this site. Another Mono success was its use as the scripting engine in Unity, a game development platform.

A big problem for Mono though was the lack of a business model. There was support and servicing of course, which must have generated some revenue for Novell, but most Mono use is free. Novell possibly had in mind that Mono could be significant as an application server, but it has never become a really trusted platform in the Enterprise. For example, as Alan Radding (Dancing Dinosaur) notes:

DancingDinosaur has not found any SUSE on z user that has successfully implemented .NET apps on the mainframe. A few have tried but reported that Mono on z wasn’t ready for prime time.

Even among the free software and open source community, Mono was hampered by suspicion of Microsoft. If Mono became successful enough to threaten Microsoft, would lawyers appear? Given the way Microsoft is currently behaving with Android, filing legal actions and signing up licensees, those fears might not be unwarranted.

So what is Mono today? The answer is that Mono is now primarily a mobile platform. The Xamarin home page makes this clear, as well as making it apparent that the Mono team has discovered the value of a business model:

image

Xamarin is tapping into two real business needs. One is the need for a cross-platform mobile development platform that works. The second is a way for Windows developers to use their existing C# skills for mobile development, given that they might not be happy with the tiny market share currently achieved by Windows Phone 7.

When I had a quick try with Monotouch I was impressed, and I would like to spend some more time with it and with Mono for Android.

Mono has touch competition though. In particular, PhoneGap, Appcelerator’s Titanium, and Adobe AIR. I was interested to see that Adobe is coming up with a packager for AIR on Android, which may significantly improve it as a cross-platform mobile toolkit.

Still, Xamarin is small and nimble and I expect it to succeed. It has also has Visual Studio integration, which is an advantage. One of the pieces Xamarin has now licensed from SUSE is Mono for Visual Studio.

The downside of these latest developments is that if you depend on Mono for the desktop or for ASP.NET, you may find these parts of the Mono project getting little attention from the new company. But Mobile is all that matters now, right?

I write this on July 19 2011. According to Wikipedia:

Recognizing that their small team could not expect to build and support a full product, they launched the Mono open source project, on July 19, 2001 at the O’Reilly conference.

Well, if there was a launch there it was low-key. It is not mentioned in this report. But de Icaza does recall:

We planned the announcement to come by July 19th 2001, so we could announce this at the O’Reilly conference, as Tim O’Reilly had been very supportive of this effort, and had offered his help since the early stages, when it was still a very young idea. When we announced the project launch we had our team in place, and we were shipping our metadata framework and our C# compiler as well as a few initial classes So officially the Mono project was launched on that date, but it had been brewing for a very long time.

Happy Anniversary!

Embarcadero RAD Studio XE2 will have cross-platform compilation

A Google search for RAD Studio XE2, presumably the successor to RAD Studio XE which includes Delphi, Delphi Prism (for .NET), C++ Builder and RAD PHP, throws up the following page:

image

The actual links need a login for a closed beta unfortunately.

Hmm, what caught my eye is the entry for cross-platform applications. Good to see this coming soon.

Adobe releases 64-bit Flash Player 11 beta, AIR 3 with packager for Windows, Mac, Android

Adobe has released a beta version of Flash Player 11 and AIR 3. The AIR release is of limited interest since as yet there is no public SDK; Adobe mainly wants to test compatibility.  That said, the announcement describes a key new feature, the ability to package AIR applications as standalone executables on Windows, Mac and Android. You can already do this on Apple iOS, a feature that was forced on Adobe by Apple’s refusal to allow application runtimes on iOS – unless they are WebKit or FileMaker. This is new for the other platforms though, and I assume comes as a result of the popularity of the iOS packager. The effect is that you no longer have to advertise the fact that your app runs on AIR or require users to obtain the runtime; your app will just work.

Adobe may have its eye on the Mac App Store, which will disallow applications that require a runtime. Extending the AIR packager to desktop OS X should get around that limitation.

64-bit Flash Player is also a big deal, and really long overdue, though there has already been a preview codenamed Square which offered 64-bit. Although there are probably not many Flash applications that really need 64-bit, this is good for compatibility with 64-bit browsers and of course desktop applications when compiled with AIR. There could also be value in 64-bit for business intelligence clients which manipulate large datasets.

Another new feature in Flash Player 11 is Stage3D, codename Molehill, which is a new API for hardware-accelerated 3D graphics. Stage3D has its own shader language, called AGAL (Adobe Graphics Assembly Language); my heart sinks a little when I see vendors inventing new languages rather than using one that is already available, such as OpenGL Shading Language, but Adobe says AGAL is simpler and more secure. If you would like to use GL SL with Stage3D, check out the 3rd-party Mandreel framework which comples GL SL shaders to AGAL.

Flash Player 11 also has a built-in H.264/AVC software encoder for cameras, which will improve video chat and video conferencing, and adds potential for applications that stream video out as well as in.

Native JSON support will simplify and accelerate the handling of data in this popular format.

Another feature that caught my eye is socket progress events. When transferring data, it is important to give feedback to the user on progress. A new property lets developers monitor the number of bytes remaining in the write buffer, and a new event is raised when data is being sent, enabling more informative data transfer applications.

LZMA compression for SWF files, the compiled format for Flash content, is claimed to reduce SWF size by up to 40%.

When do we get a full release? Adobe is taking its time, but my hunch is that it will be in 2011, maybe in time for the MAX conference in October.

Microsoft partners are not whooping and cheering for Office 365

There is a telling moment in the day two keynote at Microsoft’s Worldwide Partner Conference. “Now we’ve added Office 365”, says Corporate VP Jon Roskill. Do you guys feel the momentum?” There is a muted cheer, not the big whoop Roskill is looking for. “Now let’s have some momentum, whoo!” he repeats. Another barely audible cheer.

Why are partners not whooping and cheering?  Take a look at the Microsoft-commissioned Forrester report [PDF] on the total economic impact of Office 365. This report claims a remarkable payback period of only 2 months for a midsize organization moving to Office 365.

Looking at the figures in more detail, Forrester claims $54,000 saved over three years in eliminated hardware, $10,000 over the period in eliminated third-party software, $25,000 saved in web conferencing (Lync Online is bundled with Office 365), and $18,000 in “internal labor and professional services” saved on planning and implementation. There is an even bigger saving in support. Here I find it hard to puzzle out exactly what Forrester is claiming. It talks about “savings of $206,350 over three years” from simplified support and outsourced administration of infrastructure, but also refers to $146,250 costs in admin and support costs for Office 365; I am not sure if the $206,350 is a net figure. Forrester also throws in $260,625 saved on reduced travel thanks to online collaboration, which strikes me as highly speculative.

I suggest therefore that you do not take Forrester’s figures too seriously; but it is still worth noting that many of the savings come from revenue that would otherwise have gone to partners. How much partner income is lost will depend on the extent to which an organization outsources its IT admin, planning, support and administration, and on the margins partners achieve on things like third-party software; but it is considerable.

Of course there are also new business opportunities for partners. Presuming the savings from Office 365 and Microsoft’s other cloud offerings are real, a cloud-oriented partner has a strong sales pitch both to existing and new customers. Partners get an ongoing commission from subscriptions.

There is also an opportunity for new applications which link to cloud services. Yesterday Microsoft announced that the Windows Azure Marketplace, which used to offer data services and application building blocks, now also offers finished applications in US markets.

It is also true that Microsoft’s cloud offering is more partner-friendly than others, because it is a hybrid solution. Forrester’s report mentioned above assumes use of Active Directory Federation Services for single-sign on between on-premise and Office 365, a key feature which has been under-reported in the media coverage I have seen for Office 365. This feature, along with the fact that Microsoft’s server products like Exchange, SharePoint and Dynamics CRM can be deployed either online or as hosted services, means that there is flexibility over what is hosted and what is on-premise.

Nevertheless, it is hard to construct a reality in which the savings customers get from cloud services are real, without the further implication that total partner revenue will diminish, even though certain individual partners who take advantage of the new opportunities may end up winners.

This is true even if Microsoft succeeds in retaining all of its existing Microsoft-platform customers, rather than losing them to Google or other cloud providers. The consequences of a migration to Google, which is inherently not a hybrid platform, seem to me more severe.

Is there any way to put a positive spin on this, from a partner’s perspective? A couple of thoughts on this.

First, even if certain kinds of IT business are under threat from cloud migration, it is also true that the transforming impact of IT and the internet on businesses is far from complete. Much of what businesses currently do with IT can be greatly improved, there is still a thirst for new and improved business applications, and new technology including not only the cloud, but also massively parallel computing and of course mobile presents many new opportunities.

Second, it seems to me that partners should not be asking themselves how to maintain their business, but instead planning for change. It seems to me inevitable that the demand for skills in installing and nursing servers, deploying applications, and in maintaining and supporting clients, will diminish; and that is a good thing because these activities are IT plumbing and if they can be reduced it frees resources for other activities which have more business potential.

Behind the whooping and cheering, Microsoft’s message to partners is a tough one. Change, or die.

Embarcadero promises Delphi everywhere: Mac, iOS this year, Android, Blackberry, Windows Phone to follow

I noticed the following remark from Embarcadero’s David Intersimone regarding Delphi, its application builder based on Pascal.

We are putting Delphi (and C++Builder) everywhere this year and over the next 5 years. Today you can use Delphi for Desktop, Client/Server, Multi-Tier, Cloud, Web, Web Services (REST and SOAP). This year you will also be able to build for Macintosh and iOS. Linux is also on the roadmap for the coming years along with Android, Blackberry and Windows Phone 7.

Welcome news; though Delphi enthusiasts are all too familiar with bold promises. Two years ago I interviewed Embarcadero’s CEO Wayne Williams and he promised cross-platform Delphi in 2010; but when Delphi XE appeared last year neither Mac nor 64-bit (another longstanding request) was included.

That said, I am still a big Delphi fan. Mobile is a particularly interesting prospect. I have tried numerous cross-platform mobile toolkits and they all have problems; on the other hand they are improving fast and in a couple of years things like Appcelerator’s Titanium and  Nitobi’s PhoneGap may be hard to catch.

Update: what will Delphi’s Android support look like? I would be interested to know whether Embarcadero is working on its own compiler, or whether it is partnering with RemObjects and that what Intersimone is referring to is Project Cooper:

“Cooper” is a new and exciting research project going on in the RemObjects Software Labs, to bring the Oxygene language to the Java and Android platforms. The original Oxygene for .NET set out to bring a modern and “next generation” Object Pascal to the .NET world; Project “Cooper” is taking this endeavor to the next level, expanding the reach of Oxygene to the second big managed platform.

In other words, Project Cooper will compile Delphi code to Java.

Note that Embarcadero officially adopted Oxygene and offers it as its own product called Prism. It seems plausible that the same will happen with Project Cooper. Since Windows Phone is a .NET platform, there is also potential for Oxygene/Prism to target Microsoft’s mobile platform:

Windows Phone 7 – Microsoft’s new Windows Phone 7 uses Silverlight for application development,  and did I mention Delphi Prism does Silverlight?

says Jim McKeeth at RemObjects.

What about Delphi on the Mac and on iOS? There is also a possible Oxygene/Prism route here, via MonoMac: Delphi to .NET/Mono to Mac. However, I suspect Delphi developers would be disappointed if this turned out to be Embarcadero’s approach to Mac and iOS support. Programmers choose Delphi because they like compilation to native code.