Waiting for Godot ... er, Cobalt

At Skip, we're creating a native (well, 68K, so native vis-a-vis Java) client for the Palm. In particular, we're targeting the many Palm Treo smartphone users, who deserve a more robust Skip experience than Java has been able to deliver.

In the process of building this client, we've been stunned by the huge gaping hole that is the Palm high-level app development platform.

Since ours is a high-level business/productivity type app, since the client is not complex, and since we support many platforms, some sort of RAD tool or at least high-level API is ideal for client development.

The amazing thing is that the space is a gaping void, where only a handful of tiny ISVs with proprietary tools play.

IBM hasn't updated its Java implementation for Palm in several years ... it's not great, not free, and has no roadmap into the future. At the other end of the spectrum, PalmOS has a broad C API, but this is no high-productivity environment (it's more like C for Win 3.1). Not to mention that using many third-party C libraries requires assembly hacking and linker foo, not ./configure and make.

Adobe could push the Build button and release a Flash player for the Treo that would instantly become the high-level environment of choice for 21st-century connected apps. And the great UI possibilities would be a bonus!

The lack of a top-notch development system is even more mysterious given the large community of Treo users and thriving (by PDA/phone standards) ISV app ecosystem. In other words, the Palm Treo area is one of the most successful and least risky places to invest in infrastructure, with the highest potential return.

Presumably this whole situation stems from the prolonged wait for imaginary Cobalt devices. That's going to make things all better. Real soon now.