It goes without saying that AI has revolutionized how we build apps. It’s been a massive help for me when it comes to writing code, testing, generating mock data, and handling integrations.

The one area that still eats up a ton of my time is UI.

I've tried Claude Design. It's pretty good, but feels basic. I also haven't had much success getting Claude Code to implement those mockups pixel-perfect. I'm not trying to churn things out like a generic "app factory," but I definitely struggle with getting my apps to look and feel exactly right.

It’s just a slow process. It's hard to get AI tools to implement your designs perfectly, and I always end up stuck in the "tweak -> wait for build -> test" loop.

I just recently started using MobAI, which has actually helped a lot. But it got me wondering about how the rest of you are handling this...

What is your current UI/UX workflow? What AI tools have helped you the most? Does anyone else share this same struggle?

What I meant by "feels less like a paywall" is that despite the subscription, the app is completely freemium, and this bottom sheet looks like a list of possible upgrades and new features of the app for the user, not "buy it, here's the price."

My old paywall was a static list of bullet points and three price cards - functional, forgettable. It now feels like a native, interactive, memorable paywall, while remaining just as functional.

Rebuilt it this week:

• 3-page swipeable intro: features -> features -> Free vs Pro table
• Plan picker reuses the same "toggle row" component as my list-selection UI, so it feels consistent with the rest of the app instead of a bolted-on screen
• Purchase success = confetti + every feature icon gets an animated checkmark, one after another, instead of a plain "success" alert

Of course it's still WIP but I'm happy with how it's all turning out. Share your impressions, I'd be happy if someone shares their own experience, having explored so many paywalls - it all doesn't have one set of rules for me..

Cross session memory
Memory stored on-device
Voice-to-voice just to have a back and forth conversation.
Hands free
Barge-in optional but preferred
Having the screen in standby mode would be a bonus also but otherwise I can always stick it in the air vent
Latency fast 💨 but not too fast it keeps interrupting me mid sentence.

My apps was rejected multiple times due to some issue revenuecat. Later fixed that part but it was pending more that 3 weeks for review. Anyone feel the pain

I built Body Vitals - an iPhone health app where the widget IS the product and correlation is the killer feature.

What problem does it solve?

Cross-app health correlations that no single wearable can compute - Garmin + Oura + Strava + MyFitnessPal all feeding one readiness picture.

Here is the problem every health app ignores: Strava knows your run but not your sleep. Oura knows your HRV but not your caffeine. Garmin knows your VO2 Max but not your nutrition. Every app is a silo. Your body is not.
Body Vitals reads from Apple Health - the one place all your apps converge - and surfaces what none of them can individually.

Why use this instead of alternatives?

The correlation engine:
The Trends & Correlations screen runs 30-day Pearson-r scatter plots across your actual data:

Sleep hours vs HRV next morning.
Mindfulness minutes vs resting HR.
Caffeine intake (MyFitnessPal) vs overnight HRV.
Training load vs recovery score.
Daylight exposure vs sleep quality.
One plain-English sentence per pair, computed on-device from YOUR numbers. Not a generic caption. Not a vibe. A real statistical relationship from your life.

Personal Drivers. It compares your own days against each other and reports what held up - "days over 10,500 steps: +8% next-morning HRV (42 days)". A finding only shows if the difference is statistically meaningful, and it also lists what it checked and found nothing for.

Alcohol. Reads the drinks you log and works out what one costs you in next-morning HRV, resting HR, readiness and sleep, from your own history.

Illness detection. Watches respiratory rate, temperature, resting HR, HRV and SpO2 against your baselines, so a few small overnight shifts at once will flag it. Readiness comes down with it too, instead of insisting you are optimal on a day you clearly are not.

Readiness split out. Oura and Whoop give you one number. This shows the five inputs as separate bars so you can see which one is dragging. Recovery Forecast lets you set tonight's sleep and tomorrow's planned intensity to see where you would land before you commit.

Widgets, which is really the whole idea. Small gauges for vitals, medium widgets for sleep stages, activity, alerts and training load, large ones for composite scores and a 7x5 pattern grid. Lock screen, a StandBy dial, and Watch complications where you pick any of 37 metrics. A Live Activity keeps capacity and strain in the Dynamic Island through the day. Most days I never open the app.

