Tag Archives: mobile

Infragistics: upbeat on Windows Phone but also building for Apple iOS, Google Android

I spoke to Dean Guida, CEO and co-founder of Infragistics, at TechEd in Atlanta earlier this week. Infragistics makes components, mainly for Windows but now beginning to support non-Windows clients. There is a set of jQuery controls in preparation, and “Our roadmaps are also going to deliver native on Android and iPhone,” Guida told me. “We have a lot of software companies that use our tools in their commercial apps, and a lot of enterprises, and we feel that we need to do it,” though he adds, “we feel that the best and the smartest business solution is to go mobile web.”

image

Infragistics has a focus on data visualization, and Guida showed me some great-looking components that show animated charts, with a huge range of customisation options, and including geo-spatial and timeline controls.

I was intrigued to find Guida more upbeat about Windows Phone than most commentators, though I make allowance for the fact that his company has a component suite for the platform. “More than half of our customers told us that they’re either building or they will build for Windows Phone in the next 12 months,” he told me.

His view, which I share, is that they key advantage of Windows Phone is to Microsoft-platform enterprises rather than to consumers. “It’s so easy to extend their knowledge of Silverlight and extend apps, that they’ll be able to extend the data and the access to information this way. I think that’s going to be a beachhead for Microsoft.”

Of course Microsoft has marketed Windows Phone to consumers so far, and has told businesses they should continue to use Windows Mobile 6.5, clearly a dead-end. It may be easier when the company is able to move on from this mixed messaging and get behind Windows Phone as a business mobile platform.

Continuing a contrarian theme, Guida is also positive about Windows Presentation Foundation (WPF). “It’s huge, especially in the financial markets. They’ve made big bets on it. They’ve built a lot of their trading apps and a lot of their internal apps on it. We’ve been telling Microsoft this for years,” he says.

The problem I guess is that while WPF/Silverlight makes sense for data visualisation for internal apps where you control the platform, for broad reach apps that are visible to the rest of us, Adobe Flash or some other approach is a better fit.

It is understandable that companies like Infragistics are keen to talk up the Microsoft platform. Their business depends on it. It is true that Infragistics is now experimenting with other platforms like Apple iOS and Google Android, but historically developers on non-Microsoft platforms have not formed a strong component market.

“They don’t get it as much as Microsoft developers,” says Guida. “We used to have a ton of Java components. I was at the second JavaOne conference. We built some of the first AWT components, JavaBeans, Swing components. There’s a lot more pain developing for these platforms than on the Microsoft platform, Microsoft has done a great job with the tooling. Why have that pain? I think there is a distinction between the Microsoft and the non-Microsoft developer, that they have a higher tolerance for, pain’s probably not the right word, but a higher tolerance for taking longer to get stuff done. I can only believe that over time maturity will happen. It’s really about satisfying a business need or a consumer need. These platforms are different, but if we go in and give them the tools, why not? We’re really just this year starting to get there.”

It is a brave hope; but looking at the Infragistics site, there are currently no Java controls on offer, and even the 2008 NetAdvantage for JavaServer Faces (JSF) seems to have disappeared. If the Microsoft client platform does decline, the future will be challenging.

Succeeding in an App Store world: lessons from the Angry Birds story

At Mobile World Congress earlier this year I heard Rovio CEO Mikael Hed address a small group of Apple platform developers on the subject of the changing world of app development. His starting point is that mobile apps and the app store model are transforming the business of software. Of course he has a games industry perspective, but my hunch is that what he says applies more widely. I note that the App Store concept has already come to the Mac, and that Microsoft will follow Apple with something similar in Windows vNext.

What is the effect of an App Store? It combines opportunity and challenge for developers. Opportunity because apps can be found, purchased and installed in a few clicks. Challenge because app stores attract lots of apps, and the barriers to entry are low, much lower than traditional retail channels. This forces prices down and makes it hard to have your particular app stand out.

The App Store model seems to include the idea of single-purpose apps at low prices. Apple still sells iWork, its office suite, for £72.00 as boxed product (UK prices), but on the Mac App Store it is split into three products, Pages, Keynote and Numbers, at £11.99 each. Even if you buy all three it is half the price of the box.

Mac desktop apps are larger and more sophisticated than iPhone apps, so I guess they will always attract higher prices; but I also guess that the factors which have driven down prices on the iPhone App Store will exert the same influence on the desktop store.

