DEV Community: Vlad

Cómo construimos un registro de comidas por foto para iOS (y por qué la IA no ve el aceite)

Vlad — Tue, 20 Oct 2026 16:13:00 +0000

Aviso: soy el desarrollador de Mealumo, la app de iPhone de la que habla este post. No es una reseña, sino un repaso de las decisiones de diseño detrás de ella. La app está solo en inglés y requiere iOS 26 o posterior. Este texto se ha redactado con ayuda de IA y lo he revisado antes de publicarlo.

El punto de partida

Cuando alguien abandona una app para contar calorías, rara vez es por la nutrición. Es por el tecleo. Escribes "ensalada de pollo", te salen decenas de entradas casi iguales, adivinas la cantidad y repites el proceso con el aliño, el pan y la bebida. Hacer eso en cada comida cansa a cualquiera.

La idea de Mealumo es sencilla: que la entrada empiece con una foto. Fotografías el plato (o eliges una imagen de la galería), la app propone ingredientes, cantidades, calorías, proteínas, hidratos y grasas, y tú arreglas lo que no cuadra antes de guardarlo.

Esa última parte, la de arreglar, resultó ser el producto de verdad.

El flujo, paso a paso

Captura. Con la cámara o desde la galería. Poder importar desde la galería permite registrar por la noche lo que fotografiaste a mediodía.
Análisis. La imagen se envía a un servicio de IA externo, que devuelve su estimación: qué alimentos cree que hay, cuánto de cada uno y sus macros. Este paso necesita conexión a internet.
Revisión. El resultado aparece como una lista editable, no como una cifra cerrada. Puedes cambiar cantidades, editar ingredientes y añadir lo que falte mediante el buscador de alimentos.
Guardado. La entrada pasa al diario del día, que suma calorías y macros y las compara con tus objetivos diarios.

Alrededor de ese núcleo están las piezas menos vistosas: registro de agua, registro de peso con su evolución, ideas de recetas y objetivos diarios estimados a partir de tus metas, medidas y nivel de actividad.

Por qué una sola cifra es mala idea

La versión tentadora de esta función es la de la demo: entra una foto y sale "640 kcal". Queda espectacular, pero falla de una forma que el usuario no puede arreglar.

Si la app dice 640 y tú sabes que la ración era mayor, ¿qué tocas? Si sobrescribes el total, las macros dejan de sumar, y sigues sin saber qué parte del plato estaba mal.

Desglosar la estimación en alimentos con su cantidad lo resuelve. Los fallos en una foto de comida suelen ser localizados: se calcula mal el arroz, o la salsa resulta ser de nata y no de tomate. Con una lista, corriges esa línea y los totales se recalculan solos. El modelo no tiene que acertar siempre. Le basta con ser mejor punto de partida que un buscador vacío.

Lo que una foto no puede contar

El límite no es solo el modelo. Hay información que, sencillamente, no está en los píxeles:

La grasa de cocinar. Una cucharada de aceite de oliva ronda las 120 kcal y desaparece en cuanto se integra en el plato.
La profundidad. Desde arriba se ve la superficie, no el volumen. Un cuenco hondo y un plato llano pueden parecer iguales.
Lo que va por dentro. Burritos, empanadas, lasañas: todo lo relleno o mezclado.
La receta. "Pasta con salsa" puede ser algo ligero o algo muy contundente.

Esto no se arregla con más ingeniería. Lo que sí se puede hacer es decirlo con claridad y que corregirlo cueste poco. Por eso la ficha de la App Store avisa de que las estimaciones pueden ser inexactas y conviene revisarlas, y por eso la revisión forma parte del flujo en lugar de ser un extra opcional.

Rapidez frente a confianza

Hay una tensión real: registrar solo merece la pena si es más rápido que teclear, y cada confirmación añade fricción. Estos son los principios con los que diseñamos:

Mostrar la estimación al momento y que sea editable. Lo primero que ves tras el análisis tiene que permitirte actuar.
Tratar la cantidad como lo principal a corregir, porque es lo que peor se deduce de una imagen.
Tener la entrada manual a mano para las comidas que no se dejan fotografiar bien, como un batido en una botella opaca.
No aparentar más precisión de la que hay. Una estimación tiene que parecer una estimación.

Privacidad, en la ficha y no en la letra pequeña

Las fotos de comida son personales, y mandarlas a un servicio de terceros es una decisión que el usuario debe conocer. La ficha de Mealumo en la App Store lo dice sin rodeos: las fotos de las comidas y los datos de perfil necesarios para calcular los objetivos se envían a un servicio de IA externo para su procesamiento. Es poca cosa, pero en una app cercana a la salud ese tipo de detalle pesa en la confianza.

No es una app médica

