Our first standard client was a stand-alone Java WebApp. This client (still available) takes a minimalist approach, providing only the functionality required to access a user's cloud wallet and interface with the exchange, and nothing more. There are also several older clients, developed by the Voucher-Safe project.
Installed Client
Allegedly due to "security concerns," Oracle has recently been making it very cumbersome for users, particularly on Windows, to download and operate Java WebApps (aka Rich Internet Applications, or RIAs). Our minimal client is such an application. While a user (even on Windows) can still specify the site as a security exception, and click past all the annoying security warnings, it's neither convenient nor reassuring to do so. Oddly, Oracle appears to be discouraging the use of its own technology, or shilling for the certificate mafia, or maybe both.
Integrated Jabber Client
A private side communication channel by which users of cryptocurrency wallets can communicate with one another is inherently useful. For example, we see this with Glyph being used in the Bitcoin community, or encrypted p2p messaging being integrated into the wallets from KryptoKit and OpenTransactions. However, there seems little reason to develop entire new protocols for instant messaging, given the existence of Jabber (aka XMPP). As Henry Spencer used to say, "Reinvented wheels are often square."
Because the SilentVault wallet application is based on extensions to XMPP, the next logical step for us was to embed its functionality into a full-function Jabber client. The obvious candidate for this was Spark, from Ignite Realtime. Spark is open source, written in Java, and supports a plugin architecture. In fact, the original Voucher-Safe wallet client was first written as a Spark plugin, so with this code in hand it was a relatively easy port to provide a plugin incorporating the entire SilentVault client. Since it is permitted to rebrand and redistribute Spark, this was done. A full-blown Jabber client also provides access to multi-user group chat, drag-and-drop file sharing, and even audio-video conferencing (depending on the capabilities of the server). Moreover an installed client eliminates recent problems created by Oracle (described above) as they bizarrely try to discourage the use of their own RIAs.
Android Client
Since the present client is written in Java, a port to Android would not require a ground-up rewrite — although it would necessitate a complete retooling of the GUI. Indeed, certain functionality such as XML pull parsers and DOM processing are included in standard Android deployments, which would avoid the inclusion of several third-party JAR files. The issue with 'droid support is the almost complete lack of security for the devices themselves. Androids are phones, delivered by large telcos, which as Snowden has amply demonstrated are completely under the thumb of intrusive, often lawless governments. Concerns exist not only about the Android O/S itself, but also about the underlying broadband O/S that it runs on, even about the hardware. The NSA has been caught boasting that it has a 100% success rate compromising Apple iPhones; is there any reason to think that the rate would be less with most Androids?
Perhaps this is why Silent Circle, whose metier is providing end-to-end crypto apps for smartphones, is now embarking on a new project to supply the entire phone from hardware up. This new product has been dubbed the Blackphone. Perhaps this would be an ideal platform to port to.
Because of our reservations about security, we have not pursued the Android port. This may change in the future as we monitor developments in this space.