How to Make an App Like Photomath

Building a math-solving app is harder than it looks. The camera pipeline, the OCR layer, the solver engine — each one is a non-trivial engineering problem on its own. Here's how they fit together.

What Does Photomath Actually Do Under the Hood?

Most people think of Photomath as "a camera that solves math." That undersells the engineering. At its core, the app chains together four distinct systems: image capture and preprocessing, optical character recognition (OCR) tuned for mathematical notation, a symbolic solver engine, and a step-by-step explanation generator.

Each system has its own failure modes. A blurry image breaks OCR. Ambiguous notation (is that a 1 or an l?) breaks the parser. An edge-case equation breaks the solver. The explanation layer has to stay coherent across all of them. Getting all four to work reliably, on-device, with sub-second latency, is what took Photomath years to refine.

Image Capture and Preprocessing

The camera feed isn't fed directly to the OCR model. It goes through a preprocessing pipeline first: grayscale conversion, adaptive thresholding (Otsu's method works well here), deskewing, and noise reduction. The goal is to hand the OCR layer the cleanest possible binary image.

On Android this is typically handled with OpenCV 4.x or ML Kit's image pipeline. On iOS, Vision framework handles much of the heavy lifting via VNImageRequestHandler. You can also run a lightweight ONNX model here if you need custom preprocessing that the platform SDKs don't cover.

OCR for Mathematical Notation

General-purpose OCR engines like Tesseract 5 are trained on natural language. They'll misread fractions, exponents, and square root symbols constantly. For math, you need a model trained specifically on mathematical notation, or at minimum fine-tuned on it.

The current standard for this is a model trained on datasets like IM2LATEX-100K or CROHME (the handwritten math recognition benchmark). Architectures that work well include encoder-decoder models with attention (CNN encoder + LSTM or Transformer decoder) and newer vision-language models like Pix2Struct. The output you're aiming for is LaTeX, not plain text, because LaTeX encodes the structure of the expression, not just the characters.

Printed text is meaningfully easier than handwritten. If your use case is textbook problems, a well-tuned encoder-decoder model can reach north of 90% expression-level accuracy. Handwriting drops that, sometimes significantly, depending on how messy the input is.

What Solver Engine Should You Use?

This is where most teams underestimate the scope. A solver isn't a lookup table. It's a symbolic computation system that understands mathematical equivalence, can apply transformation rules, and knows when to use numerical methods as a fallback.

Engine	Language	Strengths	Limitations
SymPy	Python	Free, well-documented, covers algebra through calculus	Slow for complex expressions; not suitable for on-device
Wolfram Engine	Multi	Extremely broad coverage	Commercial licensing; not embeddable in mobile apps freely
Math.js	JavaScript	Good for web/Node; handles symbolic algebra	Limited CAS depth compared to SymPy or Wolfram
custom C++ CAS	C++	Fast, embeddable, full control	Expensive to build and maintain

For a mobile app, you have two realistic paths. One: run a lightweight symbolic engine on-device for common problem types (linear equations, quadratics, basic derivatives) and call a cloud solver for anything harder. Two: build or licence a compiled C++ symbolic engine that runs fully on-device.

Photomath uses a proprietary on-device engine. Rebuilding that from scratch is a multi-year effort. Most teams will start with cloud-based solving and move workloads on-device selectively as the product matures.

How Do You Generate Step-by-Step Explanations?

This is arguably the hardest part to get right. Solving an equation and explaining the solution are different problems.

A solver can produce a sequence of algebraic transformations. Turning that sequence into readable, pedagogically sound steps requires a separate layer. You need to:

1. Identify which transformation was applied at each step (e.g., "divide both sides by 3")
2. Map that transformation to a natural language template
3. Detect when steps can be merged or should be broken apart for clarity
4. Localise the output if you're serving multiple languages

