Hi Jinesh,
The simulator app will use the Mac NIC (wired or wireless, you need to know when you capture) to reach the outside world.
Capturing the app traffic will depend on how your simulator "talks" to that outside world.
I don't know about the iOS simulator but the logic is probably the same as for other types of virtualization.
Bridge mode
If the simulator has its own IP address (sometimes called Bridged Networking) then you should be able to use a pretty simple display filter to show the traffic for that IP address only. (Where 1.2.3.4 is the IP used by the app on the simulator.)
ip.addr == 1.2.3.4
NAT mode
If the simulator "shares" the NIC with the Mac then it may be using NAT.
Filtering the traffic may prove more difficult because you won't be able to easily tell if the traffic is coming from the Mac itself or the simulator.
You'll have better chance of capturing the API calls if you don't run ANYTHING else on the Mac beside the simulator when you do capture the traffic. Timing is everything so maybe displaying the system clock and launching the API call at an exact time may help retrieve the packets.
If you launched the API call at exactly 15:32:00 then look for TCP SYN packets around that time.
You can display all TCP SYN segments with this filter.
(tcp.flags.syn == 1) && (tcp.flags.ack == 0)
You then look inside the TCP segment in the packet details to find the TCP stream index for that traffic.
Display all packets for that TCP conversation using this filter:
tcp.stream eq 0
Know the destination IP?
If you know the server's IP address (the destination of the API calls) then you can also use a display filter to only show traffic to and from that IP.
ip.addr == 5.6.7.8
Hope this helps.
Cheers,
JF