Well I've no idea what this has to do with smartphone apps, but I'll bite.
1) Most public key products do use symmetric encryption for actual data transfer. The public key bit handles mutual authentication and the generation and exchange of the symmetric key. Your approach does this ahead of time, by throwing a crap ton of them in a file and copying it to the remote host (via what, sftp?).
2) The advantage of public key crypto is that there is (or should be) precisely one copy of my secret (the private key), so I have some hope of being able to control it. In your approach there is one copy per host. In a non trivial deployment managing that file to keep it (a) private and (b) current is going to be extremely difficult. All I need is one copy of that file (or a portion of it) and I can snoop any channel and modify any message in transit. The use of UDP is puzzling as I'm pretty sure that makes message tampering even easier (although I'm not enough of an expert to say that for certain).
3) I don't see the point of the passwords/hashes on top of the keys. If I have the key I can communicate with you, if I don't I can't. Adding another secret which is in the same file as the key doesn't seem to add anything (for one thing, if I have the key and can listen in on messages I can easily extract the passwords as they fly by).
4) All the stuff about file "copy numbers" is meaningless as you are trusting the peer to tell you honestly which copy it has. Rule number 1 in network security is you never, ever, trust the other side. Listener copy numbers are "256 and up" so I can just make up a random number in the 100000 range and I'm very unlikely to collide with yours, so the check passes trivially.
5) There's no host level identity. How do I know I'm talking to the host I think I'm talking to? All someone with a copy of the key file has to do is change the copy number and they can masquerade as any host on the network (with an appropriate DNS/IP spoof or whatever). SSH prevents that because knowing one host's signature doesn't help you guess another.
6) There's no user level identity. Who is logging in to this box? Are they actually allowed to do so?
7) Changing the keys all the time is pointless. Assuming I'm using a good cipher, extracting the key from the encoded stream should be essentially impossible, so changing it likely won't improve security. Moreover, if I have one of your keys I probably have all of them, so changing it won't stop me. Further, having to allow for clock skew introduces complexity which is potentially exploitable. If you were generating random session keys dynamically and exchanging them out of band somehow then periodic rolling wouldn't be a bad idea (because I'd have had to crack the crypto to figure out the first key. and now I have to start all over again).
There's more I'm sure, but it's late :)