There is another aspect to this that is being missed in the other answers. As per the Core BLE specification, only one advertising channel is being looked at during each scanInterval and is rotated to the next of 3 channels with each interval. So if there is RF interference on that channel you might not see the device even if you have the scanWindow equal to the scanInterval in order to do continuous scanning.
The BLE peripheral device that does advertising would normally rotate through all three advertising channels in sequence very quickly during each advertising blip of time. So the best central device scanning algorithm would have shorter windows and intervals in order to sequentially check each advertising channel. Apple apparently uses a 30 ms scanWindow with 40 ms scanInterval in iOS with apps in foreground mode. That means that each advertising channel will be checked every 40 ms. Per the BLE Core Specification:
Each advertising event is composed of one or more advertising PDUs sent on
used advertising channel indices. The advertising event shall be closed after
one advertising PDU has been sent on each of the used advertising channel
indices (see Section 18.104.22.168) or the advertiser may close an advertising event
earlier to accommodate other functionality.
Another very important aspect is to have the Peripheral device set an advertising interval that is relatively prime compared to the scanInterval on the Central device. This is why Apple specifies specific advertising intervals. If you were to pick a scanInterval of 100 ms with a scanWindow that was smaller, say 80 ms and had an advertising interval of 1000 ms (1 second), then you could get unlucky and always be advertising during the 20 ms when the Central device was not scanning during each scanInterval. In reality, the BLE core specification adds a random 0-10 ms to the advertising interval which helps slew to prevent a complete deadlock, but it's really done more to avoid multiple devices advertising at nearly exactly the same time from interfering with each other forever.
For all undirected advertising events or connectable directed advertising
events used in a low duty cycle mode, the time between the start of two
advertising events (T_advEvent) is computed as follows for each
T_advEvent = advInterval + advDelay
The advInterval shall be an integer multiple of 0.625 ms in the range of 20 ms
to 10.24 s. If the advertising event type is either a scannable undirected
type or a non-connectable undirected event type, the advInterval shall not be
less than 100 ms. If the advertising event type is a connectable undirected
event type or connectable directed event type used in a low duty cycle mode,
the advInterval can be 20 ms or greater.
The advDelay is a pseudo-random value with a range of 0 ms to 10 ms generated
by the Link Layer for each advertising event.
Think of having two frequencies near each other and how you get a beat frequency of their difference. That is essentially what can happen between the scanInterval and the advertising interval. Apple did a decent job with their settings for this so following their standards would not only work well for iOS but also for Android. Apple's foreground mode of 30 ms scanWindow with 40 ms scanInterval means that for a base advertising interval of 1022.5 ms that you see the device within 1 second about 3/4ths of the time and always within 2 seconds, assuming no RF interference obscuring the advertising packet. In background mode with a 30 ms scanWindow and 300 ms scanInterval, the median time becomes 5 seconds and the usual maximum becomes 19 seconds though with very bad luck of the random shifts it could be a little longer.
The Apple recommended peripheral advertising intervals are 152.5, 211.25, 318.75, 417.5, 546.25, 760, 852.5, 1022.5, 1285 ms.