Category Archives: adobe

adobe, apple, flash, professional, software development

Adobe financials: strong Creative Suite 5 and Flash, claims company undervalued

Adobe has released its financial results for its second quarter, reporting $227.3 million net income (GAAP) compared to $161.4 million in the same quarter last year; and revenue of $943 million which it says is 34% year on year growth.

Much of this is thanks to a successful launch for Creative Suite 5, which accounts for 56% of Adobe’s revenue. However, Adobe has also reported 12% year-on-year growth for LiveCycle, its enterprise server products about which I learned last week in Amsterdam. The “platform” segment, which includes the Flex development tools, Cold Fusion, and Flash media services, is also growing, from $36.8 million in Q2 2009 to $45.4 million in Q2 2010.

CEO Shantanu Narayen is upbeat, saying “we believe Adobe is significantly undervalued today” and backing his judgement with a share buyback program.

I was particularly interested in the focus on Flash in Adobe’s statements and conference call:

Approximately 3.5 million Flash designers and developers are working with Flash-based solutions today, and their ranks grew by 59 percent in 2009

said Narayen; while Executive VP Mark Garrett noted:

CS5 products containing Flash authoring and output as a product component achieved revenue growth of 22% version-over-version to date

making the point that this exceeded the growth of CS5 overall.

Any clouds on the horizon? Two that I can think of. One is that Apple wants to kill Flash. CEO Steve Jobs says:

Flash was created during the PC era – for PCs and mice. Flash is a successful business for Adobe, and we can understand why they want to push it beyond PCs. But the mobile era is about low power devices, touch interfaces and open web standards – all areas where Flash falls short.

The other issue is that Adobe is dependent on Creative Suite, desktop software that arguably will be a business hard to sustain in the cloud and device era.

Still, these are good figures, the best we have seen from Adobe for a while, and despite the efforts of Steve Jobs both Adobe and Flash are prospering right now. A side-effect of Apple’s Flash downer is that competitors have hastened to support it, with Google building Flash support deeply into its Chrome browser.

Detailed figures from Adobe are here.

adobe, apple, internet, java, microsoft, professional, sharepoint, software development, web authoring

Adobe LiveCycle and the Apple problem

6 Comments

Earlier this week I attended Adobe’s partner conference in Amsterdam, or at least part of it. The sessions were closed, but I was among the judges for the second day, where partners presented solutions they had created; the ones we judged best will likely be presented at the Max conference in October.

Seeing the showcased solutions gave insight into how and why LiveCycle is being used. LiveCycle is actually a suite of products – the official site lists 14 modules – which are essentially a bunch of server applications to process and generate PDF forms and documents, combined with data services that optimise data delivery and synchronisation with Flash clients, typically built with Flex and running either in-browser or on the desktop using AIR. These two strands got twisted together when Adobe took over Macromedia.

LiveCycle applications are Java applications, and run on top of Java Enterprise Edition application servers such as Oracle’s WebLogic or IBM’s WebSphere. This does mean that support for Microsoft’s .NET platform is weak; Adobe argues that that Microsoft’s platform has its own self-contained stack and development tool (Visual Studio) which makes it not worth supporting, though of course there are ways to integrate using web services and we saw examples of this. Many of the partners whispered to me that they also build SharePoint solutions for their Microsoft platform customers, and that SharePoint 2010 is a big improvement on earlier versions for what they do. Still, Java is the more important platform in this particular area.

Why would you want to base an Enterprise application on PDF? The answer is that many business processes involve forms and workflows, and for these LiveCycle is a strong solution. PDF is widely accepted as a suitable format for publishing and archiving. One thing that cropped up in many of the solutions is digital signatures: the ability to verify that a document was produced at a certain time and date and has not been tampered with plays well with many organisations.