So where are prices going? Here is what Hed told us:

On the pricing side, we know now that on the App Store the standard price is fast becoming free, zero. And the premium price is 99 cents. If you go higher than that, then there are higher risks, because you might never reach the top ten, or top 100, and if you do, it will drop off very fast, there’s huge price sensitivity. So this also is a big change for traditional publishers who are used to high prices up front, and that’s the classic business model in gaming. That is changing, so game developers must find additional revenue streams.

This low pricing is the foundation of his thesis. Hed’s view is that software companies, in the games industry at least, have to be ready for it. Further, he thinks that the shift toward mobile is profound and will not reverse:

We are seeing right now a big shift from retail focused, location based games where you have to have your console plugged into your TV. That is slowly slipping away and in its place is coming the digitally downloaded game that you can play anywhere.

How then do you survive and prosper in this new world? Hed’s answer is to build a brand, and find diverse ways to monetize it.

He told us the history of Angry Birds. This, he says, is the first mock screenshot which his game designer made in 2009:

image

The way he explained this game concept to me was that you have these different coloured birds and then you have blocks with similar colours, tap on one of the blocks and the birds will fly and destroy that block. I listened to that description and I felt like, maybe this game concept is not a winner as such, but everybody liked these characters very much and we felt like, hey, we have really here a good starting point.

Rovio at the time was doing what Hed called “work for hire”, such as casual games commissioned by operators or other publishers. “We didn’t have a lot of capital to put into our game,” he said. Rovio kept half its 12-strong team doing the work for hire, and put the other half on Angry Birds. This meant the game took 8 months to develop rather than the usual 3 or 4 months, but he said this slower development time worked out well because the result was more polished.

Hed told us that most app developers push out apps too quickly:

They are concerned about getting their apps quickly out there on the market in order to start generating revenue. Before Angry Birds we did release a couple of other iPhone titles and they didn’t do well at all. We learned a lot from that and one of the things we learned is that never release something that is not completely finished, because it’s so easy for reviewers to just rip your game apart because something about it was not perfect. And that is exactly what is happening. It’s tremendously demanding, the consumer on the app store is tremendously demanding even if they pay only 99 cents, they still expect it to be perfect.

Even more significant was that Rovio consciously planned for Angry Birds to be more than just a game:

Our primary goal with Angry Birds was not to make a lot of money in the app store. Our primary goal was to build a brand.

Angry Birds took off pretty fast. It became the top seller on the iPhone App Store, first in Finland, then in the UK in February 2010, then in the USA in April 2010. Rovio made some decisions. First, it would stick with Angry Birds and build it into a strong franchise, rather than simply investing its profits into new game titles. Second, it would continue to offer free updates for the original app.

Where then are the “additional revenue streams” which Hed says are essential in order to thrive in this new world? In-app purchasing is one, he said, but Rovio decided not to sell additional levels via this channel. Instead it came up with the Mighty Eagle, which he calls a product rather than a feature:

In the Mighty Eagle we offered a way for users to pass levels that they are stuck on, so it gives added value to the users. But we made it into a product, and that is one of the important things of how we act in the marketplace, we make products, we don’t make features. And in this our big role model is Apple. You can see that nobody is that much interested in one “feature”. People want products. That’s why you don’t see Apple coming out with a feature called video calling. You see them coming out with a product called Face Time.

I am not entirely convinced by the distinction between products and features, but I understand the value of this way of marketing software. Hed says Rovio has been rewarded with a 40% conversion rate, much higher than for most in-app upgrades.

Rovio is also doing merchandising. 

image

This helps to sustain the franchise and to make sure that the franchise stays relevant for years to come, and it supports our game sales, and our game sales support our merchandising sales.

he says. It is another example of finding additional revenue streams.

Hed also talked about TV and film projects. Rovio partnered with 20th Century Fox to make a game that ties in with Rio the Movie, hence the game Angry Birds Rio.

He adds that mobile advertising is a key area:

We can see from the amount of time that people spend playing our games and playing everybody else’s games and using those apps, that mobile app advertising will be huge. We will see shifting of advertising towards mobile, because there users will be engaging for long periods of time, they will be exposed to brands repeatedly, they will be closer to the point of purchase.