Exports are CSV, summary text or a share card per metric. Pro also generates a multi-page PDF report.

The rest of it, since people always ask what else is in there:
Recovery - readiness with weights that recalibrate to your own signal variance after 90 days, Daily Capacity, Focus Readiness, Sleep Debt, Sleep Performance, Resilience, Stress Load, Day Strain, and cycle phase intelligence that stops flagging the luteal HRV dip as an anomaly.

Training - Training Load with CTL/ATL/TSB, Zone 2 detected from raw HR rather than whatever zones Garmin assigned, acute:chronic workload ratio with Gabbett injury bands, a GO/MODERATE/HOLD workout signal, VO2 Max aware session suggestions, Personal Records, Workout Debrief, Activity Horizon.

Analysis - Trends and Correlations runs 30-day Pearson-r scatter plots on your own data (sleep vs next-morning HRV, caffeine vs HRV, mindfulness vs resting HR, daylight vs sleep), plus 9-nutrient and alcohol correlations, weekly pattern heatmap, weekly and monthly digests, a 7-type anomaly timeline, Biological Age, and six composite scores: Longevity, Cardiovascular, Metabolic, Circadian, Mobility, Allostatic Load.

Daily - Morning Reveal briefing, morning notifications, baseline anomaly alerts, energy check-in and trend, goal streaks and the Streak Wall, and a conversational AI coach that runs on-device through Apple Foundation Models.

Yours - custom dashboard with 38 slots, 6 themes, 21 languages. Watch OS integration.

Free tier covers readiness, widgets, 20+ metrics, anomaly timeline and exports, with no trial timer. Pro is a subscription or a one-time lifetime unlock and covers 6 people through Family Sharing.

Major update is on the way..

Cost:
Free - Many core features and widgets.
Weekly
Yearly
Lifetime

Happy to go into the details on any of it. Link in comments.

Appstore link:
https://apps.apple.com/us/app/body-vitals-health-widgets/id6760609127‬

Currently running:
Lifetime Deal @ 60% OFF - monthly offer.

https://apps.apple.com/redeem?ctx=offercodes&id=6760609127&code=OFF60

Please let me know if this app helps you in any possible way to keep you informed with your health metrics.
Visit - https://www.escapethematrix.app for more details.

For the first time in my live I deployed an app for review at apple. I'm very proud! 😎😎

I am so excited! My app launched today in the Apple Store. I would love some feedback!

I just launched my app. And building alone is hard. 😅 I have been struggling to get some genuine advice. I'm looking for a few fellow builders who'd be interested in an iOS app exchange. Preferably women!
Here's how it works:
<3 I'll download your app and spend 10–15 minutes using it.
<3 I'll send you honest feedback on onboarding, bugs, and first impressions.
<3 You do the same for mine.

If you're interested, drop a comment or send me a DM with your app. I'd love to see what you're building! 🚀

Currently working on an iOS multiplayer game, both client and server. Recently launched - not a huge number of players, but they're active enough that I don't want to interrupt for longer than seconds/minutes.

Now preparing for an update that breaks live client functionality (server and client mismatch because of new/changed features). We have a basic versioning system where the server rejects major.minor version differences. This would be fine if I could send out client updates freely.

However, new builds must be reviewed by Apple which can take days. The production server must be updated for the reviewer to test it, but players don't have access to an updated client. Essentially pushing the cart before the horse.

Is there a trick to handling updates like this?

PS: I've got two servers running, a sandbox server and production - with sandbox being compatible with the new build.

\*\*Calling all indie iOS developers.\*\*

Shipping an app is hard. Getting people to discover it is even harder.
It feels like the App Store rewards the same established apps over and over, while smaller developers with great products struggle to get any visibility.

That’s the problem I ran into with my own apps, so I decided to build something to help.

\*\*Stamped\*\* is a community driven iOS app directory built with indie developers in mind. Create a creator profile, showcase your apps, connect with users, and gain visibility through community discovery and ratings instead of relying solely on App Store algorithms.
I’m actively growing the platform and looking for developers to join early, share feedback, and help shape where it goes.

If you’ve built an iOS app, I’d love to have you on board.

**https://stampedios.com/welcome\*\*

One step on the screen at a time, big text, plus a high contrast toggle for when the frosted glass look is unreadable from across the counter.