Here’s a quick flavour of some of the solutions we saw. Ajila AG showed an application which handles planning permission in parts of Switzerland; everything is handled using PDF form submissions and email, and apparently a process which used to take 45 days is now accomplished in 3 days. Another Ajila AG solution handles the electronic paperwork for complex financial instruments at the Swiss stock exchange. Ensemble Systems showed an e-invoicing system which includes a portal where both a company and its suppliers can log in to view and track the progress of an invoice. Impuls Systems GmbH used PDF forms combined with Adobe Connect Pro conferencing to create online consultation rooms and guided form completion for clients purchasing health insurance. Aktive Reply built a system to replace printed letterheads for an insurance company with 10,000 agents; not only does the system save paper, but it also synchronises any address changes with a central database. Another Aktive Reply application lets lawyers assemble contracts from a database of fragments, enforcing rules that reduce the chance of errors; we were told that this one replaced a complex and error-prone Word macro.

OK, so why would you not want to use LiveCycle for your forms or document-based workflow or business process management application? Well, these solutions tend to be costly so smaller organisations need not apply; and I did worry on occasion about over-complexity. More important, the whole platform depends on PDF, often making use of smart features like Adobe Reader Extensions and scripting. After all, this is why Adobe added all these abilities to PDF, despite security concerns and the desire some of us have for simple, fast rendering of PDF documents rather than yet another application platform.

PDF is well supported of course, but once you move away from Windows and Mac desktops, it is often not the official Adobe Reader that you use, but some other utility that does not support all these extra features. In many cases it is not just PDF, but Flash/Flex applications which form part of these LiveCycle solutions. Adobe understands the importance of mobile devices and I was told that more effort will be put into Adobe Reader for mobile devices, to broaden its support and extend its features. Reader for Android is also available, as an app in the Android Market.

That’s fair enough, but what about Apple? Curiously (or not) PDF is not well supported on the iPad, though you can read PDF in Safari and in mail attachments. This is not Adobe Reader though; and given that PDF now supports Flash as well as scripting there seems little chance of Adobe getting it onto the App Store. Flash itself is completely absent of course.

Lack of compatibility with Apple devices did not seem to be a big concern among the partners I spoke to at the conference. Many of the solutions are internal or work within controlled environments where client compatibility can be enforced. Nevertheless, I can see this becoming an increasing problem if Apple’s success with iPhone and iPad continues, especially in cases where applications are public-facing. My suggestion to Adobe is that it now needs to work on making LiveCycle work better with plain HTML clients, in order to future-proof its platform to some extent.

adobe, flash, mobile

Flash and AIR for Windows Phone 7 by mid 2011?

I’m at an Adobe partner conference in Amsterdam – not for the partner sessions, but to be one of the judges for tomorrow’s application showcase. However, I’ve been chatting to Michael Chaize, a Flash Platform evangelist based in Paris, and picked up a few updates on the progress of Flash and AIR on mobile devices. AIR is a runtime which uses the Flash player for applications that are not hosted in the browser.

It’s well known that AIR for Android is ready to preview, though it is not quite public yet. Which platforms will come next? According to Chaize, AIR for Palm webOS is well advanced, though a little disrupted by the coming HP takeover, and Blackberry is also progressing fast. He added that Windows Phone 7 will not be long delayed, which intrigued me since that platform itself is not yet done. Although Microsoft and Adobe have said that Flash will not be in the initial release, Chaize says that it will come “within months” afterwards, where “months” implies less than a year – maybe six months or so.

We also talked about the constraints of a mobile platform and how that affects development. Currently developers will need to use the standard Flex components, but Chaize said that a forthcoming Flash Mobile Framework will be optimized for devices. Of course, the more you tailor your app for mobile, the less code you can share with your desktop version.

The Apple question also came up, as you would expect. Chaize pointed out that Adobe’s enterprise customers may still use the abandoned Flash Packager, which compiles Flash code to a native iPhone app, since internal apps do not need App Store approval. That said, I suspect that even internal developers have to agree the iPhone Developer Program License Agreement, with its notorious clause 3.3.1 that forbids use of an “intermediary translation or compatibility layer or tool”. Even if that is the case, I doubt that Apple would pursue the developers of private, custom applications.

