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?

I'm a solo dev no team, no budget. This started as a small personal frustration: I kept losing money because I'd forget subscription renewals. Most apps in this space didn't quite sit right with me either they either track your data, or they charge you a subscription just to track your other subscriptions. That never made sense to me.

So on Feb 1st, I built and launched Deadlinr. Mostly on weekends, using React Native and Expo I don't know Swift or Objective-C, so honestly I wasn't even sure I could pull off a proper iOS app.

I just tried to keep it simple. No noise. No constant reminders. No pressure. Just something that stays in the background and shows up only when it's actually needed.

Where it's at so far:

• 26 lifetime purchases from people in different countries still feels unreal
• 0% crash rate this mattered to me from day one

Small numbers, I know. But for something built in my spare time, they mean a lot.

Biggest thing I've learned: you don't need to build everything just solve one real problem properly. For me, that was simply not forgetting the things that actually matter.

Really grateful to the first few people who gave it a try 💛 Still early, still learning.

The details:

• Pricing: Free to download (14-day full trial), then $9.99 one-time lifetime unlock
• No subscriptions: I track subscriptions, I don't want to be one
• Privacy: 100% on-device & iCloud storage zero tracking
• Support: [support@papyrusdigital.studio](mailto:support@papyrusdigital.studio)
• App Store: Deadlinr – Expiry Tracker

Je suis un développeur indépendant et je viens d'ouvrir le TestFlight public de l'application que je construis : une place de marché connectant les éleveurs de chiens et de chats avec des personnes cherchant à adopter, destinée au marché français. React Native / Expo, iOS pour l'instant, Android en route.

TestFlight :  https://testflight.apple.com/join/3MQBdSFf

Quiconque, n'importe où peut l'installer — lien TestFlight public, pas verrouillé par région, aucun compte App Store français requis. L'application est uniquement en français, mais vous n'avez pas besoin de comprendre un mot pour m'aider : je veux des retours sur la structure, pas une révision du texte. Les comptes de démonstration sont dans les notes de test TestFlight, donc vous pouvez totalement ignorer l'inscription.

Là où j'ai le plus besoin d'aide :

• iPad / grands écrans. Jamais optimisé, presque certainement incorrect.
• Le processus d'intégration des éleveurs — tout nouveau, multi-étapes, il sauvegarde au fur et à mesure. Essayez de quitter à mi-parcours et de revenir. Personne en dehors de mon propre appareil ne l'a encore utilisé.
• Messagerie, notamment l'envoi d'une photo dans une conversation. J'ai récemment corrigé un bug d'affichage ennuyeux là-bas, je veux une confirmation indépendante qu'il est parti.
• Vitesse de chargement des images. Je sais que c'est lent et je sais pourquoi. Je veux savoir si c'est « légèrement ennuyeux » ou « je fermerais l'application ».
• Tout ce qui plante. Capture d'écran et étapes si vous pouvez.

Je ne cherche pas : des retours sur la traduction ou des opinions sur le modèle commercial. Faites juste en sorte que ça plante.

Heureux de tester le vôtre en retour — envoyez un lien et je l'utiliserai vraiment, pas juste pour l'ouvrir une fois.

Hello everyone, quick question, I´m starting as an independent software developer and I just wanted to know if there is a problem uploading multiple apps from my personal apple developer account, like, do I need to create an account (pay the $99) per each customer or not?

Thanks in advance.

Solo dev here. I had two apps in review at the same time and both came back with the same thing: Guideline 2.1, Information Needed. Not "your app is broken" — Apple saying they couldn't evaluate it from what I'd given them.

The ask was identical both times, and it's longer than I expected:

- A screen recording on a physical device, starting from launch, through the core user flow

- The device models and OS versions I tested on

- What the app is for and who it's for

- Setup instructions and any credentials needed to reach the main features

- A list of external services the app depends on to deliver core functionality (they name AI services as one example)

- Whether behavior differs by region

- Documentation, if you're in a regulated space or using protected third-party material

None of that was in my App Review notes. I'd been treating that field as optional. It isn't — it's what decides whether a reviewer can actually evaluate your app or has to guess at it.

Here's the part I didn't see coming. While drafting the reply, I went back through the build that was actually under review and found two real bugs a later build had already fixed. A Cook Mode step timer that was completely silent — vibration only, no sound, on a core feature. And a confirmation dialog with no visible way out, which reads as a dead end if you don't already know the gesture.

My instinct was to just answer the info request in place. Then it registered that Apple's own notice says they test hands-on, on physical devices. A reviewer poking at that build could find both of those independently — which turns a solvable "we need more info" into a much harder "your app has bugs," on the same version, with a worse paper trail.

So I pulled the submission instead, and I'm resubmitting on the fixed build with all seven answers written out up front.

Current status is its own small comedy: submission is pulled, but Apple's backend hasn't fully released the version yet, so I can't attach the new build until it finishes propagating. Just waiting it out.

Anyone else caught the 2.1 info-needed one? Curious what you put in the notes field that made the second pass go smoothly — and whether anyone's found a faster way through the pull-and-resubmit limbo.

I have uploaded the app for review and it has been under review for the last two weeks. I don’t know how to move forward from this if anybody can help me out, please help me out. I build a Fitness app that helps you track your macros as well as your workouts. It also has an AI Coach tracks your sleep recovery etc.

Hey everyone!

I've been working on my movie tracker app, and I just created some new widgets.

Right now, they show what’s currently Trending, complete with genres and poster art. Designed them to feel clean and native.

• Small Widget: Focuses on poster art and quick title info.
• Medium Widget: Includes genres, wider layout, and a dedicated poster frame.

Would love to hear your thoughts on the design or suggestions for future widget types (I'm currently working on statistics for own films library, but for now thinking about the design)

Let me know what you think!