How on-device price-tag OCR works and what stays private

From camera pixels to recognized text

The live camera supplies pixel buffers to the app. Apple Vision’s VNRecognizeTextRequest examines those pixels and returns text observations with confidence and bounding boxes. Price Tag FX uses the accurate recognition level for both live and still-image work, while throttling live requests to keep the camera responsive. Freeze and imported photos use an accurate still path with a broader, steadier opportunity to read small text.

Recognition is configured with the selected market’s locale when Apple Vision supports a matching language, then supplements it with Japanese and English fallbacks. It can make a secondary language-corrected pass in accurate mode or after repeated live misses. This design helps with real retail labels, but Vision’s supported-language list, the image itself, and the chosen market all affect what comes back.

1. The camera or selected photo provides a pixel image.
2. Vision recognizes text and returns positions and confidence values on device.
3. The app normalizes text, including some common OCR character confusions.
4. The parser extracts explicit currency-marked amounts and matches nearby retail terms.
5. The overlay maps likely prices back near their positions in the image.

• Live OCR is throttled; Freeze and Photo use the accurate still path.
• The selected source market supplies a useful locale and currency constraint.
• Glare, blur, perspective, tiny type, and decorative fonts remain physical limits.

Source: Apple Vision: Recognizing Text in Images

Local price parsing is not general translation

After OCR, Price Tag FX loads the price-term dictionary for the selected market language. The resources cover 20 source languages and include terms for tax included, tax excluded, regular, sale, member, unit, discount, multibuy, points, and related concepts. The parser uses those terms to classify nearby numbers, rank candidates, and generate warnings. Output labels for the normalized concepts are also available in 20 languages.

This is deliberately narrow. It helps answer what kind of price a number appears to be, rather than translating an entire sign, package, ingredient list, or store policy. The set of 20 source and output languages is not the same as the app’s full interface-localization set, and it is not evidence that every OCR language or every general translation pair is available on every device. Product-title translation requires iOS 26 or later.

1. Choose the market that matches the physical tag.
2. Choose the output language for the normalized price-role labels.
3. Read the original amount and role together.
4. Treat unmatched words as outside the curated price-term vocabulary.

• Tax, sale, member, and unit roles have explicit parser behavior.
• Multibuy and points terms provide context but do not form a universal deal calculator.
• Confidence and warnings communicate uncertainty rather than hiding it.

Optional product-title translation is a separate layer

The app can choose a likely short product-title block after filtering text that resembles a price, code, address, company name, or other noise. If the source and output languages differ, it asks Apple’s Translation framework whether that exact pair is installed. Only an installed pair is used. The app does not initiate a cloud fallback or promise to download a model automatically in this flow. Product-title translation requires iOS 26 or later.

If translation succeeds, the product title can appear as helpful context above the price. If the pair is unavailable, translation fails, or the result is effectively unchanged, the title is omitted. Price parsing and conversion continue independently. This separation is important for truthful copy: Price Tag FX translates supported local price concepts consistently, while product-title translation is optional and conditional. Product-title translation requires iOS 26 or later.

• The app is not an Apple product and should not imply Apple affiliation.
• Installed-pair status can differ between devices even when the same output language is selected.
• A translated title can still identify the wrong variant if OCR selected the wrong text block.
• No universal product-text or package translation claim is supported.

Source: Apple Translation framework

Draw the privacy boundary accurately

Camera frames, freeze frames, selected-photo pixels, recognized OCR text, parsed prices, product titles, manually entered amounts, and conversion results are not fields in the app’s defined analytics events. Duplicate scan protection hashes local content into a fingerprint rather than sending the raw text as telemetry. The exchange-rate request contains currency-code metadata, not the scanned image or entered amount.

Firebase Analytics and Crashlytics are enabled at startup, and the app assigns a random app-scoped installation identifier for correlation. Events can include source and target currency codes, paid status, feature actions, purchase information, and diagnostics. Optional location detection uses MapKit to resolve a country suggestion. Therefore the accurate promise is private scan-content processing with disclosed technical services, not anonymous, offline, or communication-free operation.

1. Read the privacy policy’s camera, photo, analytics, location, rate-provider, and purchase sections together.
2. Distinguish content data from technical and event metadata.
3. Disable camera or location permission in iOS Settings when you do not want those features available.
4. Use Manual when you want conversion without pointing the camera at a tag.

• No cloud OCR does not mean no network services.
• No account does not mean no pseudonymous analytics identifier.
• No third-party display ads is a safer claim than no promotional surfaces because the app cross-promotes another emonster app.

Troubleshooting

Frequently asked questions