Tag Archives: appcelerator

development, javascript, mobile, software development, Web

Appcelerator plans to rethink Titanium architecture, standardise on WebKit JavaScript engine

3 Comments

Appcelerator CEO Jeff Haynie has posted about his plans for Titanium, the company’s cross-platform mobile development toolkit.

The plan is to completely rewrite the core engine, while maintaining a mostly-compatible API. Central to the plans is the idea of using one JavaScript engine on all platforms:

With Ti.Next, we’ve created a small microkernel design that will allow us to have minimal bootstrap code in the native language (C, Java, C#, etc) that talks to a common set of compilers, tools and a single JavaScript Virtual Machine. We have found a way to make the WebKit KJS VM work on multiple platforms instead of using different VMs per platform. This means we can heavily optimize the microkernel (herein after called the “TiRuntime”) and maintenance, optimizations and profiling can be greatly simplified. We’re talking about ~5K LOC vs. 100K LOC per platform.

This will make it possible to share almost all the Titanium code itself across all platforms. The Titanium runtime itself will be shared code written in JavaScript.

Appcelerator says that Titanium code will be “faster than native code in most situations.”

No date for Ti.Next is given though according to this slidedeck the plan is to have the “first set of developer builds available soon to GitHub repo – possibly in the next 45-60 days”. It adds, “production builds are a ways away.”

Using a WebKit JavaScript engine on Windows Phone, for example, sounds interesting.

.net, embarcadero, mobile, software development

Xamarin vs Titanium vs FireMonkey: should cross-platform tools abstract the GUI?

20 Comments

Cross-platform development is a big deal, and will continue to be so until a day comes when everyone uses the same platform. Android? HTML? WebKit? iOS? Windows? Maybe one day, but for now the world is multi-platform, and unless you can afford to ignore all platforms but one, or to develop independent projects for each platform, some kind of cross-platform approach makes sense, especially in mobile.

Sometimes I hear it said that there are essentially two approaches to cross-platform mobile apps. You can either use an embedded browser control and write a web app wrapped as a native app, as in Adobe PhoneGap/Cordova or the similar approach taken by Sencha, or you can use a cross-platform tool that creates native apps, such as Xamarin Studio, Appcelerator Titanium, or Embarcardero FireMonkey.

Within the second category though, there is diversity. In particular, they vary concerning the extent to which they abstract the user interface.

Here is the trade-off. If you design your cross-platform framework to include user interface widgets, like labels, buttons, grids and menus, then you can have your application work almost the same way on every platform. You can also have tools that build the user interface once for all the platforms. This is a big win in terms of coding effort. If the framework is well implemented, it will still adopt some of the characteristics native to each platform so that it looks more or less native.

Some tools do this by drawing their own controls. Embarcadero FireMonkey is in this category. Another approach is to use native controls where possible (in other words, to call the API that shows a button, rather than drawing the button with the graphics API), but to use custom drawing where necessary, even sometimes implementing a control from one platform on another. The downside is that because those controls are not in fact native, there will be some differences, perhaps obvious, perhaps subtle. Martin Fowler at ThoughtWorks refers to this as the uncanny valley and argues against emulated controls.

Further, if you are sharing the UI design across all platforms, it is hard to make your design feel equally right in all cases. It might be better to take the approach adopted by most games, using a design that is distinctive to your app and make a virtue of its consistency across platforms, even though it does not have the native look and feel on any platform.

Xamarin Studio on the other hand makes no attempt to provide a shared GUI framework:

We don’t try to provide a user interface abstraction layer that works across all the platforms. We think that’s a bad approach that leads to lowest common denominator user interfaces.*

CEO Nat Friedman told me. He is right; but the downside is the effort involved in maintaining two or more user interface designs for your app.

This is an old debate. One of the reasons IBM created Eclipse was a disagreement with Sun over the best way to design a cross-platform user interface framework. Sun’s Swing framework, derived from Netscape’s Internet Foundation Classes first released in 1996, takes the custom-drawn approach, which is why Swing apps always look like Swing apps (even if you apply the “Windows” look and feel). A team from IBM, some originally from Object Technology International which was a company acquired by IBM, believed it was better to wrap native controls with a Java abstraction layer, created SWT (Standard Widget Toolkit) to do that, and used it to build Eclipse.

Personally I am wary of toolkits which rely heavily on custom-drawn controls rather than native controls, though I see their value. On the other hand, Xamarin Studio is so far in the other direction that it removes some of the benefit of a cross-platform framework.

My prediction is that Xamarin will come up with its own GUI abstraction framework in future, along the lines of SWT. It is a compromise; but one which delivers a lot of value to developers who want to create cross-platform apps with the maximum amount of shared code.

*I have never understood this use of the term “lowest common demominator”. The LCD in maths is the lowest number into which a specific group of numbers divide exactly, so it is an elegant thing. In cross-platform what you should strive for is the highest common intersection: to make available all the features common to each platform.

Update: in April 2014 Xamarin announced Xamarin Forms, a GUI framework which wraps native controls in a XAML implementation (XAML is the presentation language also used by Microsoft, for WPF, Silverlight, Windows Phone and Windows Runtime (Windows 8) apps. There is a quick hands-on here.

microsoft, mobile, software development, windows

Appcelerator mobile developer survey shows Windows 8 progress, uncertainty

Cross-platform mobile tools vendor Appcelerator has released its latest mobile developer survey (in conjunction with IDC) representing the views of around 5,500 developers using its tools.

It is worth a read this time around. I was particularly interested to see what Appcelerator developers think of Windows 8, launching later this month. There is a chart showing the percentage of developers who are “very interested” in developing for various mobile platforms, and which shows Apple iOS leading at 85%/83% for iPhone and iPad, Android next, then HTML5, and then Windows 8 Tablets at 33% – already ahead of Windows Phone as well as Amazon and RIM devices (RIM has declined from 40% in January 2011).

image

The report says that potential Windows 8 developers are most interested in the “shared development capabilities between desktop and tablet promised by Microsoft with the launch of Windows 8.” I am not sure exactly what this means, and of course surveys like this are broad-brush and different developers will have meant different things. It could be about code sharing between desktop applications and Windows Runtime (WinRT) apps. It could be about the ability to run WinRT apps on the desktop as well as the tablet. It could be about Visual Studio and its ability to target multiple Windows platforms. However, the the survey goes on to talk about a “single paradigm for both desktop and tablet/smartphone applications” which seems to look forward to a future Windows where desktop applications really are legacy.

There is also a note that there were as many developers convinced that they will not be building apps for Windows 8 or Windows phone, as those who were.

What really counts is in the next paragraph in the report:

A large installed base of devices was the #1 criterion for 53% of developers when asked about why they choose to develop on a platform

This is the simple truth, which is why Microsoft has chosen a strategy which puts WinRT on every Windows 8 box whether or not it is really wanted.

The report also states that developers are dissatisfied with HTML5 for mobile applications, in terms of monetization, security, fragmentation, performance, and more. I suggest not taking too much account of this since Appcelerator’s Titanium tool is an alternative to HTML for mobile apps, so will have attracted those who do not want to use HTML5.

Finally, there is a fun section on what devices developers think they will be targeting in 2015. Televisions head the list, followed by connected cars. Most intriguing though are the final two: foldable screens and Google Glass. Apparently 67.1% believe Google Glass is in their future. Surveys, always entertaining but given the volatility of the results, not something you can rely on as a predictor.

mobile, open source, software development, web authoring

Appcelerator Titanium gets Mobile Web SDK, cloud services

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

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

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

image

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

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

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

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

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

“The second is reach beyond iOS and Android.”

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

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

image

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

image

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

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

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

image

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

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

mobile, open source, professional

Appcelerator CEO on EMEA expansion, Titanium vs PhoneGap, and how WebKit drives HTML5 standards

I spoke to Appcelerator CEO Jeff Haynie yesterday, just before today’s announcement of the opening of an EMEA headquarters in Reading. It has only 4 or 5 staff at the moment, mostly sales and marketing, but will expand into professional services and training.

Appcelerator’s product is a cross-platform (though see below) development platform for both desktop and mobile applications. The mobile aspect makes this a hot market to be in, and the company says it has annual growth of several hundred percent. “We’re not profitable yet, but we’ve got about 1300 customers now,” Haynie told me. “ On the developer numbers side, we’ve got about 235,000 mobile developers and about 35,000 apps that have been built.”

Jeff Haynie, Appcelerator

In November 2011, Red Hat invested in Appcelerator and announced a partnership based on using Titanium with OpenShift, Red Hat’s cloud platform.

Another cross-platform mobile toolkit is PhoneGap, which has received lots of attention following the acquisition of Nitobi, the company which built PhoneGap, by Adobe, and also the donation of PhoneGap to the Apache Foundation. I asked Haynie to explain how Titanium’s approach differs from that of PhoneGap.

Technically what we do and what PhoneGap does is a lot different. PhoneGap is about how do you take HTML and wrap it into a web browser and put it into a native container and expose some of the basic APIs. Titanium is really about how you expose JavaScript for an API for native capabilities, and have you build a real native application or an HTML5 application. We offer both a true native application – I mean the UI is native and you get full access to all the API as if you had written it native, but you are writing it in JavaScript. We have also got now an HTML5 product where that same codebase can be deployed into an HTML5 web-driven interface. We think that is wildly different technically and delivers a much better application.

Haynie agrees that cross-platform tools can compromise performance and design, and even resists placing Titanium in the cross-platform category:

Titanium is a real native UI. When you’re in an iPhone TableView it’s actually a real native TableView, not an HTML5 table that happens to look like a TableView. You get the best of both worlds. You get a JavaScript-driven, web-driven API, but when you actually create the app you get a real app. Then we have an open extensible API so it’s really easy if you want to expose additional capabilities or bring in third-party libraries, very similar to what you do in Java with JNI [Java Native Invocation].

The category has got a bit of a bad rap. We wouldn’t really describe ourselves as cross-platform. We’re really an API that allows you target multiple different devices. It’s not a write-once run anywhere, it’s really API driven.

80% of our core APIs are meant to be portable. Filesystems, threads, things like that. Even some of the UI layer, basic views and buttons and things like that. But then you have a Titanium iOS namespace [for example] which allows you to access all the iOS-specific APIs, that aren’t portable.

I asked Haynie for his perspective on the mobile platform wars. Apple and Android dominate, but what about the others?

RIM and Microsoft are fighting for third place. I would go long on Microsoft. Look at Xbox, look at the impact of long-term endeavours, they have the sustainability and the investment power to play the long game, especially in the enterprise. We’ll see Microsoft make significant strides in Windows 8 and beyond.

Even within Android, there are going to be a lot of different types of Android that will be both complementary and competitive with Google. They will continue to take the lion’s share of the market. Apple will be a smaller but highly profitable and vertically integrated ecosystem. In my opinion Microsoft is a bit of bridge between both. They’re more open than Apple, and more vertically integrated than Google, with tighter standardisation and stacks.

I wouldn’t quite count RIM out. They still have a decent market share, especially in certain parts of the world and certain types of application. But they’ve got a long way to go with their new platform.

So will Titanium support Windows 8 “Metro” apps, running on the new WinRT runtime?

Yes, we don’t have a date or anything to announce, but yes.

I was also interested in his thoughts on Adobe, particularly as there is some flow of employees from Adobe to Appcelerator. Is he seeing migration of developers from Flex, Flash and AIR to Titanium?

Adobe has had a tremendously successful product in Flash, the web wouldn’t be the web today if it wasn’t for Flash, but the advent of HTML5 is encroaching on that. How do they move to the next big thing, I don’t know if they have a next big thing? And they’re dealing in an ecosystem that’s not necessarily level ground. That’s churning lots of dissenting and different opinions inside Adobe, is what we’re hearing.

We’re seeing a large degree of people that are Flash, ActionScript oriented that are migrating. We’ve hired a number of people from Adobe. Quite a lot of people in our QA group actually came out of the Adobe AIR group. Adobe is a fantastic company, the question is what’s their future and what’s their plan?

FInally, we discussed web standards. With a product that depends on web technology, does Appcelerator get involved in the HTML5 standards process? The question prompted an intriguing response with regard to WebKit, the open source browser engine.

We’re heavily involved in the Eclipse foundation, but not in the W3C today. I spent about 3 and half years on the W3C in my last company, so I’m familiar with the process and the people. The W3C process is largely driven – and I know the PhoneGap people have tried to get involved – by the WHAT working group and the HTML5 working group, which ultimately are driven by the browser manufacturers … it’s a largely vendor-oriented, fragmented space right now, that’s the challenge. We still haven’t managed to get a royalty-free, IPR-free codec for video.

I’d also say that one of the biggest factors pushing HTML5 is less the standardisation itself and more WebKit. WebKit has become the de facto [standard], which has really been driven by Apple and Google and against Microsoft. That’s driving HTML5 forward as much as the working group itself.

apple, mobile, software development, web authoring

Appcelerator opens component marketplace for mobile developers

Appcelerator has launched its Mobile Marketplace, offering software components for mobile and web developers using Titanium, Appcelerator’s cross-platform toolkit for Apple iOS, Google Android, and others – though only iOS and Android seem to be supported in the Marketplace currently.

image

Developers create modules using the Titanium Module SDK, and get 70% of revenue.

I took a quick look and found it thought-provoking. I am a fan of user reviews, and one nice feature of the Mobile Marketplace is that it supports reviews and ratings. Finding out what other developers think of a particular component often involves trawling through Google searches, asking on forums and so on; a marketplace with authentic hands-on reviews has real value.

That said, when I checked out an example, LucidChart, which is a diagramming component with 5 star rating and four reviews, I was not impressed with the review quality, and puzzled that some of the reviews date from July, before the Marketplace opened. Still, developers can make their own judgment about the reliability of a particular review.

Many of the components are on a monthly subscription, on a per seat, per month basis. Some developers are uncomfortable with this model and the likely costs:

… charging such high monthly fees is a complete rip off. My entire Apple developer license only works out at $8.25, are you seriously thinking that a module is worth more than what Apple provide to developers for a fraction of the cost?

Another issue is that some of the products are not really code components, but developer services like TeamworkPM.

Some components are free though, and if the Marketplace attracts a reasonable level of traffic and interest then it could prove an excellent resource for Titanium developers.

iphone, mobile, professional, software development, visual studio

Hands On with Appcelerator Titanium Studio

1 Comment

I spent some time today trying out Appcelerator’s new Titanium Studio. Titanium is a cross-platform framework that lets you compile apps for Apple iOS, Google Android, RIM Blackberry, and desktop operating systems. Its chief attraction is the mobile aspect, particularly as it claims to build “native apps”.

I am thoroughly bored of writing calculator apps, but having embarked on this this test case I am keeping going since it makes it easier to compare one with another. I started by writing it for Android on Windows. I had some setup issues, but once resolved it pretty much worked, though the development process was fairly painful.  There is no visual GUI designer and my calculator has quite a few buttons, so I ended up counting pixels and trying out my work by debugging in the emulator. Performing a build and running in the emulator is a lengthy operation, so this is a tedious way to work. Come back Visual Studio, all is forgiven!

I persevered though, and eventually had my calculator up and running on my HTC Desire.

image

The design could be improved; but it is good enough for my purpose. Unfortunately though the GUI is not as responsive as I would like. It is easy to lose taps if you tap a little too fast, which is a serious flaw in a calculator. In this respect, the Titanium build is better than the PhoneGap/JQuery app I built, but still not good enough for a production app.

Time to port to iOS. Here I ran into a number of difficulties. I installing Titanium Studio on a Mac, copied the project from Windows and tried to open it. Titanium Studio complained about the absence of the Android SDK and eventually froze trying to fully initialize the workspace. Force Quit, delete the project, and try again. This time I created a new project and just copied over the app.js file that has my source code. Titanium Studio was happier; but the app would not open in the iOS Simulator.

The problem: I have installed the latest Xcode and IOS 5.0 beta SDK. Even if you target iOS 4.x, Titanium is not quite compatible. However, my iPhone is still on iOS 4.3, and I was able to deploy the app to the device. Unfortunately the GUI was scrambled. This is how it looked:

image

Not good. Eventually I worked out the problem. On Titanium for Android there is no need to specify the height of buttons and labels; this automatically sizes to the content. On iOS though, if you do not specify the height it stretches the object from whatever you specify as top down to the bottom of the container.

I added height attributes to sort out the GUI, though I am still scratching my head over one issue. I specified a different value for the top attribute of a label and a button, but they were rendered at the same vertical position. Odd. I simply compensated for this and ended up with a workable GUI. Here it is on the iPhone:

image

The good news: this is by far the best performing of all the cross-platform solutions I have tried. I cannot out-tap it, and it would be fine in this respect for a production app.

Note that attempting to debug using the community edition raises this message:

image

No debugging without a subscription; a strong incentive to subscribe.

It is also worth noting that you can open the project generated by Titanium in Xcode. I wondered if that might shed light on the compatibility issues. It is an interesting thing to try, as you see the innards of Titanium’s code, complete with a number of reported issues.

image

I also get this:

image

Still, time to wrap up. I am impressed with the performance of my app on the iPhone, but disappointed on Android. On the other hand, the whole point of Titanium is to achieve cross-platform, otherwise you might as well use Objective C. Of course there may be ways to improve the performance; I just dived in and tried out the tool without chasing up possible optimisations.

adobe, apple, eclipse, google, mobile, professional, software development

Appcelerator has released Titanium Studio, IDE for cross-platform mobile development

Appcelerator has released Titanium Studio, an IDE built with Aptana, the Eclipse-based IDE which the company acquired in January. It is an interesting products because it lets you build cross-platform mobile apps for Apple iOS, Google Android, and Blackberry, as well as desktop applications.

I downloaded the community edition and gave it a quick try. The download includes the Titanium SDK and is around 150MB.

Titanium Studio wanted to grab file associations for CSS, JS and PHP by default – but at least it asked first

image

I noticed lots of Python scripts getting installed. The install completed and I was up and running.

Running the IDE requires login, which seems intrusive. You can avoid this by going offline.

image

I created a new empty Android 2.2 project and got an error on first run. Required jarsigner not found. Required javac not found.

image

I fixed this by adding the JDK to the path and setting Java_home to the JDK; previously my Adobe CS5 install had set this to its own JRE install.

Next, I built a hello world application.

image

It feels like a version 1.0 release. When I clicked Run it started the emulator but did not run the app for some reason. A second run after the emulator had opened worked. Code Assist seems a bit hit or miss. There it tooltip help for some keywords, but too brief to be much use, and pressing F1 is unrewarding. No visual GUI designer. Finally, and this is purely a personal thing, the editor has a black background – something I will be sure to change soon.

Nevertheless, this is a step forward for Titanium and presuming the apps perform well I think it is significant and worth investigating.

development, mobile, professional, software development, web authoring

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

2 Comments

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

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

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

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

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

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

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

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

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

apple, google, microsoft, mobile, nokia, professional, software development, sony

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.