By offline signing I guess you mean the ability to transfer sufficient unsigned data to an offline wallet, have it create a signed transaction, and then transfer the transaction to the online wallet. We have been thinking about that for a long time but there are a few things holding us back.
1. For security reasons it is not enough to just transfer the unsigned transaction offline. You need to transfer all the complete set of transactions that fund the new transaction. This allows the offline signer to verify that you do not pay an exorbitant fee. This can easily mean tens or hundreds of kilo bytes of data. Using animated QR codes will not suffice. You need something like a USB stick or a bluetooth (which may open another attack vector)
Right. It's important that the offline device be made aware of the parent transactions in order to know the value that it's signing for. So like you said, QR codes are not practical due to the potentially-large volume of transacted data. The natural solution to this for mobile devices IMO is NFC. NFC supports bi-directional communication at least as fast as 106 kbps, is extremely short range, and generates a magnetic field that can power a low-cost microcontroller and a display (think NFC version of Trezor).
I am not saying that we will not do it, but it is not as trivial as it may seem.
It's not trivial at all. I think for this to be useful, the community needs to work towards a BIP that tries to define an open and flexible protocol for inter-wallet transactions, perhaps built off the payment protocol (BIP70). It could work over USB / NFC / etc by defining only a new transport layer. I'm wondering if it's possible that such a protocol can be sufficiently flexible to define wallet-to-wallet transfers between online/online and online/offline devices, as well as bitcoin payments at brick-and-mortar stores.