The documentation of the responsiveData network service type simply says "A service type for data that the user is actively waiting for."
Reading an NSHipster post from when this was introduced in iOS 12:
...guidance from the engineers presenting WWDC 2018 Session 714: “Optimizing Your App for Today’s Internet” is to use this feature judiciously, only when time is of the essence. The example they provide is “the checkout page for a shopping app”...
My question: how far does 'responsive' extend to other use cases?
In an app where the user primarily interacts with a list of friends or a list of chats for example, would fetching this list of friends or chats fall under the 'responsive data' type, or would that primarily be used for instant messaging itself?
how far does 'responsive' extend to other use cases?
It kinda depends…
In an app where the user primarily interacts with a list of friends or a list of chats for example, would fetching this list of friends or chats fall under the ‘responsive data’ type, or would that primarily be used for instant messaging itself?
… even in a concrete scenario like this.
Consider your list of friends. It’d probably make sense to cache this locally, and the requests used to sync up that cache should be .default rather than .responsiveData. OTOH, if you’re implement a friend filter feature — imagine the user is typing in the To box and you want to display the list of matches — then any requests you generate should be .responsiveData.
In short, it’s about user expectations. If the user is staring at a spinner waiting for the data to show up then .responsiveData is warranted.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