adobe, microsoft, silverlight, software development

Native code interop in Adobe AIR vs Microsoft Silverlight

3 Comments

The latest versions of Adobe AIR and Microsoft Silverlight both allow access to native code, but with limitations. The two platforms take a different approach though – here is a quick comparison.

Native code access in AIR

The new version 2.0 of Adobe AIR is just about done. The runtime is available now (as is Flash Player 10.1), but we have to wait until June 15 for the final version of the SDK.

AIR lets you create cross-platform desktop applications that use the Flash runtime. Supported operating systems include Mac, Windows and Linux, and coming soon, Android. Sadly, supported operating systems do not include Apple’s iPhone or iPad.

One of the big new features in AIR 2.0 is access to native code. Of course this breaks cross-platform, unless you create identical native code extensions for all the platforms that AIR supports. Still, the ability to extend AIR without limit using native code is significant. So how do you use it, can you call a DLL or a dynamic shared library? What about COM on Windows, for automating Microsoft Office?

The answer is that you can do all these things, but not easily. There are actually three obvious ways to communicate with native applications in AIR 2.0:

1. Open a document using the default file handler. This is done using the new openWithDefaultApplication function. This is a handy way to open a PDF or Microsoft Office document, but you as the developer have little control over what happens. You do not know which application will open, and cannot control it once it does open.

2. Socket support. Your AIR application can send and receive data over a TCP socket. If you write a native code socket server and install it, you can get access to the local operating system APIs that way.

3. Native process support. This one looks promising. The new NativeProcess class lets you launch a native application and communicate with it via STDIN and STDOUT. Your native application could do anything, of course, such as calling a DLL or using COM, but it must use STDIN and STDOUT to communicate with AIR.

Another limitation is that AIR applications which use this function must be installed with a native installer, rather than by downloading an .AIR file. A further limitation is that auto-update does not work for these applications. You will have to write your own code to check for updates and download an updated installer if necessary.

Native code access in Silverlight

Microsoft Silverlight 4.0 also has the ability to run on the desktop and to call native code – but the native code part only works on Windows, and is restricted to applications that are “Trusted”, which means the user has approved the installation. A trusted Silverlight 4.0 desktop application can call COM via AutomationFactory.CreateObject. Presuming it is successful, your application can call methods on the returned object. If what you really want is to call a DLL, for example, you would have to write a COM DLL (or an application with a COM API) that calls the native DLL.

In addition, Silverlight 4.0 trusted applications have socket support, so that would be another possible approach. However, unlike Adobe AIR 2.0, you cannot simply open a document using the default file handler for its type. That said, it would be trivial to do so using COM and the WScript object, for example. You can also use the browser to do this – see here for an interesting case study from Beat Kiener, who does this with remote documents.

The main limitation of native code access in Silverlight is that it only works on Windows. Even if it does go cross-platform at some point, you would not use COM on Mac or Linux, so some other mechanism will be necessary.

Comparing the two

First, let’s acknowledge that native code interop is not something to use lightly in a cross-platform runtime. If you have to use native code, maybe AIR or Silverlight is not the right choice.

Opening files using the default file handler is a different case, as you can do this without any platform-specific code.

Still, if you can do almost everything in AIR or Silverlight, but need to call a native API for just one or two important features, it may be a reasonable approach.

My immediate observation is that native code interop is easier in Silverlight, though wrecked by being restricted to Windows only. The packaging and updating limitations in AIR, plus being restricted to STDIN and STDOUT, is more arduous than using COM in Silverlight.

Further, it is a shame that neither platform lets you simply call a dynamic library. It would then be relatively easy to write some conditional code to load the appropriate library on different platforms, and many tasks could be accomplished without needing to build and deploy your own native code executable for each platform.

Will you be using native code interop in either AIR or Silverlight? I’d be interested in hearing of examples, and how well it is working for you.

adobe, apple, flash, google, java