Rule-based template systems work well for structured problem types. For open-ended explanations or for handling unusual problem structures, fine-tuned LLMs (GPT-4o, Gemini 1.5 Pro, or a domain-specific fine-tune of Llama 3) can fill the gaps. The risk with LLMs is hallucination: the model might generate a plausible-sounding but mathematically incorrect step. You need a verification pass that checks each generated step against the solver's ground truth.

Building for Mobile: iOS, Android, or Cross-Platform?

If OCR accuracy and camera performance are central to your product, native is safer. The Vision framework on iOS and ML Kit on Android give you the best access to hardware acceleration, including the Neural Engine on Apple Silicon and NNAPI on Android.

Flutter is viable if you wrap the heavy ML work in platform-specific plugins. The Dart layer handles UI; the native plugin handles camera and inference. This approach works, but the integration overhead is real. You'll be writing and maintaining three codebases in practice: Dart, Swift, and Kotlin.

React Native is harder here. The bridge overhead matters when you're pushing frames through a model at 15-30 fps.

On-device inference is typically done via Core ML on iOS and TensorFlow Lite or ONNX Runtime on Android. Model sizes matter: a quantised INT8 model that fits under 50 MB loads fast and doesn't bloat the app. FP32 models above 200 MB will cause complaints.

What Does It Actually Cost to Build This?

Rough ballpark, not a quote. A team that can ship a working v1 with printed-text OCR, cloud-based solving for common problem types, and step-by-step explanations needs at minimum: two ML engineers, two mobile engineers (or one strong cross-platform engineer with native plugin experience), and one backend engineer for the solver API and auth layer.

Timeline to a usable beta: 6 to 9 months for a focused team. Timeline to something competitive with Photomath's accuracy on common school-level problems: longer, because the dataset curation and model iteration cycles take time that can't easily be compressed.

If your use case is narrower, say, solving only quadratic equations for a specific curriculum, you can cut scope aggressively and ship in 3 to 4 months.

Conclusion

The architecture is clear enough: preprocess the image, run a math-aware OCR model, pass the parsed expression to a solver, and generate human-readable steps. The difficulty is in the quality at each stage and how gracefully the system degrades when one stage fails.

If you're deciding whether to build this in-house or work with a team that has already integrated these components, the honest question is whether your team has ML engineers who have worked with mathematical OCR specifically. General computer vision experience helps, but mathematical notation has enough quirks that domain experience accelerates the work considerably.

The clearest next step is to define your problem scope tightly: which subjects, which grade levels, printed or handwritten, which languages. Scope determines architecture. Architecture determines cost. Starting with a narrow scope and a working pipeline beats starting broad and shipping nothing.

FAQ

How accurate is math OCR today? For printed, well-lit text on standard paper, state-of-the-art models reach over 90% expression-level accuracy on benchmarks like IM2LATEX-100K. Handwriting accuracy varies widely, typically 70 to 85%, depending on how the training data matches your users' input style.

Can I use GPT-4o as the solver? You can, and it works surprisingly well for standard school-level problems. The risk is that LLMs don't guarantee correctness. For a tutoring app where wrong answers undermine trust, you should pair LLM-generated explanations with a deterministic solver that verifies each step.

What's the minimum viable on-device setup? A quantised TensorFlow Lite or Core ML model for OCR, a lightweight symbolic solver compiled to C++ and bundled natively, and a template engine for step generation. This avoids API latency and works offline, but the initial build cost is higher than a cloud-first approach.

Do I need a custom dataset to train the OCR model? Not necessarily. CROHME and IM2LATEX-100K are publicly available and sufficient to get started. You'll likely need to fine-tune on your own data after launch once you see which expressions your users actually submit and where the model fails.

How does Photomath handle multiple problem types? It uses a classifier upstream of the solver to route the parsed expression to the right solver module. Arithmetic, algebra, calculus, and statistics each have different solving strategies. Building a modular solver architecture from the start, rather than one monolithic engine, makes this routing much easier to extend.

Have a project in mind? Contact Sodio Technologies to discuss your requirements and explore the right technology solution for your business.