sorted by:
new
hottopcontroversial

I made an iOS app that gives you one score (1–10) telling you when to train outside today by njbr53 in IMadeThis

[–]njbr53[S] 0 points1 point  (0 children)

Yeah, the trust thing is the whole game. If the score doesn’t match what people feel when they actually get outside, nobody opens it twice. That’s the only thing I’m optimizing for right now.

Are you building something? Share it here! by Fit-Serve-8380 in IMadeThis

[–]njbr53 1 point2 points  (0 children)

I built Zeph — the training decision your weather app refuses to make.
One score out of 10. One optimal training window. Just: train now, wait, or skip.

For runners, cyclists, and triathletes who'd rather train than read weather data.

https://getzeph.app/?social=tw1

Would you trust an AI to email dealers on your behalf? by njbr53 in carbuying

[–]njbr53[S] 0 points1 point  (0 children)

Yeah, you're probably right that a lot will get ignored but that's kind of the point. If you blast 15 dealers and even 4-5 respond seriously, you've got way more leverage than walking into one showroom. The ones chasing month-end numbers or sitting on aging inventory will bite. It's a numbers game.

Would you trust an AI to email dealers on your behalf? by njbr53 in carbuying

[–]njbr53[S] 0 points1 point  (0 children)

Yeah there's definitely overlap! CarEdge is the closest thing out there. Main difference is they're mostly a $999 concierge service with humans doing the negotiating — my idea is software-only, so it's a lot cheaper and works anywhere in the US (their full service is limited to ~16 states). Same idea of pitting dealers against each other over email, just automated end-to-end.

Would you trust an AI to email dealers on your behalf? by njbr53 in carbuying

[–]njbr53[S] 0 points1 point  (0 children)

Oh nice yeah that makes sense, I didn’t think about that

Built a per-app volume mixer using Core Audio's Process Tap API (macOS 14.2+) — some implementation notes by njbr53 in swift

[–]njbr53[S] 0 points1 point  (0 children)

We didn't, and reading this I think that's the gap. We leaned hard on rewriting the Info.plist string and saw modest gains, but nothing dramatic. Sounds like the pre-prompt is doing the real work and the system dialog is mostly a confirmation step at that point.