Google advances its platform – or should that be advances the Web?

Yesterday Google presented its latest platform innovations at the Google I/O conference in San Francisco. Its strategy is relatively clear: to improve web applications so that you can do everything you need in the browser. The client pieces are HTML 5 – though bear in mind that this is not yet a fixed standard – and especially the Chrome browser, whether installed on a traditional operating system or delivered on a Chrome OS device.

Chrome has always had lightning-fast JavaScript. We’re now seeing other pieces in the Chrome-as-application-platform story, including:

Integrated Adobe Flash

The  Native Client for secure native code, typically coded in C/C++, running in the browser

Announced yesterday, the WebM video and audio format. This includes VP8, acquired with On2 Technologies and now open source, as well as Vorbis audio and the Matroska multimedia container.

The Chrome Web Store, also announced yesterday, which will be an App Store equivalent for web applications.

image

Web Store apps are “installable” which may mean little more than a shortcut in the browser, similar to a bookmark or favourite link. However, there will be a payment infrastructure as well as ratings and user reviews.

Serverless apps. This is another aspect to the Web Store. A Web Store app can be designed to run offline, with all the necessary HTML and JavaScript bundled into the .crx format used by the store. Google calls these Serverless apps, and in many ways the concept is similar to that in Palm’s WebOS – HTML and JavaScript applications that run locally. This is interesting for Chrome OS as it makes it easy to create applications that work offline.

The Google Font API and Directory. This is big news. Most of us stick to the same old web fonts, or use images, or a plug-in like Flash or PDF, for going beyond the standard browser fonts. Using Google’s API, it is easy to include any font in the new directory, with nothing more than a specially crafted CSS link.

The Google Font API hides a lot of complexity behind the scenes. Google’s serving infrastructure takes care of converting the font into a format compatible with any modern browser (including Internet Explorer 6 and up), sends just the styles and weights you select, and the font files and CSS are tuned and optimized for web serving.

On the server side, there is Google App Engine for Business. Google is cooperating with VMware so that you can host Spring applications on its web application platform, App Engine. Spring Roo, a rapid application development tool for Spring, has been integrated with Google Web Toolkit (GWT) to make it easy to build browser-hosted clients for Spring applications. GWT lets you code in Java, but run in JavaScript. Using Spring gives you a choice of where to host your application: on-premise, on App Engine, on the Salesforce.com platform with VMforce, or on another platform such as Amazon EC2.

Spring’s Rod Johnson explains the goals here:

Until the announcement of VMforce and today’s announcement, Java developers lacked a PaaS destination to which they could easily deploy their applications. This was an important gap that threatened to become a danger to the long-term future of Java. I’m delighted that VMware/SpringSource is leading the charge to fill this gap.

Another feature worth highlighting is SQL for App Engine:

SQL database support on App Engine gives enterprise developers access to the full capabilities of a dedicated relational database, without the headache of managing it.

though Google adds that this is a “premium service” which may come at extra cost. According to the roadmap, this is coming in Q3 2010.

While there is a lot to take in, there is a consistent theme: making the web and browser platform more capable, and making desktop applications and on-premise servers less necessary.

Whereas Apple aims to lock us into its devices and App Store, Google’s approach is more open. It is happy to give away stuff like the WebM multimedia project and the Font API in order to improve the Web overall; though of course every time we use the Font API Google can record the traffic on our site and mine that data if it chooses to do so. It is in line with the strategy unveiled at the Mobile World Congress in February: a little bit of everything you do. Google will take its cut of any Web Store sales. What is Web and what is Google is deliberately blurred.

I still think that the forthcoming Chrome OS is an amazing experiment, and the new offline application support announced yesterday makes sense as an alternative to traditional local applications.

