Forem: Oleksandr Prudnikov

How I Synced 100K Items from an iOS App Using CSV & GZIP (No Backend)

Oleksandr Prudnikov — Mon, 06 Apr 2026 21:35:00 +0000

I'm building an iOS inventory tracker. Users add items at markets — often with no mobile signal — and want to see everything in a spreadsheet on their laptop later. The app needed to be offline-first and the sync needed to just work.

The problem with Google Sheets API

My first approach: use the Sheets API to update individual cells as users make changes. User taps a price, queue the cell update, sync when online.

Two problems killed this.

Queueing was fragile. When a user toggles a field quickly — yes, no, no, yes, no — the queue needs to reflect the final state, not deduplicate away intermediate changes. I hit a bug where deduplication logic was collapsing the queue incorrectly, sending stale values. Fixing it properly meant building a mini sync engine for what is essentially a data export.

Google's permission model. The Sheets API has no restricted scope. If your app can read one spreadsheet, it can read every spreadsheet on the user's account. The OAuth consent screen would say "allow this app to read and edit ALL your spreadsheets." That's a terrible first impression.

To get this scope approved, Google requires video verification — record a demo, explain why you need access, wait for manual review. I had users on a waitlist. Spending weeks on Google verification while they lose interest was not an option.

The CSV-to-Drive approach

Instead of updating cells one by one, I upload the entire inventory as a single CSV file to Google Drive. The trick: set the MIME type to application/vnd.google-apps.spreadsheet and Google converts it into a Sheets document automatically.

The Google Drive drive.file scope only allows your app to access files it created — it cannot touch anything else on the user's Drive. This scope is auto-approved with no verification required. No video demo, no waiting, no scary consent screen.

From the user's perspective nothing changed. They get a spreadsheet link, open it, see all their items with prices and calculations. They don't care that it's a CSV behind the scenes.

The file size problem and GZIP

I stress-tested the app with 100,000 inventory items. The CSV was huge. Each row implicitly carries the weight of column headers, commas, and quotes. Uploading this over mobile every time the user closes the app was not going to work.

At a previous job I'd seen microservices communicate with Content-Encoding: gzip headers — compressed traffic between APIs to reduce latency. I knew the concept but hadn't applied it to file uploads.

Before GZIP, I spent time manually optimising the CSV — truncating column headers, stripping null values, omitting trailing empty fields. Google Drive supports all of this. But once I added GZIP encoding, all of that manual work became pointless. GZIP gave approximately 20x compression. The algorithm handles repetitive text patterns (which CSV is full of) far better than any manual optimisation.

Swift has built-in GZIP support through the Compression framework, so implementation was minimal — compress the data, add the content encoding header, upload.

Fitting sync into iOS background tasks

iOS is strict about background work. Two main options:

BGProcessingTask — runs overnight when charging. Timing is unpredictable, might not run if battery is low
beginBackgroundTask — gives ~30 seconds when the user closes the app

I went with the 30-second window. When the user closes the app, it builds the CSV, compresses with GZIP, compares against the last uploaded version, and uploads if needed. 100,000 items sync comfortably within the limit.

The comparison is simple: keep a hash of the last successfully uploaded CSV. On app close, build new CSV, hash it, compare. Same hash = no upload needed. Different = compress and upload.

Same sync triggers on app launch too, so data stays current from both directions.

Photos are handled separately

Inventory photos follow a different path. Each photo is compressed using iOS built-in image processing (~10x size reduction) and queued for upload individually. The queue processes photos progressively — on launch, close, and in the background.

If a user adds 50 photos at once, they upload gradually. Photos go to Google Drive alongside the CSV, under the same drive.file scope.

The architecture that emerged

What started as a shortcut turned into something genuinely simpler and more robust:

Offline-first — all data lives on the phone. Works with no internet, which matters at outdoor markets
No backend — zero infrastructure, zero running costs. Google Drive is the only dependency and it's the user's own storage
Auto-approved permissions — drive.file scope means no Google verification, no scary consent screens
Sync is a view, not a source of truth — the spreadsheet is an export. If it breaks, phone data is safe. No sync conflicts
Optional — originally required Google sign-in. Now sync is entirely optional

Is this permanent? Probably not at scale. But 100,000 items holds up under stress testing. That's years of headroom. By the time it's outgrown, it'll be clear whether building something more complex is worth it.

Key takeaway

I usually try to make the technical solution perfect before moving on. This time I had users waiting and couldn't afford to. The shortcut turned out to be better than the "proper" approach would have been — simpler permissions, no backend costs, works offline, syncs fast.

Sometimes the temporary workaround is the architecture. The trick is knowing when to stop optimising and ship.

I built an offline-first iOS app in 43 days with Swift, SQLite, and Claude Code

Oleksandr Prudnikov — Fri, 03 Apr 2026 05:10:08 +0000

My wife buys secondhand items at flea markets and car boot sales in the UK and resells them on eBay and Vinted. She was tracking everything in Google Sheets and kept forgetting what she paid for things. When someone sent an offer she had no idea if it was a good deal.

So I built her an iOS app. That was 43 days ago. It's now on the App Store, completely free, and a few people are actually using it. Here's how I built it and the technical decisions along the way.

What the app does

You take a photo at the market, enter the price, and the app tracks the item through its lifecycle: purchased → listed on platforms → sold. It calculates profit after all expenses — entry fees, transport, packaging. Supports 4 currencies with automatic exchange rates. Works completely offline.