This has worked for Rovio so far, though personally I am not sure for how long it can prosper if the Angry Birds franchise is all it has. It is a fashion thing and people will get bored of it – or does Rovio now have its own enduring franchise like Disney’s Mickey Mouse?

My main interest though is Hed’s insistence that software world is changing, prices are tumbling, and software developers will have to look for ways to monetize apps that go beyond the purchase price. “It’s the same for everybody. Now the industry is in the midst of transformation so everybody must adapt,” he says.

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

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

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

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

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

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

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

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

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

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

The mobile app ecosystem before Apple – was it really this bad?

For some time I have been meaning to post about a talk I heard at Mobile World Congress, by Rovio (Angry Birds) CEO Mikael Hed. What interested me about this talk was not so much the Angry Birds app itself – now downloaded over 75 million times – but rather Hed’s thoughtful perspective on what it is like to be a software company in the App era. “It’s been a year of transformation not only for us but for the whole industry,” he told us.

image

Hed started his talk by describing life as a mobile games developer before Apple launched the iPhone in 2007. Rovio was founded in 2003, and did 51 titles before Angry Birds, encompassing “every type of game,” he said.

Before the iPhone came along we were on feature phones only. That market was completely different from the iPhone market today. Looking back on it, it’s a small miracle that there were any game companies in that ecosystem.

Why? Several reasons.

In order to have a game commercially available on a feature phone, you would have to make that game, and make probably nine other strong games in order to be interesting to the carriers. And the carriers would only take your game if you could support all the handsets that their customers had. That meant hundreds of handsets.

Dealing with the carriers was a huge headache.

You would have to make an agreement with each carrier in each country, and you had to have an all-day sales team working for you to do any business at all. It was really expensive.

After all that, the revenue share and payment system was loaded against you.

All operators would take more than half of the revenue that you would make, and then pay you a long time after your game is out. They would report quarterly, and once you get the report you send them an invoice, then they have ninety days to pay. So if by some miracle you manage to get your game onto their devices , the earliest time you would see your money would be six months later.

The system was poor for consumers too.

It was also very difficult for consumers to find these games. It varied a lot across the different carriers, how you find the games. You might have to send an SMS somewhere and get a link back, click on that, download the game, and then hope that the game would actually run on your device; and probably at the end even if you had the latest and greatest phone it was made for the lowest common denominator so it would not use any of the nice features of your phone. So you would get a poor experience, if it worked at all. That was the past ecosystem.

Ouch. Was it really that bad?

The immediate conclusion is that while Apple’s closed and dictatorial iOS ecosystem has drawbacks, it is at least one that works, whereas what existed before was badly broken.

So how are things for app developers now, in the Apple era? Look out for a follow-up post soon. And by the way, it is still by no means easy.

Hands on: Building a PhoneGap app with Dreamweaver CS 5.5

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

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

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

image

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

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

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

image

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

image

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

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

image

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

image

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

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

image

Build and Emulate from the Mobile Applications menu.

image

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

image

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

image

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

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

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

image

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

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

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

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

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

Developers and mobile platforms: lies, damn lies and surveys

I’ve been reading the IDC/Appcelerator developer survey about their attitudes to mobile platforms. The survey covered 2,760 Appcelerator Titanium developers between April 11-13, so it is certainly current and with a sample just about big enough to be interesting.

The survey asks developers if they are “very interested” in developing for specific platforms, with the following results, and with comparisons to 3 months ago:

  • 91% iPhone (fractionally down)
  • 86% iPad (fractionally down)
  • 85% Android phones (down from 87%)
  • 71% Android tablets (down from 74%)
  • 29% Windows Phone 7 (down from 36%)
  • 27% Blackberry phones (down from 38%)

The survey is titled:

Apple shines, Google slows, and Microsoft edges RIM in battle for mobile developer mindshare.

Is that a fair summary? It is not what I would highlight. I cannot read the exact figures from the chunky graphic, but it is clear that the iOS figures are also fractionally down, maybe by just 1%, but hardly much different from the Android figures on a sample of this size. Both are pretty much flat.

The figures for Windows Phone 7 and Blackberry are more dramatic; though we should at least note that Appcelerator Titanium is a cross-platform toolkit that does not currently support Windows Phone 7, and that its support for Blackberry is only in preview. That was true last time round as well, but I’m not sure that asking developers about their plans for a platform which the toolkit does not currently support is the best way to gauge overall interest.