A good day for Adobe and Flash, or a bad one? Adobe’s Kevin Lynch demonstrated new HTML 5 capabilities in Dreamweaver, via an add-on pack. As expected, Adobe is becoming a little less Flash-focused in its PR. Google’s emerging platform is a tool opportunity for Adobe. Still, that is a lesser role than establishing Flash as the universal client, a possibility which Apple seems to have killed. Google is supporting Flash, of course, by building it into Chrome, but at the same time things like WebM, Font API, HTML5, and Native Client (shown as the natural client platform for browser-hosted games) undermine the need for Flash.

Apple is a problem for Google too. Will native client ever work on iPhone or iPad? WebM? The big question – who will marginalise whom?

adobe, intel, microsoft, silverlight, software development

What is happening with Silverlight on Intel Moblin/Meego?

1 Comment

Last September, Microsoft and Intel announced a port of Silverlight to Moblin Linux. I posted on the subject here, including a quote from Microsoft’s Brian Goldfarb:

Microsoft and Intel announced today that the two companies have agreed to work together to bring support for Silverlight 3 to Intel’s Atom-based Mobile Internet Devices (MID). These Atom-based devices run on Windows and Moblin, an open source, Linux-based operating system targeted at Atom-based devices. In order to help bring Silverlight content to these devices, Microsoft has provided Intel with Silverlight source code and test suites, and Intel will provide Microsoft with an optimized version of Silverlight for Moblin devices that Microsoft can then redistribute to OEMs.

Since then, Moblin has merged with Novell’s Maemo to form MeeGo (though this is still work in progress), and we’ve heard very, very little about Silverlight on either platform. The only snippet of news I have is that it was mentioned at the Intel Developer Forum in Beijing and reported by Char Zvolanek, who said that it came up in the Meego Q&A after regular sessions ended, and Silverlight will be supported in Meego  version 1.1 in October:

In May, the 1.0 version will be released, and with 1.1 coming out in October, there will be support for Silverlight, Java, and Air. Developers can write native or runtime apps that can be Java-based, Web-based, Silverlight-based, or Air-based.

Today, another clue, but not a good one for Silverlight. Intel is holding an application lab on May 26th in San Jose, for developing for the Intel AppUp store, either on Windows or Moblin. On the agenda: C/C++ and Adobe AIR, and the upcoming Adobe AIR SDK for Moblin. No Silverlight.

If anyone is going along, and can discover any news about Silverlight on Moblin, I’d be interested to know.

adobe, apple, internet, iphone, java, mobile, silverlight, web authoring

Adobe’s campaign against Apple misses the target

8 Comments

Nothing better demonstrates Adobe’s concern about being locked out of Apple’s mobile platform than a huge advertising campaign attempting, one assumes, to win public support and pressure Apple into yielding ground.

Still, if you are going to run a big PR campaign it helps to be right. But Adobe seems to be arguing that Flash support is essential to an open web, which is incorrect.

We believe that consumers should be able to freely access their favorite content and applications, regardless of what computer they have, what browser they like, or what device suits their needs. No company — no matter how big or how creative — should dictate what you can create, how you create it, or what you can experience on the web. … In the end, we believe the question is really this: Who controls the World Wide Web? And we believe the answer is: nobody — and everybody, but certainly not a single company.

says the open letter from Adobe founders Churck Geschke and John Warnock.

Very good, but this is not an argument in favour of Flash. Flash is not part of HTML, Flash is not a standard, and Flash is not open – the specification for the player is published, but what goes into that specification is controlled solely by Adobe, and its player implementation is not open source. Flash is a proprietary plug-in. Are Geschke and Warnock arguing that all browsers on all devices should allow all plug-ins to be installed – including Silverlight, Java, ActiveX, and anything else you can think of? Or are they arguing that Adobe Flash is a special case? It is certainly a special case for Adobe, but any company will argue in favour of its own stuff.

The full-page advertisement that I’ve seen in various newspapers is not much better. Adobe’s pitch is that Apple is:

taking away your freedom to choose what you create, how you create it, and what you experience on the web

This again is incorrect. Apple has an excellent mobile browser based on WebKit, as also used by Google, Adobe and others. You can do what you want on the Web, but if you use Flash it won’t render on Apple’s mobile devices. All that means is that Apple has chosen not to support Adobe’s plug-in. It is not an issue of freedom.