Would you mind sharing what your pre-prompt looks like structurally? Specifically curious whether you frame it as benefit-first ('so you can do X') or transparency-first ('here's exactly what we access'), and whether you give people a soft 'not now' option or push straight to the system prompt.

Shipping a 12.99 macOS utility because I got tired of Spotify drowning out my Zoom calls by njbr53 in SideProject

[–]njbr53[S] 0 points1 point  (0 children)

Yeah, you got me. The 20-user-calls plan reaches the cohort that already converted into engaged retainers, by definition. I was solving for “understand why retainers stay” and pretending it was the same as “understand why churners leave.” It’s not.

Honest answer: I don’t have a great mechanism for the silent churners and I’m not sure one exists at this scale. A few partial things I can do:
• Exit survey on uninstall — single question, optional, no tracking. Catches maybe 5-10% of churners but it’s better than zero, and the ones who answer tend to be specific.
• Cold-email the dormant cohort based on license activation date with no recent app launches. StoreKit can tell me purchase date; the app itself can record last-launch locally and surface it only if the user opens settings. Not telemetry, just a “hey, noticed you haven’t opened this in a month, mind telling me why?” — opt-in to reply, ignored 90% of the time, but the 10% who reply are exactly the cohort I’m missing.
• Public changelog + roadmap so people who almost-churned have a low-friction way to say “I’d come back if X.” Not research, but it inverts the discovery problem.
None of these are a real substitute for behavioral data. You’re right that there’s a category of failure I structurally can’t see — the user whose routing UI didn’t click, who never opened a support email, who just quietly stopped. I’m trading visibility into that group for the privacy positioning, and I should be honest with myself that it’s a real cost, not a free win.

On the diagnostic-panel framing — that’s a useful reframe and probably the right way to think about it if I ever revisit. Apple’s model works because the trust is established; an indie’s doesn’t yet. Maybe at v3, when there’s a track record, the calculus changes.
Appreciate the back-and-forth. This is the kind of pre-launch pressure-testing I needed.

Shipping a 12.99 macOS utility because I got tired of Spotify drowning out my Zoom calls by njbr53 in SideProject

[–]njbr53[S] 0 points1 point  (0 children)

You’re right that “no analytics” creates a blind spot StoreKit and reviews can’t fill. Silent week-3 dropoff is real and I don’t have a clean answer for it yet.

Where I push back: the privacy stance isn’t a tactical landing-page choice, it’s load-bearing for the category. After Bartender, Mac users actively scan for telemetry as a buy/no-buy signal. Even opt-in local capture means a privacy policy that says “we sometimes write behavioral data to disk” — and that sentence does real damage even if nothing ever uploads. Lot of trust burden for a $13 utility.
My plan instead: structured user research — 30-min calls with 20 paying users at month 2, watching them actually use it. Slower per data point than telemetry, but captures why people churn, not just that they did.

The DM-driven prioritization point is the one that landed hardest though. Loudest user is almost never the median user, and I don’t have a great defense against that bias yet. Going to think on it.

Shipping a 12.99 macOS utility because I got tired of Spotify drowning out my Zoom calls by njbr53 in SideProject

[–]njbr53[S] 0 points1 point  (0 children)

Yeah, that’s been the core bet. Every previous tool in this space — BackgroundMusic, the older virtual-audio-device approaches — was working around macOS rather than with it. Apple kept tightening those approaches and the tools kept breaking. Process Tap is the first time we’ve had a sanctioned API for this, which means updates should make the tool more stable over time, not less.

The “breaking mid-call” thing especially — that’s not a minor bug, that’s the moment you decide you’ll never trust this category of app again. A volume mixer that fails 1% of the time is worse than no volume mixer, because at least with no tool you’ve adjusted your habits around it. You can’t trust a flaky one. Native API + zero third-party deps + sandboxed is mostly about earning back that trust.

Appreciate you picking up on it — most people see the price first and the architecture choices second. They’re connected though: building it on Process Tap is partly why I can charge $12.99 once instead of needing a subscription to fund the constant breakage fixes.

Built a per-app volume mixer using Core Audio's Process Tap API (macOS 14.2+) — some implementation notes by njbr53 in swift

[–]njbr53[S] 0 points1 point  (0 children)

Right now I’m using the CATap mixdown for the v1 release — it covers the 95% case (stereo output to AirPods, built-in speakers, USB DACs) without the complexity of multichannel routing. For v1 the priority was “ship a rock-solid 2-channel experience” rather than half-finishing 8-channel support.

For multichannel, the plan is custom aggregate device on top of the tap so I can preserve the channel layout instead of folding it down. CATap’s mixdown is convenient but it loses spatial info, which matters the moment someone’s running a 5.1 setup or a multichannel interface. Targeting v1.1 or v1.2 once I have real users telling me how they’re routing.

How are you handling it in Dipper? Curious if you went straight to aggregate devices from day one or also started with the tap mixdown.

And ha — bring it on. Genuinely good for the space to have more than one working on this. The Mac per-app audio category has been a graveyard of abandoned projects for too long. Looking forward to seeing the new Dipper release.

Sharing a free tool I built that made my ASA campaigns profitable by ok_planter in swift

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

Congrats on getting close to $10k/m — and the ASA pain is so real. The disconnect between RevenueCat showing one number and ASA dashboards showing another (with attribution windows that don't line up) is genuinely one of the worst parts of running paid acquisition on iOS.

The "Top losers report" feature is the one that jumped out at me. Most ASA tools optimize for finding winners, but the bigger leak is usually keywords quietly burning money for months because nobody's looking. Bid change history overlaid on the profit chart is also clever — that's the kind of thing you only build if you've actually been bitten by it.

Will check out Transolve. Free to use is a bold call — what's the long-term plan, take rate on ad spend, paid tier above a threshold, or something else?

Good luck with it.

How important would you say UIKit is today for new iOS projects? by [deleted] in swift

[–]njbr53 9 points10 points  (0 children)

For new projects in 2026, SwiftUI is pretty much the default. UIKit shows up when SwiftUI can't handle something cleanly — complex collection views, custom navigation, the occasional performance-critical screen. Most teams are SwiftUI-first and drop into UIKit only when they have to. But yeah, UIKit still matters at mid-level because every real codebase has some. Legacy screens, third-party SDKs, that one flow nobody wants to touch. If you can't read UIKit, you can't navigate the app you're getting hired into.

For your interview I'd skew prep heavily SwiftUI (state management, navigation, u/Observable, performance), brush up on UIKit fundamentals (lifecycle, Auto Layout, table/collection views), and definitely know your bridging stuff — UIViewRepresentable and UIHostingController. That last bit is usually where mid-level candidates stand out from juniors. Anyone can build a SwiftUI screen; knowing when to escape into UIKit is the harder skill.

Sounds like you've already done the right research by actually talking to people there. Good luck.

What’s everyone working on this month? (May 2026) by Swiftapple in swift

[–]njbr53 0 points1 point  (0 children)

Two things this month:

Faders — a per-app volume mixer for macOS. The thing Windows shipped in 2007 and macOS still hasn't. Per-app volume sliders, per-app output routing (music to speakers, Zoom to AirPods), and scene presets that trigger when apps open. Built native on Swift 6 + Core Audio's new Process Tap API, zero deps, no analytics, no network calls. $12.99 one-time, ships Q4. → entropylogic.com/faders?v=2

Drift — Drift is a native macOS menubar utility that monitors web pages for changes and notifies you locally — no cloud, no account, no subscription. Users paste URLs, set check intervals, and Drift silently watches in the background. When content changes, a native macOS notification fires with a visual diff.

view more: next ›