When to Raise Your Minimum iOS Version — Count Leftover Branches, Not User Percentages
Judging a minimum OS bump by usage share produces the same answer every year, so the decision never happens. Here is the annotation convention, the sweep script that counts how many iOS and Android branches each candidate floor would retire, and what to watch for 30 days after.
Auditing the Dependencies Rork Generates: A Supply-Chain Hygiene Routine
Even a four-screen Rork app pulls in 900+ transitive dependencies. Before a vulnerability lands and you cannot tell which app is affected, build an audit habit with npm ls, npm audit, overrides, and depcheck — framed for running several apps at once.
Keeping Manual Fixes Alive Across Rork Regenerations — Boundary Design for AI-Owned Code
A tiny copy-change request quietly reverted my week-old ATT fix. Here is the boundary architecture I use now: a guarded directory, one-line adapters, patch assets, and scoped prompts — with measured blast-radius numbers.
Auto-Throttling AdMob When Crash Rates Spike: A Revenue-Protecting Brake Architecture with Rork, Firebase Remote Config, and Crashlytics
When crash rates spike, do you keep showing ads and watch your store rating crater, or pull back and accept the lost revenue? After 12 years of indie operations, my answer is neither: a four-state auto-throttle architecture that ties Firebase Remote Config and Crashlytics signals into AdMob serving decisions.
Keeping a Rork-Built Solo App Alive Past Year Three — A Maintenance Design Against Silent App Aging
When you run a Rork-built app over the long haul, a kind of 'aging' starts creeping in that wasn't visible at launch — OS updates, breaking library changes, shifting device landscapes. After more than a decade of independent app development and two years of running Rork apps, here are the maintenance design principles I rely on to keep apps stable past year three.