Personally I don’t like Apple’s approach. I’d prefer it to support the leading plug-ins (not only Flash); I don’t like the appification of the web -  dubbed the splinternet, or splintered web, by some. And I particularly object to Apple’s clause 3.3.1 in its new developer agreement, which blocks apps that are created with cross-platform tools, no matter how well they perform or how good they look. That, it seems to me, is anti-competitive in spirit.

I think Adobe should make more of clause 3.3.1, rather than indulging in special pleading for its plug-in. And if I were Adobe, I wouldn’t be whinging about Flash being blocked. Rather, I’d be highlighting all the great things Flash can do, and all the content you will miss without it. My full-page ad would say, “Mr Jobs, your iPhone is broken”, and extol the merits of Android and other devices that will run Flash.

I’d also be working on the technical arguments, that Flash is unstable, insecure and resource-hungry. Is it Apple’s fault? Is it because of poorly coded SWFs, and if so what is Adobe doing about that? And how will Adobe improve Flash so that it behaves better in future, and not be perceived as the new Vista?

Maybe next time round?image

.net, adobe, flash, java, microsoft

Java versus C/C++ performance – which is really faster?

9 Comments

Cliff Click of Azul Systems has an excellent post on Java vs C/C++ performance:

Is Java faster than C/C++?  The short answer is: it depends.

He then presents three categories of cases: the first C/C++ beats Java, the second where Java beats C/C++, and the third and longest, where C/C++ proponents claim Java is slower but in reality it is not.

