Apple's latest security documentation indicates that it now uses CTR_DRBG for generating pseudo-random numbers (previously Yarrow instead of CTR_DRBG), using "timing variations during boot" and "interrupt timing once the device has booted" as seeds. Calls to the iOS API SecRandomCopyBytes will retrieve random bytes from /dev/random by default. Apple's random(4) man page seems to suggest that their /dev/random is non-blocking, but that it somehow does not need to block in order to ensure fresh entropic bytes:
/dev/urandom is a compatibility nod to Linux. On Linux, /dev/urandom will produce lower quality output if the entropy pool drains, while /dev/random will prefer to block and wait for additional entropy to be collected. With Yarrow, this choice and distinction is not necessary, and the two devices behave identically. You may use either.
NIST's DRBG validation list indicates that Apple is using AES-128 in counter mode as a pseudo-random function for CTR_DRBG.
So, how many bits of entropy can we expect out of SecRandomCopyBytes? If I query it for 256 bits of entropy, will I instead get 128 bits of reasonably entropic data, potentially followed by another 128 bits of less entropy data due to the lack of blocking in iOS's /dev/random?