That's a question without much to go on. What have you tried, and why didn't it work?

I would suggest a logical star topology -- elect one of the iPhones as the "hub" (server) and all the others send to that. That then echoes back aggregate packets to all the "spokes" (clients). This is similar to how games like Quake or Counterstrike or Minecraft work on the Internet today.

Quote:What coding standards and techniques should i use to hide this delay and lag?

That depends on what type of game you're building.

If your send rate is 20 packets per second, then you should expect a latency of no more than 100 milliseconds. You may want to develop some timing code that verifies that you're not seeing more latency than you expect. Also, if it's low-power devices, you may not be able to keep up a high rate of packet sending, which would increase the latency.

Often, the "hiding" of latency has to be done in game design, rather than in any particular technical solution. Latency is latency; at a fundamental level you cannot make it lower than the technological limitations.

The main tool in your toolchest is guessing. For example, when the user presses a command button, you can guess that the command will work fine, and show the result immediately to the user. When the result comes back from the server, if it doesn't work, then you have to change the display of the command to make it clear that it didn't work. How to make this acceptable to the user is a presentation issue, not a technical issue.

It shows around 22 to 30 seconds gap between server's and client time.

There are two kinds of dis-sync:
1) a difference in absolute time (from a second, to an hour, to potentially years if the clock is out of date)
2) a different in rate of progression

Within a single game, you may be able to assume that 2) doesn't matter. Thus, the only thing you need to compensate for is 1).
This is not that hard. When the client connects, it can send a copy of its current time stamp. When the server sends a response packet, it can include:
a: the timestamp that the client sent
b: the server timestamp at the time the packet was received
c: the server timestamp at which the packet is sent
The client can then, in turn, add d: its timestamp for when it received that packet.

Now, you have enough information to measure round trip time through the system and network. A reasonable estimate is rtt = ((d - a) - (c - )/2.
You also have an estimate for the difference between server and client clock. It will be offset = ((d - c - rtt) + (b - a - rtt)) / 2.
Now you can easily estimate the server clock simply by taking local time and subtracting "offset" (which may be negative).

Another option is to run the simulation in fixed time steps, and calculate all actions based on integral time steps. All you need is a mapping from local clock to time step, which you can establish by seeing what time step the server provides in its packets updating the client.

I think it should be "offset =((c - d + rtt) + (b - a - rtt)) / 2". I got this information from website : "http://www.mindcontrol.org/~hplus/time-offset.html".

Hey, I wrote that article :-) I should just have pointed at that.
Yes, it's quite likely I got one of the terms wrong.

Anyway, yes, the approach you take is one way that games use the clock to display predicted positions. There are other ways, such as only ever displaying an entity in the "past" so that you know that you're displaying it at the correct location. The drawback there is that you get higher visible latency.