@mike623317: no TITAN .. possibly never .. due to the ECC tech and transaction scanning requirement
Certainly supporting TITAN should not be a priority for the mobile wallet, but I think "never" is too strong. TITAN should definitely be eventually made available on mobile clients since mobile users want privacy too.
I don't see how the ECC tech would make it limited to desktops/laptops but not suitable for mobile (assuming only relevant transactions are processed). The transaction scanning requirement is the only problem with mobile clients. The full blockchain should of course not be processed on a mobile device but that is the reason for the mail server: to notify the client about the subset of transactions in the blockchain meant for the user so that the client can selectively retrieve from the server and process the data for only those transactions.
I think better compatibility between TITAN and non-TITAN usage is really important. Full clients should easily be able to withdraw funds from their TITAN balances or non-TITAN addresses and send the funds privately to TITAN accounts and publicly to non-TITAN addresses (in both cases with an encrypted memo and private sender information included). Mobile clients should be able to publicly withdraw funds from their non-TITAN addresses and send them to TITAN accounts and non-TITAN addresses (again an encrypted memo could be included as well as the private sender information, but the sender information would in most cases would not really be private since the public will know the sender is associated with the public non-TITAN address the funds were withdrawn from). The only permutation left is mobile clients withdrawing funds from TITAN balances and sending them to TITAN accounts and non-TITAN addresses, which is not feasible without the mail server (that is the very low priority feature).
I would like to see the same UX on full clients and mobile clients in which a checkbox distinguishes whether the transfer was going to the user's public balance (the non-TITAN address corresponding to their active public key) or to their private balance (regular TITAN procedure). In either case, I think the to field should be the user's BTS account name (or a local alias) and not the ugly addresses. In the case of the mobile client, the client could retrieve the active public key of a BTS account name from the server and just trust the server is honest, or the user could pin the active public key along with the corresponding BTS account name to their address book after verifying out-of-band that it is correct (bonus points for a feature in the mobile client that allows trading this contact information between two smartphones automatically using NFC or Bluetooth).