Please update the docs for the registerSyncEnabledGeodatabase to mention that timeouts for that command can be fixed by adjusting the timeoutInterval property of AGSRequestConfiguration. The default is 60 seconds, and much time was lost determining whether the timeout was coming from the OS, the server, or the Runtime SDK. Increasing the timeoutInterval property allows for a more forgiving client when a field crew is on a slow network, or once the organization's feature service becomes big enough to start slowing down. Any mention in the docs of controlling registerSyncEnabledGeodatabase through AGSRequestConfiguration would have saved us a lot of time.
The registerSyncEnabledGeodatabase command is a client-side wrapper around a call to the ArcGIS Server "createReplica" command, one of the functions of a sync-enabled feature service. I confirmed through REST endpoint tests after watching web traffic through a Fiddler proxy that the createReplica service itself was well past 70 seconds response time, and that the response content was successful and valid.
This can affect any organization that uses the preplanned disconnected editing workflow once their geodatabase, feature service, and number of users reaches high enough maturity to slow down registration past the default timeout of 60 seconds. For reference, my organization has ~1000 field data collection devices, just over 100 feature classes, an enterprise geodatabase that has been around for about a year, about 500,000 features, and just over 5000 replicas. We support nightly automatic creation of the latest preplanned offline geodatabase for download, and we typically see about one to two thousand syncs per week. When we first deployed, offline geodatabase registration never reached 60 seconds, though it would be an issue from some field offices with slow network connections. Current speed of the createReplica command for our production service is about 80 seconds.
Thank you
-Reed