Another question that interests me: is developer interest a cause or an effect of a mobile platform’s success? A bit of each, no doubt; but personally I think the “effect” model is stronger than the “cause” model. Developers pick a platform either because they have immediate customers for apps on that platform, or because they think they can make money from it.

Nurturing a strong developer community is definitely important for a platform provider; but I doubt it ranks as highly as other factors, like building a strong retail presence, delivering excellent devices at the right price, and focusing on usability and a good end-user experience.

If you are interested in Appcelerator Titanium you might like to read my interview with the CEO at Mobile World Congress; and this discussion on whether Titanium really builds native apps.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

He says Adobe should embrace HTML and Flash equally.

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

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

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

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

Appcelerator CEO on Titanium, Aptana and the future of mobile development

I met with Aptana CEO and co-founder Jeff Haynie at the Mobile World Congress in Barcelona last month.

Appcelerator’s main product is Titanium, an SDK which takes HTML and JavaScript source files and compiles them to native apps for several platforms, including Windows Mac and Linux on the desktop, and Google Android or Apple iOS for mobile. RIM Blackberry support is in preview. Appcelerator has recently acquired the Aptana IDE for HTML, JavaScript, CSS, Ruby on Rails, Python and Adobe AIR. The company has also partnered with Engine Yard for cloud-hosted Ruby on Rails applications to deliver web services to clients built with Titanium.

Haynie says that mobile is currently a three-horse race between Apple iOS, Google Android, and RIM Blackberry; but he expects further diversification. Microsoft Windows Phone is under consideration, and he says that cross-compiling to Silverlight would be possible for Titanium:

It’s a .NET SDK, we would have to build a translation into Silverlight. That’s how we do it for iOS, we translate code into Objective C. We don’t think it’s technically insurmountable.

I asked about the Appcelerator Freemium business model. Titanium is open source and you can download and use the SDK commercially for free. Haynie says it works well because companies can do a full evaluation and get to understand the value of the software fully before deciding whether to purchase. However he emphasised that larger companies, other than non-profits, are expected to take out a paid subscription.

This point could do with clarification. Indeed, the Appcelerator Plans and Pricing page shows Titanium Indie which is free but for companies of less then 25 employees, and other editions which are paid-for. But as far as I can tell there are no restrictions on the SDK. See the FAQ which says:

Can I use Titanium for a commercial application?

Yes. You can use Titanium in both a personal and commercial application regardless of what your license or price is.

What is your License?

The Titanium SDK is licensed under the Apache Public License (version 2).

I also took the opportunity to ask about Adobe AIR support in Aptana. It strikes me that this is under threat following the acquisition, since AIR competes with Titanium. Haynie was just a little evasive, but at the same time impressed me with his attitude:

Obviously we have a competitive platform from Adobe AIR. But we want developers to have the best choice, the best tools possible. So competitively we need to build the best product. If AIR is a better product and people want to use Aptana to build AIR apps, then fine. That means we need to continue to work to make a better runtime for the desktop.

Nevertheless, Haynie implied that AIR support will only continue if Adobe supports it; I am not sure what support means in this context but I think it includes a financial contribution:

We’re with Adobe on trying to figure out where we go from here … we have to spend a lot of money to support that, so we’re making sure that we’ve got Adobe’s support behind that.

I am not sure what Adobe gains from Aptana support, given that it has its own Eclipse-based IDE called Flash Builder, so I would not bet on there being significant updates to the current AIR 1.5 plug-in.

Finally, Haynie emphasised what to me are familiar themes in talking about the direction for Titanium and Aptana. Cross-platform visual design tools; designer and developer workflow; and integration in a single IDE of rich client and cloud back-end. This integration has long struck me as one of the best things about Microsoft’s Visual Studio, so it is interesting to see the theme reappear in a cross-platform context.

What I enjoyed about the interview is the way Haynie communicates the huge change and volatility that has arrived within the software development world, thanks to the impact of cloud and mobile. Times of change mean new opportunities and new products. Titanium has plenty of competition, but if Appcelerator is able to deliver a robust, cloud to device, cross-platform toolkit, then it will have a bright future.

I have posted a transcript of most of the interview.

More germs on an iPhone than on a toilet seat? Proporta’s screen protectors kill the other kind of bugs.

Today’s inbox brings the disturbing news that:

In independent laboratory tests, the E. coli population on an untreated screen protector soared from 200,000 to 13 million in 24 hours.

Note the inclusion of the word “untreated” in this sentence, preparing us for the good news that:

The unique SteriTouch® coating on Proporta Antimicrobial Screen Protectors not only prevent this unbridled growth, but eradicates the E. coli completely.

The idea is that touch screens get, well, touched a lot; possibly even by more than one person. Touching spreads germs, so if you want to be safe maybe Proporta’s new “anti-bacterial germ resistant advanced screen protector with steritouch for iPad2” is just the thing for you. Bug-zapping screen protectors are also available for iPhone4, iPod touch, HTC Desire HD, Blackberry Torch, and Samsung Galaxy S2.

If this sounds like your thing, head over to Proporta’s site where you can also learn that

the average mobile has 25,127 germs per square inch, whilst the average toilet seat has just 49.

While quoting this sounds like a great way of annoying an Apple fanperson, the scientist in me would like a bit more information please. What about other things in our life that are touched frequently, door handles for example? How does the risk from using an “untreated” mobile device compare with that from, say, shaking hands with someone? Or travelling on the London Underground in the rush hour?

I am all in favour of a cleaner, healthier world; though I also recall theories that too much hygiene can be counter-productive since the body’s built-in defences need some enemies to munch on in order to operate at full efficiency. It makes some kind of intuitive sense.

Still, if you would like your shiny new Apple iPad2 to be more germ-free than a toilet seat, it looks like an Antimicrobial Screen Protector is the answer.

Microsoft backs Telefonica’s BlueVia mobile SDK – but the market is fragmented

Announced at Mobile World Congress last month, BlueVia is Telefonica’s effort to attract developers to its app platform. Telefonica is the largest phone operator in Spain and also owns O2 in the UK, and has various other operations around the world.

In this case though, “Platform” is not just the devices connected to Telefonica networks, but also services exposed to apps via newly published APIs. BlueVia has APIs for sending and receiving SMS messages, delivering mobile ads, and obtaining information about the current user through a User Context API.

Things like sending a text from an app are nothing new, but a difference is that BlueVia will pay the developer a cut from the revenue generated. Along with ads, the idea is that an app can generate a revenue stream, rather than being just a one-off purchase.

The news today is that Microsoft is backing BlueVia with a toolset and marketing to Windows platform developers. There has been an SDK for Microsoft .NET for some time, but today Microsoft and BlueVia have delivered a new SDK for .NET which includes both server and client side support for the BlueVia APIs. On the server, there are templates for Windows Azure and for BlueVia ASP.NET MVC2 and WCF (Windows Communication Foundation) applications. On the client side, there are Silverlight controls such as a DialPad, an Advertising control, and a text to speech control. Microsoft also provides hooks to Windows Live Services in the hope that you will integrate these with your BlueVia applications.

The snag with developing your app with BlueVia APIs is that it will only work for Telefonica customers, thus restricting your market or forcing you to code to different APIs for other operators. “If you want to expose an API in the way that Telefonica is doing, you need to be a Telefonica customer in order to be able to use it,” says Jose Valles, Head of BlueVia at Telefonica.

If you further restrict your app’s market by targeting only Windows Phone, it gets small indeed.

Valles says there is hope for improvement. “We are working with the industry and with WAC in order to standardise this API,” says, assuring me that the reaction is “very positive”. WAC is the Wholesale Applications Community, a cross-industry forum for tackling fragmentation. Do not count on it though; it strikes me as unlikely that a cross-industry group would accept BlueVia’s APIs as-is.

There is also a glimpse of the challenges facing developers trying to exploit this market in the BlueVia forums. This user observes:

During the submission process we could only submit the app for a single device model while it is actually supported on hundreds of models. So please also explain how to specify all the supported models during the submission process

The answer: BlueVia has defined around 20 groups of compatible devices, and you can only upload your app for one at a time. 20 uploads is better than hundreds, but still demonstrates the effort involved in trying to attain any kind of broad reach through this channel.

BlueVia is in beta, but Valles says this will change “in the next few weeks”. That said, it is already up and running and has 600 developers signed up. “It is already commercial, whoever wants to come in just needs to email and we will send it to him,” he says.

The idea of the operator sharing its ongoing revenue with app developers is a good one, but be prepared to work hard to make it a reality.