Tech stack

Swift + SwiftUI — iOS 17+
SQLite via GRDB — local storage with WAL mode, foreign keys, composite indexes
Google Drive API — optional photo sync + CSV export (drive.file scope only)
BGTaskScheduler — background photo uploads
CoreLocation — auto-suggest nearby markets
No backend — everything runs on device, zero server costs

The architecture

SwiftUI Views
    ↓
ViewModels (ObservableObject)
    ↓
Services (GoogleAuth, Export, Location, Notification)
    ↓
DatabaseStore (Swift Actor — all CRUD operations)
    ↓
SQLite (GRDB, WAL mode) + Local Images

The key decision was making it offline-first. Car boot sales happen in fields with no signal. The app can't depend on network for anything core. Google Drive sync is purely optional — you can use the app forever without ever connecting a Google account.

Day 1–7: JSON files and regret

I started with the simplest possible storage — JSON files in the Documents directory. One file per entity type (items, markets, sellers, expenses). Read the whole file into memory, modify, write it back.

This worked fine for 20 items. It did not work fine for 200 items. Loading the entire items array into memory on every read was getting slow, and there was no way to do efficient queries like "show me all unsold items sorted by date, paginated."

Day 18: The SQLite migration

I migrated everything to GRDB (a Swift SQLite wrapper). This was the most significant single-day change in the project.

GRDB gives you:

Typed record structs that map to tables
A migration system (versioned schema changes)
WAL mode for concurrent reads
Proper indexes for fast queries

My migration system has 4 versions so far:

// v1: Initial schema — all tables, indexes, foreign keys
// v2: Composite indexes for paginated list queries
// v3: Crockford Base32 SKU regeneration
// v5: Market "askForEntryFee" boolean column

The paginated queries went from "load everything into memory and filter" to actual SQL with LIMIT/OFFSET on indexed columns. Night and day difference.

Offline-first with optional Google sync

The sync model is simple. Items default to "local" status. If you connect Google Drive:

Photos queue for upload via SyncQueueService
BGTaskScheduler processes the queue even when app is suspended
CSV export runs on a 5-minute timer — compares MAX(updatedAt) vs last sync timestamp, only uploads if data changed
CSV is gzip-compressed before upload
Google auto-converts the CSV to a Google Sheet (no Sheets API needed)

I deliberately avoided the Sheets API. Using only drive.file scope means the app can only access files it created itself. Better privacy, simpler OAuth, fewer permissions to explain to users.

Multi-currency with exchange rates

My wife buys in GBP at UK markets but sometimes sells in EUR or USD on eBay. The app needs to show profit in your home currency regardless of what currencies you bought and sold in.

I fetch daily rates from a free API and cache 365 days of history locally in SQLite. For conversions I support three paths:

Direct rate — GBP → USD
Reverse rate — USD → GBP (1/rate)
Cross rate via common base — EUR → CAD via USD

If you're offline for days the app uses cached rates and shows a warning that they might be stale. You can refresh manually when you get signal.

SKU generation

Every item gets a unique SKU like FH-20D6G0NR. I use Crockford Base32 encoding — uppercase only, no ambiguous characters (I, L, O, U are excluded). The SKU is time-based with an atomic counter for guaranteed uniqueness.

Users can copy the SKU and paste it into their eBay/Vinted listing descriptions, then match up sales later.

Building with Claude Code

I used Claude Code throughout the entire build. It's genuinely how I shipped this in 43 days as a solo developer. The AI handled a lot of the boilerplate — GRDB record types, SwiftUI form layouts, CSV generation, the Google OAuth flow.

Where it helped most was the migration from JSON to SQLite. I could describe the existing data model and the target schema and Claude Code would generate the migration code, the new record types, and update all the queries.

Where it didn't help: design decisions. What should be offline vs synced, how to handle currency conversion edge cases, which features actually matter for my wife's workflow. Those are product decisions that need human context.

The Figma redesign (Day 23)

I'm not a designer but I knew the app looked like a developer built it. So I created a proper design system in Figma first:

Font: Roboto Flex (variable weight)
Design tokens: gold #F9DDA5, badge #BBCBF7, card bg #F8FAFB, accent #334B90
Neumorphic shadows: two styles — large (radius 30) and small (radius 15)
Light mode only: explicit colors everywhere, no system adaptive

Then rebuilt every screen to match the Figma exactly. The 1:1 Figma px → iOS pt mapping made this surprisingly straightforward.

What I'd do differently

Start with SQLite from day one. The JSON-to-SQLite migration was worth it but I lost time building something I knew I'd throw away. If your app will have more than ~50 records, just use a database from the start.

Add search earlier. Users asked for it immediately. Being able to find an item by title or SKU across all tabs seems obvious in hindsight.

Don't overthink Google integration. I spent too long trying to make the sync perfect. The simpler approach — CSV upload with change detection — works well and is much easier to maintain than real-time sync.

Current state

~18,100 lines of Swift across 69 source files
16 selling platforms supported
4 currencies with daily exchange rates
4 database migrations
8-page onboarding walkthrough
Free on the App Store, no ads

The whole thing runs with zero server costs. GitHub Pages for the website, GitHub Actions for CI/CD, Apple Developer account for distribution. That's it.

If you're curious:

App Store: FlipperHelper
Website: flipperhelper
Blog: guides for resellers

Happy to answer questions about the architecture, the GRDB setup, or the Claude Code workflow.