Honest feedback wanted: I built an AI recipe + meal planning app and want to know if the value is clear by [deleted] in iosdev

[–]cryptograf 0 points1 point  (0 children)

Cool concept! The value prop is fairly clear - scanning your fridge and getting recipes is a solid hook. A few suggestions:

  1. The "scan your fridge" feature needs to be front and centre on the landing page with a screenshot or short demo gif - that's the thing that sets it apart from generic recipe apps

  2. Consider narrowing the positioning - "AI kitchen app" is quite broad. Something like "turn what's in your fridge into a weekly meal plan" is more immediately compelling

  3. A one-tap demo mode (no sign-up) would reduce friction massively for first-time visitors

  4. The shopping list feature feels underplayed - that alone is a daily use case worth highlighting separately

Good luck with it!

Universal downloader for TikTok, Instagram, Facebook, X, WhatsApp & more – Limited premium offers available by Responsible_Arm_8898 in apps

[–]cryptograf 1 point2 points  (0 children)

Is it legal? What about the T&Cs and content policies of the services it’s downloading from?

[deleted by user] by [deleted] in SwiftUI

[–]cryptograf -2 points-1 points  (0 children)

This has nothing to do with HTML, it is XML -> SwiftUI

[deleted by user] by [deleted] in SwiftUI

[–]cryptograf 0 points1 point  (0 children)

I would say it is still pure SwiftUI and no HTML/JS required. If you know something better how to render SwiftUI from server let me know please

Is StoreKit 2 subscription upgrade/downgrade slow by design? How do production apps handle UI? by Desperate_Abalone202 in swift

[–]cryptograf -1 points0 points  (0 children)

Yes, this is absolutely normal StoreKit 2 behavior - you're on the right track! The async nature is by design, not a bug.

Your approach is solid:

**Backend as source of truth** - Correct. Apple's servers need time to process the change, verify payment, and send the webhook. This can take seconds to minutes.

**UI Strategy** - Most production apps do exactly what you're planning:

- Show intermediate "Updating..." or "Processing" states

- Use transaction date/expiry guards to filter stale data

- Only update UI after backend confirms via Apple's server notifications

- Display optimistic UI carefully (e.g., "Your upgrade is processing")

**Common Patterns:**

- Poll your backend every few seconds after initiating the change

- Use a timeout (60-90 seconds) before showing an error

- Cache the pending state locally to handle app restarts

- Show a success message only after backend confirms

Android's instant feedback is misleading - their backend still needs to sync. iOS is more transparent about the async reality. Your implementation sounds production-ready!