Mobile and Web SDK: Split changes rolls out slowly to user devices.

Issue

When making a change to a Split in Split UI, the Mobile (iOS and Android) and Javascript Browser SDKs do not reflect that change at the same time, rather small population of devices are synched in the first day, then more user devices get synched in subsequent days until all SDKs are updated. 

Why would the Split change propagation goes too slow to user devices?

Root Cause

This scenario have two potential root causes:

1. The code in mobile app or web page does not listen to SDK_READY event, and thus will use the stored cache from the last user session. Which is not synched to latest changes. When user hit the page the next day, the existing cache got synched from the previous day, so the change is detected now and reflected in the impression.
2. The code in mobile app or web page listen to SDK_READY_FROM_CACHE event only and trigger the treatments after that event fires, this event will fire if the SDK detected the cache exist in App/Browser filesystem, which is not synched yet with latest changes. That is why the treatments will always reflect the cache in previous user session.

Solution

Always implement calculating treatment when SDK_READY event fires, this event fires only when the sync is finished with Split cloud and will guarantee the latest changes are reflected in the cache.

While the SDK_READY_FROM_CACHE are very useful to allow calculating treatments quickly, it is recommended to check the treatment again after SDK_READY and reflect the treatment in case there is a change.