Posting this because a lot of people still don't realize how far along the Stocky sunset already is — and there's one detail that'll bite you if you wait.

Timeline:

• July 2025: forecasting (min/max) and inventory transfers between locations already stopped working.
• Feb 2, 2026: Stocky was removed from the App Store. Uninstall it now and you can't get it back.
• Aug 31, 2026: full shutdown. App and API stop working entirely.

The part that's easy to miss: supplier records and historical transfer/PO data are not exportable. Product and cost data you can pull via CSV, but supplier info and history you'll likely have to recreate by hand wherever you move. So even if you're not switching today, export/screenshot what you can now, while it still runs.

On replacements, honestly depends what you used Stocky for:

• Mostly reorder points / low-stock alerts → a few cheap apps do just that well (Orlio, Sensible).
• Need a full inventory/ERP (B2B, multi-channel, BOM) → bigger tools cover it (Finale, inFlow, Sumtracker), at higher price + learning curve.
• If your Stocky pain was specifically purchase orders + keeping cost updated on receipt (the thing people say Stocky was clunky at) → that middle ground is thinner.

Full disclosure: that last gap is what I'm building for (Shopify + Square), so I'm not neutral. Not dropping a link in the post — happy to share if useful, but mostly I'll be in the comments helping with migration questions, since I've spent way too long reading about Stocky lately.

What did you use Stocky for, and what are you moving to?

If you've felt Cursor go from magic to drifting around prompt 15-20 on a UI task, the cause usually isn't the model. It's that the design intent only lives in the chat. Once the conversation gets long enough that Composer starts trimming history, the spec is the first thing to go. After that you're just re-prompting against a model that no longer knows what you wanted, and it hallucinates dependencies or rewrites unrelated screens.

The fix that actually holds across long sessions is moving the design spec out of chat and into the repo, as a file you u/reference per task. Exact hex values, type scale, spacing system, every screen state, the nav graph. Concrete enough that the model can't drift, durable across as many prompts and Composer trims as you need.

Writing that spec by hand for every screen is friction enough that nobody does it, so I built the references instead. 200 popular apps, each as a structured markdown DESIGN.md, with SwiftUI, Jetpack Compose, and Expo versions for each. Drop one into your repo, u/reference it in Composer or Agent, and your UI work stops degrading at prompt 20.

Repo, MIT, no dependencies: github.com/Meliwat/awesome-ios-design-md

Two questions: which apps would actually help you next, and for Cursor users on long projects, are you holding design intent in .cursorrules, an u/file, or chat? Trying to nail this down.

The biggest reason the UIs Codex builds for you all look the same: you're handing it a vibe, not a spec. "Make it clean and modern" produces the exact same generic gradient-card layout every time, because that prompt has no anchor. The model fills the gap with its own average taste.

The fix that actually works is giving Codex a real app's exact design as the target. Not "like Spotify" in prose. The actual hex values, type scale, spacing system, every screen state, the nav graph. With that, Codex stops averaging and starts matching.

Writing that spec by hand for every screen is tedious enough that nobody does it, which is why the vibe-prompt habit sticks. So I built the references instead: 200 popular apps, each as a structured markdown design spec, with SwiftUI, Jetpack Compose, and Expo versions. Point Codex at the one you want and it has concrete values instead of guessing.

Repo, 200 apps, MIT, no dependencies: github.com/Meliwat/awesome-ios-design-md

Two questions for people building UI with Codex: do you get better results keeping the spec as a repo file Codex reads every run (AGENTS.md style) or pasting it per task? And which apps are worth adding next?

Small numbers, but the pattern might be useful to someone here.

I'm building Spectr, a tool that turns iOS screen recordings into structured design specs. Hard to explain in one sentence, which kept early traffic flat. Direct "here's my tool" posts did almost nothing.

What changed it: I built a free companion repo, a library of 50 popular apps already converted into design specs, and posted about the workflow insight behind it instead of the product. The repo is genuinely useful on its own. The product gets mentioned once, in passing.

Result over ~36h (screenshot attached):

- New users +124.5%

- Active users +115.7%

- Flat baseline to a clear spike on the 12th

- Inbound from Ireland, Brazil, Greece, New Zealand, none of which I targeted

Absolute numbers are still small (110, not 10,000). Not pretending otherwise. But the shape changed, and the mechanism is repeatable: the free artifact does the convincing, the product is the footnote.

What people are actually landing on: spectr.to/gallery, real spec outputs from real apps.

What I'd do differently: I posted two things to the same subreddit too close together. Self-promo flag risk. Space them out.

For people who've run lead-magnet distribution: did the free artifact cannibalize your paid product, or feed it? I'm betting feed, but it's early.

https://preview.redd.it/2bxv4bhuzc1h1.png?width=2044&format=png&auto=webp&s=296db7c40c10f090fa8ab7f2085ca17a3b728c91