I have a MacBook Pro that I'm using to develop an iOS app, and during development I have the app setup to connect to the mac's local ipv4 address instead of my production server address. However, multiple times a day I get the "The request timed out" error on my app (iPhone), and it persists for a few minutes. Then all of a sudden it will start working again, until it happens again, sometimes even 15 minutes later. During that "down" time I can still connect to to any other server from the phone, and I believe (it's been at least a year at this point) I have successfully sent some http requests to my Mac's ip from another local machine. I'm running XCode 14.2 (14C18), iOS 16.3.1 (app target at 16.0). The development machine is a MacBook Pro 13" (2017) with macOS Ventura 13.2.1, and I run the 3 services I need (httpd, mysql, php) through Brew (it was a while ago, but I believe I used Brew because I couldn't get it to work with the native installations). For what it's worth though, this issue has been happening on older macOS, iOS, and Xcode versions. Any ideas or pointers?

I'm developing on iOS, and Apple's docs on Verifying a User with Apple Sign In - https://developer.apple.com/documentation/sign_in_with_apple/sign_in_with_apple_rest_api/verifying_a_user state the following: You may verify the refresh token up to once a day to confirm that the user’s Apple ID on that device is still in good standing with Apple’s servers. Apple’s servers may throttle your call if you attempt to verify a user’s Apple ID more than once a day. I find this statement is a bit vague. What calls are in risk of getting throttled? Only validating the refresh_token? what about validating an authorization_code? What about validating a refresh_token obtained by a newly issued identity_token? I'm going through my login flow and realized that a user may sign out and re-sign in within the 24 hour span, thus risking the throttling. As far as I can see, I have two options: I would ask the user to Sign In with Apple (interactively), obtain a new identity_token (which I would immediately validate), then I would validate the authorization_code to obtain a new refresh_token. Is this process, so far, exempt from 24h throttling? And if so, is validating this new refresh_token also exempt from 24h throttling since it's originating from a new identity_token? Or would the old refresh_token still even work for that user? (in which case I could do option #2:  I would ask the user to Sign In with Apple (interactively), obtain a new identity_token (which I would immediately validate), but skip the authorization_code validation. Instead, I would still trust the old refresh_token, and validate it every 24 hours as usual. Any clarification would be appreciated, thank you!!