Titanium SDK 10.0 Cloud Offline Sync: Unresolved Cost‑Control Decision

Short answer

You cannot bound Cloud request costs from the SDK 10.0 documentation alone. The Cloud module queues offline mutations and replays them as individual API requests, but the docs do not define the lifecycle event that fires the replay, and quota accounting is decided by your Cloud plan, not by the SDK. The missing decision point is a documented sync-trigger contract plus a manual-sync-only mode — neither is clearly documented, so the only reliable cost control today is to stop relying on automatic replay and sync explicitly.

What is confirmed vs. what is assumed

Confirmed by the documented model: changes made offline are queued locally and sent to the Cloud backend on sync. Each queued change becomes its own request, so N offline edits become a burst of N requests at sync time. Request quotas and pricing are enforced server-side by your Cloud plan.

Assumed, not verified for 10.0: the exact trigger (app resume, a connectivity listener, or only an explicit sync call) is not pinned down in the documentation, and it may differ between iOS and Android because the underlying connectivity and background-fetch mechanisms differ. Treat any claim about a specific trigger as unverified until you observe it.

Answers to the three questions

1. What triggers automatic sync? Not documented precisely for SDK 10.0. The realistic candidates are app resume or a network-restore listener, but this must be measured, not assumed.
2. Does sync traffic count against the free tier? Almost certainly yes in principle — quota is enforced server-side per request, and the server cannot distinguish a replayed offline write from a live one. There is no client-side mechanism that could exempt sync traffic from quota. Confirm against your current plan's terms, because plan definitions are vendor-controlled and may have changed.
3. Is there a documented "disable automatic sync" switch? No widely documented toggle exists. Check the installed module's source and changelog for sync-related flags before concluding none exist in your exact version.

How to close the gap yourself

Run a controlled measurement before making the cost decision:

1. Route the device or emulator through a logging proxy (e.g., mitmproxy or Charles) or add a request counter around Cloud calls.
2. Go offline, make a known number of edits (say 5), then restore connectivity without touching the UI.
3. Record which lifecycle moment fires the replay and how many requests leave the device. Repeat on both iOS and Android — timing and burstiness may differ.

If the burst fires on connectivity restore with no opt-out, the cost-safe architecture is: queue edits yourself (or leave the queue unused for cost-sensitive entities), batch them, and call sync explicitly on a schedule you control — for example, on user action or a throttled timer rather than on every network flap.

Important caveat

Appcelerator Titanium and the Arrow/ACS Cloud backend have gone through major lifecycle changes, including end-of-life announcements and community forks. Any statement here about current tiers, free-quota limits, or SDK 10.0 behavior may be outdated. Verify the plan's request accounting in the current vendor console and confirm sync behavior against the exact module version you ship. The one detail that would change this recommendation is whether your installed module version exposes a sync configuration flag — check its changelog first.