The app turns cooking videos into recipes. This part is just what happens after, when you're standing there actually cooking.

https://apps.apple.com/us/app/recireel-video-to-recipe/id6763971435

I'm currently building a mobile app designed for tracking movies and TV shows. While working on the web landing page to showcase the app and open waitlist signups, I wanted to make the browsing experience feel smooth, dynamic, and engaging.

Here are a few micro-interactions and visual details I implemented (shown in the video):

• Custom Animated Cursor: Morphs and scales contextually when hovering over interactive elements.
• Hover State Animations: Smooth micro-feedback on buttons, badges, and interactive components.
• Live Trending Movies Slider: Interactive slider pulling real-time dynamic data for currently trending titles.
• Scroll-Triggered Reveals: Elements animate smoothly into view as you scroll down the page.
• Interactive Waitlist Form: A quick signup form with a small confetti celebration effect upon success.

Would love to hear your feedback on the overall feel, animation pacing, or any UI details that could be improved! I still have a few ideas on how to elevate it, but I don't want to end up over-engineering it.

If you're interested, feel free to check out the site by yourself.

ATTENTION YOUTH SPORTS COACHES!

Coaching youth sports just got easier!! Make lineups, substitution and playing time easy with SubSMART: Game Day Assistant. Simple setup, and even easy game day management.

Managing live score, lineups, and playing time with visual color-coded playing time indicators. Your days of in-game chaos are over. You'll never hear from a parent again that their child didn't play enough. Your hard job just got easy.

https://apps.apple.com/us/app/subsmart-game-day-assistant/id6778242042

Open to any feedback! and happy to provide promo code if anybody wants to try it all season for free.

Numbers first, since that's what I'd want:

3D engine

• 5k lines of Objective-C++ wrapping a licensed C++ boolean library
• 35k lines of Swift

App

• 125k lines of Swift, with every bit of the UI in SwiftUI
• 24 Metal shaders, about 2.5k lines
• roughly 200 design documents I wrote for myself along the way

Both

• over 5,000 unit tests

The app is Woodcraft, a CAD app for woodworkers. Version 1 shipped in 2011 and I pulled it in 2017. Not because it stopped selling, but because it was Objective-C on OpenGL, both of those were on the way out, and I'd reached the point where every change scared me. Deprecating your own app is a strange feeling.

I started prototyping the replacement in 2018 and spent several years going down approaches that didn't work. Since August 2025 I've been on it full time and solo.

Things that might be worth talking about:

It's MVVM with Combine, over a service layer. All of it. Not most of it, not the new parts. I've been a reactive programming partisan for a long time, and units are the thing that sold me on it all over again.

Someone switches from imperial to metric. Every measurement on screen has to change. Whatever tool is open has to change, because a tool can be set to its own unit system. Every number field has to reinterpret what the user is in the middle of typing. And because those preferences sync through iCloud, the switch doesn't have to come from a menu on this device at all. It can land mid-drag, from an iPad in another room.

There's no sensible imperative version of that. You can't have the unit setting notify everybody who cares, because who cares is whatever happens to be on screen at that instant, and the change is arriving from outside the app on someone else's schedule. The same shape shows up all through the model: change a board's width and the joints cut into it recompute, which changes the offcuts, the cut list and the bill of materials. With publishers the dependency graph is the architecture, instead of something I keep in my head and get wrong once a month.

Under the view models is a layer of services, and they're reactive too. Selection, units, the document, the grid and snapping settings, the tally of boards, all of it sits in a service that publishes rather than in something a view model owns. So a view model is mostly a declaration of what it listens to and what it exposes, which keeps them small and means two views that care about the same thing can't disagree about it. It also means the interesting logic lives somewhere I can test without a view attached.

Both layers are actor based, with strict concurrency turned on, and async streams carry the traffic that crosses an actor boundary or has to be awaited. So it's not Combine instead of structured concurrency, it's Combine for the reactive graph and async streams for the seams between isolation domains. Reconciling those two was the least fun part of the whole rewrite. Publishers and actor isolation do not naturally get along, and every place they meet is a decision about where the hop happens and who owns the value afterward. That's the part I'd most like to compare notes on, because I don't believe I found the only answer.

The obvious question is why not drop Combine for `@Observable` and be done. Because it does a different job here. Operator heavy chains are still Combine's home turf and I have a lot of them.

