The scan is the easy part of a barcode scanning app for food.
A barcode scanning app for food takes about a day to get working and about a month to make honest. The camera part is solved: a phone reads the code off a cereal box in well under a second. What you do with those digits is the whole product, and that depends on which database you point them at and what you say when it has never heard of the thing in somebody's hand. The same gap shows up in home inventory apps, where the scan is instant and the record behind it is thin.
This page covers what a food barcode actually encodes, how a phone camera reads one, the free food database you can query without an API key, and how a food label scanner app should behave when the answer matters to somebody's health.
Try the allergen matchThe short version
The camera is solved, the database is the product.
A barcode holds a number and nothing else. No ingredients, no allergens, no price, no brand, no date. Every useful thing your app shows after the beep came from a lookup, which means the app is exactly as complete, as current and as correct as whatever you looked that number up in.
So the real design questions are not about scanning. They are: which database, what happens when the code is missing from it, and what you tell a person who is asking because they cannot eat the wrong thing.
What the number on the pack actually is
The stripes on a grocery pack encode a GTIN, printed as a 13 digit EAN-13 in most of the world, a 12 digit UPC-A in North America, and an 8 digit EAN-8 on packs too small for the full symbol. The number identifies one product, from one company, in one pack size. Two flavours of the same crisps are two different numbers. The 200 gram bag and the 400 gram bag are two different numbers as well.
Nothing else is in there. The leading digits point at the numbering organisation that issued the range to the company, not at where the food was made, so they are not a country of origin. There is a check digit at the end, worth validating in the app so a misread fails fast instead of becoming a silent lookup for a product that never existed.
So your app is a lookup client wearing a camera. Every screen after the scan is data somebody else entered, and the quality of a grocery barcode app is decided by that choice rather than by the scanning code.
Reading it on a phone, and what the camera will read
On React Native and Expo the camera view takes a barcodeScannerSettings prop and an onBarcodeScanned callback, and the documented list of scannable types covers aztec, ean13, ean8, qr, pdf417, upc_e, datamatrix, code39, code93, itf14, codabar, code128 and upc_a. Narrow that list to the grocery formats rather than leaving it open. A pack with a promotional QR code on the back will otherwise fire your handler with a marketing URL.
Two details save a day each. The callback keeps firing while the code stays in frame, so gate it behind a flag you clear when the result screen closes, or one tin will scan forty times. And the camera permission string is set in the Expo config plugin, which also carries a barcodeScannerEnabled option, so the prompt a shopper sees is written by you rather than defaulted. There is also a launchScanner method that hands off to the Google code scanner on Android and the system scanning view on iOS 16 and later.
Phone cameras struggle where grocery scanning happens: dim aisles, shrink wrap, curved tins, a code half under a price sticker. A torch toggle and a manual entry field fix most of it. If you are scanning hundreds of items in a stock room rather than a handful in a shop, a dedicated imager is a different build, closer to a zebra scanner control app than to a camera screen.
There is a free food database with an open API
Yes, and it is Open Food Facts. Read requests need no API key and no account. The documentation asks only for a custom User-Agent in the form AppName/Version (ContactEmail) so they can tell your app from a bot. The product endpoint is a plain GET of the barcode, such as /api/v2/product/3017620422003.json, and a record can come back with product name, brands, quantity, ingredients text, allergen tags, trace tags, nutrient values and a Nutri-Score grade.
The limits are published, so build to them. Read queries are capped at 15 requests per minute per IP address and searches at 10, and the documentation notes that when requests come from your users directly, as they do from a mobile app, the limits apply per user. For more than a few hundred products they ask you to download the data export instead. The database is under the Open Database License, its contents under the Database Contents License, and images under Creative Commons Attribution ShareAlike, so check the attribution terms before you ship.
The honest part: the data is contributed by volunteers, and the project says plainly there are no assurances it is accurate, complete or reliable and that the user assumes the risk. You can see it in live records. One real product returns the allergen tags en:gluten and en:Corn side by side, one normalised and one not. Coverage is uneven by country and thinnest on own-brand and local products, which are exactly the ones people scan in a small shop.
Open Food Facts API documentation, authentication and rate limits
An allergen scanner app is a matching problem
The job is to compare a list a person keeps against a list a record carries. Match on the structured allergen tags, which arrive as language prefixed values such as en:milk, en:nuts and en:soybeans, and keep trace tags separate because they mean may contain rather than contains. Do not search the free text ingredients for a word: the string milk appears inside coconut milk, and a text search will both over fire and under fire on the same shelf.
A food label scanner app has two failure modes and they are not symmetric. A false flag costs somebody one product. A missed flag can cost them a reaction. So show a match loudly and show a blank carefully: no allergen tag on this record is not the same sentence as this product is safe. Write that on the result screen, not in a settings page nobody opens.
Whether may contain counts is the shopper's decision, not yours. Some people avoid every trace line and some ignore them entirely, so store that choice per person along with the avoid list itself. The same record is also worth keeping once it has been looked up, because a scan that ends in a list is more useful than a scan that ends in a verdict, which is where this meets a meal planner grocery list app.
Try it
What a lookup can and cannot tell a shopper
Pick what this shopper avoids, then pick a scan. The tags are the real allergen tags Open Food Facts returns for these three codes today.
Flag it
Matched on Milk. A match is worth showing loudly, because it is the cheap half of the job.
What each approach gives someone in the aisle
| Option | Reads the code for you | Returns ingredients and allergens | Checks a personal avoid list | Handles a product with no record |
|---|---|---|---|---|
| Reading the pack by eye | No | Yes | No | Yes |
| A generic QR and barcode reader | Yes | No | No | No |
| A public food database app | Yes | Yes | preset allergen list | by adding it to the public database |
| A spreadsheet of your own products | No | only what you typed | Yes | Yes |
| A scanning app you build | Yes | via an open API | Yes | Yes |
Building a scanner around your own shelf
A public food app is built for the general shopper, and that is where it stops fitting. If you scan a fixed catalogue, a school kitchen, a food bank intake desk, a cafe stock room, a wholesaler with its own codes, the public database is the wrong shape. You want your own product table with your own fields, prep date, allergen sign off, who checked it, and the public lookup demoted to a helper that pre-fills a new record when the code is unknown. That inversion is the whole build, and an off-the-shelf scanner will not do it, because it is your catalogue and not theirs.
Newly is an AI app builder. You describe the app in plain English and it writes a real React Native and Expo project you own, runs it on a cloud simulator while it builds, and ships it. It costs $25 a month and there is no free plan. iOS goes out through TestFlight and App Store Connect using your own Apple Developer account. The Deploy tab has an Android section where one press builds, signs and uploads the app to Google Play internal testing, and it also builds a standalone release APK you can download and install on a phone directly. It does not come with a food database, and there are no built-in payments.
Settle one thing before you write any of it: what the app does in a shop with no signal. A supermarket aisle is often the worst reception a phone sees all week, and a scanner that spins on a loading state is a scanner nobody opens twice.
Questions people ask about food barcode apps
Yes. Open Food Facts publishes an open API. Read requests need no API key, only a custom User-Agent in the form AppName/Version (ContactEmail). You fetch a product by barcode, for example /api/v2/product/3017620422003.json. Reads are limited to 15 requests per minute per IP address and searches to 10. The data is licensed under the Open Database License, so check the attribution terms before shipping.
Describe the shelf you actually scan
Write down the fields your own product record needs, what the screen says when the code is unknown, and who the allergen list belongs to. Build the scanning around those three answers.
Start building