Patch is a UK-first garden-planning app that reads your postcode and local weather forecast, then tells you what to do in your garden today. Simplepage, a two-developer software company on the Isle of Man, took Patch from first sketch to a live iOS release in three weeks. The app ships with 382 crops, runs on Umbraco 17 and .NET 10, and survived three App Store rejections before Apple approved it. This is the honest account of what we built, what we cut, and what caught us out.
Why build another gardening app?
Most gardening apps split into two camps: visual layout tools like GrowVeg let you draw your beds, while calendar tools like Seed to Spoon track what to sow when. Neither connects the two, and almost none of them care about your actual weather.
The apps that do exist are mostly built around USDA hardiness zones and zip codes. Useful if you're in Iowa. Not if you're growing chard in Gwynedd in February, where what matters is whether last night's soil temperature dropped below 4°C and whether you have rain forecast before you need to water.
That was the brief: a UK-first app that knows your postcode, reads the forecast, and tells you what to do in your garden today - not a generic list from a hardiness zone table.
Why is a gardening app built on Umbraco?
Patch uses Umbraco 17 as a managed content platform for its crop library, with .NET 10 as the backend and a vanilla JavaScript PWA wrapped in Capacitor for the App Store submission. That probably sounds like an odd stack for a gardening app, but it made sense for one reason: the crop library.
Patch ships with 382 crops. Each one has sowing windows, frost hardiness, spacing data, companion planting relationships, and UK-specific growing notes. That data needs to be maintained - adding varieties, correcting errors, updating notes based on what users report. Umbraco gives us a managed CMS for that library at no extra build cost, and anyone on the team can edit crop data without touching code.
User data - beds, plantings, tasks, harvests, diary entries - lives in seven custom SQL tables via EF Core, completely separate from the Umbraco content layer. Shared crop reference data in Umbraco, personal growing data in SQL. The split meant we could iterate on user-facing features without touching the crop library, and vice versa.
How do you ship an app in three weeks without cutting quality?
The answer is ruthless scope control: one screen per job, the smallest crop database that feels complete, and deferring anything that needed extra backend work. We cut everything that wasn't a seed-to-harvest loop. No accounts, no social features, no cloud sync on day one. No drag-and-drop visual garden designer - that's the feature every competitor leads with, and it costs three times what it's worth in build time. Deferred.
The rule was one screen per job. The Today tab shows your tasks for today. The Garden tab shows your beds. The Crops tab lets you browse and search. Nothing earns a screen unless it has a clear job.
The crop database was the other constraint. We wanted it to feel complete on day one - not embarrassingly thin. That meant sourcing data from multiple sources, collating it, validating it, and presenting it in a format we could use easily. 168 of the 382 crops shipped with full UK growing data on launch.
The review queue was the only deadline we didn't control, and Apple turned it around in 96 hours - the first time.
Why did Apple reject the app three times?
Apple rejected Patch for three separate reasons: non-compliant in-app purchase promotional images, a missing Terms and Conditions link, and login emails that never reached the reviewer. Each one is common, and each one is avoidable.
The first rejection came under Guideline 2.3.2. The IAP promotional images for the Premium subscription were screenshots of the app; Apple's requirement is a clean marketing image. The rejection cascades: one non-compliant image puts the entire IAP product into "Developer Action Needed", which blocks StoreKit from fetching products in the sandbox. Fixed, resubmitted.
The second rejection: missing Terms and Conditions link in the subscription flow. The third: OTP email delivery - Apple's review team are US-based, and our magic-link emails hit spam thresholds during review. Adding demo credentials and an OTP flow explanation to the review notes got it approved.
Then the auto-release got stuck. App Store Connect showed "1.0 Ready for Distribution", but the release date kept rolling forward, the "Release This Version" button was absent, and the manual-release radio buttons were greyed out - with every agreement, bank detail and tax form green. Apple Developer Support unstuck it from their end. The app went live without any code change.
The lesson isn't that Apple's review process is painful - it's that you need to treat the review notes like a user test. The reviewer doesn't know your auth flow, doesn't know magic links, and may be confused by UK-specific content. Write the notes as if you're onboarding someone who has never seen the app.
What catches developers out in App Store submission?
Three specific traps ate our time, and none of them are obvious from the documentation:
RevenueCat entitlement IDs are case-sensitive. The entitlement in the dashboard was
Premium; the code was checking forpremium. The mismatch produces no error - premium just silently doesn't unlock.Subscription products in "Ready to Submit" status aren't fetchable by StoreKit on real devices. They have to be submitted for review alongside the app before sandbox purchases work. The workaround is a StoreKit Configuration file for local testing - knowing this up front saves two hours of debugging.
Smidge doesn't minify ES6 template literals. Our asset bundling library serves the entire JS bundle unminified when template literals are present. Not a disaster, but not what the docs suggest.
What's next for Patch?
The iOS app is live at apps.apple.com/gb/app/mypatch/id6761283635. Google Play submission is next. Web payments for users who don't go through the App Store is still to solve.
The crop library is the ongoing work. 168 crops with full data is a reasonable start; getting the remaining 214 to the same quality is a longer project. The data infrastructure is there - it's editorial time now.