FilesMagic
A file-conversion product developed across web and iPhone experiences, with an emphasis on a clear workflow and private, offline processing in the current mobile application.
What FilesMagic is
FilesMagic helps people convert files through a direct workflow: select a file, identify the input, choose a supported output format, run the conversion, and receive the result. It is available as a web product and an iPhone application.
Why it exists
File conversion is often made harder by cluttered interfaces, unclear format support, and uncertainty about how uploaded files are handled. FilesMagic focuses the interface on the conversion itself and makes the current state visible.
My role
I developed FilesMagic as a product rather than a demonstration page. That work includes the product workflow, frontend behavior, conversion infrastructure, error states, platform-specific decisions, and the operational work required to make the product publicly available.
The public App Store listing identifies Almuthanna Shihab as the developer. Apple provides useful independent evidence of that developer relationship; it does not independently certify every implementation or product claim.
Two product surfaces, two architectures
The published engineering write-up documents an earlier web implementation using React for the frontend and Python with Flask for hosted conversion work. The current iPhone listing describes supported conversion work as offline and on-device.
Those are different architectures with different operational boundaries. A hosted web product must manage server-side file handling and deployment. An offline mobile product must package supported conversion capability for the device and work within mobile resource and platform constraints.
Product experience
The current mobile interface makes privacy and the conversion path visible. It separates conversion controls from explanatory material, includes an optional detailed-log mode, and states that supported files remain on the device.
Technical and production considerations
- Format boundaries: input validation, supported output combinations, and understandable errors.
- Resource use: conversion work can be CPU-, memory-, and storage-intensive on both servers and phones.
- State clarity: the interface must distinguish selection, conversion, failure, and completion.
- Privacy: the mobile release states that supported conversions happen locally and that the developer does not collect app data.
- Distribution: the web product and iPhone application have separate deployment, review, and maintenance paths.
Current status
The product has a live website and an active iPhone listing. No user totals, download totals, ratings, conversion volume, or performance claims are presented here because those figures are not part of the verified public record used for this case study.