My quick summary: there are few cases where Java (or C#) is so much slower that it matters, save for one big issue which Click mentions early on – start-up time:

Flash games beat Java games mostly because it took 30+sec to load the JVM from disk… and so now the web-game developer community has settled on Flash as the standard (and it still takes 10+sec to load the JVM).

Start-up time makes a big difference to usability, for reasons which I cannot entirely explain. Just for fun, I’ve been running Microsoft Office 95 in a virtual instance of Windows XP recently, and the fact that Word 95 loads in a blink makes it feel much faster than Word 2010, which takes 5-10 seconds on first load, even though the productivity difference must be negligible.

If I had to theorise about this, I’d say it is to do with the way humans learn from experience. We don’t like waiting, and if an application take a while to start then part of our brain tells us to avoid it in future. We override that instinct when it is an app we need to run, but it contributes to a negative impression.

The opposite is also true. If an application starts instantly – I mean to the point where we can use it, not just a splash screen – it contributes to a positive impression and we are more inclined to use it in future.

Incidentally, Click thinks that Java is generally faster than C#, though he adds that he is “not able to give C# a fair treatment” because he does not track it closely.

adobe, apple, internet, iphone, software, software development

Adobe’s Kevin Lynch: we’re focusing on everybody else

4 Comments

I enjoyed this interview with Adobe’s Kevin Lynch from Web 2.0 Expo in San Francisco, where he talks about the Apple problem. Adobe has created a compiler for Flash that creates a native code iPhone application, but Apple’s latest developer agreement prohibits its use.

Lynch presents it as a matter of freedom. Software developers should be allowed to target multiple operating systems with one code base; and developers should be allowed to deploy applications without needing permission from a company.

“We’re focusing on everybody else” he says, talking about forthcoming devices that will support Flash and the Flash-based Open Screen Project. “All the variety and the innovation that happening with all hese other companies is going to dwarf what’s happening from one company,” he says. “We’re at the beginning of the game not the end of the game.”

The snag is that Apple’s devices are the most attractive market for applications, thanks to smooth deployment via the App Store and the higher than average wealth of Apple’s customers. It’s a matter of which is more true: that Flash is marginalising iPhone and iPad, or that iPhone and iPad are marginalising Flash.

I’d also suggest that having Adobe control the platform for the Open Screen Project is not ideal, if we are going to talk about software freedom. If you listen to the interview, notice how Lynch tries to avoid mentioning Flash in the same breath as the Open Screen Project. It’s really the Adobe Flash Screen Project, but you wouldn’t know from what he says.

Nevertheless I agree with both his points. Both the App Store and Apple’s new restrictive developer agreement are bad for competition and I dislike them. That said, I doubt that the existence of a few upset developers will have any noticeable impact on Apple’s success. What will make a difference is if the “variety and innovation” which Lynch talks about produces devices that are better than Apple’s offerings.

adobe, apple, flash, google, internet, web authoring

After Apple’s Flash ban, what next for Adobe?

2 Comments

I imagine there must be urgent meetings taking place at Adobe following Apple’s prohibition of Flash content or applications on its iPhone and iPad devices, and last week’s open letter from Apple CEO Steve Jobs which leaves little hope of a change in policy.

The problem is that until now Adobe has put the Flash runtime at the heart of its strategy. The Flash Platform is a suite of tools and technologies including middleware (LiveCycle Data Services), web and desktop runtimes (Flash and AIR), design and developer tools (Creative Suite and Flash Builder). The company has worked to integrate Flash and PDF, using embedded Flash content for multimedia and to blur the boundaries between documents and applications.

If you look at Creative Suite 5, the latest release of Adobe’s flagship tools and from which it derives most of its revenue, there is scarcely a product within it which Flash does not touch.

Adobe’s hosted document and collaboration platform, Acrobat.com, uses Flash for online document viewing and editing, for web conferencing, for online presentations.

Adobe’s abandoned Flash to iPhone compiler was not only something for third-party developers, but also for Adobe itself, and the company has already been using it to enable access from iPhone to some of its Flash-based online services. For example, Adobe Acrobat Connect Pro Mobile for iPhone, which lets you attend Acrobat Connect Pro meetings:

This application was developed using the Flash platform and the Packager for iPhone to publish it as a native iPhone application. We will also be able to use the same code to deliver this application on other mobile devices when AIR for mobile devices becomes available later this year.

Of course Adobe is not solely a Flash company. It’s also a PDF company, and while there is no Adobe Reader for iPhone, it is at least possible to view PDFs on Apple’s devices. Adobe is an HTML company too, and products like Dreamweaver and Fireworks are geared towards HTML content.

Still, Apple has created a big problem for Adobe. The appeal of the Flash Platform starts with the ubiquity of the runtime.

Let’s assume that Apple trundles on, grabbing an increasing share of the Smartphone market and encroaching into what we now think of as the laptop/netbook market with iPad and possibly other appliance-type computing devices. What can Adobe do? Here are a couple of top-level choices that occur to me:

1. Resign itself to being an anything-but-Apple company. There is life beyond iPhone and iPad; and Adobe is making good progress towards establishing Flash elsewhere, from Android mobiles to set-top boxes to games consoles. Unfortunately the Apple-owning community is a wealthy and influential one; the impact of losing that part of the market is greater than its market share implies. Nevertheless, this seems to be Adobe’s immediate reaction to the Jobs bombshell. It is rumoured to be giving Android phones to its employees, for example, and there are signs of an Adobe-Google alliance forming against Apple – note that Google is building Flash by default into its Chrome browser.

2. Pull back on Flash. For example, redesign Buzzword, its Flash-based online document editor, in HTML and JavaScript. Tune its PR message to emphasise how useful its tools are in an non-Flash context, rather than presuming its runtime will be everywhere. I think Adobe will have to do this to some extent.

A mitigating factor is that while Adobe has (until now) done a great job of deploying the Flash runtime, it has done less well at monetising it. If you look at its latest financials, you’ll see that Flash Platform (including AIR) accounted for only 6% of its revenue, compared to 50% for design tools including Creative Suite and Photoshop, 28% for business use of Acrobat, and 10% for the recently acquired Omniture web analytics. Although some of its design market is Flash-dependent, there is plenty more that is not.