Mealumo es un diario de comidas de bienestar general. Los objetivos son estimaciones, no diagnostica ni trata nada, y así lo indica la ficha. No promete resultados de salud, y creo que ninguna app de este tipo debería hacerlo.

Si trabajas con modelos de visión

Devuelve estructura, no un veredicto. Una salida desglosada permite corregir una parte sin tirar el resto.
Ten claro qué no puede contener tu entrada. En comida son la grasa, la profundidad y lo que queda oculto; cada dominio tiene lo suyo.
Haz visible la incertidumbre en la interfaz. Un resultado editable comunica "esto es una estimación" mejor que cualquier aviso legal.
Explica adónde van los datos. La gente se fija.

Pruébala y dime dónde falla

Mealumo es de descarga gratuita para iPhone (iOS 26+, app en inglés), con una suscripción PRO opcional para seguir escaneando y acceder a todas las recetas:
https://apps.apple.com/app/id6811904664

Cualquier plan PRO empieza con 3 días de prueba gratis. Si quieres probarlo más tiempo, deja un comentario o escríbeme por mensaje directo y te paso un código promocional PRO gratis. Y me interesa especialmente lo contrario: fotos en las que la estimación se vaya claramente.

¿Has trabajado con modelos de visión sobre datos reales y desordenados? ¿Cómo gestionaste los casos en los que la respuesta simplemente no está en la imagen?

Shipping an iOS 26-only app in 2026: how do you decide where the cutoff goes?

Vlad — Tue, 20 Oct 2026 08:52:01 +0000

Disclosure: I'm the developer of Mealumo, an iPhone calorie-tracking app. I'm using it as the example here, but this is a question for the community, not a launch post.

Mealumo requires iOS 26.0 or later. That's the minimum on its App Store page, and it means anyone who hasn't updated to this year's iOS can't install it.

I'm not going to argue that this was the right or wrong call. I'd rather hear how other people make this decision, because it seems to be one of those choices every new app makes and few people talk about openly.

What the listing actually says

For context, here's the compatibility section on the App Store page:

iPhone: requires iOS 26.0 or later
Mac: requires macOS 26.0 or later and a Mac with an Apple M1 chip or later
Apple Vision: requires visionOS 26.0 or later

So the cutoff carries over to other platforms too, which raises its own questions.

Questions I'd love your take on

1. How do you pick a minimum version for a brand-new app?
Do you start from the latest OS and only go back if you need to? Or start with N-1 or N-2 and only drop versions when an API forces you? Is there a rule of thumb you trust?

2. What data do you actually look at?
Apple publishes adoption figures from time to time, and analytics vendors publish their own. Which sources do you trust, and do you weight them differently for a niche audience? For a consumer health and fitness app, for example, would you expect users to update faster or slower than average?

3. Which APIs have pushed you to require the newest iOS?
I'm curious whether it's usually one specific framework, a SwiftUI behavior that only works properly on the latest release, or simply the cost of maintaining if #available branches.

4. Does the cutoff show up in your numbers?
If you've shipped a latest-only app, did you see a measurable difference in product page conversion, or in reviews from people who couldn't install it? Or was it hard to notice at all?

5. Would you lower the minimum after launch?
Going back to support older versions later means testing on more OS versions and possibly rewriting features. Has anyone done this, and was it worth it?

6. How does this play out on Mac and visionOS?
When an iPhone app becomes available on Apple silicon Macs or Vision Pro, do you think about those minimums at all, or do they just follow whatever you chose for iOS?

Why I'm asking

The choice about how far back to support older iOS versions tends to get made early and then stays in place for a long time. I'd rather understand how experienced iOS devs think about it than assume there's one obvious answer.

Please share your reasoning, your data sources, or the times you got it wrong. Disagreement is very welcome.

If you're on iOS 26 and want to see the app in question, it's here: https://apps.apple.com/app/id6811904664. It's free to download, any PRO plan starts with a 3-day free trial, and if you want to try PRO longer, comment or DM me for a free PRO promo code.

This post was drafted with AI assistance and reviewed before publishing.

Building a photo-to-calories logger for iOS: the AI can't see the olive oil

Vlad — Mon, 19 Oct 2026 09:40:24 +0000

Turning a meal photo into an editable food entry, and why the review step matters more than the model

Disclosure: I'm the developer of Mealumo, the iOS app this post is about. This is a write-up of the design decisions behind it, not a review. The link is at the end. If you think we got a tradeoff wrong, I'd like to hear it in the comments.

This post was drafted with AI assistance and reviewed before publishing.

The problem

When people give up on calorie trackers, it's usually not the nutrition that beats them. It's the data entry. You type "chicken salad", scroll through dozens of near-identical entries, guess a portion, then do it all again for the dressing, the bread and the drink. Doing that three to five times a day is a lot to ask.

