BLE Scan interval and window
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 4.4.2.1) 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
  consecutive
  advertising events (T_advEvent) is computed as follows for each
  advertising event:

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
  event
  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.

https://developer.apple.com/hardwaredrivers/BluetoothDesignGuidelines.pdf

The Apple recommended peripheral advertising intervals are 152.5, 211.25, 318.75, 417.5, 546.25, 760, 852.5, 1022.5, 1285 ms.