{ "componentChunkName": "component---src-templates-blog-post-jsx", "path": "/en/blog/coding/website-or-app-yes-hacky-expo-router-guide/", "result": {"data":{"site":{"siteMetadata":{"siteUrl":"https://pablo.gg"}},"markdownRemark":{"id":"46c52258-c9b4-535c-9c88-3758ac8a0cc5","excerpt":"One of the annoying little side quests of shipping an app is that Google occasionally forces you to become a website owner too. Back when I first wrote about…","html":"

One of the annoying little side quests of shipping an app is that Google occasionally forces you to become a website owner too.

\n

Back when I first wrote about Musclog in 2024, the website mostly existed because Google wanted it to exist. I needed the privacy policy, the public pages, the whole respectable app developer starter pack, so I quickly spun up a small Next.js site, got the app approved, and moved on with my life.

\n

That worked right until I had to touch the website again.

\n

New screenshots? Other repo. New feature copy? Other repo. Legal page update? Other repo. Translation tweak? Other repo.

\n

None of that was actually hard, which almost made it worse. It was just annoying enough to keep reminding me that I had split one product into two codebases for a reason I no longer respected.

\n

So now I don’t.

\n

Musclog’s website lives inside the app repo. Same Expo Router project. Same deploy. musclog.app is the public site, musclog.app/app is the actual web app, and Android + iOS still come from the same codebase.

\n

Best practice? Questionable. Convenient? Extremely.

\n

\n \n ;\r\nimport { useEffect } from 'react';\r\nimport { Platform } from 'react-native';\r\n\r\nexport default function Index() {\r\n const router = useRouter();\r\n\r\n useEffect(() => {\r\n if (Platform.OS === 'web') {\r\n router.replace('/home');\r\n }\r\n }, [router]);\r\n\r\n if (Platform.OS === 'web') {\r\n return null;\r\n }\r\n\r\n return <Redirect href=\"/app\" />;\r\n}\n

That’s it. On web, / becomes the website. On native, / becomes the app.

\n

The website also gets its own lighter layout:

\n
// app/(website)/_layout.web.tsx\r\nimport { Slot } from 'expo-router';\r\n\r\nimport { WebsiteChrome } from '@/components/website/WebsiteChrome';\r\nimport { WebsiteProviders } from '@/components/website/WebsiteProviders';\r\n\r\nexport default function WebsiteLayout() {\r\n  return (\r\n    <WebsiteProviders>\r\n      <WebsiteChrome>\r\n        <Slot />\r\n      </WebsiteChrome>\r\n    </WebsiteProviders>\r\n  );\r\n}
\n

That matters because the real app layout had already grown into an actual app layout. Database boot, migrations, React Query, safe area, gestures, modals, snackbars, camera, coach context, all the usual “small side project” lies. The website does not need any of that just to explain what the app does.

\n

And if a native user somehow lands on a website-only route, the fix is beautifully blunt:

\n
// app/(website)/home.tsx\r\nimport { Redirect } from 'expo-router';\r\n\r\nexport default function Home() {\r\n  return <Redirect href=\"/app\" />;\r\n}
\n

Done. Back to your macros.

\n

\n \n \n \n \n
Musclog public website rendered from the same Expo Router codebase as the app
\n

\n

The desktop phone nonsense

\n

This is where I stopped behaving like a normal person.

\n

I wanted musclog.app/app on desktop to show the actual working app inside a phone frame. Partly because it looks nice. Partly because it doubles as a product preview. Mostly because once the idea entered my head, every less ridiculous option started feeling wrong.

\n

The annoying detail was that /app should look like a phone, but /home absolutely should not. So routing alone was not enough. I needed the raw HTML shell to know, before hydration, whether the browser should render the fake phone wrapper or not.

\n

That logic lives in app/+html.tsx, inside a script in the document <head>:

\n
function landingPanelGate(base: string) {\r\n  try {\r\n    function update() {\r\n      const raw = window.location.pathname;\r\n      const path = (base && raw.startsWith(base) ? raw.slice(base.length) : raw) || '/';\r\n\r\n      if (!path.startsWith('/app')) {\r\n        document.documentElement.classList.add('hide-desktop-wrapper');\r\n      } else {\r\n        document.documentElement.classList.remove('hide-desktop-wrapper');\r\n      }\r\n    }\r\n\r\n    update();\r\n    window.addEventListener('popstate', update);\r\n\r\n    const origPush = history.pushState.bind(history);\r\n    history.pushState = function (...args) {\r\n      origPush(...args);\r\n      update();\r\n    };\r\n\r\n    const origReplace = history.replaceState.bind(history);\r\n    history.replaceState = function (...args) {\r\n      origReplace(...args);\r\n      update();\r\n    };\r\n  } catch (_) {}\r\n}
\n

The important part is the pushState / replaceState monkey patch. First paint was easy. Client-side navigation was the annoying bit. Without this, you could leave /app and keep the wrong shell around like Chrome had forgotten what page it was on.

\n

The HTML shell itself is basically the landing panel, the routed app, and the phone frame:

\n
<body className=\"expo-web-body\">\r\n  <div className=\"expo-web-landing\">...</div>\r\n  <script dangerouslySetInnerHTML={{ __html: LANDING_I18N_SCRIPT }} />\r\n  <div className=\"expo-web-root\">\r\n    <div className=\"expo-web-app-shell\">{children}</div>\r\n    <img\r\n      className=\"expo-web-phone-frame\"\r\n      src={withExpoBaseUrl(PHONE_FRAME_SRC)}\r\n      alt=\"\"\r\n      aria-hidden\r\n    />\r\n  </div>\r\n</body>
\n

Then CSS commits the crime:

\n
@media (min-width: 1024px) {\r\n  .expo-web-root {\r\n    --frame-h: min(100dvh, max(min(360px, 100dvh), 85dvh));\r\n    aspect-ratio: 1438 / 2976;\r\n    width: min(100vw, calc(var(--frame-h) * 1438 / 2976));\r\n    max-height: var(--frame-h);\r\n    overflow: hidden;\r\n  }\r\n\r\n  .expo-web-app-shell {\r\n    position: absolute;\r\n    left: 7.4409%;\r\n    top: 2.9906%;\r\n    right: 6.3282%;\r\n    bottom: 3.125%;\r\n    zoom: 0.85;\r\n  }\r\n}
\n

Yes, I measured the transparent screen area inside the PNG until the app lined up correctly. There is no elegant geometry behind those percentages. It was just me, a phone bezel, and a lot of nudging until the app stopped looking crooked.

\n

On routes that are not /app, the whole performance gets disabled:

\n
.hide-desktop-wrapper .expo-web-landing,\r\n.hide-desktop-wrapper .expo-web-phone-frame {\r\n  display: none !important;\r\n}\r\n\r\n.hide-desktop-wrapper .expo-web-app-shell {\r\n  position: static !important;\r\n  width: 100% !important;\r\n  height: auto !important;\r\n  zoom: 1 !important;\r\n  overflow: visible !important;\r\n}
\n

Yes, it uses !important. This is pre-hydration CSS whose entire job is keeping the lie intact. We are not doing refined architecture at this layer.

\n

\n \n \n \n \n
Musclog desktop web app rendered inside a phone frame next to the landing panel
\n

\n

Three tiny crimes

\n

\"Straight

\n

Once the shell worked, the smaller annoyances started lining up like they had booked appointments.

\n

1. The landing panel needed i18n before hydration

\n

The text beside the phone frame lives in raw HTML, which means React and i18n are still sleeping when the page first renders. So if I wanted a Portuguese page to not flash English first, I had to patch it myself from localStorage:

\n
function landingI18nPatcher(translations, storageKey) {\r\n  try {\r\n    let lang = localStorage.getItem(storageKey);\r\n    let s = (lang && translations[lang]) || translations['en-US'];\r\n\r\n    document.querySelectorAll('[data-landing-i18n]').forEach(function (el) {\r\n      let k = el.getAttribute('data-landing-i18n');\r\n      if (k && s[k]) {\r\n        el.textContent = s[k];\r\n      }\r\n    });\r\n  } catch (_) {}\r\n}
\n

Not elegant. Also not flash-banging a Portuguese page with English text, so I’m keeping it.

\n

2. Raw HTML assets do not get Expo’s usual help

\n

The phone frame PNG and QR code are referenced from raw HTML too, which means Expo’s usual asset niceness does not really help me there. So I needed a helper for base URLs:

\n
function withExpoBaseUrl(path: string): string {\r\n  const base = process.env.EXPO_BASE_URL;\r\n  if (base == null || base === '') {\r\n    return path;\r\n  }\r\n\r\n  const basePath = String(base).replace(/^\\/+|\\/+$/g, '');\r\n  const normalized = path.startsWith('/') ? path : `/${path}`;\r\n  return `/${basePath}${normalized}`;\r\n}
\n

And because those files live outside the React Native asset pipeline, I copy them into public/ before dev and export. Forget that step once and the site immediately reminds you who is in charge.

\n

3. expo export occasionally needed emotional support

\n

In some environments, expo export --platform web would successfully finish and then just stay alive for no reason. Dist folder there. Files generated. Process spiritually complete, technically still hanging around.

\n

So now there is a wrapper script:

\n
// scripts/export-web-wrapper.js\r\nif (output.includes('Exported: dist')) {\r\n  console.log('[export-web-wrapper] Detected successful export. Forcing exit in 5s...');\r\n  setTimeout(() => process.exit(0), 5000);\r\n}
\n

Not glamorous. Very effective.

\n

Then modals got weird

\n

\n \n \n \n \n
Musclog desktop modal rendered correctly inside the phone frame
\n

\n

Of course they did.

\n

When the web app lives inside a fake phone on desktop, React Native Web’s default Modal behavior starts looking ridiculous very quickly. Portaling straight to document.body is fine when the whole app owns the page. It is much less fine when the app is visually clipped inside a phone shell and the modal suddenly decides it belongs to the whole browser window instead.

\n

So I added a WebModalShellProvider high in app/app/_layout.tsx, with an overlay host inside the phone shell:

\n
// context/WebModalShellContext.web.tsx\r\nreturn (\r\n  <WebModalShellContext.Provider value={{ hostElement }}>\r\n    <View style={{ flex: 1, minHeight: 0, height: '100%', width: '100%', position: 'relative' }}>\r\n      <View style={{ flex: 1, minHeight: 0, height: '100%', width: '100%' }} collapsable={false}>\r\n        {children}\r\n      </View>\r\n      <View\r\n        id=\"expo-web-modal-shell-host\"\r\n        ref={setHostRef}\r\n        collapsable={false}\r\n        style={{\r\n          position: 'absolute',\r\n          left: 0,\r\n          right: 0,\r\n          top: 0,\r\n          bottom: 0,\r\n          zIndex: 1_000_000,\r\n        }}\r\n      />\r\n    </View>\r\n  </WebModalShellContext.Provider>\r\n);
\n

Then Modal.web.tsx does the obvious-not-obvious thing and switches between a portal inside that host and the normal RN modal:

\n
const useShellPortal = Platform.OS === 'web' && isDesktopFrame && hostElement != null;\r\n\r\nif (useShellPortal) {\r\n  return createPortal(\r\n    <View\r\n      style={{\r\n        position: 'absolute',\r\n        left: 0,\r\n        right: 0,\r\n        top: 0,\r\n        bottom: 0,\r\n        width: '100%',\r\n        height: '100%',\r\n      }}\r\n    >\r\n      {children}\r\n    </View>,\r\n    hostElement\r\n  );\r\n}\r\n\r\nreturn <RNModal visible={visible}>{children}</RNModal>;
\n

And the shared overlay hook knows whether it should behave like a full viewport modal or a fake-phone viewport modal:

\n
export function useWebModalLayerStyle(options = {}) {\r\n  const isDesktopFrame = useWebDesktopPhoneFrame();\r\n\r\n  if (isDesktopFrame) {\r\n    return {\r\n      position: 'absolute',\r\n      top: 0,\r\n      left: 0,\r\n      right: 0,\r\n      bottom: 0,\r\n      width: '100%',\r\n      height: '100%',\r\n    };\r\n  }\r\n\r\n  return {\r\n    position: 'fixed',\r\n    top: 0,\r\n    left: 0,\r\n    right: 0,\r\n    bottom: 0,\r\n    width: '100vw',\r\n    height: '100dvh',\r\n  };\r\n}
\n

That fixed the visual part. Then pointer events decided they wanted attention too.

\n

On native, pointerEvents=\"box-none\" is normal. On HTML, that turns into pointer-events: box-none, which is not real CSS, which means the browser gets to improvise. So there is now a defensive rule for the overlay host:

\n
.expo-web-app-shell #expo-web-modal-shell-host {\r\n  pointer-events: none !important;\r\n}\r\n\r\n.expo-web-app-shell #expo-web-modal-shell-host * {\r\n  pointer-events: auto !important;\r\n}
\n

There is also a useLayoutEffect forcing the same thing inline, because by that point I was no longer interested in finding out how polite the correct solution was.

\n

Look, I have a type

\n

If you’ve been reading this blog for a while, none of this should surprise you.

\n

I already turned this blog into a top-down RPG because the Konami Code deserved a bigger payoff than just a background effect.

\n

Then I added Stories to the blog because my internet provider’s app had Stories, and something about that annoyed me deeply enough that I made it everybody else’s problem.

\n

So yes, of course my fitness app now ships its website from the same Expo Router repo, and of course the desktop web app runs inside a giant picture of a phone. This is not a surprising escalation. This is just continuity.

\n

Why I’m keeping it

\n

Past the comedy value, this fixed a very real maintenance tax.

\n

Translations are shared. Design tokens are shared. Components are shared. Legal pages live next to the product they are legally defending. When I change copy, screenshots, or feature positioning, I don’t need to remember which repo holds the respectable public version of the same app.

\n

Deploy also got nicer. One build. One export. One artifact. The website and the web app cannot drift apart unless I deliberately make them drift apart, which is much harder when they are literally shipped together.

\n

And when I shipped the Musclog redesign, the website basically came along for the ride. Same spacing tokens, same colors, updated screenshots, same PR. Exactly the kind of boring maintenance win that makes a slightly weird architecture decision feel smart six months later.

\n

Conclusion

\n

Could I have kept the website in a separate Next.js repo like a more emotionally stable person? Sure.

\n

Was I ever going to keep doing that once Expo Router made this possible? No.

\n

The funny part is that the routing was the boring part. Expo Router handled that just fine. The annoying work lived in all the little browser lies around it: route gating before hydration, raw HTML i18n, asset syncing, shell-aware modals, pointer-event weirdness, and convincing desktop Chrome to temporarily believe it was a phone.

\n

Still worth it.

\n

If you want to poke around the code, Musclog is open-source on GitHub. If you want to use it, it’s at musclog.app. The website lives in the app repo now.

\n

Everybody lives here now.

","fields":{"postHashId":"Y29kaW5ndHJ1ZW51bGwyMDI2LTA0LTI1VDAwOjAwOjAwLjAwMFo=","slug":"/2026/2026-04-25-website-or-app-yes-hacky-expo-router-guide.en/","path":"/blog/coding/website-or-app-yes-hacky-expo-router-guide/","locale":"en"},"readingTime":{"minutes":10.545},"frontmatter":{"path":"website-or-app-yes-hacky-expo-router-guide","allowComments":true,"title":"Website or App? Yes! The hacky guide to building sites with Expo Router","date":"2026-04-25T00:00:00.000Z","categories":["coding"],"tags":["expo","expo router","react native","musclog","website","monorepo","javascript","typescript"],"hideExcerpt":false,"subtitle":"The routing part was easy. The fake phone in the browser was not."}},"categoryImage":{"childImageSharp":{"original":{"width":1920,"height":1080,"src":"/static/categories_coding-aa17d098a6a0d8e0a764a345865f5ffb.jpg"}}}},"pageContext":{"postHashId":"Y29kaW5ndHJ1ZW51bGwyMDI2LTA0LTI1VDAwOjAwOjAwLjAwMFo=","relatedPosts":[{"fields":{"postHashId":"Y29kaW5ndHJ1ZW51bGwyMDI2LTAzLTIyVDAwOjAwOjAwLjAwMFo=","slug":"/2026/2026-03-22-musclog-redesign-nutrition-tracking-and-why-your-fitness-app-subscription-is-a-scam.en/","path":"/blog/coding/musclog-redesign-nutrition-tracking-and-why-your-fitness-app-subscription-is-a-scam/","locale":"en"},"frontmatter":{"tags":["react","react native","expo","android","fitness","musclog","nutrition","usda","open food facts","stitch","design","offline","watermelondb","nativewind"],"categories":["coding"],"allowComments":true,"publishOnMedium":false,"cover":null,"date":"2026-03-22T00:00:00.000Z","id":null,"path":"musclog-redesign-nutrition-tracking-and-why-your-fitness-app-subscription-is-a-scam","show":true,"title":"Musclog: Redesign nutrition tracking and why your fitness app subscription is a scam","hideExcerpt":false,"subtitle":"New UI, real food databases, and a rant about fitness app subscriptions I've been sitting on for two years"}},{"fields":{"postHashId":"Y29kaW5ndHJ1ZW51bGwyMDI0LTA5LTIxVDAwOjAwOjAwLjAwMFo=","slug":"/2024/2024-09-21-musclog-leveraging-my-reactjs-experience-to-build-a-react-native-app.en/","path":"/blog/coding/musclog-leveraging-my-reactjs-experience-to-build-a-react-native-app/","locale":"en"},"frontmatter":{"tags":["react","react native","expo","android","workout","tracker","logger","musclog"],"categories":["coding"],"allowComments":true,"publishOnMedium":false,"cover":null,"date":"2024-09-21T00:00:00.000Z","id":null,"path":"musclog-leveraging-my-reactjs-experience-to-build-a-react-native-app","show":true,"title":"Musclog: Leveraging my React.js experience to build a React Native App","hideExcerpt":false,"subtitle":"From Bodybuilding to Codebuilding: Crafting a comprehensive fitness App using React Native and Expo"}},{"fields":{"postHashId":"Y29kaW5ndHJ1ZW51bGwyMDI2LTAyLTEyVDAwOjAwOjAwLjAwMFo=","slug":"/2026/2026-02-12-why-the-7700-calorie-rule-is-broken-and-how-i-fixed-it-in-my-app.en/","path":"/blog/coding/why-the-7700-calorie-rule-is-broken-and-how-i-fixed-it-in-my-app/","locale":"en"},"frontmatter":{"tags":["typescript","musclog","algorithms","fitness","nutrition","bodybuilding"],"categories":["coding"],"allowComments":true,"publishOnMedium":false,"cover":null,"date":"2026-02-12T00:00:00.000Z","id":null,"path":"why-the-7700-calorie-rule-is-broken-and-how-i-fixed-it-in-my-app","show":true,"title":"Why the 7700 calorie rule is broken (and how I fixed it in my app)","hideExcerpt":false,"subtitle":"Spoiler: your body did not read the rulebook"}},{"fields":{"postHashId":"Y29kaW5ndHJ1ZW51bGwyMDI0LTEwLTI1VDAwOjAwOjAwLjAwMFo=","slug":"/2024/2024-10-25-sharing-encrypted-laravel-cookies-with-next-js.en/","path":"/blog/coding/sharing-encrypted-laravel-cookies-with-next-js/","locale":"en"},"frontmatter":{"tags":["laravel","next.js","cookies","encryption","synchronization","web development","php","javascript"],"categories":["coding"],"allowComments":true,"publishOnMedium":false,"cover":null,"date":"2024-10-25T00:00:00.000Z","id":null,"path":"sharing-encrypted-laravel-cookies-with-next-js","show":true,"title":"Sharing encrypted Laravel cookies with Next.js","hideExcerpt":false,"subtitle":"Bridging Laravel and Next.js: How we synchronized encrypted cookies between two different frameworks."}},{"fields":{"postHashId":"Y29kaW5ndHJ1ZW51bGwyMDI0LTA2LTE2VDAwOjAwOjAwLjAwMFo=","slug":"/2024/2024-06-16-tracking-my-working-hours-on-personal-projects-ssing-nodejs.en/","path":"/blog/coding/tracking-my-working-hours-on-personal-projects-ssing-nodejs/","locale":"en"},"frontmatter":{"tags":["nodejs","git","foss","javascript","simple-git","math"],"categories":["coding"],"allowComments":true,"publishOnMedium":false,"cover":null,"date":"2024-06-16T00:00:00.000Z","id":null,"path":"tracking-my-working-hours-on-personal-projects-using-nodejs","show":true,"title":"Tracking my working hours on personal projects using Node.js","hideExcerpt":false,"subtitle":"Finding out the hard way that some information are not supposed to be known"}},{"fields":{"postHashId":"Y29kaW5ndHJ1ZW51bGwyMDIzLTEyLTIwVDAwOjAwOjAwLjAwMFo=","slug":"/2023/2023-12-20-creating-instagram-reels-coding-tutorials-automatically-with-openais-gpt.en/","path":"/blog/coding/creating-instagram-reels-coding-tutorials-automatically-with-openais-gpt/","locale":"en"},"frontmatter":{"tags":["openai","gpt","javascript","node","nodejs","instagram"],"categories":["coding"],"allowComments":true,"publishOnMedium":false,"cover":null,"date":"2023-12-20T00:00:00.000Z","id":null,"path":"creating-instagram-reels-coding-tutorials-automatically-with-openais-gpt","show":true,"title":"Creating Instagram Reels coding tutorials automatically with OpenAI's GPT","hideExcerpt":false,"subtitle":"Node.js and OpenAI: auto-generating coding tutorial videos."}},{"fields":{"postHashId":"Y29kaW5ndHJ1ZW51bGwyMDIzLTEwLTI1VDAwOjAwOjAwLjAwMFo=","slug":"/2023/2023-10-25-how-to-automatically-create-thumbnails-for-your-videos-with-nodejs.en/","path":"/blog/coding/how-to-automatically-create-thumbnails-for-your-videos-with-nodejs/","locale":"en"},"frontmatter":{"tags":["instagram","thumbnail","node","nodejs","javascript","canvas","image","video"],"categories":["coding"],"allowComments":true,"publishOnMedium":false,"cover":null,"date":"2023-10-25T00:00:00.000Z","id":null,"path":"how-to-automatically-create-thumbnails-for-your-videos-with-nodejs","show":true,"title":"How to automatically create thumbnails for your videos with Node.js","hideExcerpt":false,"subtitle":"The best way to create thumbnails for your videos on Instagram"}},{"fields":{"postHashId":"Y29kaW5ndHJ1ZW51bGwyMDIzLTEwLTE0VDAwOjAwOjAwLjAwMFo=","slug":"/2023/2023-10-14-posting-instagram-reels-using-nodejs-and-the-art-of-overcoming-limitations.en/","path":"/blog/coding/posting-instagram-reels-using-nodejs-and-the-art-of-overcoming-limitations/","locale":"en"},"frontmatter":{"tags":["instagram","node","nodejs","javascript","axios","ngrok","ffmpeg","automation"],"categories":["coding"],"allowComments":true,"publishOnMedium":false,"cover":null,"date":"2023-10-14T00:00:00.000Z","id":null,"path":"posting-instagram-reels-using-nodejs-and-the-art-of-overcoming-limitations","show":true,"title":"Posting Instagram Reels using Node.js and the art of overcoming limitations","hideExcerpt":false,"subtitle":"After all, why spend 30 seconds doing something manually when you can spend 30 hours automating it?"}},{"fields":{"postHashId":"Y29kaW5ndHJ1ZW51bGwyMDIzLTA5LTA0VDAwOjAwOjAwLjAwMFo=","slug":"/2023/2023-09-04-my-blog-now-has-stories-and-im-not-sure-why.en/","path":"/blog/coding/my-blog-now-has-stories-and-im-not-sure-why/","locale":"en"},"frontmatter":{"tags":["instagram","instagram stories","unnecessary inventions","gatsby","react","javascript"],"categories":["coding"],"allowComments":true,"publishOnMedium":false,"cover":null,"date":"2023-09-04T00:00:00.000Z","id":null,"path":"my-blog-now-has-stories-and-im-not-sure-why","show":true,"title":"My blog now has Stories, and I'm not sure why","hideExcerpt":false,"subtitle":"The saga of \"Well, It's here now\""}},{"fields":{"postHashId":"Y29kaW5ndHJ1ZW51bGwyMDIzLTA4LTAyVDAwOjAwOjAwLjAwMFo=","slug":"/2023/2023-08-02-using-google-fitness-api-to-calculate-my-tdee-and-more.en/","path":"/blog/coding/using-google-fitness-api-to-calculate-my-tdee-and-more/","locale":"en"},"frontmatter":{"tags":["google cloud","fitness api","google fit","nodejs","node","javascript"],"categories":["coding"],"allowComments":true,"publishOnMedium":false,"cover":null,"date":"2023-08-02T00:00:00.000Z","id":null,"path":"using-google-fitness-api-to-calculate-my-tdee-and-more","show":true,"title":"Using Google Fitness API to calculate my TDEE and more","hideExcerpt":false,"subtitle":"From calories to code: Integrating Google Fitness API for personalized health insights"}}],"alternativeHtml":"

One of the annoying little side quests of shipping an app is that Google occasionally forces you to become a website owner too.

\n

Back when I first wrote about Musclog in 2024, the website mostly existed because Google wanted it to exist. I needed the privacy policy, the public pages, the whole respectable app developer starter pack, so I quickly spun up a small Next.js site, got the app approved, and moved on with my life.

\n

That worked right until I had to touch the website again.

\n

New screenshots? Other repo. New feature copy? Other repo. Legal page update? Other repo. Translation tweak? Other repo.

\n

None of that was actually hard, which almost made it worse. It was just annoying enough to keep reminding me that I had split one product into two codebases for a reason I no longer respected.

\n

So now I don’t.

\n

Musclog’s website lives inside the app repo. Same Expo Router project. Same deploy. musclog.app is the public site, musclog.app/app is the actual web app, and Android + iOS still come from the same codebase.

\n

Best practice? Questionable. Convenient? Extremely.

\n

\n \n ;\nimport { useEffect } from 'react';\nimport { Platform } from 'react-native';\n\nexport default function Index() {\n const router = useRouter();\n\n useEffect(() => {\n if (Platform.OS === 'web') {\n router.replace('/home');\n }\n }, [router]);\n\n if (Platform.OS === 'web') {\n return null;\n }\n\n return <Redirect href=\"/app\" />;\n}\n

That’s it. On web, / becomes the website. On native, / becomes the app.

\n

The website also gets its own lighter layout:

\n
// app/(website)/_layout.web.tsx\nimport { Slot } from 'expo-router';\n\nimport { WebsiteChrome } from '@/components/website/WebsiteChrome';\nimport { WebsiteProviders } from '@/components/website/WebsiteProviders';\n\nexport default function WebsiteLayout() {\n  return (\n    <WebsiteProviders>\n      <WebsiteChrome>\n        <Slot />\n      </WebsiteChrome>\n    </WebsiteProviders>\n  );\n}
\n

That matters because the real app layout had already grown into an actual app layout. Database boot, migrations, React Query, safe area, gestures, modals, snackbars, camera, coach context, all the usual “small side project” lies. The website does not need any of that just to explain what the app does.

\n

And if a native user somehow lands on a website-only route, the fix is beautifully blunt:

\n
// app/(website)/home.tsx\nimport { Redirect } from 'expo-router';\n\nexport default function Home() {\n  return <Redirect href=\"/app\" />;\n}
\n

Done. Back to your macros.

\n

\n \n \n \"Musclog\n \n
Musclog public website rendered from the same Expo Router codebase as the app
\n

\n

The desktop phone nonsense

\n

This is where I stopped behaving like a normal person.

\n

I wanted musclog.app/app on desktop to show the actual working app inside a phone frame. Partly because it looks nice. Partly because it doubles as a product preview. Mostly because once the idea entered my head, every less ridiculous option started feeling wrong.

\n

The annoying detail was that /app should look like a phone, but /home absolutely should not. So routing alone was not enough. I needed the raw HTML shell to know, before hydration, whether the browser should render the fake phone wrapper or not.

\n

That logic lives in app/+html.tsx, inside a script in the document <head>:

\n
function landingPanelGate(base: string) {\n  try {\n    function update() {\n      const raw = window.location.pathname;\n      const path = (base && raw.startsWith(base) ? raw.slice(base.length) : raw) || '/';\n\n      if (!path.startsWith('/app')) {\n        document.documentElement.classList.add('hide-desktop-wrapper');\n      } else {\n        document.documentElement.classList.remove('hide-desktop-wrapper');\n      }\n    }\n\n    update();\n    window.addEventListener('popstate', update);\n\n    const origPush = history.pushState.bind(history);\n    history.pushState = function (...args) {\n      origPush(...args);\n      update();\n    };\n\n    const origReplace = history.replaceState.bind(history);\n    history.replaceState = function (...args) {\n      origReplace(...args);\n      update();\n    };\n  } catch (_) {}\n}
\n

The important part is the pushState / replaceState monkey patch. First paint was easy. Client-side navigation was the annoying bit. Without this, you could leave /app and keep the wrong shell around like Chrome had forgotten what page it was on.

\n

The HTML shell itself is basically the landing panel, the routed app, and the phone frame:

\n
<body className=\"expo-web-body\">\n  <div className=\"expo-web-landing\">...</div>\n  <script dangerouslySetInnerHTML={{ __html: LANDING_I18N_SCRIPT }} />\n  <div className=\"expo-web-root\">\n    <div className=\"expo-web-app-shell\">{children}</div>\n    <img\n      className=\"expo-web-phone-frame\"\n      src={withExpoBaseUrl(PHONE_FRAME_SRC)}\n      alt=\"\"\n      aria-hidden\n    />\n  </div>\n</body>
\n

Then CSS commits the crime:

\n
@media (min-width: 1024px) {\n  .expo-web-root {\n    --frame-h: min(100dvh, max(min(360px, 100dvh), 85dvh));\n    aspect-ratio: 1438 / 2976;\n    width: min(100vw, calc(var(--frame-h) * 1438 / 2976));\n    max-height: var(--frame-h);\n    overflow: hidden;\n  }\n\n  .expo-web-app-shell {\n    position: absolute;\n    left: 7.4409%;\n    top: 2.9906%;\n    right: 6.3282%;\n    bottom: 3.125%;\n    zoom: 0.85;\n  }\n}
\n

Yes, I measured the transparent screen area inside the PNG until the app lined up correctly. There is no elegant geometry behind those percentages. It was just me, a phone bezel, and a lot of nudging until the app stopped looking crooked.

\n

On routes that are not /app, the whole performance gets disabled:

\n
.hide-desktop-wrapper .expo-web-landing,\n.hide-desktop-wrapper .expo-web-phone-frame {\n  display: none !important;\n}\n\n.hide-desktop-wrapper .expo-web-app-shell {\n  position: static !important;\n  width: 100% !important;\n  height: auto !important;\n  zoom: 1 !important;\n  overflow: visible !important;\n}
\n

Yes, it uses !important. This is pre-hydration CSS whose entire job is keeping the lie intact. We are not doing refined architecture at this layer.

\n

\n \n \n \"Musclog\n \n
Musclog desktop web app rendered inside a phone frame next to the landing panel
\n

\n

Three tiny crimes

\n

\"Straight

\n

Once the shell worked, the smaller annoyances started lining up like they had booked appointments.

\n

1. The landing panel needed i18n before hydration

\n

The text beside the phone frame lives in raw HTML, which means React and i18n are still sleeping when the page first renders. So if I wanted a Portuguese page to not flash English first, I had to patch it myself from localStorage:

\n
function landingI18nPatcher(translations, storageKey) {\n  try {\n    let lang = localStorage.getItem(storageKey);\n    let s = (lang && translations[lang]) || translations['en-US'];\n\n    document.querySelectorAll('[data-landing-i18n]').forEach(function (el) {\n      let k = el.getAttribute('data-landing-i18n');\n      if (k && s[k]) {\n        el.textContent = s[k];\n      }\n    });\n  } catch (_) {}\n}
\n

Not elegant. Also not flash-banging a Portuguese page with English text, so I’m keeping it.

\n

2. Raw HTML assets do not get Expo’s usual help

\n

The phone frame PNG and QR code are referenced from raw HTML too, which means Expo’s usual asset niceness does not really help me there. So I needed a helper for base URLs:

\n
function withExpoBaseUrl(path: string): string {\n  const base = process.env.EXPO_BASE_URL;\n  if (base == null || base === '') {\n    return path;\n  }\n\n  const basePath = String(base).replace(/^\\/+|\\/+$/g, '');\n  const normalized = path.startsWith('/') ? path : `/${path}`;\n  return `/${basePath}${normalized}`;\n}
\n

And because those files live outside the React Native asset pipeline, I copy them into public/ before dev and export. Forget that step once and the site immediately reminds you who is in charge.

\n

3. expo export occasionally needed emotional support

\n

In some environments, expo export --platform web would successfully finish and then just stay alive for no reason. Dist folder there. Files generated. Process spiritually complete, technically still hanging around.

\n

So now there is a wrapper script:

\n
// scripts/export-web-wrapper.js\nif (output.includes('Exported: dist')) {\n  console.log('[export-web-wrapper] Detected successful export. Forcing exit in 5s...');\n  setTimeout(() => process.exit(0), 5000);\n}
\n

Not glamorous. Very effective.

\n

Then modals got weird

\n

\n \n \n \"Musclog\n \n
Musclog desktop modal rendered correctly inside the phone frame
\n

\n

Of course they did.

\n

When the web app lives inside a fake phone on desktop, React Native Web’s default Modal behavior starts looking ridiculous very quickly. Portaling straight to document.body is fine when the whole app owns the page. It is much less fine when the app is visually clipped inside a phone shell and the modal suddenly decides it belongs to the whole browser window instead.

\n

So I added a WebModalShellProvider high in app/app/_layout.tsx, with an overlay host inside the phone shell:

\n
// context/WebModalShellContext.web.tsx\nreturn (\n  <WebModalShellContext.Provider value={{ hostElement }}>\n    <View style={{ flex: 1, minHeight: 0, height: '100%', width: '100%', position: 'relative' }}>\n      <View style={{ flex: 1, minHeight: 0, height: '100%', width: '100%' }} collapsable={false}>\n        {children}\n      </View>\n      <View\n        id=\"expo-web-modal-shell-host\"\n        ref={setHostRef}\n        collapsable={false}\n        style={{\n          position: 'absolute',\n          left: 0,\n          right: 0,\n          top: 0,\n          bottom: 0,\n          zIndex: 1_000_000,\n        }}\n      />\n    </View>\n  </WebModalShellContext.Provider>\n);
\n

Then Modal.web.tsx does the obvious-not-obvious thing and switches between a portal inside that host and the normal RN modal:

\n
const useShellPortal = Platform.OS === 'web' && isDesktopFrame && hostElement != null;\n\nif (useShellPortal) {\n  return createPortal(\n    <View\n      style={{\n        position: 'absolute',\n        left: 0,\n        right: 0,\n        top: 0,\n        bottom: 0,\n        width: '100%',\n        height: '100%',\n      }}\n    >\n      {children}\n    </View>,\n    hostElement\n  );\n}\n\nreturn <RNModal visible={visible}>{children}</RNModal>;
\n

And the shared overlay hook knows whether it should behave like a full viewport modal or a fake-phone viewport modal:

\n
export function useWebModalLayerStyle(options = {}) {\n  const isDesktopFrame = useWebDesktopPhoneFrame();\n\n  if (isDesktopFrame) {\n    return {\n      position: 'absolute',\n      top: 0,\n      left: 0,\n      right: 0,\n      bottom: 0,\n      width: '100%',\n      height: '100%',\n    };\n  }\n\n  return {\n    position: 'fixed',\n    top: 0,\n    left: 0,\n    right: 0,\n    bottom: 0,\n    width: '100vw',\n    height: '100dvh',\n  };\n}
\n

That fixed the visual part. Then pointer events decided they wanted attention too.

\n

On native, pointerEvents=\"box-none\" is normal. On HTML, that turns into pointer-events: box-none, which is not real CSS, which means the browser gets to improvise. So there is now a defensive rule for the overlay host:

\n
.expo-web-app-shell #expo-web-modal-shell-host {\n  pointer-events: none !important;\n}\n\n.expo-web-app-shell #expo-web-modal-shell-host * {\n  pointer-events: auto !important;\n}
\n

There is also a useLayoutEffect forcing the same thing inline, because by that point I was no longer interested in finding out how polite the correct solution was.

\n

Look, I have a type

\n

If you’ve been reading this blog for a while, none of this should surprise you.

\n

I already turned this blog into a top-down RPG because the Konami Code deserved a bigger payoff than just a background effect.

\n

Then I added Stories to the blog because my internet provider’s app had Stories, and something about that annoyed me deeply enough that I made it everybody else’s problem.

\n

So yes, of course my fitness app now ships its website from the same Expo Router repo, and of course the desktop web app runs inside a giant picture of a phone. This is not a surprising escalation. This is just continuity.

\n

Why I’m keeping it

\n

Past the comedy value, this fixed a very real maintenance tax.

\n

Translations are shared. Design tokens are shared. Components are shared. Legal pages live next to the product they are legally defending. When I change copy, screenshots, or feature positioning, I don’t need to remember which repo holds the respectable public version of the same app.

\n

Deploy also got nicer. One build. One export. One artifact. The website and the web app cannot drift apart unless I deliberately make them drift apart, which is much harder when they are literally shipped together.

\n

And when I shipped the Musclog redesign, the website basically came along for the ride. Same spacing tokens, same colors, updated screenshots, same PR. Exactly the kind of boring maintenance win that makes a slightly weird architecture decision feel smart six months later.

\n

Conclusion

\n

Could I have kept the website in a separate Next.js repo like a more emotionally stable person? Sure.

\n

Was I ever going to keep doing that once Expo Router made this possible? No.

\n

The funny part is that the routing was the boring part. Expo Router handled that just fine. The annoying work lived in all the little browser lies around it: route gating before hydration, raw HTML i18n, asset syncing, shell-aware modals, pointer-event weirdness, and convincing desktop Chrome to temporarily believe it was a phone.

\n

Still worth it.

\n

If you want to poke around the code, Musclog is open-source on GitHub. If you want to use it, it’s at musclog.app. The website lives in the app repo now.

\n

Everybody lives here now.

","otherLanguagesUrl":["/pt-br/blog/coding/site-ou-app-sim-o-guia-gambiarrístico-para-sites-feitos-em-expo-router/"],"rss":{"title":"Website or App? Yes! The hacky guide to building sites with Expo Router","description":"Website or App? Yes! The hacky guide to building sites with Expo Router","date":"2026-04-25T00:00:00.000Z"},"images":["/static/f71a459f3034e47544de2f3ce309dd61/42a19/musclog-shared-router-website-home-1.png","/static/c50b08ecc21b0e02ed7774578063a5f6/42a19/musclog-shared-router-website-home-2.png","/static/49361b3283ae34ef30a950b13c7f5594/42a19/musclog-desktop-phone-frame-wrapper.png","/377ac4354ce553fccf98c5d8d1017e50/straight-to-jail.gif","/static/a2af4c3fcf36eee559fddfb48a5143d1/42a19/musclog-desktop-modal-inside-phone-frame.png"],"videos":[],"comments":[],"googleFormData":{"fvv":1,"pageHistory":0,"fbzx":"2341154569390836157","action":"e/1FAIpQLSeST_0jBnLKkEkXGpyx9LWrvV2a1-1F5dr-AcA4wn0BSRyPCw","title":"blog_comment","description":null,"fields":[{"label":"name","description":null,"type":"SHORT_ANSWER","id":"1953327618","required":true},{"label":"email","description":null,"type":"SHORT_ANSWER","id":"1309141965","required":false},{"label":"twitter","description":null,"type":"SHORT_ANSWER","id":"740186305","required":false},{"label":"comment","description":null,"type":"LONG_ANSWER","id":"1663940054","required":true},{"label":"post_path","description":null,"type":"SHORT_ANSWER","id":"1852628638","required":true}],"fieldsOrder":{"740186305":2,"1309141965":1,"1663940054":3,"1852628638":4,"1953327618":0}},"pageType":"blogPost","categoryImage":"/categories_coding.jpg/","slug":"/2026/2026-04-25-website-or-app-yes-hacky-expo-router-guide.en/","locale":"en","title":"Website or App? Yes! The hacky guide to building sites with Expo Router","previous":{"excerpt":"Imagina a cena: você tá na academia. Entre séries. Suado…","html":"

Imagina a cena: você tá na academia. Entre séries. Suado. Com uns 90 segundos antes de ter que pegar a barra de novo, e você tá ali cutucando o seu próprio aplicativo igual ao pai de alguém tentando navegar num site de 2008. Quatro toques pra registrar uma série. Quatro toques. Num app que você mesmo escreveu. Que você poderia mudar. E mesmo assim, toda vez, você faz os quatro toques porque sempre tem outra coisa mais urgente pra fazer antes.

\n

Era o Musclog. Meu app de treino. Meu projeto de “300 horas que não vou recuperar” que eu escrevi lá em 2024. Funcionava. Meus amigos usavam. Eu registrei cada treino e cada grama de comida por meses com ele.

\n

Também era, objetivamente, um dos apps mais feios que eu já tinha colocado no meu celular.

\n

\n \n \n \n \n
Design original do Musclog - a foto de antes que ninguém pediu
\n

\n

Eu sabia. Meus amigos sabiam. O amigo honesto o suficiente pra falar “cara, isso parece um site” sabia, e falou na minha cara sem a menor cerimônia. Mas funcionava, e por um tempo isso era suficiente. “Funciona” é o equivalente do desenvolvedor ao “tá bom” - tecnicamente verdade, emocionalmente uma mentira completa com a qual você concordou em viver.

\n

Aí a dívida de UX foi rendendo juros na minha vida. Registrar um treino parecia preencher papelada. Adicionar comida exigia pular entre três telas diferentes quando deveria ser uma. Navegar no app na academia, já suado e com tempo contado, era um exercício de fricção que eu tinha projetado pra mim mesmo sem querer. Fui empilhando features em cima desse caos visual, que é um jeito excelente de deixar a casa do acumulador ainda mais difícil de navegar. Sem falar nos bugs, que às vezes simplesmente crashavam o app e ficavam lá no Sentry, sem solução.

\n

Tinha que mudar alguma coisa. E por “alguma coisa” eu quero dizer tudo.

\n

Eu não dou pra um bom designer

\n

Eu tenho muitos amigos que dão pra um bom designer. Muitos. Não é o meu caso. O app original foi feito com react-native-paper, que é uma biblioteca perfeitamente decente. O problema não era o react-native-paper. O problema era eu. Fui jogando componentes juntos na ordem que fazia sentido na hora, escolhendo cores no feeling, e shippando sem nenhum design system de verdade. Sem escala de espaçamento. Sem paleta de cores semântica. Puro instinto de desenvolvedor aplicado diretamente numa UI, que, como se descobriu, produz exatamente o tipo de app que eu terminei tendo.

\n

O mesmo conceito parecia diferente em três telas diferentes porque cada tela foi construída num momento diferente da minha compreensão do app. Botões primários tinham alturas diferentes dependendo de onde você os encontrava. Cards tinham três raios de canto diferentes que eu provavelmente escolhi com grande intenção e depois esqueci completamente. Cores eram hardcoded em todo lugar. A coisa toda era mantida unida por confiança e fita adesiva.

\n

O plano de migração: arrancar o react-native-paper, substituir pelo NativeWind (Tailwind CSS pro React Native), e construir um design system de verdade do zero. Simples. Direto. Completamente insano dado o tamanho do codebase nessa altura.

\n

Fui e fiz mesmo assim, porque não tenho nenhum instinto de autopreservação quando se trata de side projects.

\n

Entra o Stitch

\n

Eu estava de olho no Google Stitch desde que lançou. A versão curta: é uma ferramenta de IA que gera UI de app mobile a partir de prompts e screenshots. Você descreve a estética que quer, joga umas telas de referência, e ele gera componentes React coerentes. Pra um desenvolvedor que genuinamente tentou aprender design três vezes separadas e falhou cada vez por razões fundamentalmente diferentes, isso pareceu cola no melhor sentido possível.

\n

Alimentei com as telas existentes do Musclog e descrevi o que queria: tema escuro, estética de fitness e performance, algo que parecesse estar olhando pra dados sérios ao invés de uma lista de tarefas. Queria que parecesse o dashboard de algo que faz sentido, não um app de bem-estar que vai sugerir que você “respire fundo” antes de registrar seu deadlift.

\n

\n \n \n \n \n
Nova tela inicial do Musclog
\n

\n

A parte inesperada foi o quanto esse processo me forçou a pensar claramente sobre o produto em si. Pra gerar uma boa tela no Stitch, eu precisava articular pra que aquela tela servia antes de poder descrever como deveria parecer. Esse processo expôs problemas de UX que não tinham nada a ver com cores. Um passo no fluxo de registro de treino existia puramente por causa de uma limitação técnica que eu tinha contornado com UI ao invés de resolver o problema de verdade. Resolvido. Fingi que nunca aconteceu. Resolvido, depois refatorei o serviço por baixo pra que nunca voltasse.

\n

Eu escrevi O Stitch também escreveu um documento de design de verdade pela primeira vez na vida desse projeto: cores de superfície com nomes, cores semânticas pra macros (proteína é sempre índigo #6366f1, gordura é sempre âmbar #f59e0b, carbo é esmeralda #10b981, fibra é rosa #ec4899), escala de espaçamento em 4/8/12/16/20/24/32px, padrões de border radius em 12px pra inputs e 16px pra cards primários. Coisas que eu deveria ter definido antes de escrever uma única linha de código de UI. A conta do “manda ver” chegou, como sempre chega, com juros.

\n

A arquitetura que ninguém pediu

\n

Já que eu estava queimando a UI até os alicerces, aproveitei pra apertar a arquitetura por baixo também. Essa é a parte onde a maioria das pessoas desliga, mas se você tá construindo algo com armazenamento local-first em React Native, algumas dessas decisões podem te poupar tempo.

\n

O Musclog usa WatermelonDB pro armazenamento local. Não SQLite puro, não MMKV, não AsyncStorage. O WatermelonDB fica em cima do SQLite no native e LokiJS no web, e te dá uma camada de modelo com queries reativas. Quando o dado muda, qualquer componente observando aquela query re-renderiza automaticamente. Sem sync de estado manual. Sem bug de “lembrei de atualizar a lista depois de salvar?“. O mesmo codebase roda no Android e no browser sem tocar na camada de dados, o que importa quando você quer testar algo rápido sem subir um device.

\n

A estrutura em camadas vai assim: definição de schema na base, depois models, depois services que cuidam de CRUD e lógica de negócio. Serviços que não são de banco (IA, notificações, sync do Health Connect) vivem separados no próprio dir services/. Todo write passa por database.write(async () => { ... }). Sem exceções. Blocos de write aninhados causam deadlocks no WatermelonDB, e são uma dor de cabeça pra debugar, então a regra é simples: nunca aninhe, e se você quiser fazer isso, você projetou algo errado lá atrás.

\n

É assim que fica no NutritionCheckinService.ts criando um lote de check-ins semanais:

\n
static async createBatch(\r\n    nutritionGoalId: string,\r\n    checkins: NutritionCheckinInput[]\r\n): Promise<NutritionCheckin[]> {\r\n    return await database.write(async () => {\r\n        const collection = database.get<NutritionCheckin>('nutrition_checkins');\r\n\r\n        const preparedRecords = checkins.map((data) =>\r\n            collection.prepareCreate((record) => {\r\n                record.nutritionGoalId = nutritionGoalId;\r\n                record.checkinDate = data.checkinDate;\r\n                record.targetWeight = data.targetWeight;\r\n                record.status = data.status ?? 'pending';\r\n            })\r\n        );\r\n\r\n        await database.batch(...preparedRecords);\r\n        return preparedRecords;\r\n    });\r\n}
\n

A combinação prepareCreate + database.batch() é como o WatermelonDB lida com múltiplos inserts atomicamente sem múltiplas viagens de ida e volta. Um bloco write(), um batch, feito. Você nunca chama o database.write() de outro service lá de dentro, porque é assim que você consegue um deadlock às 23h que misteriosamente só reproduz no device.

\n

\n \n ;\r\nimport Animated, { useAnimatedStyle, useSharedValue } from 'react-native-reanimated';\r\n\r\n// components/charts/LineChart.web.tsx - web (SVG)\r\nimport { VictoryArea, VictoryAxis, VictoryChart, VictoryLine, VictoryScatter } from 'victory';\n

Mesma interface de props, mesmo comportamento, backends de renderização diferentes. O bundler do Expo resolve LineChart pro arquivo .web.tsx no web e pro .tsx em todo o resto. Zero condicionais no componente que realmente o usa.

\n

O tracking de volume funciona da mesma forma na infraestrutura, exceto que o problema interessante aí é a matemática. O Musclog rastreia volume como máximo estimado de uma repetição, não peso x reps bruto, porque 5 reps em 80kg e 12 reps em 60kg são estímulos de treino diferentes que produzem o mesmo número num gráfico de volume ingênuo. O problema é que não existe uma fórmula de 1RM aceita universalmente. Brzycki, Epley, Lander, Mayhew - todas dão um número ligeiramente diferente pro mesmo set, e a pesquisa não elege um vencedor claro. Então o Musclog roda as sete e tira a média:

\n
// utils/workoutCalculator.ts\r\nexport function calculateAverage1RM(weight: number, reps: number, rir: number = 0): number {\r\n    const formulas: FormulaType[] = [\r\n        'Epley', 'Brzycki', 'Lander', 'Lombardi', 'Mayhew', 'OConner', 'Wathan',\r\n    ];\r\n    let total1RM = 0;\r\n    let validFormulas = 0;\r\n\r\n    formulas.forEach((formula) => {\r\n        const oneRM = calculate1RM(weight, reps, formula, rir);\r\n        if (oneRM !== null) {\r\n            total1RM += oneRM;\r\n            validFormulas++;\r\n        }\r\n    });\r\n\r\n    return validFormulas > 0 ? total1RM / validFormulas : 0;\r\n}
\n

O parâmetro rir é Reps in Reserve: se você parou em 8 mas tinha mais 2 no tanque, rir = 2 ajusta a estimativa pra cima pra refletir o que você realmente poderia levantar. Registrar seu RIR é opcional. O tipo de pessoa que construiu seu próprio app de fitness e rastreia tudo em planilha geralmente também é o tipo de pessoa que rastreia o RIR. Não tô dizendo que sou eu. Sou eu.

\n

Espera, e os dados reais de comida?

\n

É. O redesign foi a parte visível dessa atualização. A parte mais significativa, pelo menos do ponto de vista de “esse app é realmente útil”, foi reconstruir completamente como o tracking de comida funciona.

\n

A versão original dependia muito das informações nutricionais vindas do Health Connect. Se você não tinha outro app pra fazer o tracking de nutrição, ficava a deriva. Isso é aceitável pra um projeto de fim de semana. Não é aceitável pra um app que as pessoas usam diariamente pra rastrear calorias, proteína, carbo, gordura, e mais de 40 micronutrientes em múltiplas refeições.

\n

Pra minha genuína surpresa, descobri que dados de alta qualidade sobre comida não ficam atrás de um portão corporativo. Existem APIs públicas e gratuitas enormes - como USDA e Open Food Facts - que fornecem de quebra de micronutrientes detalhada a consulta de código de barras global sem cobrar um centavo. Encontrar isso foi um grande momento “aha!”: se o dado é público e o processamento acontece direto no seu device, não existe justificativa técnica alguma pra rastreamento de nutrição ser um SaaS baseado em assinatura. A maioria dos apps “premium” basicamente te cobra uma mensalidade pra ser intermediário de dados que nem são deles, mas essa é uma discussão picante que guardei pra outra hora.\r\nO Musclog agora conecta a dois bancos de dados de comida reais.

\n

USDA FoodData Central

\n

USDA FoodData Central é o banco de dados nutricional público do Departamento de Agricultura dos EUA. Centenas de milhares de alimentos, de produtos de marcas a ingredientes brutos, com detalhamento de macro e micronutrientes. São dados governamentais, é gratuito, e a API não requer cartão de crédito, o que como você vai ver é uma consideração não trivial pra mim. A cobertura de produtos de marcas americanos e globais é genuinamente sólida. Essa é a espinha dorsal da busca.

\n

O USDA identifica nutrientes por códigos numéricos, então mapeá-los pra algo legível por humanos requer uma camada de lookup. É assim que o mapper parece na prática:

\n
// utils/usdaMapper.ts\r\nexport function mapUSDAFoodToUnified(food: USDAFood): UnifiedFoodResult {\r\n    const nutrients = food.foodNutrients;\r\n\r\n    // USDA usa códigos numéricos de nutrientes - 1008/208 é energia, 1003/203 é proteína, etc.\r\n    const calories = mapUSDANutritient(nutrients, '1008') ?? mapUSDANutritient(nutrients, '208');\r\n    const protein  = mapUSDANutritient(nutrients, '1003') ?? mapUSDANutritient(nutrients, '203');\r\n    const carbs    = mapUSDANutritient(nutrients, '1005') ?? mapUSDANutritient(nutrients, '205');\r\n    const fat      = mapUSDANutritient(nutrients, '1004') ?? mapUSDANutritient(nutrients, '204');\r\n    const fiber    = mapUSDANutritient(nutrients, '1079') ?? mapUSDANutritient(nutrients, '291');\r\n\r\n    return {\r\n        id: String(food.fdcId),\r\n        name: food.description,\r\n        brand: food.brandOwner,\r\n        calories: calories !== undefined ? Math.round(calories) : undefined,\r\n        protein, carbs, fat, fiber,\r\n        source: 'usda',\r\n    };\r\n}
\n

O fallback duplo ?? existe porque o USDA tem dois esquemas de numeração de nutrientes diferentes dependendo do tipo de dado (Foundation Foods vs. Branded Foods). Ambos mapeiam pro mesmo formato de saída.

\n

Open Food Facts

\n

Open Food Facts é um banco de dados comunitário de produtos alimentícios do mundo inteiro. Pensa num Wikipedia mas pra rótulos nutricionais: qualquer um pode adicionar um produto, os dados são abertos sob a licença ODbL, e como é crowdsourced globalmente cobre produtos que o banco do USDA ignora na maior, tipo o negócio de laticínio fermentado que tem no supermercado holandês a cinco minutos do meu apartamento. Quando seu banco de dados nutricional principal assume que você come exclusivamente produtos americanos e você mora na Holanda, você começa a apreciar datasets globais abertos muito rapidamente.

\n

Fazer queries nele é surpreendentemente simples pra algo tão abrangente:

\n
// hooks/useUnifiedFoodSearch.ts\r\nconst url = `https://world.openfoodfacts.org/cgi/search.pl` +\r\n    `?search_terms=${encodeURIComponent(query)}` +\r\n    `&json=1` +\r\n    `&page_size=20` +\r\n    `&fields=code,product_name,brands,nutriments,serving_size,image_url`;\r\n\r\nconst response = await fetch(url, { signal: abortController.signal });\r\nconst result = await response.json();\r\n\r\nconst products = result.products.filter(\r\n    (product: SearchResultProduct) => getProductName(product)\r\n);
\n

Ambas as buscas rodam em paralelo (com abort controllers pra requests velhas não brigarem entre si) e os resultados se fundem em uma única lista unificada. O usuário escolhe entre comidas locais, resultados do Open Food Facts, e resultados do USDA, tudo de uma vez, sem saber ou se importar de qual backend cada um veio.

\n

Entre os dois, você consegue buscar praticamente qualquer comida e obter dados nutricionais reais sem digitar nada manualmente. E porque o Musclog agora rastreia mais de 40 micronutrientes além dos macros padrão, você consegue ver coisas como sua ingestão de magnésio, seus níveis de zinco, sua vitamina D. Acontece que isso importa quando você começa a olhar o que está consistentemente faltando. Pra mim é magnésio. É sempre magnésio.

\n

\n \n \n \n \n
Scanner de código de barras do Musclog em ação
\n

\n

Pra quando você não consegue escanear nada porque tá comendo num restaurante ou olhando pra um prato de “provavelmente é frango com algum molho,” tem OCR de rótulo (tesseract.js no web, rn-mlkit-ocr no native) e estimativa por foto com IA, que vou chegar lá em um segundo.

\n

O OCR segue o mesmo padrão de arquivo duplo dos gráficos. Assinatura de função idêntica, engine diferente, o bundler pega o certo na hora do build:

\n
// utils/ocr.ts - native (Google ML Kit, roda no device)\r\nimport { recognizeText } from 'rn-mlkit-ocr';\r\n\r\nexport async function performOcr(imageUri: string): Promise<string | null> {\r\n    const result = await recognizeText(imageUri);\r\n    const text = result.text.trim();\r\n    return text.length > 0 ? text : null;\r\n}\r\n\r\n// utils/ocr.web.ts - web (Tesseract.js, roda inteiramente no browser)\r\nimport { createWorker } from 'tesseract.js';\r\n\r\nconst OCR_LANGS = 'eng+spa+por+nld+deu+fra';\r\n\r\nexport async function performOcr(imageUri: string): Promise<string | null> {\r\n    const worker = await createWorker(OCR_LANGS);\r\n    const { data: { text } } = await worker.recognize(imageUri);\r\n    await worker.terminate();\r\n    return text.trim() || null;\r\n}
\n

ML Kit roda no device e é rápido. Tesseract.js sobe e mata um worker completo pra cada scan, o que não é elegante, mas funciona offline e nada sai do browser. O pacote de idiomas cobre inglês, espanhol, português, holandês, alemão e francês. Moro na Holanda, sou brasileiro, e não ia shipar um scanner de rótulo de supermercado que engasgasse com embalagem de queijo holandês.

\n

O coach de IA cresceu

\n

O chatbot original se chamava Chad. Sim, eu sei, não é muito criativo, mas eu tava mais focado em “shipar” features do que em deixá-las atraentes. E tá beleza, né, Chad?

\n

\n \n \n \n \n
sim.
\n

\n

Agora se chama Loggy, suporta tanto OpenAI quanto Google Gemini, e tá realmente conectado aos seus dados de forma significativa. Quando você pergunta algo pro Loggy, ele sabe quem você é: seus treinos recentes, seus logs de nutrição, sua tendência de peso, seus objetivos atuais. “Meu volume de treino da semana passada tava no caminho certo?” recebe uma resposta real baseada em dados reais, não uma dica genérica sobre sobrecarga progressiva que você já leu quinze vezes.

\n

A camada de saída estruturada foi um dos problemas técnicos mais interessantes aqui. Fazer LLMs outputarem dados estruturados de forma confiável (ao invés de prosa que parece dados estruturados mas quebra seu parser de JSON) requer cuidado. O utilitário makeSchemaStrict em utils/coachAI.ts pega qualquer schema JSON e força additionalProperties: false em todo objeto aninhado enquanto marca todos os campos como required. Isso vai pra config de function calling do OpenAI e fala pro modelo “retorna exatamente esse formato ou falha limpo.” É a diferença entre uma feature que funciona 95% do tempo e uma que realmente funciona.

\n

A função em si é simples o suficiente que eu quase não escrevi sobre ela:

\n
// utils/coachAI.ts\r\nfunction makeSchemaStrict(schema: any): any {\r\n    if (schema.type === 'object') {\r\n        const properties = schema.properties ? { ...schema.properties } : {};\r\n\r\n        Object.keys(properties).forEach((key) => {\r\n            properties[key] = makeSchemaStrict(properties[key]);\r\n        });\r\n\r\n        return {\r\n            ...schema,\r\n            properties,\r\n            additionalProperties: false, // OpenAI requer isso pro modo estrito\r\n        };\r\n    }\r\n\r\n    if (schema.type === 'array' && schema.items) {\r\n        return { ...schema, items: makeSchemaStrict(schema.items) };\r\n    }\r\n\r\n    return schema;\r\n}
\n

Percorre recursivamente cada objeto aninhado no schema e enfia additionalProperties: false nele. Sem isso, o function calling estrito do OpenAI rejeita o schema completamente. Com isso, o modelo é restringido exatamente ao formato que você definiu. Sem chaves extras surpresa. Sem campos que existem numa resposta mas não em outra. A IA propõe, o schema impõe.

\n

\n \n \n \n \n
Chat com o coach de IA do Musclog
\n

\n

A feature de análise por foto é a que faz novos usuários olharem duas vezes. Você tira uma foto da sua refeição, o Loggy estima as porções e o conteúdo nutricional. Não substitui uma balança de alimentos pra tracking de precisão, mas pra comer fora ou em dias que você genuinamente não consegue escanear nada, te deixa na bola certa rápido. O fluxo manda a imagem pro modelo com um schema estruturado pra resposta, extrai as estimativas, e aí te faz confirmar antes de logar. Esse último passo importa: a IA propõe, você decide.

\n

Os system prompts ficam em utils/prompts.ts e puxam instruções customizadas da tabela ai_custom_prompts, então o comportamento da IA é configurável sem tocar no código.

\n

Check-ins semanais: a feature que mais me orgulha

\n

Todo semana, o Musclog roda uma análise automatizada das suas médias móveis de 7 dias pra peso, ingestão calórica e atividade. Você recebe um status: No Caminho, Adiantado ou Atrasado. Se seus números estão divergindo dos seus objetivos, ele pode recalcular suas metas nutricionais baseado no que realmente aconteceu ao invés de te prender num plano que claramente não tá batendo com a realidade.

\n

O coração disso é getCheckinMetrics, que pega um registro de check-in e puxa todos os dados da janela de 7 dias terminando naquela data:

\n
// database/services/NutritionCheckinService.ts\r\nstatic async getCheckinMetrics(checkin: NutritionCheckin): Promise<CheckinMetrics> {\r\n    const periodEnd = checkin.checkinDate;\r\n    const periodStart = periodEnd - 7 * 24 * 60 * 60 * 1000;\r\n\r\n    // Puxa todas as medições de peso da janela de 7 dias\r\n    const weightMetrics = await database\r\n        .get<UserMetric>('user_metrics')\r\n        .query(\r\n            Q.where('type', 'weight'),\r\n            Q.where('date', Q.between(periodStart, periodEnd)),\r\n            Q.where('deleted_at', Q.eq(null)),\r\n            Q.sortBy('date', Q.asc)\r\n        )\r\n        .fetch();\r\n\r\n    // Descriptografa cada valor (pesos são criptografados com AES no banco)\r\n    const decryptedWeights: number[] = [];\r\n    for (const metric of weightMetrics) {\r\n        const { value } = await metric.getDecrypted();\r\n        decryptedWeights.push(value);\r\n    }\r\n\r\n    const avgWeight = decryptedWeights.length > 0\r\n        ? decryptedWeights.reduce((a, b) => a + b, 0) / decryptedWeights.length\r\n        : checkin.targetWeight;\r\n\r\n    // Quão longe o average real está de onde esperávamos estar?\r\n    const trend = avgWeight - checkin.targetWeight;\r\n\r\n    // Nutrição: agrupa logs por dia, calcula média de calorias e consistência\r\n    const nutritionLogs = await database\r\n        .get<NutritionLog>('nutrition_logs')\r\n        .query(Q.where('date', Q.between(periodStart, periodEnd)), Q.where('deleted_at', Q.eq(null)))\r\n        .fetch();\r\n\r\n    const caloriesByDay = new Map<number, number>();\r\n    for (const log of nutritionLogs) {\r\n        const snapshot = await log.getDecryptedSnapshot();\r\n        const dayKey = Math.floor(log.date / (24 * 60 * 60 * 1000));\r\n        caloriesByDay.set(dayKey, (caloriesByDay.get(dayKey) ?? 0) + snapshot.loggedCalories);\r\n    }\r\n\r\n    const consistency = Math.round((caloriesByDay.size / 7) * 100); // % de dias com logs\r\n    // ...e assim por diante pra treinos, gordura corporal, minutos ativos\r\n}
\n

O trend é o número chave: positivo significa que você tá mais pesado do que o alvo previa, negativo significa que você tá à frente. Combinado com consistency (que porcentagem dos 7 dias você realmente logou comida), o service consegue inferir se a variância é real ou só dado faltando.

\n

O cálculo de TDEE é empírico ao invés de baseado em fórmula. O Musclog olha sua mudança real de peso ao longo do tempo combinada com sua ingestão calórica real logada e trabalha ao contrário pra estimar suas calorias reais de manutenção. Se você tá comendo 2.200 calorias por dia e perdendo 0,3kg por semana, a matemática te diz algo sobre seu metabolismo real que a fórmula de Harris-Benedict nunca vai te dizer, especialmente se seu nível de atividade não se encaixa perfeitamente em “sedentário” ou “moderadamente ativo” ou qualquer categoria vaga que você escolheu no onboarding.

\n

A função que faz isso mora em utils/nutritionCalculator.ts. A lógica é direta; as constantes, não:

\n
// utils/nutritionCalculator.ts\r\nexport const calculateTDEE = (params: TDEEParams): number => {\r\n    const { totalCalories, totalDays, initialWeight, finalWeight,\r\n            initialFatPercentage, finalFatPercentage, bmr, activityLevel } = params;\r\n\r\n    // Caminho 1: dados reais de tracking existem - deriva TDEE da Primeira Lei da Termodinâmica\r\n    if (totalDays && totalCalories && initialWeight && finalWeight) {\r\n        const weightDifference = finalWeight - initialWeight;\r\n\r\n        // Divide a mudança de peso em gordura vs massa magra.\r\n        // Exato quando temos % de gordura nos dois extremos; estimativa pela curva Hall/Forbes caso contrário.\r\n        let fatDifference: number;\r\n        let leanDifference: number;\r\n\r\n        if (initialFatPercentage !== undefined && finalFatPercentage !== undefined) {\r\n            const initialFatMass = (initialFatPercentage * initialWeight) / 100;\r\n            const finalFatMass = (finalFatPercentage * finalWeight) / 100;\r\n            fatDifference = finalFatMass - initialFatMass;\r\n            leanDifference = weightDifference - fatDifference;\r\n        } else {\r\n            const comp = getWeightChangeComposition(initialWeight * 0.25, weightDifference);\r\n            fatDifference = comp.fatChangeKg;\r\n            leanDifference = comp.leanChangeKg;\r\n        }\r\n\r\n        // Construir vs queimar gordura e músculo têm custos termodinâmicos diferentes.\r\n        // Essas não são constantes intercambiáveis - são valores medidos separados.\r\n        const leanCalories = leanDifference > 0\r\n            ? leanDifference * CALORIES_BUILD_KG_MUSCLE   // 3900 kcal/kg pra construir\r\n            : leanDifference * CALORIES_STORED_KG_MUSCLE; // 1250 kcal/kg armazenados\r\n\r\n        const fatCalories = fatDifference > 0\r\n            ? fatDifference * CALORIES_BUILD_KG_FAT   // 8840 kcal/kg pra construir\r\n            : fatDifference * CALORIES_STORED_KG_FAT; // 7730 kcal/kg armazenados\r\n\r\n        // TDEE = (energia consumida − energia presa em mudanças de tecido) / dias\r\n        return Math.round((totalCalories - (fatCalories + leanCalories)) / totalDays);\r\n    }\r\n\r\n    // Caminho 2: ainda sem histórico - cai de volta pra BMR x multiplicador de atividade\r\n    if (bmr && activityLevel) {\r\n        return Math.round(bmr * ACTIVITY_MULTIPLIERS[activityLevel]);\r\n    }\r\n\r\n    return 0;\r\n};
\n

A assimetria entre construir gordura (8840 kcal/kg) e queimá-la (7730 kcal/kg) é real. A eficiência termodinâmica não é 100%, então criar novo tecido custa mais do que o que acaba sendo armazenado. O mesmo princípio se aplica ao músculo. Se você só hardcoda 7700 e segue em frente você tem algo que é aproximadamente certo, mas você tá tirando a média exatamente do sinal que você construiu o sistema de check-in inteiro pra encontrar.

\n

\n \n \n \n \n
Tela de check-in semanal do Musclog
\n

\n

Essa não é uma feature chamativa. Você não percebe até o fim da semana. Mas ter um app que percebe “você ficou abaixo do seu alvo calórico a semana inteira e seu peso ainda não mudou, vamos descobrir por quê” é exatamente o tipo de insight que eu estava construindo quando comecei esse projeto. Só não sabia disso na época. Achei que estava construindo um registrador de treinos.

\n

As outras coisas que fui shippando no sapatinho

\n

Widgets de tela inicial pra registro rápido e resumos diários. Um rastreador de ciclo menstrual com recomendações de intensidade de treino por fase, porque assumir uma base de usuários só masculina é um ponto de partida razoável não tá certo, então o Musclog não usa gênero pra inferir dados de ciclo menstrual. Integração com Health Connect pra sincronizar peso, nutrição e dados de exercício com outros apps de saúde Android. Exportação completa de dados como JSON encriptado (ou não encriptado). Importação de JSON pra migrar entre devices sem perder seu histórico.

\n

A feature de exportação de dados parece chata até seu celular morrer e você não ter. Nesse ponto você tá simultaneamente grato por ter construído e levemente furioso com o seu eu do passado por não ter testado o fluxo de importação mais a fundo. Pode perguntar como eu sei.

\n

\n \n \n \n \n
Detalhe do tracking de micronutrientes do Musclog
\n

\n

Por que a assinatura do seu app de fitness é problema de outro

\n

Quero falar algo sobre o mercado de apps de fitness, porque faz uns dois anos que tô segurando isso e esse é o meu blog.

\n

A história se repete num cronograma que você pode acertar seu relógio: app lança gratuito, adquire usuários, introduz um nível premium, gradualmente migra features centrais pra trás do paywall, aumenta os preços, usuários reclamam no Reddit, nada muda. Assisti isso acontecer com apps que eu genuinamente gostava de usar. MyFitnessPal passou de realmente bom e gratuito pra uma assinatura onde definir suas próprias metas de macro custa dinheiro. Outros apps introduziram “bancos de dados de alimentos premium” que tiraram a coisa útil e a venderam de volta mensalmente. Um app que usei por um tempo moveu os gráficos de progresso pra trás de um paywall. Os gráficos de progresso. Num app de rastreamento de fitness. A única feature que mostra se o app tá funcionando.

\n
\n

“Mas sem receita de assinatura, como você mantém as luzes acesas?”\r\nAs luzes são um cabo de carregamento e custam zero por mês. Próxima pergunta.

\n
\n

Entendo a economia. Servidores custam dinheiro. Times de engenharia custam dinheiro. Construir um negócio de produto sustentável é genuinamente difícil e alguém tem que pagar por isso. Tudo bem.

\n

Mas o Musclog não tem servidores. Não tem infraestrutura de nuvem. Nenhum banco de dados que estou pagando pra hospedar em algum lugar. Seus dados vivem no seu celular. Os bancos de dados de alimentos que uso são públicos e gratuitos. As features de IA, se você usá-las, falam diretamente com a OpenAI ou o Google usando sua própria chave de API: você paga pra eles, sem intermediário, sem comissão. O app é gratuito no Google Play e open source no GitHub.

\n

\n \n \n \n \n
O ciclo de assinatura de apps de fitness, ilustrado
\n

\n

Isso não é uma posição de princípio contra o capitalismo. É uma decisão de design que faz sentido pro que isso realmente é: uma ferramenta pessoal que construí pra mim mesmo e depois compartilhei com outras pessoas. A arquitetura que escolhi naturalmente não cria custos de servidor, o que significa que não tenho pressão financeira pra monetizar, o que significa que os usuários não têm motivo pra desconfiar do que estou fazendo com os dados deles. Porque não estou fazendo nada com os dados deles. Estão no celular deles.

\n

O design offline-first é deliberado pelo mesmo motivo. Histórico de peso, composição corporal, o que você come, seu ciclo menstrual, seu histórico de treinos: nada disso deveria ficar no servidor de um estranho por padrão. A maioria dos apps de fitness não explica claramente o que faz com esses dados porque uma resposta transparente seria impopular. O Musclog mantém tudo local. O único dado que sai do seu device é o que você explicitamente manda pra IA, e só quando você escolhe usar essa feature.

\n

Tem uma população inteira de pessoas treinando em academias com WiFi ruim, em porões, em garagens, em parques, que nunca tiveram o Musclog falhar porque precisava de conexão. Isso importa pra mim mais do que um número de receita recorrente mensal.

\n

O que vem por aí

\n

O onboarding é a parte mais fraca do app agora. O Musclog é significativamente mais útil quanto mais dados tem, mas a experiência de novo usuário ainda tá muito perto de “aqui tá o app inteiro, se vira.” Quero construir um fluxo de onboarding de verdade que deixe alguém configurado com seus objetivos, seu primeiro template de treino, e seu primeiro log de comida em menos de cinco minutos. Você não deveria precisar de 500 horas de contexto pra ter valor desde o primeiro dia.

\n

Suporte a devices BLE pra balanças inteligentes também está na lista. Entrar o peso e gordura corporal manualmente todo dia é ok. Ter a balança mandar pro app automaticamente quando você sobe nela é melhor, e a infraestrutura não é tão complexa. É principalmente uma questão de conseguir hardware pra testar, o que é um problema muito solucionável e definitivamente algo que vou fazer assim que terminar as outras dezessete coisas que já comecei.

\n

Vai ser gratuito pra sempre?

\n

Pergunta justa. A resposta curta é: não faço a menor ideia. A resposta mais longa é mais interessante.

\n

O código é open source sob a licença Attribution-NonCommercial-NoDerivatives 4.0 International. Você pode ler, fazer fork pra uso pessoal, aprender com ele. O que você não pode é shipar um produto construído em cima dele sem falar comigo primeiro, porque Musclog é uma marca minha, e porque as quinhentas horas de trabalho por trás disso representam algo em torno de €25000 em salário de desenvolvedor europeu. Não tô tocando uma ONG. Tô tocando um side project que ainda não te pediu dinheiro.

\n

Se isso mudar algum dia, aqui tá minha promessa: não vou fazer assinatura. Se o Musclog algum dia custar dinheiro, vai custar uma vez. Você paga o preço de um café, o app é seu, pra sempre. Sem mensalidade. Sem “seu plano premium foi pausado.” O modelo bom e velho, aquele que a App Store basicamente matou.

\n

O que tá me empurrando mais perto desse cenário agora é o iOS. Minha namorada quer no iPhone. Alguns amigos próximos querem no iPhone. Há meses escuto “coloca na App Store” como se fosse uma coisa trivial. O programa de desenvolvedor da Apple custa 100 USD por ano. Por ano. Não uma vez. Todo ano. A Apple transformou o direito de distribuir software num SaaS, e falo isso como alguém que acha que a taxa única de 35 USD do Google Play é como deveria ser em todo lugar. Então sim, se o Musclog algum dia chegar no iOS, provavelmente vai ter um preço, porque não vou pagar 100 USD de pedágio anual pra Apple de boa vontade.

\n

Por enquanto: Android, gratuito, sem planos de mudar isso. Então baixe agora enquanto tá de graça, porque uma vez que você instala no Google Play, ele é seu pra sempre. Mesmo que você não tenha pagado nada. Especialmente se você não pagou nada.

\n

Conclusão

\n

Dois anos, duas versões, 500 horas. O Musclog finalmente parece algo pelo qual eu não me desculpo mentalmente antes de mostrar pra alguém. O redesign limpou anos de dívida de UI do “manda ver”, e fazer direito me forçou a pensar sobre o produto de maneiras que eu deveria ter pensado desde o começo. Acontece que design systems existem por boas razões e não só pra dar aos designers algo pra discutir no Figma.

\n

É gratuito. É open source. Não tem seus dados. Funciona no modo avião. Bancos de dados de comida reais. IA que realmente sabe quem você é. Check-ins semanais automatizados. E um esquema de cores verde escuro do qual eu me orgulho genuinamente, mesmo que uma ferramenta de IA tenha feito a maior parte do trabalho visual pesado.

\n

Se quiser experimentar: Google Play.

\n

Se quiser ver como foi construído ou contribuir com algo: github.com/blopa/musclog-app.

\n

Treina, Loga, Repete.

\n

Até a próxima!

","fields":{"postHashId":"Y29kaW5ndHJ1ZW51bGwyMDI2LTAzLTIyVDAwOjAwOjAwLjAwMFo=","slug":"/2026/2026-03-22-musclog-redesign-acompanhamento-nutricional-e-por-que-a-assinatura-do-seu-app-de-fitness-e-uma-enganacao.pt-br/","path":"/blog/coding/musclog-redesign-acompanhamento-nutricional-e-por-que-a-assinatura-do-seu-app-de-fitness-e-uma-enganacao/","locale":"pt-br"},"rawMarkdownBody":"\r\nImagina a cena: você tá na academia. Entre séries. Suado. Com uns 90 segundos antes de ter que pegar a barra de novo, e você tá ali cutucando o seu próprio aplicativo igual ao pai de alguém tentando navegar num site de 2008. Quatro toques pra registrar uma série. Quatro toques. Num app que você mesmo escreveu. Que você poderia mudar. E mesmo assim, toda vez, você faz os quatro toques porque sempre tem outra coisa mais urgente pra fazer antes.\r\n\r\nEra o Musclog. Meu app de treino. Meu projeto de \"300 horas que não vou recuperar\" que eu [escrevi lá em 2024](/en/blog/coding/musclog-leveraging-my-reactjs-experience-to-build-a-react-native-app/). Funcionava. Meus amigos usavam. Eu registrei cada treino e cada grama de comida por meses com ele.\r\n\r\nTambém era, objetivamente, um dos apps mais feios que eu já tinha colocado no meu celular.\r\n\r\n![Design original do Musclog - a foto de antes que ninguém pediu](../../uploads/blog/2024/09/musclog-workout-screenshot.png)\r\n\r\nEu sabia. Meus amigos sabiam. O amigo honesto o suficiente pra falar \"cara, isso parece um site\" sabia, e falou na minha cara sem a menor cerimônia. Mas funcionava, e por um tempo isso era suficiente. \"Funciona\" é o equivalente do desenvolvedor ao \"tá bom\" - tecnicamente verdade, emocionalmente uma mentira completa com a qual você concordou em viver.\r\n\r\nAí a dívida de UX foi rendendo juros na minha vida. Registrar um treino parecia preencher papelada. Adicionar comida exigia pular entre três telas diferentes quando deveria ser uma. Navegar no app na academia, já suado e com tempo contado, era um exercício de fricção que eu tinha projetado pra mim mesmo sem querer. Fui empilhando features em cima desse caos visual, que é um jeito excelente de deixar a casa do acumulador ainda mais difícil de navegar. Sem falar nos bugs, que às vezes simplesmente crashavam o app e ficavam lá no Sentry, sem solução.\r\n\r\nTinha que mudar alguma coisa. E por \"alguma coisa\" eu quero dizer tudo.\r\n\r\n## Eu não dou pra um bom designer\r\n\r\nEu tenho muitos amigos que dão pra um bom designer. Muitos. Não é o meu caso. O app original foi feito com [react-native-paper](https://reactnativepaper.com/), que é uma biblioteca perfeitamente decente. O problema não era o react-native-paper. O problema era eu. Fui jogando componentes juntos na ordem que fazia sentido na hora, escolhendo cores no feeling, e shippando sem nenhum design system de verdade. Sem escala de espaçamento. Sem paleta de cores semântica. Puro instinto de desenvolvedor aplicado diretamente numa UI, que, como se descobriu, produz exatamente o tipo de app que eu terminei tendo.\r\n\r\nO mesmo conceito parecia diferente em três telas diferentes porque cada tela foi construída num momento diferente da minha compreensão do app. Botões primários tinham alturas diferentes dependendo de onde você os encontrava. Cards tinham três raios de canto diferentes que eu provavelmente escolhi com grande intenção e depois esqueci completamente. Cores eram hardcoded em todo lugar. A coisa toda era mantida unida por confiança e fita adesiva.\r\n\r\nO plano de migração: arrancar o react-native-paper, substituir pelo [NativeWind](https://www.nativewind.dev/) (Tailwind CSS pro React Native), e construir um design system de verdade do zero. Simples. Direto. Completamente insano dado o tamanho do codebase nessa altura.\r\n\r\nFui e fiz mesmo assim, porque não tenho nenhum instinto de autopreservação quando se trata de side projects.\r\n\r\n## Entra o Stitch\r\n\r\nEu estava de olho no [Google Stitch](https://stitch.withgoogle.com/) desde que lançou. A versão curta: é uma ferramenta de IA que gera UI de app mobile a partir de prompts e screenshots. Você descreve a estética que quer, joga umas telas de referência, e ele gera componentes React coerentes. Pra um desenvolvedor que genuinamente tentou aprender design três vezes separadas e falhou cada vez por razões fundamentalmente diferentes, isso pareceu cola no melhor sentido possível.\r\n\r\nAlimentei com as telas existentes do Musclog e descrevi o que queria: tema escuro, estética de fitness e performance, algo que parecesse estar olhando pra dados sérios ao invés de uma lista de tarefas. Queria que parecesse o dashboard de algo que faz sentido, não um app de bem-estar que vai sugerir que você \"respire fundo\" antes de registrar seu deadlift.\r\n\r\n![Nova tela inicial do Musclog](../../uploads/blog/2026/03/musclog-home-screen.png)\r\n\r\nA parte inesperada foi o quanto esse processo me forçou a pensar claramente sobre o produto em si. Pra gerar uma boa tela no Stitch, eu precisava articular pra que aquela tela *servia* antes de poder descrever como deveria parecer. Esse processo expôs problemas de UX que não tinham nada a ver com cores. Um passo no fluxo de registro de treino existia puramente por causa de uma limitação técnica que eu tinha contornado com UI ao invés de resolver o problema de verdade. ~~Resolvido. Fingi que nunca aconteceu.~~ Resolvido, depois refatorei o serviço por baixo pra que nunca voltasse.\r\n\r\n~~Eu escrevi~~ O Stitch também escreveu um documento de design de verdade pela primeira vez na vida desse projeto: cores de superfície com nomes, cores semânticas pra macros (proteína é sempre índigo `#6366f1`, gordura é sempre âmbar `#f59e0b`, carbo é esmeralda `#10b981`, fibra é rosa `#ec4899`), escala de espaçamento em 4/8/12/16/20/24/32px, padrões de border radius em 12px pra inputs e 16px pra cards primários. Coisas que eu deveria ter definido antes de escrever uma única linha de código de UI. A conta do \"manda ver\" chegou, como sempre chega, com juros.\r\n\r\n## A arquitetura que ninguém pediu\r\n\r\nJá que eu estava queimando a UI até os alicerces, aproveitei pra apertar a arquitetura por baixo também. Essa é a parte onde a maioria das pessoas desliga, mas se você tá construindo algo com armazenamento local-first em React Native, algumas dessas decisões podem te poupar tempo.\r\n\r\nO Musclog usa [WatermelonDB](https://watermelondb.dev/) pro armazenamento local. Não SQLite puro, não MMKV, não AsyncStorage. O WatermelonDB fica em cima do SQLite no native e [LokiJS](https://github.com/techfort/LokiJS) no web, e te dá uma camada de modelo com queries reativas. Quando o dado muda, qualquer componente observando aquela query re-renderiza automaticamente. Sem sync de estado manual. Sem bug de \"lembrei de atualizar a lista depois de salvar?\". O mesmo codebase roda no Android e no browser sem tocar na camada de dados, o que importa quando você quer testar algo rápido sem subir um device.\r\n\r\nA estrutura em camadas vai assim: definição de schema na base, depois models, depois services que cuidam de CRUD e lógica de negócio. Serviços que não são de banco (IA, notificações, sync do Health Connect) vivem separados no próprio dir `services/`. Todo write passa por `database.write(async () => { ... })`. Sem exceções. Blocos de write aninhados causam deadlocks no WatermelonDB, e são uma dor de cabeça pra debugar, então a regra é simples: nunca aninhe, e se você quiser fazer isso, você projetou algo errado lá atrás.\r\n\r\nÉ assim que fica no `NutritionCheckinService.ts` criando um lote de check-ins semanais:\r\n\r\n```typescript\r\nstatic async createBatch(\r\n nutritionGoalId: string,\r\n checkins: NutritionCheckinInput[]\r\n): Promise {\r\n return await database.write(async () => {\r\n const collection = database.get('nutrition_checkins');\r\n\r\n const preparedRecords = checkins.map((data) =>\r\n collection.prepareCreate((record) => {\r\n record.nutritionGoalId = nutritionGoalId;\r\n record.checkinDate = data.checkinDate;\r\n record.targetWeight = data.targetWeight;\r\n record.status = data.status ?? 'pending';\r\n })\r\n );\r\n\r\n await database.batch(...preparedRecords);\r\n return preparedRecords;\r\n });\r\n}\r\n```\r\n\r\nA combinação `prepareCreate` + `database.batch()` é como o WatermelonDB lida com múltiplos inserts atomicamente sem múltiplas viagens de ida e volta. Um bloco `write()`, um batch, feito. Você nunca chama o `database.write()` de outro service lá de dentro, porque é assim que você consegue um deadlock às 23h que misteriosamente só reproduz no device.\r\n\r\n![Tela de registro de treino do Musclog](../../uploads/blog/2026/03/musclog-workout-logging.png)\r\n\r\nDados sensíveis, especificamente seu histórico de peso, percentuais de gordura corporal e logs de nutrição, são criptografados com AES antes de entrar no banco. Não porque eu espero que alguém invada um arquivo SQLite local, mas porque são dados de saúde. Merecem ser tratados como tal. O arquivo `encryptionHelpers.ts` cuida de encrypt/decrypt de forma transparente pela camada de service. Você nunca pensa nisso como usuário. Nem precisa pensar nisso como contribuidor, porque tá em um lugar e tudo passa por ele.\r\n\r\nEntão quando você loga uma refeição, é isso que realmente fica armazenado:\r\n\r\n```typescript\r\n// database/encryptionHelpers.ts\r\nexport async function encryptNutritionLogSnapshot(plain: {\r\n loggedFoodName?: string;\r\n loggedCalories: number;\r\n loggedProtein: number;\r\n loggedCarbs: number;\r\n loggedFat: number;\r\n loggedFiber: number;\r\n loggedMicros?: Record;\r\n}) {\r\n const [\r\n loggedFoodName,\r\n loggedCalories,\r\n loggedProtein,\r\n loggedCarbs,\r\n loggedFat,\r\n loggedFiber,\r\n loggedMicrosJson,\r\n ] = await Promise.all([\r\n encryptOptionalString(plain.loggedFoodName),\r\n encryptNumber(plain.loggedCalories),\r\n encryptNumber(plain.loggedProtein),\r\n encryptNumber(plain.loggedCarbs),\r\n encryptNumber(plain.loggedFat),\r\n encryptNumber(plain.loggedFiber),\r\n encryptJson(plain.loggedMicros),\r\n ]);\r\n\r\n return { loggedFoodName, loggedCalories, loggedProtein, loggedCarbs, loggedFat, loggedFiber, loggedMicrosJson };\r\n}\r\n```\r\n\r\nAquele `loggedCalories: 165` que você digitou? É uma string criptografada com AES no banco. `loggedFoodName: \"Chicken breast\"` também é criptografado. Até o blob de JSON dos micronutrientes é criptografado. Tudo descriptografa na hora da leitura pela camada de service. A chave de criptografia é derivada por device e nunca sai dele.\r\n\r\nO sistema de gráficos tem uma peculiaridade que vale mencionar. O Musclog usa [Victory Native](https://commerce.nearform.com/open-source/victory-native/) pra gráficos no mobile, que usa Skia pra renderizar. Skia não funciona no web. Então todo componente de gráfico tem um par `.web.tsx` usando [Victory](https://commerce.nearform.com/open-source/victory/) normal com SVG no lugar. O bundler do Expo pega o arquivo certo automaticamente baseado na extensão. Parece o dobro de trabalho e é meio que isso mesmo, mas a alternativa são gráficos que quebram silenciosamente no web, e eu uso a versão web bastante durante o desenvolvimento.\r\n\r\nO mesmo `LineChart`, dois runtimes:\r\n\r\n```typescript\r\n// components/charts/LineChart.tsx - native (Skia)\r\nimport { Area, CartesianChart, Line, Scatter } from 'victory-native';\r\nimport Animated, { useAnimatedStyle, useSharedValue } from 'react-native-reanimated';\r\n\r\n// components/charts/LineChart.web.tsx - web (SVG)\r\nimport { VictoryArea, VictoryAxis, VictoryChart, VictoryLine, VictoryScatter } from 'victory';\r\n```\r\n\r\nMesma interface de props, mesmo comportamento, backends de renderização diferentes. O bundler do Expo resolve `LineChart` pro arquivo `.web.tsx` no web e pro `.tsx` em todo o resto. Zero condicionais no componente que realmente o usa.\r\n\r\nO tracking de volume funciona da mesma forma na infraestrutura, exceto que o problema interessante aí é a matemática. O Musclog rastreia volume como máximo estimado de uma repetição, não peso x reps bruto, porque 5 reps em 80kg e 12 reps em 60kg são estímulos de treino diferentes que produzem o mesmo número num gráfico de volume ingênuo. O problema é que não existe uma fórmula de 1RM aceita universalmente. Brzycki, Epley, Lander, Mayhew - todas dão um número ligeiramente diferente pro mesmo set, e a pesquisa não elege um vencedor claro. Então o Musclog roda as sete e tira a média:\r\n\r\n```typescript\r\n// utils/workoutCalculator.ts\r\nexport function calculateAverage1RM(weight: number, reps: number, rir: number = 0): number {\r\n const formulas: FormulaType[] = [\r\n 'Epley', 'Brzycki', 'Lander', 'Lombardi', 'Mayhew', 'OConner', 'Wathan',\r\n ];\r\n let total1RM = 0;\r\n let validFormulas = 0;\r\n\r\n formulas.forEach((formula) => {\r\n const oneRM = calculate1RM(weight, reps, formula, rir);\r\n if (oneRM !== null) {\r\n total1RM += oneRM;\r\n validFormulas++;\r\n }\r\n });\r\n\r\n return validFormulas > 0 ? total1RM / validFormulas : 0;\r\n}\r\n```\r\n\r\nO parâmetro `rir` é Reps in Reserve: se você parou em 8 mas tinha mais 2 no tanque, `rir = 2` ajusta a estimativa pra cima pra refletir o que você realmente poderia levantar. Registrar seu RIR é opcional. O tipo de pessoa que construiu seu próprio app de fitness e rastreia tudo em planilha geralmente também é o tipo de pessoa que rastreia o RIR. ~~Não tô dizendo que sou eu.~~ Sou eu.\r\n\r\n## Espera, e os dados reais de comida?\r\n\r\nÉ. O redesign foi a parte visível dessa atualização. A parte mais significativa, pelo menos do ponto de vista de \"esse app é realmente útil\", foi reconstruir completamente como o tracking de comida funciona.\r\n\r\nA versão original dependia muito das informações nutricionais vindas do Health Connect. Se você não tinha outro app pra fazer o tracking de nutrição, ficava a deriva. Isso é aceitável pra um projeto de fim de semana. Não é aceitável pra um app que as pessoas usam diariamente pra rastrear calorias, proteína, carbo, gordura, e mais de 40 micronutrientes em múltiplas refeições.\r\n\r\nPra minha genuína surpresa, descobri que dados de alta qualidade sobre comida não ficam atrás de um portão corporativo. Existem APIs públicas e gratuitas enormes - como USDA e Open Food Facts - que fornecem de quebra de micronutrientes detalhada a consulta de código de barras global sem cobrar um centavo. Encontrar isso foi um grande momento \"aha!\": se o dado é público e o processamento acontece direto no seu device, não existe justificativa técnica alguma pra rastreamento de nutrição ser um SaaS baseado em assinatura. A maioria dos apps \"premium\" basicamente te cobra uma mensalidade pra ser intermediário de dados que nem são deles, mas essa é uma discussão picante que guardei pra outra hora.\r\nO Musclog agora conecta a dois bancos de dados de comida reais.\r\n\r\n### USDA FoodData Central\r\n\r\n[USDA FoodData Central](https://fdc.nal.usda.gov/) é o banco de dados nutricional público do Departamento de Agricultura dos EUA. Centenas de milhares de alimentos, de produtos de marcas a ingredientes brutos, com detalhamento de macro e micronutrientes. São dados governamentais, é gratuito, e a API não requer cartão de crédito, o que como você vai ver é uma consideração não trivial pra mim. A cobertura de produtos de marcas americanos e globais é genuinamente sólida. Essa é a espinha dorsal da busca.\r\n\r\nO USDA identifica nutrientes por códigos numéricos, então mapeá-los pra algo legível por humanos requer uma camada de lookup. É assim que o mapper parece na prática:\r\n\r\n```typescript\r\n// utils/usdaMapper.ts\r\nexport function mapUSDAFoodToUnified(food: USDAFood): UnifiedFoodResult {\r\n const nutrients = food.foodNutrients;\r\n\r\n // USDA usa códigos numéricos de nutrientes - 1008/208 é energia, 1003/203 é proteína, etc.\r\n const calories = mapUSDANutritient(nutrients, '1008') ?? mapUSDANutritient(nutrients, '208');\r\n const protein = mapUSDANutritient(nutrients, '1003') ?? mapUSDANutritient(nutrients, '203');\r\n const carbs = mapUSDANutritient(nutrients, '1005') ?? mapUSDANutritient(nutrients, '205');\r\n const fat = mapUSDANutritient(nutrients, '1004') ?? mapUSDANutritient(nutrients, '204');\r\n const fiber = mapUSDANutritient(nutrients, '1079') ?? mapUSDANutritient(nutrients, '291');\r\n\r\n return {\r\n id: String(food.fdcId),\r\n name: food.description,\r\n brand: food.brandOwner,\r\n calories: calories !== undefined ? Math.round(calories) : undefined,\r\n protein, carbs, fat, fiber,\r\n source: 'usda',\r\n };\r\n}\r\n```\r\n\r\nO fallback duplo `??` existe porque o USDA tem dois esquemas de numeração de nutrientes diferentes dependendo do tipo de dado (Foundation Foods vs. Branded Foods). Ambos mapeiam pro mesmo formato de saída.\r\n\r\n### Open Food Facts\r\n\r\n[Open Food Facts](https://world.openfoodfacts.org/) é um banco de dados comunitário de produtos alimentícios do mundo inteiro. Pensa num Wikipedia mas pra rótulos nutricionais: qualquer um pode adicionar um produto, os dados são abertos sob a licença ODbL, e como é crowdsourced globalmente cobre produtos que o banco do USDA ignora na maior, tipo o negócio de laticínio fermentado que tem no supermercado holandês a cinco minutos do meu apartamento. Quando seu banco de dados nutricional principal assume que você come exclusivamente produtos americanos e você mora na Holanda, você começa a apreciar datasets globais abertos muito rapidamente.\r\n\r\nFazer queries nele é surpreendentemente simples pra algo tão abrangente:\r\n\r\n```typescript\r\n// hooks/useUnifiedFoodSearch.ts\r\nconst url = `https://world.openfoodfacts.org/cgi/search.pl` +\r\n `?search_terms=${encodeURIComponent(query)}` +\r\n `&json=1` +\r\n `&page_size=20` +\r\n `&fields=code,product_name,brands,nutriments,serving_size,image_url`;\r\n\r\nconst response = await fetch(url, { signal: abortController.signal });\r\nconst result = await response.json();\r\n\r\nconst products = result.products.filter(\r\n (product: SearchResultProduct) => getProductName(product)\r\n);\r\n```\r\n\r\nAmbas as buscas rodam em paralelo (com abort controllers pra requests velhas não brigarem entre si) e os resultados se fundem em uma única lista unificada. O usuário escolhe entre comidas locais, resultados do Open Food Facts, e resultados do USDA, tudo de uma vez, sem saber ou se importar de qual backend cada um veio.\r\n\r\nEntre os dois, você consegue buscar praticamente qualquer comida e obter dados nutricionais reais sem digitar nada manualmente. E porque o Musclog agora rastreia mais de 40 micronutrientes além dos macros padrão, você consegue ver coisas como sua ingestão de magnésio, seus níveis de zinco, sua vitamina D. Acontece que isso importa quando você começa a olhar o que está consistentemente faltando. Pra mim é magnésio. É sempre magnésio.\r\n\r\n![Tracking de nutrição do Musclog com breakdown completo de macros](../../uploads/blog/2026/03/musclog-nutrition-screen.png)\r\n\r\nTem também um scanner de código de barras. Aponta a câmera pro produto, ele busca o código de barras no Open Food Facts, adiciona ao seu log. Eu escanio minha embalagem de iogurte grego toda manhã por puro hábito a essa altura. Registro sem fricção era o que eu queria quando comecei esse projeto e finalmente tenho, duas versões e uns 500 horas depois.\r\n\r\n![Scanner de código de barras do Musclog em ação](../../uploads/blog/2026/03/musclog-barcode-scanner.png)\r\n\r\nPra quando você não consegue escanear nada porque tá comendo num restaurante ou olhando pra um prato de \"provavelmente é frango com algum molho,\" tem OCR de rótulo (tesseract.js no web, rn-mlkit-ocr no native) e estimativa por foto com IA, que vou chegar lá em um segundo.\r\n\r\nO OCR segue o mesmo padrão de arquivo duplo dos gráficos. Assinatura de função idêntica, engine diferente, o bundler pega o certo na hora do build:\r\n\r\n```typescript\r\n// utils/ocr.ts - native (Google ML Kit, roda no device)\r\nimport { recognizeText } from 'rn-mlkit-ocr';\r\n\r\nexport async function performOcr(imageUri: string): Promise {\r\n const result = await recognizeText(imageUri);\r\n const text = result.text.trim();\r\n return text.length > 0 ? text : null;\r\n}\r\n\r\n// utils/ocr.web.ts - web (Tesseract.js, roda inteiramente no browser)\r\nimport { createWorker } from 'tesseract.js';\r\n\r\nconst OCR_LANGS = 'eng+spa+por+nld+deu+fra';\r\n\r\nexport async function performOcr(imageUri: string): Promise {\r\n const worker = await createWorker(OCR_LANGS);\r\n const { data: { text } } = await worker.recognize(imageUri);\r\n await worker.terminate();\r\n return text.trim() || null;\r\n}\r\n```\r\n\r\nML Kit roda no device e é rápido. Tesseract.js sobe e mata um worker completo pra cada scan, o que não é elegante, mas funciona offline e nada sai do browser. O pacote de idiomas cobre inglês, espanhol, português, holandês, alemão e francês. Moro na Holanda, sou brasileiro, e não ia shipar um scanner de rótulo de supermercado que engasgasse com embalagem de queijo holandês.\r\n\r\n## O coach de IA cresceu\r\n\r\nO chatbot original se chamava Chad. Sim, eu sei, não é muito criativo, mas eu tava mais focado em \"shipar\" features do que em deixá-las atraentes. E tá beleza, né, Chad?\r\n\r\n![sim.](../../uploads/blog/2026/03/chad-yes.png)\r\n\r\nAgora se chama Loggy, suporta tanto [OpenAI](https://openai.com/) quanto [Google Gemini](https://deepmind.google/technologies/gemini/), e tá realmente conectado aos seus dados de forma significativa. Quando você pergunta algo pro Loggy, ele sabe quem você é: seus treinos recentes, seus logs de nutrição, sua tendência de peso, seus objetivos atuais. \"Meu volume de treino da semana passada tava no caminho certo?\" recebe uma resposta real baseada em dados reais, não uma dica genérica sobre sobrecarga progressiva que você já leu quinze vezes.\r\n\r\nA camada de saída estruturada foi um dos problemas técnicos mais interessantes aqui. Fazer LLMs outputarem dados estruturados de forma confiável (ao invés de prosa que parece dados estruturados mas quebra seu parser de JSON) requer cuidado. O utilitário `makeSchemaStrict` em `utils/coachAI.ts` pega qualquer schema JSON e força `additionalProperties: false` em todo objeto aninhado enquanto marca todos os campos como `required`. Isso vai pra config de function calling do OpenAI e fala pro modelo \"retorna exatamente esse formato ou falha limpo.\" É a diferença entre uma feature que funciona 95% do tempo e uma que realmente funciona.\r\n\r\nA função em si é simples o suficiente que eu quase não escrevi sobre ela:\r\n\r\n```typescript\r\n// utils/coachAI.ts\r\nfunction makeSchemaStrict(schema: any): any {\r\n if (schema.type === 'object') {\r\n const properties = schema.properties ? { ...schema.properties } : {};\r\n\r\n Object.keys(properties).forEach((key) => {\r\n properties[key] = makeSchemaStrict(properties[key]);\r\n });\r\n\r\n return {\r\n ...schema,\r\n properties,\r\n additionalProperties: false, // OpenAI requer isso pro modo estrito\r\n };\r\n }\r\n\r\n if (schema.type === 'array' && schema.items) {\r\n return { ...schema, items: makeSchemaStrict(schema.items) };\r\n }\r\n\r\n return schema;\r\n}\r\n```\r\n\r\nPercorre recursivamente cada objeto aninhado no schema e enfia `additionalProperties: false` nele. Sem isso, o function calling estrito do OpenAI rejeita o schema completamente. Com isso, o modelo é restringido exatamente ao formato que você definiu. Sem chaves extras surpresa. Sem campos que existem numa resposta mas não em outra. A IA propõe, o schema impõe.\r\n\r\n![Chat com o coach de IA do Musclog](../../uploads/blog/2026/03/musclog-ai-coach.png)\r\n\r\nA feature de análise por foto é a que faz novos usuários olharem duas vezes. Você tira uma foto da sua refeição, o Loggy estima as porções e o conteúdo nutricional. Não substitui uma balança de alimentos pra tracking de precisão, mas pra comer fora ou em dias que você genuinamente não consegue escanear nada, te deixa na bola certa rápido. O fluxo manda a imagem pro modelo com um schema estruturado pra resposta, extrai as estimativas, e aí te faz confirmar antes de logar. Esse último passo importa: a IA propõe, você decide.\r\n\r\nOs system prompts ficam em `utils/prompts.ts` e puxam instruções customizadas da tabela `ai_custom_prompts`, então o comportamento da IA é configurável sem tocar no código.\r\n\r\n## Check-ins semanais: a feature que mais me orgulha\r\n\r\nTodo semana, o Musclog roda uma análise automatizada das suas médias móveis de 7 dias pra peso, ingestão calórica e atividade. Você recebe um status: No Caminho, Adiantado ou Atrasado. Se seus números estão divergindo dos seus objetivos, ele pode recalcular suas metas nutricionais baseado no que realmente aconteceu ao invés de te prender num plano que claramente não tá batendo com a realidade.\r\n\r\nO coração disso é `getCheckinMetrics`, que pega um registro de check-in e puxa todos os dados da janela de 7 dias terminando naquela data:\r\n\r\n```typescript\r\n// database/services/NutritionCheckinService.ts\r\nstatic async getCheckinMetrics(checkin: NutritionCheckin): Promise {\r\n const periodEnd = checkin.checkinDate;\r\n const periodStart = periodEnd - 7 * 24 * 60 * 60 * 1000;\r\n\r\n // Puxa todas as medições de peso da janela de 7 dias\r\n const weightMetrics = await database\r\n .get('user_metrics')\r\n .query(\r\n Q.where('type', 'weight'),\r\n Q.where('date', Q.between(periodStart, periodEnd)),\r\n Q.where('deleted_at', Q.eq(null)),\r\n Q.sortBy('date', Q.asc)\r\n )\r\n .fetch();\r\n\r\n // Descriptografa cada valor (pesos são criptografados com AES no banco)\r\n const decryptedWeights: number[] = [];\r\n for (const metric of weightMetrics) {\r\n const { value } = await metric.getDecrypted();\r\n decryptedWeights.push(value);\r\n }\r\n\r\n const avgWeight = decryptedWeights.length > 0\r\n ? decryptedWeights.reduce((a, b) => a + b, 0) / decryptedWeights.length\r\n : checkin.targetWeight;\r\n\r\n // Quão longe o average real está de onde esperávamos estar?\r\n const trend = avgWeight - checkin.targetWeight;\r\n\r\n // Nutrição: agrupa logs por dia, calcula média de calorias e consistência\r\n const nutritionLogs = await database\r\n .get('nutrition_logs')\r\n .query(Q.where('date', Q.between(periodStart, periodEnd)), Q.where('deleted_at', Q.eq(null)))\r\n .fetch();\r\n\r\n const caloriesByDay = new Map();\r\n for (const log of nutritionLogs) {\r\n const snapshot = await log.getDecryptedSnapshot();\r\n const dayKey = Math.floor(log.date / (24 * 60 * 60 * 1000));\r\n caloriesByDay.set(dayKey, (caloriesByDay.get(dayKey) ?? 0) + snapshot.loggedCalories);\r\n }\r\n\r\n const consistency = Math.round((caloriesByDay.size / 7) * 100); // % de dias com logs\r\n // ...e assim por diante pra treinos, gordura corporal, minutos ativos\r\n}\r\n```\r\n\r\nO `trend` é o número chave: positivo significa que você tá mais pesado do que o alvo previa, negativo significa que você tá à frente. Combinado com `consistency` (que porcentagem dos 7 dias você realmente logou comida), o service consegue inferir se a variância é real ou só dado faltando.\r\n\r\nO cálculo de TDEE é empírico ao invés de baseado em fórmula. O Musclog olha sua mudança real de peso ao longo do tempo combinada com sua ingestão calórica real logada e trabalha ao contrário pra estimar suas calorias reais de manutenção. Se você tá comendo 2.200 calorias por dia e perdendo 0,3kg por semana, a matemática te diz algo sobre seu metabolismo real que a fórmula de Harris-Benedict nunca vai te dizer, especialmente se seu nível de atividade não se encaixa perfeitamente em \"sedentário\" ou \"moderadamente ativo\" ou qualquer categoria vaga que você escolheu no onboarding.\r\n\r\nA função que faz isso mora em `utils/nutritionCalculator.ts`. A lógica é direta; as constantes, não:\r\n\r\n```typescript\r\n// utils/nutritionCalculator.ts\r\nexport const calculateTDEE = (params: TDEEParams): number => {\r\n const { totalCalories, totalDays, initialWeight, finalWeight,\r\n initialFatPercentage, finalFatPercentage, bmr, activityLevel } = params;\r\n\r\n // Caminho 1: dados reais de tracking existem - deriva TDEE da Primeira Lei da Termodinâmica\r\n if (totalDays && totalCalories && initialWeight && finalWeight) {\r\n const weightDifference = finalWeight - initialWeight;\r\n\r\n // Divide a mudança de peso em gordura vs massa magra.\r\n // Exato quando temos % de gordura nos dois extremos; estimativa pela curva Hall/Forbes caso contrário.\r\n let fatDifference: number;\r\n let leanDifference: number;\r\n\r\n if (initialFatPercentage !== undefined && finalFatPercentage !== undefined) {\r\n const initialFatMass = (initialFatPercentage * initialWeight) / 100;\r\n const finalFatMass = (finalFatPercentage * finalWeight) / 100;\r\n fatDifference = finalFatMass - initialFatMass;\r\n leanDifference = weightDifference - fatDifference;\r\n } else {\r\n const comp = getWeightChangeComposition(initialWeight * 0.25, weightDifference);\r\n fatDifference = comp.fatChangeKg;\r\n leanDifference = comp.leanChangeKg;\r\n }\r\n\r\n // Construir vs queimar gordura e músculo têm custos termodinâmicos diferentes.\r\n // Essas não são constantes intercambiáveis - são valores medidos separados.\r\n const leanCalories = leanDifference > 0\r\n ? leanDifference * CALORIES_BUILD_KG_MUSCLE // 3900 kcal/kg pra construir\r\n : leanDifference * CALORIES_STORED_KG_MUSCLE; // 1250 kcal/kg armazenados\r\n\r\n const fatCalories = fatDifference > 0\r\n ? fatDifference * CALORIES_BUILD_KG_FAT // 8840 kcal/kg pra construir\r\n : fatDifference * CALORIES_STORED_KG_FAT; // 7730 kcal/kg armazenados\r\n\r\n // TDEE = (energia consumida − energia presa em mudanças de tecido) / dias\r\n return Math.round((totalCalories - (fatCalories + leanCalories)) / totalDays);\r\n }\r\n\r\n // Caminho 2: ainda sem histórico - cai de volta pra BMR x multiplicador de atividade\r\n if (bmr && activityLevel) {\r\n return Math.round(bmr * ACTIVITY_MULTIPLIERS[activityLevel]);\r\n }\r\n\r\n return 0;\r\n};\r\n```\r\n\r\nA assimetria entre construir gordura (8840 kcal/kg) e queimá-la (7730 kcal/kg) é real. A eficiência termodinâmica não é 100%, então criar novo tecido custa mais do que o que acaba sendo armazenado. O mesmo princípio se aplica ao músculo. Se você só hardcoda 7700 e segue em frente você tem algo que é aproximadamente certo, mas você tá tirando a média exatamente do sinal que você construiu o sistema de check-in inteiro pra encontrar.\r\n\r\n![Tela de check-in semanal do Musclog](../../uploads/blog/2026/03/musclog-weekly-checkin.png)\r\n\r\nEssa não é uma feature chamativa. Você não percebe até o fim da semana. Mas ter um app que percebe \"você ficou abaixo do seu alvo calórico a semana inteira e seu peso ainda não mudou, vamos descobrir por quê\" é exatamente o tipo de insight que eu estava construindo quando comecei esse projeto. Só não sabia disso na época. Achei que estava construindo um registrador de treinos.\r\n\r\n## As outras coisas que fui shippando no sapatinho\r\n\r\nWidgets de tela inicial pra registro rápido e resumos diários. Um rastreador de ciclo menstrual com recomendações de intensidade de treino por fase, porque assumir uma base de usuários só masculina é ~~um ponto de partida razoável~~ não tá certo, então o Musclog não usa gênero pra inferir dados de ciclo menstrual. Integração com Health Connect pra sincronizar peso, nutrição e dados de exercício com outros apps de saúde Android. Exportação completa de dados como JSON encriptado (ou não encriptado). Importação de JSON pra migrar entre devices sem perder seu histórico.\r\n\r\nA feature de exportação de dados parece chata até seu celular morrer e você não ter. Nesse ponto você tá simultaneamente grato por ter construído e levemente furioso com o seu eu do passado por não ter testado o fluxo de importação mais a fundo. Pode perguntar como eu sei.\r\n\r\n![Detalhe do tracking de micronutrientes do Musclog](../../uploads/blog/2026/03/musclog-micronutrients.png)\r\n\r\n## Por que a assinatura do seu app de fitness é problema de outro\r\n\r\nQuero falar algo sobre o mercado de apps de fitness, porque faz uns dois anos que tô segurando isso e esse é o meu blog.\r\n\r\nA história se repete num cronograma que você pode acertar seu relógio: app lança gratuito, adquire usuários, introduz um nível premium, gradualmente migra features centrais pra trás do paywall, aumenta os preços, usuários reclamam no Reddit, nada muda. Assisti isso acontecer com apps que eu genuinamente gostava de usar. MyFitnessPal passou de realmente bom e gratuito pra uma assinatura onde definir suas próprias metas de macro custa dinheiro. Outros apps introduziram \"bancos de dados de alimentos premium\" que tiraram a coisa útil e a venderam de volta mensalmente. Um app que usei por um tempo moveu os gráficos de progresso pra trás de um paywall. Os gráficos de progresso. Num app de rastreamento de fitness. A única feature que mostra se o app tá funcionando.\r\n\r\n> \"Mas sem receita de assinatura, como você mantém as luzes acesas?\"\r\n> As luzes são um cabo de carregamento e custam zero por mês. Próxima pergunta.\r\n\r\nEntendo a economia. Servidores custam dinheiro. Times de engenharia custam dinheiro. Construir um negócio de produto sustentável é genuinamente difícil e alguém tem que pagar por isso. Tudo bem.\r\n\r\nMas o Musclog não tem servidores. Não tem infraestrutura de nuvem. Nenhum banco de dados que estou pagando pra hospedar em algum lugar. Seus dados vivem no seu celular. Os bancos de dados de alimentos que uso são públicos e gratuitos. As features de IA, se você usá-las, falam diretamente com a OpenAI ou o Google usando sua própria chave de API: você paga pra eles, sem intermediário, sem comissão. O app é gratuito no [Google Play](https://play.google.com/store/apps/details?id=com.werules.logger) e open source no [GitHub](https://github.com/blopa/musclog-app).\r\n\r\n![O ciclo de assinatura de apps de fitness, ilustrado](../../uploads/blog/2026/03/fitness-app-subscription-meme.png)\r\n\r\nIsso não é uma posição de princípio contra o capitalismo. É uma decisão de design que faz sentido pro que isso realmente é: uma ferramenta pessoal que construí pra mim mesmo e depois compartilhei com outras pessoas. A arquitetura que escolhi naturalmente não cria custos de servidor, o que significa que não tenho pressão financeira pra monetizar, o que significa que os usuários não têm motivo pra desconfiar do que estou fazendo com os dados deles. Porque não estou fazendo nada com os dados deles. Estão no celular deles.\r\n\r\nO design offline-first é deliberado pelo mesmo motivo. Histórico de peso, composição corporal, o que você come, seu ciclo menstrual, seu histórico de treinos: nada disso deveria ficar no servidor de um estranho por padrão. A maioria dos apps de fitness não explica claramente o que faz com esses dados porque uma resposta transparente seria impopular. O Musclog mantém tudo local. O único dado que sai do seu device é o que você explicitamente manda pra IA, e só quando você escolhe usar essa feature.\r\n\r\nTem uma população inteira de pessoas treinando em academias com WiFi ruim, em porões, em garagens, em parques, que nunca tiveram o Musclog falhar porque precisava de conexão. Isso importa pra mim mais do que um número de receita recorrente mensal.\r\n\r\n## O que vem por aí\r\n\r\nO onboarding é a parte mais fraca do app agora. O Musclog é significativamente mais útil quanto mais dados tem, mas a experiência de novo usuário ainda tá muito perto de \"aqui tá o app inteiro, se vira.\" Quero construir um fluxo de onboarding de verdade que deixe alguém configurado com seus objetivos, seu primeiro template de treino, e seu primeiro log de comida em menos de cinco minutos. Você não deveria precisar de 500 horas de contexto pra ter valor desde o primeiro dia.\r\n\r\nSuporte a devices BLE pra balanças inteligentes também está na lista. Entrar o peso e gordura corporal manualmente todo dia é ok. Ter a balança mandar pro app automaticamente quando você sobe nela é melhor, e a infraestrutura não é tão complexa. É principalmente uma questão de conseguir hardware pra testar, o que é um problema muito solucionável e definitivamente algo que vou fazer assim que terminar as outras dezessete coisas que já comecei.\r\n\r\n## Vai ser gratuito pra sempre?\r\n\r\nPergunta justa. A resposta curta é: não faço a menor ideia. A resposta mais longa é mais interessante.\r\n\r\nO código é open source sob a licença Attribution-NonCommercial-NoDerivatives 4.0 International. Você pode ler, fazer fork pra uso pessoal, aprender com ele. O que você não pode é shipar um produto construído em cima dele sem falar comigo primeiro, porque Musclog é uma marca minha, e porque as quinhentas horas de trabalho por trás disso representam algo em torno de €25000 em salário de desenvolvedor europeu. Não tô tocando uma ONG. Tô tocando um side project que ainda não te pediu dinheiro.\r\n\r\nSe isso mudar algum dia, aqui tá minha promessa: não vou fazer assinatura. Se o Musclog algum dia custar dinheiro, vai custar uma vez. Você paga o preço de um café, o app é seu, pra sempre. Sem mensalidade. Sem \"seu plano premium foi pausado.\" O modelo bom e velho, aquele que a App Store basicamente matou.\r\n\r\nO que tá me empurrando mais perto desse cenário agora é o iOS. Minha namorada quer no iPhone. Alguns amigos próximos querem no iPhone. Há meses escuto \"coloca na App Store\" como se fosse uma coisa trivial. O programa de desenvolvedor da Apple custa 100 USD por ano. Por ano. Não uma vez. Todo ano. A Apple transformou o direito de distribuir software num SaaS, e falo isso como alguém que acha que a taxa única de 35 USD do Google Play é como deveria ser em todo lugar. Então sim, se o Musclog algum dia chegar no iOS, provavelmente vai ter um preço, porque não vou pagar 100 USD de pedágio anual pra Apple de boa vontade.\r\n\r\nPor enquanto: Android, gratuito, sem planos de mudar isso. Então baixe agora enquanto tá de graça, porque uma vez que você instala no Google Play, ele é seu pra sempre. Mesmo que você não tenha pagado nada. Especialmente se você não pagou nada.\r\n\r\n## Conclusão\r\n\r\nDois anos, duas versões, 500 horas. O Musclog finalmente parece algo pelo qual eu não me desculpo mentalmente antes de mostrar pra alguém. O redesign limpou anos de dívida de UI do \"manda ver\", e fazer direito me forçou a pensar sobre o produto de maneiras que eu deveria ter pensado desde o começo. Acontece que design systems existem por boas razões e não só pra dar aos designers algo pra discutir no Figma.\r\n\r\nÉ gratuito. É open source. Não tem seus dados. Funciona no modo avião. Bancos de dados de comida reais. IA que realmente sabe quem você é. Check-ins semanais automatizados. E um esquema de cores verde escuro do qual eu me orgulho genuinamente, mesmo que uma ferramenta de IA tenha feito a maior parte do trabalho visual pesado.\r\n\r\nSe quiser experimentar: [Google Play](https://play.google.com/store/apps/details?id=com.werules.logger).\r\n\r\nSe quiser ver como foi construído ou contribuir com algo: [github.com/blopa/musclog-app](https://github.com/blopa/musclog-app).\r\n\r\nTreina, Loga, Repete.\r\n\r\nAté a próxima!\r\n","frontmatter":{"tags":["react","react native","expo","android","fitness","musclog","nutrition","usda","open food facts","stitch","design","offline","watermelondb","nativewind"],"categories":["coding"],"allowComments":true,"publishOnMedium":false,"cover":null,"date":"2026-03-22T00:00:00.000Z","id":null,"path":"musclog-redesign-acompanhamento-nutricional-e-por-que-a-assinatura-do-seu-app-de-fitness-e-uma-enganacao","show":true,"title":"Musclog: Redesign do acompanhamento nutricional e por que a assinatura do seu app de fitness é uma enganação","hideExcerpt":false,"subtitle":"Nova interface, bancos de dados de alimentos reais e um desabafo sobre assinaturas de apps de fitness que estou guardando há dois anos"}},"next":{"excerpt":"Uma das side quests mais chatas de publicar um app na Google…","html":"

Uma das side quests mais chatas de publicar um app na Google Play Store é que o Google às vezes decide que você também virou dono de site.

\n

Lá em 2024, quando eu escrevi pela primeira vez sobre o Musclog, o site existia basicamente porque o Google queria que ele existisse. Eu precisava da política de privacidade, das páginas públicas, do kit básico do desenvolvedor de app respeitável, então subi rapidinho um site pequeno em Next.js, consegui aprovar o app, e segui com a minha vida.

\n

Funcionou perfeitamente até o dia em que eu precisei mexer no site de novo.

\n

Screenshots novas? Outro repo. Texto de feature nova? Outro repo. Atualização de página legal? Outro repo. Ajustezinho de tradução? Outro repo.

\n

Nada disso era difícil de verdade, o que quase piorava a situação. Era só chato o suficiente pra continuar me lembrando que eu tinha dividido um produto em duas bases de código por um motivo que eu já não respeitava mais.

\n

Então agora eu não faço mais isso.

\n

O site do Musclog mora dentro do repo do app. Mesmo projeto com Expo Router. Mesmo deploy. musclog.app é o site público, musclog.app/app é o app web de verdade, e Android + iOS continuam saindo da mesma base de código.

\n

Boa prática? Questionável. Conveniente? Demais.

\n

\n \n ;\r\nimport { useEffect } from 'react';\r\nimport { Platform } from 'react-native';\r\n\r\nexport default function Index() {\r\n const router = useRouter();\r\n\r\n useEffect(() => {\r\n if (Platform.OS === 'web') {\r\n router.replace('/home');\r\n }\r\n }, [router]);\r\n\r\n if (Platform.OS === 'web') {\r\n return null;\r\n }\r\n\r\n return <Redirect href=\"/app\" />;\r\n}\n

É isso. No web, / vira o site. No native, / vira o app.

\n

O site também ganha o próprio layout mais leve:

\n
// app/(website)/_layout.web.tsx\r\nimport { Slot } from 'expo-router';\r\n\r\nimport { WebsiteChrome } from '@/components/website/WebsiteChrome';\r\nimport { WebsiteProviders } from '@/components/website/WebsiteProviders';\r\n\r\nexport default function WebsiteLayout() {\r\n  return (\r\n    <WebsiteProviders>\r\n      <WebsiteChrome>\r\n        <Slot />\r\n      </WebsiteChrome>\r\n    </WebsiteProviders>\r\n  );\r\n}
\n

Isso importa porque o layout do app de verdade já tinha crescido e virado um layout de app mesmo. Boot de banco, migrações, React Query, safe area, gestos, modais, snackbars, câmera, contexto do coach, todas aquelas mentiras clássicas de “é só um projetinho paralelo”. O site não precisa de nada disso só pra explicar o que o app faz.

\n

E se algum usuário nativo cair numa rota exclusiva do site, a correção é maravilhosamente direta:

\n
// app/(website)/home.tsx\r\nimport { Redirect } from 'expo-router';\r\n\r\nexport default function Home() {\r\n  return <Redirect href=\"/app\" />;\r\n}
\n

Pronto. Volta pros macros.

\n

\n \n \n \n \n
Site público do Musclog renderizado pela mesma base de código com Expo Router do app
\n

\n

A palhaçada do celular no desktop

\n

Foi aqui que eu parei de me comportar como uma pessoa normal.

\n

Eu queria que musclog.app/app, no desktop, mostrasse o app funcionando dentro de uma moldura de celular. Um pouco porque fica bonito. Um pouco porque funciona como preview do produto. Mas principalmente porque, depois que a ideia entrou na minha cabeça, qualquer opção menos ridícula começou a parecer errada.

\n

O detalhe chato era que /app precisava parecer um celular, mas /home definitivamente não. Então só o roteamento não bastava. Eu precisava que o shell bruto de HTML soubesse, antes da hidratação, se o navegador deveria renderizar a gambiarra do celular fake ou não.

\n

Essa lógica mora em app/+html.tsx, dentro de um script no <head> do documento:

\n
function landingPanelGate(base: string) {\r\n  try {\r\n    function update() {\r\n      const raw = window.location.pathname;\r\n      const path = (base && raw.startsWith(base) ? raw.slice(base.length) : raw) || '/';\r\n\r\n      if (!path.startsWith('/app')) {\r\n        document.documentElement.classList.add('hide-desktop-wrapper');\r\n      } else {\r\n        document.documentElement.classList.remove('hide-desktop-wrapper');\r\n      }\r\n    }\r\n\r\n    update();\r\n    window.addEventListener('popstate', update);\r\n\r\n    const origPush = history.pushState.bind(history);\r\n    history.pushState = function (...args) {\r\n      origPush(...args);\r\n      update();\r\n    };\r\n\r\n    const origReplace = history.replaceState.bind(history);\r\n    history.replaceState = function (...args) {\r\n      origReplace(...args);\r\n      update();\r\n    };\r\n  } catch (_) {}\r\n}
\n

A parte importante é a gambiarra em pushState / replaceState. A primeira renderização foi tranquila. A navegação client-side é que era a parte chata. Sem isso, dava pra sair de /app e continuar com o shell errado ali, como se o Chrome tivesse esquecido em que página estava.

\n

O shell HTML em si é basicamente o painel da landing, o app roteado, e a moldura do celular:

\n
<body className=\"expo-web-body\">\r\n  <div className=\"expo-web-landing\">...</div>\r\n  <script dangerouslySetInnerHTML={{ __html: LANDING_I18N_SCRIPT }} />\r\n  <div className=\"expo-web-root\">\r\n    <div className=\"expo-web-app-shell\">{children}</div>\r\n    <img\r\n      className=\"expo-web-phone-frame\"\r\n      src={withExpoBaseUrl(PHONE_FRAME_SRC)}\r\n      alt=\"\"\r\n      aria-hidden\r\n    />\r\n  </div>\r\n</body>
\n

Aí o CSS comete o crime:

\n
@media (min-width: 1024px) {\r\n  .expo-web-root {\r\n    --frame-h: min(100dvh, max(min(360px, 100dvh), 85dvh));\r\n    aspect-ratio: 1438 / 2976;\r\n    width: min(100vw, calc(var(--frame-h) * 1438 / 2976));\r\n    max-height: var(--frame-h);\r\n    overflow: hidden;\r\n  }\r\n\r\n  .expo-web-app-shell {\r\n    position: absolute;\r\n    left: 7.4409%;\r\n    top: 2.9906%;\r\n    right: 6.3282%;\r\n    bottom: 3.125%;\r\n    zoom: 0.85;\r\n  }\r\n}
\n

Sim, eu medi a área transparente da tela dentro do PNG até o app encaixar direito. Não tem geometria elegante nenhuma por trás dessas porcentagens. Era só eu, uma moldura de celular, e muito empurra-pra-lá até o app parar de parecer torto.

\n

Nas rotas que não são /app, o espetáculo inteiro é desligado:

\n
.hide-desktop-wrapper .expo-web-landing,\r\n.hide-desktop-wrapper .expo-web-phone-frame {\r\n  display: none !important;\r\n}\r\n\r\n.hide-desktop-wrapper .expo-web-app-shell {\r\n  position: static !important;\r\n  width: 100% !important;\r\n  height: auto !important;\r\n  zoom: 1 !important;\r\n  overflow: visible !important;\r\n}
\n

Sim, usa !important. Isso é CSS de pré-hidratação cujo trabalho inteiro é manter a mentira de pé. Não estamos fazendo arquitetura refinada nessa camada.

\n

\n \n \n \n \n
App web do Musclog no desktop renderizado dentro de uma moldura de celular ao lado da landing
\n

\n

Três pequenos crimes

\n

\"Direto

\n

Depois que o shell funcionou, os incômodos menores começaram a aparecer como se tivessem marcado horário.

\n

1. O painel da landing precisava de i18n antes da hidratação

\n

O texto do lado do celular mora em HTML cru, o que significa que React e i18n ainda estão dormindo quando a página renderiza pela primeira vez. Então, se eu quisesse que a página em português não desse um flash de inglês antes, eu tinha que remendar isso manualmente a partir do localStorage:

\n
function landingI18nPatcher(translations, storageKey) {\r\n  try {\r\n    let lang = localStorage.getItem(storageKey);\r\n    let s = (lang && translations[lang]) || translations['en-US'];\r\n\r\n    document.querySelectorAll('[data-landing-i18n]').forEach(function (el) {\r\n      let k = el.getAttribute('data-landing-i18n');\r\n      if (k && s[k]) {\r\n        el.textContent = s[k];\r\n      }\r\n    });\r\n  } catch (_) {}\r\n}
\n

Não é elegante. Também evita jogar um flashbang de texto em inglês numa página em português, então eu vou manter.

\n

2. Assets em HTML cru não recebem a ajuda de sempre do Expo

\n

O PNG da moldura do celular e o QR code também são referenciados a partir de HTML cru, então aquela conveniência normal de assets do Expo não me ajudava muito ali. Resultado: eu precisei de um helper pra base URL:

\n
function withExpoBaseUrl(path: string): string {\r\n  const base = process.env.EXPO_BASE_URL;\r\n  if (base == null || base === '') {\r\n    return path;\r\n  }\r\n\r\n  const basePath = String(base).replace(/^\\/+|\\/+$/g, '');\r\n  const normalized = path.startsWith('/') ? path : `/${path}`;\r\n  return `/${basePath}${normalized}`;\r\n}
\n

E como esses arquivos vivem fora do pipeline normal de assets do React Native, eu copio tudo pra public/ antes de rodar dev e export. Esquece esse passo uma vez e o site imediatamente te lembra quem manda.

\n

3. O expo export às vezes precisava de apoio emocional

\n

Em alguns ambientes, expo export --platform web terminava com sucesso e depois só… continuava vivo sem motivo nenhum. Pasta dist lá. Arquivos gerados. Processo espiritualmente concluído, tecnicamente ainda pendurado.

\n

Então agora existe um script wrapper:

\n
// scripts/export-web-wrapper.js\r\nif (output.includes('Exported: dist')) {\r\n  console.log('[export-web-wrapper] Detected successful export. Forcing exit in 5s...');\r\n  setTimeout(() => process.exit(0), 5000);\r\n}
\n

Não é glamouroso… mas resolve.

\n

Aí os modais ficaram esquisitos

\n

\n \n \n \n \n
Modal do Musclog no desktop renderizado corretamente dentro da moldura do celular
\n

\n

Claro que ficaram.

\n

Quando o app web mora dentro de um celular fake no desktop, o comportamento padrão de Modal no React Native Web começa a ficar ridículo bem rápido. Fazer portal direto pro document.body funciona bem quando o app é dono da página inteira. Funciona bem menos quando o app está visualmente recortado dentro de uma carcaça de celular e o modal decide do nada que agora pertence à janela inteira do navegador.

\n

Então eu adicionei um WebModalShellProvider lá em cima em app/app/_layout.tsx, com um host de overlay dentro do shell do celular:

\n
// context/WebModalShellContext.web.tsx\r\nreturn (\r\n  <WebModalShellContext.Provider value={{ hostElement }}>\r\n    <View style={{ flex: 1, minHeight: 0, height: '100%', width: '100%', position: 'relative' }}>\r\n      <View style={{ flex: 1, minHeight: 0, height: '100%', width: '100%' }} collapsable={false}>\r\n        {children}\r\n      </View>\r\n      <View\r\n        id=\"expo-web-modal-shell-host\"\r\n        ref={setHostRef}\r\n        collapsable={false}\r\n        style={{\r\n          position: 'absolute',\r\n          left: 0,\r\n          right: 0,\r\n          top: 0,\r\n          bottom: 0,\r\n          zIndex: 1_000_000,\r\n        }}\r\n      />\r\n    </View>\r\n  </WebModalShellContext.Provider>\r\n);
\n

Aí o Modal.web.tsx faz aquela coisa óbvia que só parece óbvia depois, alternando entre um portal dentro desse host e o modal normal do RN:

\n
const useShellPortal = Platform.OS === 'web' && isDesktopFrame && hostElement != null;\r\n\r\nif (useShellPortal) {\r\n  return createPortal(\r\n    <View\r\n      style={{\r\n        position: 'absolute',\r\n        left: 0,\r\n        right: 0,\r\n        top: 0,\r\n        bottom: 0,\r\n        width: '100%',\r\n        height: '100%',\r\n      }}\r\n    >\r\n      {children}\r\n    </View>,\r\n    hostElement\r\n  );\r\n}\r\n\r\nreturn <RNModal visible={visible}>{children}</RNModal>;
\n

E o hook compartilhado do overlay sabe se ele deve se comportar como um modal de viewport inteira ou como um modal de viewport de celular fake:

\n
export function useWebModalLayerStyle(options = {}) {\r\n  const isDesktopFrame = useWebDesktopPhoneFrame();\r\n\r\n  if (isDesktopFrame) {\r\n    return {\r\n      position: 'absolute',\r\n      top: 0,\r\n      left: 0,\r\n      right: 0,\r\n      bottom: 0,\r\n      width: '100%',\r\n      height: '100%',\r\n    };\r\n  }\r\n\r\n  return {\r\n    position: 'fixed',\r\n    top: 0,\r\n    left: 0,\r\n    right: 0,\r\n    bottom: 0,\r\n    width: '100vw',\r\n    height: '100dvh',\r\n  };\r\n}
\n

Isso resolveu a parte visual. Aí os pointer events decidiram que também queriam atenção.

\n

No native, pointerEvents=\"box-none\" é normal. No HTML, isso vira pointer-events: box-none, que não é CSS de verdade, então o navegador fica livre pra improvisar. Então agora existe uma regra defensiva pro host do overlay:

\n
.expo-web-app-shell #expo-web-modal-shell-host {\r\n  pointer-events: none !important;\r\n}\r\n\r\n.expo-web-app-shell #expo-web-modal-shell-host * {\r\n  pointer-events: auto !important;\r\n}
\n

Também existe um useLayoutEffect forçando a mesma coisa inline, porque a essa altura eu já não tinha mais interesse em descobrir quão elegante seria a solução correta.

\n

Eu claramente tenho um padrão

\n

Se você já lê este blog há algum tempo, nada disso deveria te surpreender.

\n

Eu já transformei este blog num RPG top-down porque o Konami Code merecia uma recompensa maior do que só um efeitinho de fundo.

\n

Depois eu coloquei Stories no blog porque o app da minha operadora tinha Stories, e isso me irritou profundamente num nível suficiente pra eu transformar o problema em problema de todo mundo.

\n

Então sim, é claro que agora o meu app de fitness serve o site a partir do mesmo repo com Expo Router, e é claro que o app web no desktop roda dentro de uma foto gigante de um celular. Isso não é uma escalada surpreendente. É só continuidade.

\n

Por que eu vou manter isso

\n

Passando da piada, isso resolveu um imposto de manutenção bem real.

\n

As traduções são compartilhadas. Os design tokens são compartilhados. Os componentes são compartilhados. As páginas legais ficam do lado do produto que elas estão legalmente defendendo. Quando eu mudo texto, screenshot ou posicionamento de feature, eu não preciso lembrar qual repo guarda a versão pública e comportada do mesmo app.

\n

O deploy também ficou melhor. Um build. Um export. Um artefato. O site e o app web não têm como sair de sincronia a não ser que eu faça questão de separá-los, o que fica bem mais difícil quando eles literalmente são publicados juntos.

\n

E quando eu lancei o redesign do Musclog, o site basicamente veio junto no embalo. Mesmo spacing, mesmas cores, screenshots atualizadas, mesmo PR. Exatamente o tipo de vitória chata de manutenção que faz uma decisão de arquitetura meio estranha parecer inteligente seis meses depois.

\n

Conclusão

\n

Eu poderia ter mantido o site num repo separado em Next.js como uma pessoa emocionalmente mais estável? Poderia.

\n

Eu ia continuar fazendo isso depois que o Expo Router deixou esse caminho aberto? Não.

\n

A parte engraçada é que o roteamento foi a parte sem graça. O Expo Router resolveu isso muito bem. O trabalho irritante estava em todas as mentirinhas de navegador ao redor: bloqueio de rota antes da hidratação, i18n em HTML cru, sincronização de assets, modais que sabiam em que shell estavam, esquisitice com pointer-events, e convencer o Chrome do desktop a acreditar temporariamente que era um celular.

\n

Ainda assim, valeu muito a pena.

\n

Se quiser fuçar o código, o Musclog é open-source no GitHub. Se quiser usar, tá em musclog.app. O site mora dentro do repo do app agora.

\n

Agora mora todo mundo aqui.

","fields":{"postHashId":"Y29kaW5ndHJ1ZW51bGwyMDI2LTA0LTI1VDAwOjAwOjAwLjAwMFo=","slug":"/2026/2026-04-25-site-ou-app-sim-o-guia-gambiarrístico-para-sites-feitos-em-expo-router.pt-br/","path":"/blog/coding/site-ou-app-sim-o-guia-gambiarrístico-para-sites-feitos-em-expo-router/","locale":"pt-br"},"rawMarkdownBody":"\r\nUma das side quests mais chatas de publicar um app na Google Play Store é que o Google às vezes decide que você também virou dono de site.\r\n\r\nLá em 2024, quando eu [escrevi pela primeira vez sobre o Musclog](/pt-br/blog/coding/musclog-aproveitando-minha-experiencia-com-reactjs-para-criar-um-app-em-react-native/), o site existia basicamente porque o Google queria que ele existisse. Eu precisava da política de privacidade, das páginas públicas, do kit básico do desenvolvedor de app respeitável, então subi rapidinho um site pequeno em Next.js, consegui aprovar o app, e segui com a minha vida.\r\n\r\nFuncionou perfeitamente até o dia em que eu precisei mexer no site de novo.\r\n\r\nScreenshots novas? Outro repo. Texto de feature nova? Outro repo. Atualização de página legal? Outro repo. Ajustezinho de tradução? Outro repo.\r\n\r\nNada disso era difícil de verdade, o que quase piorava a situação. Era só chato o suficiente pra continuar me lembrando que eu tinha dividido um produto em duas bases de código por um motivo que eu já não respeitava mais.\r\n\r\nEntão agora eu não faço mais isso.\r\n\r\nO site do Musclog mora dentro do repo do app. Mesmo projeto com Expo Router. Mesmo deploy. [musclog.app](https://musclog.app/) é o site público, [musclog.app/app](https://musclog.app/app) é o app web de verdade, e Android + iOS continuam saindo da mesma base de código.\r\n\r\nBoa prática? Questionável. Conveniente? Demais.\r\n\r\n![Site público do Musclog renderizado pela mesma base de código com Expo Router do app](../../uploads/blog/2026/04/musclog-shared-router-website-home-1.png)\r\n\r\n## Ok mas por quê?\r\n\r\nBasicamente porque o Expo Router arrancou a minha última desculpa.\r\n\r\nO Musclog já usava [Expo Router](https://expo.github.io/router/docs), então o app já estava organizado em rotas baseadas em arquivos dentro da pasta `app/`. Aí eu percebi que podia simplesmente criar um grupo de rotas chamado `(website)`, mover as páginas públicas pra lá, deixar o app de verdade em `app/app/*`, e parar de fingir que eu estava lidando com dois produtos diferentes.\r\n\r\nO repo separado tinha virado uma daquelas decisões de arquitetura que parecem limpas na teoria e depois ficam te cobrando imposto de manutenção pra sempre:\r\n\r\n- dois PRs pra uma mudança num produto\r\n- dois deploys\r\n- dois lugares pras traduções\r\n- dois lugares pras páginas legais\r\n- dois lugares pra esquecer alguma coisa\r\n\r\nSem condições.\r\n\r\n## A divisão\r\n\r\nA parte engraçada é que o roteamento em si acabou sendo a parte menos amaldiçoada dessa história:\r\n\r\n- `app/app/*` é o Musclog de verdade. Treinos, nutrição, coach com IA, tudo.\r\n- `app/(website)/*` é o site público. Landing page, política de privacidade, termos, contato, calculadora.\r\n\r\nA rota raiz só checa a plataforma e te joga pra onde você pertence:\r\n\r\n```tsx\r\n// app/index.tsx\r\nimport { Redirect, useRouter } from 'expo-router';\r\nimport { useEffect } from 'react';\r\nimport { Platform } from 'react-native';\r\n\r\nexport default function Index() {\r\n const router = useRouter();\r\n\r\n useEffect(() => {\r\n if (Platform.OS === 'web') {\r\n router.replace('/home');\r\n }\r\n }, [router]);\r\n\r\n if (Platform.OS === 'web') {\r\n return null;\r\n }\r\n\r\n return ;\r\n}\r\n```\r\n\r\nÉ isso. No web, `/` vira o site. No native, `/` vira o app.\r\n\r\nO site também ganha o próprio layout mais leve:\r\n\r\n```tsx\r\n// app/(website)/_layout.web.tsx\r\nimport { Slot } from 'expo-router';\r\n\r\nimport { WebsiteChrome } from '@/components/website/WebsiteChrome';\r\nimport { WebsiteProviders } from '@/components/website/WebsiteProviders';\r\n\r\nexport default function WebsiteLayout() {\r\n return (\r\n \r\n \r\n \r\n \r\n \r\n );\r\n}\r\n```\r\n\r\nIsso importa porque o layout do app de verdade já tinha crescido e virado um layout de app mesmo. Boot de banco, migrações, React Query, safe area, gestos, modais, snackbars, câmera, contexto do coach, todas aquelas mentiras clássicas de \"é só um projetinho paralelo\". O site não precisa de nada disso só pra explicar o que o app faz.\r\n\r\nE se algum usuário nativo cair numa rota exclusiva do site, a correção é maravilhosamente direta:\r\n\r\n```tsx\r\n// app/(website)/home.tsx\r\nimport { Redirect } from 'expo-router';\r\n\r\nexport default function Home() {\r\n return ;\r\n}\r\n```\r\n\r\nPronto. Volta pros macros.\r\n\r\n![Site público do Musclog renderizado pela mesma base de código com Expo Router do app](../../uploads/blog/2026/04/musclog-shared-router-website-home-2.png)\r\n\r\n## A palhaçada do celular no desktop\r\n\r\nFoi aqui que eu parei de me comportar como uma pessoa normal.\r\n\r\nEu queria que [musclog.app/app](https://musclog.app/app/), no desktop, mostrasse o app funcionando dentro de uma moldura de celular. Um pouco porque fica bonito. Um pouco porque funciona como preview do produto. Mas principalmente porque, depois que a ideia entrou na minha cabeça, qualquer opção menos ridícula começou a parecer errada.\r\n\r\nO detalhe chato era que `/app` precisava parecer um celular, mas `/home` definitivamente não. Então só o roteamento não bastava. Eu precisava que o shell bruto de HTML soubesse, antes da hidratação, se o navegador deveria renderizar a gambiarra do celular fake ou não.\r\n\r\nEssa lógica mora em `app/+html.tsx`, dentro de um script no `` do documento:\r\n\r\n```tsx\r\nfunction landingPanelGate(base: string) {\r\n try {\r\n function update() {\r\n const raw = window.location.pathname;\r\n const path = (base && raw.startsWith(base) ? raw.slice(base.length) : raw) || '/';\r\n\r\n if (!path.startsWith('/app')) {\r\n document.documentElement.classList.add('hide-desktop-wrapper');\r\n } else {\r\n document.documentElement.classList.remove('hide-desktop-wrapper');\r\n }\r\n }\r\n\r\n update();\r\n window.addEventListener('popstate', update);\r\n\r\n const origPush = history.pushState.bind(history);\r\n history.pushState = function (...args) {\r\n origPush(...args);\r\n update();\r\n };\r\n\r\n const origReplace = history.replaceState.bind(history);\r\n history.replaceState = function (...args) {\r\n origReplace(...args);\r\n update();\r\n };\r\n } catch (_) {}\r\n}\r\n```\r\n\r\nA parte importante é a gambiarra em `pushState` / `replaceState`. A primeira renderização foi tranquila. A navegação client-side é que era a parte chata. Sem isso, dava pra sair de `/app` e continuar com o shell errado ali, como se o Chrome tivesse esquecido em que página estava.\r\n\r\nO shell HTML em si é basicamente o painel da landing, o app roteado, e a moldura do celular:\r\n\r\n```tsx\r\n\r\n
...
\r\n