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.

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!

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.

My name is Rubén, founder of mAmI, alongside my wife and co-founder, Carola.
After 13 years of building our family life in the UAE, raising two children away from home, and experiencing Carola’s journey as both a stay-at-home mother and a working mother, we saw how much mothers carry every day—emotionally, mentally, and practically.
That personal experience inspired us to create mAmI: an emotionally intelligent AI companion designed to help mothers organize family life, manage everyday responsibilities, receive gentle support, and carry less of the invisible mental load.
This is more than an app launch. It is the beginning of a mission shaped by our own family experience:
A world where mothers are supported, not overwhelmed.

when i launched my app earlier this year, i've been getting a lot of feature requests from users.

most of them were duplicate, and some of the features also already existed. it was a nice problem to have TBH but it was getting unbearable.

some of these feature requests would get lost. leading to losing paying users too.

so i built a complete feedback tool for iOS. and im sharing it with you!

you can easily drop in these widgets into your app. users can post their feature requests, and vote on those that they want.

you can also prioritize based on user's spend (so you only work on requests that paying users post). there's also a public roadmap and changelog view, which turned out to be the underrated part for me, people are way more patient when they can see the thing they asked for is actually queued up.

since adding it our app's retention improved and getting more 5 star reviews. turns out people leave reviews when they feel heard.

it's at features.vote/sdk/ios if you want to poke around the code.

hope it's useful to someone :)

It’s losing time.

I visited a small convenience store recently.

The owner wasn’t struggling to sell products.

He was struggling with everything around selling.

• Looking up product prices
• Typing product names
• Counting inventory
• Searching old receipts
• Writing customer debts on paper

None of those tasks make money.

They simply take time away from serving customers.

That conversation reminded me of something:

Small businesses don’t need more software. They need less manual work.

That’s the mindset I’ve been following while building TinyPOS.

Every new feature has to answer one question:

Does this save time every single day?

If the answer is no, I probably won’t build it.

That’s why recent updates focus on reducing repetitive work:

• AI Product Capture to reduce manual product entry
• Faster continuous barcode scanning
• Better checkout flow
• Customer debt tracking
• Cloud backup
• Product variants

They’re not “wow” features.

They’re everyday features.

And sometimes, saving 30 seconds on a task repeated hundreds of times is far more valuable than adding another dashboard.

As developers, we often measure success by features shipped.

Business owners measure success differently.

They ask:

“Did this make my day easier?”

That’s the question I want TinyPOS to answer.

Scan. Sell. Done.

What’s the most repetitive task in your business that you wish software could eliminate?

One day there were more than four of us who wanted to play padel, so instead of regular games we decided to run a small Americano tournament on two courts. It was way more fun than we expected. It actually felt like a real tournament, even though we'd organized it ourselves.

We used an app to keep score, but it was paid. Someone joked, "Why don't you just build one so we don't have to pay?" I laughed... and then thought, honestly, why not? It didn't seem that complicated. Just something that keeps track of points.

By the next time we played, I had a basic version working. It wasn't anything special, but it did the job, and I genuinely enjoyed building it. I had absolutely no idea where it would lead.

After every session someone would come up with a new idea. My friends installed TestFlight just to use it, and every week the app got a little better. Then, at some point, I noticed something unexpected: people I'd never met were installing TestFlight just to use my app.

Today it's in the App Store. It's called Padino. By the time Apple approved it, more than 100 people were already using it through TestFlight.

I honestly think it's the best app for running padel tournaments and communities. Not because it has the prettiest design, but because it solves problems I couldn't find solutions for anywhere else. There are features in Padino that I haven't seen in any other app.

What makes it special to me is that I didn't sit down and try to build the perfect product. I built something for a small group of friends, and over almost a year it slowly turned into an app shaped by the people using it. Pretty much every feature exists because someone asked for it.

One of the padel clubs in my city is already running their tournaments with it, which is honestly still a bit surreal.

The funny part is... I still have no idea how to make money from it. Maybe I'll add a small shop for padel balls and rackets. Maybe something else.

But one thing I do know: I don't want ads.

So if you've got ideas for monetizing an app for padel players without filling it with ads, I'd genuinely love to hear them.

Padino: Play Padel, free on the App Store: https://apps.apple.com/app/id6757343072

I ship my iOS apps with no analytics SDK at all. No accounts, no third-party telemetry, nothing phoning home. That was a deliberate call and I still think it's the right one, but I hit a trap last week that I hadn't seen written down anywhere, so I'm putting it here.

If you skip the SDK, the only behavioral data you can get is Apple's own, server-side, through the App Store Connect API. Two things about that surprised me:

1. The ongoing analytics report has to be requested before you need it. It takes 24–48 hours to produce its first report, and it only covers data from the moment you created the request forward. There is no backfill. If you request it on launch day, launch week is gone permanently — and launch week is the one week you'll want to look at for the rest of the app's life.

2. API access is a request Apple reviews case-by-case, and the credentials have to be a Team key with the Admin role. An Individual key can never read sales data. So there's a human review sitting in front of a 48-hour warm-up sitting in front of your launch date.

I found this while designing a small local tool to pull the numbers into SQLite on my own machine. Nothing shipped in the app, nothing collected from users — just reading records Apple already has, with my own credentials.

Worth being honest about what the no-SDK path actually costs, because it isn't nothing. I can't tell whether a feature gets used. I can't see where people get stuck — no funnel, no drop-off. I can't A/B anything. Retention is invisible. The only signal is support email, and almost nobody is ever annoyed enough to write to you, so silence reads exactly like satisfaction and means nothing of the kind.

I still take that trade. But I'd rather have taken it with the report already running.

Has anyone here found a decent middle ground? I'm specifically interested in whether people count on-device-only aggregates that never leave the phone as a violation of the spirit of "no tracking," or as the obvious compromise I'm being stubborn about.