How I replaced GTLR with a lean REST setup—token-based Google Drive integration using URLSession, safer secrets, and fewer moving parts.

GTLR is gone from my stack. I rebuilt file list, upload, and metadata calls with token-based Google Drive integration using pure REST and URLSession. The result: smaller binaries, clearer errors, and auth I actually understand. This post shows the moving pieces, pitfalls, and a copy-paste checklist you can apply today. For layout sanity while rebuilding screens, I leaned on Golden Scaling in Practice—pre-deciding anchors kept my UI and my head calm during refactors.

Why token-based Google Drive integration?

Libraries hide complexity—until they don’t. A direct REST approach gives you explicit control over scopes, refresh timing, and retries. With a short AuthService, I trade magical “it works” for transparent calls I can reason about. See my earlier context in LifeOS Dev Log: Drive Tokens & List/Grid Toggle for how this started.

Core flow for token-based Google Drive integration

1. Sign in & get tokens. Use Google Sign-In to obtain an access token and refresh token (on first consent).
2. Store securely. Keep tokens in Keychain; never in UserDefaults or the document.
3. Attach bearer. Each request sets Authorization: Bearer <access_token>.
4. Auto-refresh. On 401, refresh using the OAuth token endpoint and retry once.
5. Call Drive v3. Hit /drive/v3/files for list/search, /upload/drive/v3/files for media.

Minimal checklist for token-based Google Drive integration

• Scopes: request the smallest set that covers your features (drive.file beats drive).
• Expiry: track expires_in and refresh proactively at ~80% of lifetime.
• Retries: 1 refresh retry max; then sign-in flow.
• Logging: log request ids + status codes, redact tokens.

Endpoints you’ll call (REST)

• List files: GET https://www.googleapis.com/drive/v3/files?q=name contains 'doc'&fields=files(id,name,mimeType,modifiedTime,size)
• Upload (simple): POST https://www.googleapis.com/upload/drive/v3/files?uploadType=media
• Upload (multipart): POST https://www.googleapis.com/upload/drive/v3/files?uploadType=multipart
• Refresh token: POST https://oauth2.googleapis.com/token

The official references are clear and current: Drive API (REST) Overview and Google Identity: OAuth 2.0.

UI notes (because UX still matters)

Token work is plumbing; users feel rhythm. Anchor your headline on 3/5, your primary action (Upload / Connect) on 5/8, and stick to one gutter (8/13/21). These small rules keep “settings” screens from feeling like a spreadsheet.

Common mistakes (and quick fixes)

• Using broad scopes: start with drive.file; escalate only if required.
• Storing tokens loosely: Keychain or secure enclave wrappers—always.
• No refresh guard: limit retries to prevent loops.
• JSON field bloat: set fields= to exactly what you render; faster and cheaper.
• Blocking the UI: do I/O off the main actor; stream uploads when possible.

What I cut (and didn’t miss)

• Heavy client libs, auto-generated models, opaque errors.
• I kept: typed request builders, small decoders, and a single HTTPClient with request/response logging (redacted).

Ship it

Start by swapping your file list screen to REST calls behind an AuthService. If it feels good, move uploads and metadata next. When you hit the first 401 in the wild, you’ll be glad you understand the flow. Download the starter snippet for URLSession + refresh and make your Drive calls boring—in the best way.

- randomblink