Convertix is a cross-platform file conversion product for the web and Apple platforms. A Convertix account is required to convert files, and the same Supabase identity keeps conversion history together across supported clients.
The core experience is straightforward: upload a file, choose a supported target format, submit the conversion, and download the result when processing finishes.
Convertix has a working end-to-end conversion pipeline running on AWS in eu-west-2, a production Next.js application, and a native SwiftUI app for iOS, iPadOS, and macOS.
The production path now supports document, image, audio, and video conversions through the web application. Recent image support includes HEIC / HEIF → JPG, PNG, or WebP, with content-based HEIF detection so iPhone photos are handled by their actual image format rather than only their filename. Files are uploaded directly to Amazon S3 using short-lived presigned URLs, conversion jobs are submitted through the API, queued in Amazon SQS, processed by an autoscaling ECS/Fargate worker, and returned through a temporary presigned download URL.
The full flow has been tested end to end:
- The web app requests a secure upload URL.
- The source file is uploaded directly to S3.
- The API validates the conversion request and places a job onto SQS.
- The worker service scales up when work is waiting.
- The worker downloads the source file, performs the conversion, and uploads the result.
- Conversion status is polled until completion.
- The completed file is exposed through a temporary S3 download URL.
- The worker can scale back down when the queue is empty.
Signed-in conversions from the web and Apple app write to the same user-scoped conversion_history source in Supabase. History is account-only and supports filename, format, status, and time filtering. Conversion files continue to use the existing AWS pipeline; Supabase stores account and conversion metadata, not a replacement copy of the conversion backend.
Convertix is structured as a multi-service project so the frontend, API, worker, and infrastructure can evolve independently.
Next.js / SwiftUI clients
|
+----> Supabase Auth + user-scoped conversion history
|
v
AWS HTTP API
|
+----> Amazon S3 uploads + converted files
|
+----> Amazon SQS conversion job queue
|
v
ECS / Fargate
worker service
|
v
Amazon S3
The frontend is built with Next.js 16, React 19, and TypeScript and is deployed through Vercel at convertix.uk.
The interface includes a typed API client and explicit conversion state handling for stages such as:
- Ready
- Uploading
- Queued
- Starting
- Converting
- Completed
- Failed
Conversion requires an authenticated Convertix account. Completed cloud conversions are recorded against that account so they also appear in the native Apple app. The frontend deliberately does not fake successful conversions; routes are only enabled when the required API configuration and backend support exist.
apps/apple contains the native Swift/SwiftUI application for iOS, iPadOS, and macOS. It shares the existing conversion API and Supabase account with the web app while providing native capabilities including:
- A shared Swift Concurrency conversion coordinator and persistent conversion queue
- Safe on-device image conversions where Apple frameworks support them, with cloud fallback for other supported routes
- Account-only cross-platform conversion history with search and filters
- App Intents and Shortcuts actions, typed deep links, widgets, and Live Activities
- Native file import, drag and drop, clipboard entry points, notifications, and network awareness
- A macOS menu bar experience, keyboard commands, native sharing, and Finder reveal actions
Client metadata is cleared on sign-out, and history requests are always scoped to the authenticated Supabase user. Local and cloud execution are labelled separately so the UI does not imply that uploaded files remained on-device.
Supabase provides a single account identity across Convertix clients. The web and Apple apps use the existing conversion_history schema and associate writes with the authenticated user. History is unavailable while signed out and currently supports:
- Filename search
- Source and target format filters
- Status filters
- Time filters
- Pagination on the web
- User-scoped deletion
The account and history contracts are platform-neutral so a future Android client can authenticate with the same Supabase project and consume the same user-owned records without introducing an Android-specific data model.
The current serverless API runs on AWS Lambda behind an HTTP API.
Implemented routes include:
GET /healthPOST /uploadsPOST /conversionsGET /conversions/{id}
POST /uploads creates short-lived presigned S3 upload URLs.
POST /conversions validates the requested source and target formats, creates a conversion ID, and sends the job to Amazon SQS.
GET /conversions/{id} reports the current state and, once processing has completed, returns a temporary download URL for the converted file.
The conversion worker is a Python service packaged as a Docker image and stored in Amazon ECR.
It runs on Amazon ECS with AWS Fargate, consumes conversion jobs from SQS using long polling, retrieves input files from S3, performs the conversion, uploads the output, and acknowledges the queue message when processing succeeds.
The worker service is designed to scale from 0 running tasks when idle to active capacity when work enters the queue, keeping the development environment inexpensive while still allowing jobs to start automatically.
The queue also has a dead-letter queue configured for repeatedly failing jobs.
Convertix currently uses:
- Next.js 16 — web application and frontend
- React 19 — user interface
- TypeScript — typed frontend and API integration
- Python — API and conversion worker logic
- AWS Lambda — serverless API execution
- Amazon API Gateway / HTTP API — public API entry point
- Amazon S3 — temporary file storage and presigned uploads/downloads
- Amazon SQS — durable conversion-job queue
- Amazon ECS / AWS Fargate — conversion worker runtime
- Amazon ECR — worker container registry
- Amazon CloudWatch — logs, alarms, and operational visibility
- Docker — worker packaging and local development
- Terraform — AWS infrastructure management
- Vercel — frontend deployment
- Swift / SwiftUI — iOS, iPadOS, and macOS application
- App Intents, WidgetKit, ActivityKit — Apple system integrations
- Supabase Auth and Postgres — cross-platform accounts, profiles, and user-scoped conversion history
The repository still contains room for supporting services such as PostgreSQL and Redis as the product grows, but the live conversion path currently relies primarily on AWS-native storage, queueing, compute, and serverless services.
Convertix already models several format families in the application, including:
- DOCX
- TXT
- JPG / JPEG
- PNG
- WebP
- HEIC / HEIF input to JPG, PNG, or WebP
- MP3
- WAV
- MP4
- WebM
Not every possible pair is enabled yet. Live routes include document conversion, common raster image conversion, SVG rasterisation, MP3/WAV audio conversion, MP4/WebM video conversion, and HEIC / HEIF → JPG, PNG, or WebP.
Keeping the UI aware of backend capabilities means unsupported routes can remain disabled until the corresponding worker implementation is ready.
apps/
web/ Next.js frontend
apple/ SwiftUI app for iOS, iPadOS, and macOS
services/
worker/ Python conversion worker
infrastructure/ Terraform and cloud infrastructure
The project is intentionally kept as a monorepo so application code and infrastructure changes can be developed together without splitting Convertix into disconnected repositories.
Meaningful public converters, tools, and user-facing features should be followed through the feature launch checklist so engineering, search discovery, distribution, and measurement are treated as separate parts of shipping. Launch-specific assets and measurement notes live under docs/launches/.
The current AWS development environment includes:
- Temporary S3 object lifecycle handling
- SQS conversion queue
- SQS dead-letter queue
- Lambda API
- ECR worker repository
- ECS/Fargate worker service
- CloudWatch logging and queue-based scaling alarms
A queued conversion can cause the worker service to scale from zero, process the job, upload the converted result, acknowledge the SQS message, and return to idle capacity afterward.
The next major stage is expanding the working conversion engine rather than replacing the architecture.
Planned work includes:
- More document conversions
- Broader image conversion coverage
- Broader audio conversion coverage
- Broader video conversion coverage
- Faster worker startup and conversion times
- Richer progress reporting
- Improved failure states and retry handling
- Larger-file workflows
- Android client using the shared account and history contracts
- Usage limits and rate limiting
- Free and paid usage tiers
- Subscription and payment support
- API access for developers
- Additional monitoring and operational tooling
- Continued infrastructure optimisation as usage grows
Convertix is intended to feel like a polished consumer product rather than a collection of conversion scripts.
The frontend is being designed around a familiar, approachable file-handling experience while the backend remains asynchronous, scalable, and cost-conscious. The long-term goal is one consistent conversion service across web, desktop, mobile, and API clients.
The first cloud workflow is now proven. The focus from here is broader format coverage, faster processing, stronger product polish, and scaling the existing system cleanly as real usage grows.
Convertix — Ease and speed.