Terms
These current terms summarize how access, permissions, syncing, and account controls are documented for MySched today. This page is intentionally limited to documented app behavior from the architecture reference rather than adding unsupported legal boilerplate.
Contact and scope
For account deletion or privacy concerns, contact privacy@getmysched.com. This route reflects the current product behavior documented in the published architecture reference.
Intended use
The architecture docs describe MySched as a college scheduling app built to help students scan a registration card, review imported classes, keep schedules in one place, and manage reminders.
The same documentation states that the app is designed for college students, typically 18 and older, with no advertising, no tracking, and no features aimed at minors.
Account access
The published authentication flow supports these sign-in methods:
- Email and password on all supported platforms.
- Google sign-in on Android and iOS.
- Apple sign-in on iOS.
Email registration is documented as collecting full name, student ID, email, and password, then sending a verification code before the account becomes active.
Failed email-password logins are tracked server-side. After five or more failed attempts, the account is documented as locked for 15 minutes.
Permissions and device behavior
- Camera access is used for OCR scanning.
- Notifications and exact alarms are used for class reminders.
- Photo library access is optional and used only for image import.
- If a permission is denied, the documented behavior is graceful degradation instead of full app failure.
The permissions model also documents point-of-use requests, clear rationale messaging before system prompts, and settings links when a permission is permanently denied.
Offline, sync, and queue limits
MySched is documented as offline-first: it reads from local cache first, applies optimistic updates, queues failed writes, and syncs back when connectivity returns.
The offline queue is documented with a maximum size of 100 items, a maximum of 5 retries per item, and a maximum age of 14 days. Items that continue failing move to a dead-letter queue for up to 30 days.
Conflict resolution is also documented: create conflicts favor the server version, updates use last write wins by timestamp, and deletes win when delete conflicts occur.
Sessions and security
Sessions are stored in platform-secure storage, refreshed when needed, and checked for stale or invalid tokens. On the web, secure session data is documented as in-memory only and not persisted to disk.
Password changes sign out other sessions. Normal logout is documented as a global sign-out that clears local state such as cached schedules, profile cache, notification schedules, settings cache, and session tokens.
Account deletion
The architecture docs describe in-app account deletion at Settings → Account → Delete Account, with password confirmation for email-password accounts and authenticated confirmation for OAuth accounts.
The documented deletion flow permanently removes:
- Profile and personal information.
- Class schedule and custom classes.
- Reminders and settings.
- Avatar storage and related authentication records.
The same docs state that deletion completes immediately, clears local device data, signs the user out, and does not require contacting support.