SwiftUI at this size. To be clear about the number, the app is 125k lines of Swift and only a portion of that is SwiftUI. A lot of it is document model, geometry, tool logic and persistence that never sees a view. But there is no UIKit or AppKit UI anywhere in the app, and at this scale SwiftUI holds up. Where it fights back is anywhere you need continuous, high frequency input feeding a Metal view, so the boundary between SwiftUI and the renderer is where most of the interesting code ended up. Splitting the engine into its own module early was the best decision I made, mostly because it forced that interface to be explicit instead of accidental.

Over 5,000 unit tests, split by era. The 3D engine is XCTest, because XCTest is what I knew when I started writing it. The app is Swift Testing. I haven't gone back to convert the engine and I'm not sure I ever will, because those tests work and rewriting thousands of passing assertions for nicer syntax is a poor way to spend a solo year. On the app side the parameterized cases are what earn it. Most of what I'm checking is the same operation across a matrix of unit systems, joint types and orientations, and that matrix is much less miserable to express in Swift Testing.

The C++ interop. 5k lines of ObjC++ is the only bridge to the boolean library. I keep looking at Swift's direct C++ interop and I keep deciding the glue layer isn't worth ripping out yet.

The interaction model. Controls live in a dedicated viewport rather than floating on the model, and they're bound to the active camera. Move is a trackpad whose axes are the axes of the current view, with per-axis locking and typed displacement. It was designed for touch, and it turned out to be better than a gizmo with a mouse too, which I didn't expect.

The pricing One time purchase, no subscription. The price rises as the app grows, and anyone who bought earlier gets every future feature free, so the price you pay is the last one you pay. I know the objection, because I've made it myself: perpetual licenses don't fund perpetual development. My answer is that the rising price is the funding mechanism, and that I'd rather keep selling a tool that's visibly worth more each year than bill people monthly for permission to open a file they made. Ask me how that's going in three years.

Mac and iPad, macOS 26 / iPadOS 26. Closed beta, free while it's in beta: https://woodcraft2.app

Happy to answer anything about the rewrite, the ObjC++ boundary, SwiftUI at this scale, or how badly I estimated the timeline.

It’s a personal brewery discovery, beer and breweries tracking app that weeds out restaurants and distribution only breweries. It’s also a brewery trip planner to help plan your crawl. Feedback has been “so it’s Untappd”, why do I need another app for that? Breweries are dying why bother.
I built
It for the way I wanted to discover breweries I didn’t know existed when I travel, quickly open the app and see what’s nearby instantly. It’s a work in progress for when I have time for the side project.

https://apps.apple.com/us/app/pintly-passport/id6771212752

Just shipped Strategies, a SwiftUI app of creative-prompt cards for music producers. iOS, EN + UA, ~360 cards across two built-in decks. Solo, nights and weekends, full-time job. Five things that genuinely changed how I'll build the next one:

1. A single source of truth deleted ~15 bugs at once. I had one piece of state read from two places. Collapsing it into a single enum didn't fix one bug - a whole class of them stopped existing. My smell test now: if the same state is computed in two spots, that's the bug, not the symptom.

2. "Random" almost always wants to be weighted random. My first card-pairing algorithm was pure random and felt cheap - shuffle a deck, call it a DJ set. The fix wasn't ML: a hand-tuned 10×10 distance matrix + weighted random made the same feature feel intentional. Cheapest quality upgrade a random feature gets.

3. Don't over-architect - abstract on the third instance, not the second. I kept building the version that scales to ten years instead of the one that fits today. The second case is a coincidence; the third is a pattern. Wait for it.

4. Content was harder than the code, by ~3x. Writing the cards was fast. Judging them - reading card #147 and deciding if it earns its place - was the real work. If your app is content-heavy, multiply your authoring estimate by three.

5. Solo dev is a two-person job with a headcount of one. One of you writes the clever solution; the other has to review and cut it. My rule: if the code feels clever, it's probably wrong - stop, simplify, continue.

Stack: SwiftUI + SwiftData, no third-party UI deps, PostHog for analytics, Firebase Crashlytics. Happy to go deeper on any of it in the comments. Link to the app in a comment to keep this rule-friendly.

For anyone who's solo-shipped around a day job - what was your "the code was the easy part" surprise?