Apple opening its Foundation Models to developers under two million first downloads is about as close as WWDC gets to a gift aimed squarely at indie developers. But tailwind weeks are exactly when judgment matters most — the question is never whether the news is good, it is what your own app should do about it. The four posts we published at Rork Lab this week all sit on that theme: after you have shipped something small, how do you decide what deserves to go deeper? Here they are, with editor's notes.
Decide the move up with store data, not mood
When Should a Rork App Move Up to Rork Max? Deciding With Store Data, Not Aspiration
The premise here is that validation and scaling should not happen in the same environment, and from there the post defines three concrete triggers — drawn from store metrics — for moving up to Max. What earns my trust is that it treats staying on Expo as a decision deserving evidence too, not a failure to upgrade. Tool migrations tend to be driven by enthusiasm and timing; writing the triggers down before the enthusiasm arrives is a discipline I want in my own operations.
Translate the free tier into a cost design
A Three-Layer AI Cost Design for Rork Apps After Apple Opened Foundation Models to Small Developers
This is the week's headline converted into engineering. The post assigns roles across three layers — on-device, Private Cloud Compute, and third-party APIs — and insists on estimating the savings with a script before moving anything. That ordering matters: deciding which task belongs in which layer is a design asset that outlives the current terms of the free tier. It is a premium post, and the back half, which wires the layers into an Expo-based Rork app, is where the design becomes something you can ship.
One step outside the app: a home-screen presence
Adding a Home Screen Widget to a Rork App — Making WidgetKit Work Within Expo's Constraints
Widgets run outside your app as extension targets, which is precisely why a straightforward generation flow cannot produce them. This build log explains that constraint clearly, lays out three implementation routes, and shows why the config plugin route won. The App Group data bridge and the two snags found during device testing keep it honest. A widget changes the relationship users have with an app — it stops being something they open and starts being something they see.
Notice the refunds quietly eating your revenue
A refund goes through, and the entitlement quietly lives on — this implementation memo closes that gap. Because App Store and Google Play deliver refund signals differently, the post starts by mapping the revocation path before writing any code, then covers both a RevenueCat setup and a self-managed one. Defensive work like this never trends, but it is what keeps a long-running app trustworthy, and the memo treats it with the seriousness it deserves.
If you try one thing this week
Open the staged-migration post and write down your own go/stay triggers in actual numbers. Once the criteria exist in words, tailwind weeks like this one stop being noise — you move in your own order, on your own evidence. More posts on judging well, not just building fast, are coming next week.