So the idea behind Mealumo is simple: let a photo start the entry. You take a picture of your plate, or pick one from your photo library, and the app proposes ingredients, portions, calories, protein, carbs and fat. Then you fix whatever is wrong and save it.

That last sentence turned out to be the real product.

The flow

Here's how an entry gets made:

Capture. Use the camera or choose an existing photo. Library import means a meal photographed at lunch can be logged in the evening.
Analyze. The photo goes to an external AI service, which estimates what's on the plate: individual ingredients, their portions, and the calories and macros for each. This step needs an internet connection.
Review. The estimate is shown as a list of ingredients you can edit, not as one final number. You adjust portions, edit ingredients, and add anything that's missing.
Save. The entry goes into a daily journal, which adds up calories and macros against your daily targets.

Around that core sit the less glamorous parts: food search for adding ingredients by hand, a water log, a weight log with progress over time, recipe ideas, and daily nutrition targets estimated from your goals, body measurements and activity.

Why one number is the wrong output

The tempting version of this feature is the demo version: photo in, "640 kcal" out. It looks great, but it fails in a way the user can't fix.

Suppose the app says 640 and you know the portion was bigger. What do you edit? If you overwrite the total, the macros stop adding up, and you still don't know which part of the meal was wrong.

Breaking the estimate into ingredients × portions fixes that. Most mistakes on a food photo are local: the amount of rice is misjudged, or a sauce turns out to be cream-based rather than tomato. When the output is a list, you correct the one wrong line and the totals follow. The model doesn't need to be perfect. It needs to be a better starting point than an empty search box.

An itemized estimate also has practical benefits on the app side. Each line can be shown, checked and edited on its own, which is much easier than parsing a paragraph of free text.

What a photo physically can't tell you

The model isn't the hard limit. Some information just isn't in the pixels:

Fats and oils. A tablespoon of olive oil is roughly 120 kcal and becomes basically invisible once it's cooked into the food. The same goes for butter on vegetables and oil in a dressing.
Portion depth. A photo taken from above shows area, not volume. A deep bowl and a shallow plate can look the same.
Hidden layers. Burritos, sandwiches, casseroles: anything mixed or wrapped.
Recipes. "Pasta with sauce" might be a light tomato sauce or a heavy cream one.
Drinks. Two cups can look alike and contain very different things.

You can't engineer these away. What you can do is be honest about them and make corrections cheap. That's why the App Store listing says outright that nutrition estimates may be inaccurate and should be reviewed before use, and why reviewing the estimate is part of the flow, not an optional extra.

An app that users trust a little less, so they check for the oil, is better than one they trust completely until the numbers stop making sense.

Speed vs. trust

There's a real tension here. Logging only works if it's quicker than typing, and every confirmation step adds friction back.

These are the principles we designed around:

Show the estimate right away, and make it editable. The first thing you see after a scan should be something you can act on.
Treat portions as the main thing to correct. Portion size is what a photo shows least reliably, so adjusting it has to be easy.
Keep manual entry close by. Some meals don't photograph well, like a shake in an opaque bottle or a meal that's already half eaten. Food search covers those.
Never claim more precision than exists. An estimate should look like an estimate.

Privacy is a product decision, not a footnote

Meal photos are personal. Sending them to a third-party service is a real decision, and users should know about it. The Mealumo listing says plainly that meal photos, and the profile details needed to generate nutrition targets, are sent to an external AI service for processing. Putting that sentence on the store page, rather than burying it in a policy, is a small thing. It's still the kind of thing that decides whether people trust a health-adjacent app.

Not a medical app

A calorie tracker can easily slide into health claims. Mealumo is a general-wellness food journal. Its targets are estimates, it doesn't diagnose or treat anything, and the listing says so. It doesn't promise weight loss, and I don't think a tracker should. What it can do is make the tedious part of paying attention to food take less time.

Takeaways for anyone building on vision models

Return structure, not a verdict. Itemized output lets users fix one item instead of throwing the whole result away.
Know what your input can't contain. For food it's oil, depth and hidden layers. Every domain has its own version of this.
Put the uncertainty in the UI. A disclaimer helps, but an editable result communicates "this is a guess" better than any fine print.
Be explicit about where the data goes. Users notice.

Try it / tell me where it's wrong

Mealumo is free to download on iPhone (iOS 26+), with an optional PRO subscription for continued scanning and the full recipe collection:
https://apps.apple.com/app/id6811904664

It's new and has no ratings yet, so feedback counts for a lot right now, especially photos where the estimate is clearly off. If you want to try PRO, comment or DM me for a free PRO promo code.

And if you've built something on vision models with messy real-world input, how did you handle the cases where the answer simply isn't in the image?