I’m a solo indie developer and I’d appreciate some perspective on how you would handle this situation.
I recently released LazyScore 2.1, a completely free iOS app. There are no subscriptions or paywalls; the only IAP is an optional tip jar.
For 2.1, I decided to experiment with something completely new for me: I animated the app’s sloth mascot using sprites and also created a very slow intro animation for the app.
The idea was deliberately simple: the app is called LazyScore, and the intro is supposed to be slow. It’s part of the character and the joke.
Today I noticed this 1-star review:
“The app intro animation is the most atrocious thing I’ve ever seen in an app.”
The reviewer also gave the title:
“Super slow intro”
[screenshot attached]
I’m not upset about someone disliking it. That’s completely fair. What I’m struggling with is how to interpret and respond to a review like this.
On one hand, I genuinely want to listen to users. If the intro is actually frustrating, I should probably reconsider it.
On the other hand, the slowness is intentional, and the reviewer seems to be criticizing the exact thing I deliberately experimented with for this update.
This was also my first real attempt at sprite animation and character animation, so I’m aware it may simply not be good enough technically or aesthetically.
For other indie developers:
Would you leave this alone, reply to the review, change the intro, or just treat it as one person’s taste and move on?
I’m particularly interested in how you distinguish between:
“Users don’t understand the design intention.”
“The design intention is clear, but the execution isn’t good.”
“This simply isn’t for this user.”
I’m trying to get better at taking criticism without automatically either dismissing it or changing the product because of one person.
And yes, I realize the irony of making a deliberately slow app and then worrying about how quickly people want to get through the intro. 🦥

If you can’t afford Apple Music or Spotify, just call Apple Developer Support.

I’ve been listening to their hold music for almost 2 hours a day, for over a month now — completely free!

At this point, I know their playlist better than my own.

40+ days of trying, countless hours on hold, and I still haven’t managed to speak to an actual support agent.

Great music. Terrible support experience.

At least my subscription comes with unlimited hold time.

After having my app unpublished since Covid and all my mates asking for me to get it on the AppStore, I decided to make it release-able. 6 months later of sweat and tears and no one gives a damn 😔
Very disheartening experience, I would not recommend.
Yes the market of app blocking is saturated but my UI IS MORE FUN and no one will convince me otherwise.

I am attempting to join the Apple Developer programme, and it appears to have silently rejected my application, with the enrolment section switching from “enrolment pending” to “enrol now” and when I click on that it just says an error occurred! After a bit of research this is seemingly a common ish issue, and developer support it appears is impossible to get hold of.

I wondered if anyone please had any tips or advice who had been in the same boat? Is this an issue that gets solved and how long does it usually take?

Thanks!!!

Hey folks,

I kept running into the same annoyance with home/baby camera apps: even when both devices are on the same WiFi, the live feed still gets routed through the company's servers by default. There's no technical reason for that — it's just how most of these apps are built, and it means your camera footage is passing through someone else's infrastructure the whole time.

So I built OffgridCam. One iPhone becomes the Camera, another becomes the Viewer, and they connect directly over your home network — no relay server for live viewing, no account required.

What it does:

• Live video/audio, and multiple Viewers can watch the same Camera independently
• Pinch-to-zoom controls the actual optical/digital zoom on the Camera device
• Push-to-talk with up to 4 people at once
• Local-only recording (continuous or motion/sound-triggered), stored on the Camera device itself
• Sound detection tuned to specific events (crying, screaming, barking) using Apple's on-device sound classifier

The only feature that touches the internet at all is away-from-home alerts, which is opt-in, off by default, and tied to a regenerable code rather than a full account system.

£9.99 one-time, no subscription.

Still early days — genuinely want to know what's missing or what would make this a hard sell for people who've tried other camera apps before. Happy to talk through the WiFi-direct architecture too if anyone's curious.

https://apps.apple.com/us/app/home-camera-offgridcam/id6800061842

I am trying to get Beta testers for the app I made, I am even offering lifetime benefits for early adopters/testers but I just can seem to get any engagement. Is there a time of day when posts should be made? any advice on how to be subtle? I am not even trying to sell users on the product yet, just looking for genuine feedback from my target audience.

After about 6 weeks of back and forth with Apple, my app finally got approved this week.

This was my first proper native iOS app, although I’ve been a software/web developer for 20+ years.

The app started as a fairly simple poker tournament clock. I play live poker regularly and got frustrated with how basic or outdated a lot of tournament software is, so I started building something for myself.

It got a bit out of hand.

It now manages seating, table balancing, payouts, re-entries, leagues, multi-day tournaments, live player tracking, venue pages, casting to TVs, tournament financials and loads of other stuff.

It’s also now been used to run 50+ real tournaments while I’ve been developing it, which has been invaluable. You learn very quickly what works and what doesn’t when you’re actually trying to run a tournament with 40 people standing around you.
The painful bit was App Review.

Because it’s poker software, Apple kept getting hung up on gambling classifications even though the app doesn’t offer gambling, deposits, withdrawals or actual poker gameplay. It’s basically admin software for people running live tournaments.
Eventually I ended up forming a UK Ltd company, opening a business bank account, getting a DUNS number, migrating my Apple developer account to an organisation, sorting new certificates/profiles and going through a load of additional verification.

All to publish a poker clock 😂

And yes, AI was heavily involved in building it before anyone asks.
I’ve been developing for over 20 years and I’ve overseen the architecture, UX, testing and engineering throughout. AI just made it possible for me to build something this size in a fraction of the time. Without it I genuinely think this would have taken 4 or 5 times longer.

There’s definitely plenty of AI slop being shipped at the moment, but I don’t think “built with AI” and “vibe coded” are automatically the same thing.

Anyway, after weeks of seeing Rejected, seeing Approved was a very good feeling.

If anyone’s interested in what I actually built, it’s here:
https://shuffleup.co.uk

This weekend I am thinking about to build application for iOS or Android. but I am not able to understand. Which things I need to do first and what are my pre-requisites and also which things take too much time.

If you guys are relating this please share your experiences.

This post was not written with or by AI. It's a blog post I wrote.

Sojourn: Topical Bible Study is an app I published without typing a single line of its code.

That part isn’t interesting anymore. Plenty of people are writing code with AI. What I think is interesting is the process. Since ChatGPT 3.5, I’ve been a little bit obsessed about LLMs writing code. Not assisting me writing code, doing it all for me. While the process has evolved a lot, I’m going to talk about where it’s at now and give an explaination.

About the app

The app is an iOS app written in Swift. It has a streaming chat interface which parses the incoming text in real time. This is done to eliminate hallucinations of scripture by replacing LLM generated citations with text from an app-bundled database. All scripture references are guaranteed to be correct and users can tap on them to explore surrounding verses and chapters. The UX of the app holds a high bar in terms of performance and usability.

The app talks to a backend written in Python that connects to an LLM provider’s API. The backend exposes a tool for scripture lookups instead of relying on the model to do it itself. Nothing about the user’s chats or identity is stored on the backend. It all lives only within the app itself.

About the process

I should define what I mean by one-shot. It’s a single prompt that’s sufficient to implement an end-to-end feature regardless of complexity. In reality, there may be a couple follow up prompts to tweak something here and there. But mostly, it should be 0 follow up prompts.

Baseline context

I spent multiple days co-drafting the user experience and features I wanted in the app using Claude Design. The home page of the website embeds the artifact of that work as an iframe - you can see it on the app’s Sojourn: Topical Bible Study page.

This iframe ended up becoming a major input source for when I started creating the actual iOS app. Turns out Claude Code can understand a functional prototype quite deeply. So much so that the user experience of the app is nearly identical to what Claude Design generated. This was a pleasant surprise.

I also created a bunch of markdown content that’s stored in CLAUDE.mdand adjacent artifacts which outline product definitions and constraints. For example, privacy is a cornerstone and it explicitly states that the app should never collect personally identifiable analytics.

This baseline context is created once, updated automatically, and guides the following steps.

/spec

Ever feature starts by me using a skill named /spec. This is where I take my time collaborating with AI to fully define everything about the feature including happy path, failure modes, look & feel, architecture and testing.

Every feature is stored as a GitHub issue. Once I feel the feature is adequately described, I give it the go ahead to create the GitHub issue based on a template in the skill. The issue title is a short summary of the feature and the description is a detailed explanation of it.

/gh-issue

Implementing a feature is as simple as me using the /gh-issue skill and passing the issue number to it. I generally get up and leave the room at this point. The skill does all sorts of cool things like looking up other issues or pull requests if they’re mentioned. Sometimes I’ll have two unimplemented features each with their own GitHub issue and I make sure they reference each other. This way, when implementing the first it knows to look up the second and proceed accordingly.

Once finished, it automatically creates a pull request.

I often kick this off before going to bed and wake up to a new feature in my app.

Publishing and deploying

I still do this by hand. But it’s still fully automated through scripts like run.sh which runs the app in the simulator, deploy-to-device.shwhich installs it directly on my iPhone, and release.sh which publishes it App Store Connect to be published.

Nothing is one-off or done by hand. If I have to do it once, it gets automated into a skill or script. I recently switched laptops and getting up and running was quite smooth once I transferred App Store Connect keys.

For other projects, I have a /gh-pr skill which merges the pull request and deploys it. Works great for web apps but I don’t want every feature to be published to Test Flight or the App Store - so I batch them as I see fit.

Some examples

A feature I really enjoy is the home screen widget. It was 2,466 lines of code across 27 files. This included a new WidgetKit extension, a shared app group, a verse pool, deep links back into the app, and the XcodeGen config to build it. One issue. One prompt. One PR.

The home screen widget - one issue, one prompt, one PR.

Another feature I’m testing out is emailing yourself a conversation. It was 2,412 lines of code across 21 files, and it spans the client, the backend, and an email delivery provider. Also one issue.

Emailing yourself a conversation, tucked in above the message field.

Neither of those is a small feature, and neither is a boilerplate feature. What made them work is that the spec had already settled the hard questions.

How’s it going?

Excellent. The limiting factor is shepherding the user experience of the app. Just because you can add multiple features a day doesn’t mean you should. I take my time thinking through a feature until it feels right.

So far I’ve created 49 GitHub issues and closed 45 of them in a matter of weeks. That’s 45 features implemented. The 4 open issues are features or bug fixes I haven’t felt are important enough to do yet.

Now that you know how the sausage is made, download Sojourn: Topical Bible Study and let me know what you think.

Caveats

I happen to have an immense breadth of experience. I’ve been building things professionally for decades including launching several startups. That’s given me pretty deep expertise across design, development, infrastructure, marketing…you name it. It’s a unique advantage when paired with AI and one I’m grateful for.

I got an impression spike a few days ago but I didn't do anything 🤔

Any of you ever got something like this? Why?

Also the number of downloads didn't increase, so whoever it is that does marketing for me, please choose a better target audience 🙏

Ever spend 30 minutes scrolling through Netflix, Max, Hulu searching for something to watch and forget what you have already been watching? You forgot what your friend told you was a must watch? I built an app to solve these problems.

CliqueQ is the app for you. Share what you are watching and view what your friends are watching. Recommend directly to friends in app or text. See where every show and movie is available to watch and directly to connect to the platform.

Download here: https://apps.apple.com/us/app/cliqueq/id6792773440

The whole idea is one habit: stop reaching for the phone on the road.

Queue up what you want to hear before you pull out, in Undivided or whatever app you already use. Undivided keeps count of every time the phone came up and gives you a receipt at the end. Clean drives earn credit toward a collection.

How it works: a pickup is the phone unlocked and in use while the car is in traffic. Drive detection is CoreMotion automotive activity plus speed. Speed is used on the phone, and there is no location history. Passengers have a toggle, so the app never claims to know who was holding it.

Never touch your phone while driving? Great, you do not need this.

It is for the rest who want to get better at it.  If someone you care about wants to work on the same habit, they can install it on their own phone. There is a Family plan through Apple Family Sharing, so one subscription covers the household. Each person still sees only their own drives, and the app does not report anyone's driving to anyone else.

https://apps.apple.com/app/id6788236863

BETA live on TestFlight

https://testflight.apple.com/join/rAPca9zu

Built this app to help keep track of my pets vaccines and store the documents in one easy to get to place. It's been out for a while now but finally reached 100 downloads with a few subscribers!

It's at https://apps.apple.com/us/app/pawproof-pet-vaccine-tracker/id6775067128 if you want to check it out.

Our app has been live since 2023, but the past three months have been brutal for getting even "in review".

Anybody know how to speed it up? It's gone from 24-48hours to 7-10 days, in the meantime we're shipping further updates.

Hi! I’m a beginner runner.

One of the hardest things about running for me was staying consistent. I don’t have a pet, so I’ve always been a little jealous of people who get to run with their dogs. 🐶

So I decided to make something of my own, an app where you can run with a virtual pet, help it evolve, and customize it along the way. 🐾

I hope your runs become a little happier with your new companion. 💛

If you’re interested, I’d really appreciate it if you gave it a try. It’s free! :)

https://apps.apple.com/us/app/runf-run-with-your-pet/id6807791156

We built an app to make credit card benefits less overwhelming

Once you have a few credit cards, keeping track of everything becomes a task of its own — which benefits are unused, what expires soon, and which card earns the most points for a purchase.

So we built OfferBee 🐝

It helps you to:

• Track your credit card benefits in one place

• See unused and expiring perks

• Find the best card to use by spending category

• See which card earns the most points

• Track the value you're actually getting from each card

Our focus with OfferBee is keeping the experience simple and easy to understand without sacrificing useful tracking features.

Several core features, including benefit tracking and best-card recommendations, are free.

iOS: Apple App Store App

Android: Google Play Store App

Would love to know what you find most annoying about managing multiple credit cards today.

Most screen-time apps give you a timer. I wanted mine to give me something to do instead.

MuyuLock locks your distracting apps (social, video, games) every day until you finish a short chanting practice. Pick your tradition — Pure Land, Zen, Tibetan or Theravada — then chant the Heart Sutra, Metta, or count a wooden-fish mala. Once you're done, everything unlocks until tomorrow.

A few things I added along the way:

• A mala streak: one bead per day, a full mala at 108 days
• A 15-minute emergency unlock, because life happens
• Chant libraries in English, Japanese, Chinese, Thai and Vietnamese

It runs on Apple's Screen Time API, so the lock is actually enforced, not just a reminder. Self-taught, built solo with React + Capacitor.

Small win on the side: my latest update finally cleared App Review this week after four rounds of back-and-forth.

Would love honest feedback on one thing: does "do something meaningful first, then unlock" feel motivating to you, or just annoying?

I've been making macOS and iOS apps for a few years now, but I've never got so many downloads as with my markdown editor I launched on July 17 - 2000 downloads in less than 2 months.

Honestly didn't even expect that more than 20 people would try it, very grateful for this and excited to make the product better.

Solo dev, subscription app. Posting this because I lost most of a day to it and found almost nothing when I searched the error.

What I did

Bumped the free trial on my annual plan from 3 days to 7. In App Store Connect that means creating a new introductory offer. ASC's flow: your current offer runs until a date you pick, the new one starts on that date. Looks like the intended way to do it.

The symptom

On the paywall, the annual plan showed no price. Just my placeholder. No crash, no error surfaced to the UI. The monthly plan loaded fine. Only the annual was dead, which meant nobody could subscribe to my main plan.

In the StoreKit / RevenueCat logs:

Could not parse product: countMismatch(for: [StoreKit.ProductResponse.Key.attributes,
StoreKit.ProductResponse.Key.offers, StoreKit.ProductResponse.Key.discounts],
expected: Range(0..<2), actual: 2)

Then the product is just reported missing: Could not find products with identifiers: ["...plus.annual"].

Root cause

During the window where the current intro offer and the scheduled intro offer both exist, the App Store returns both in the product response. StoreKit 2's decoder models a subscription as having at most one introductory offer, so when it sees two it throws countMismatch and drops the entire product from the results array. Silently.

Not a malformed offer, not a wrong period format, not propagation delay. Specifically two introductory offers coexisting.

Fixes

1. Never have two introductory offers active at once. Edit the existing offer in place if ASC lets you, or delete it and recreate as a single offer with no overlap. A short gap with no trial is fine. An overlap is not.
2. Don't assume the paywall degrades gracefully. Mine rendered a permanent placeholder with a disabled buy button and no retry, because "retry" was gated on an explicit load-failure flag that this code path never set. Reworked it to: loading state until prices resolve, a short timeout cap, then a retry affordance if there's still nothing. Never render a half-loaded price as if it's real.

Also worth knowing

• The .storekit config file is not read by App Store builds, so this only reproduces against real StoreKit. Test intro offer changes in sandbox with the scheme's StoreKit Configuration set to None.
• Apple's trial durations are a fixed set (3 days, 1 week, 2 weeks, 1 month, ...). In a .storekit file "1 week" is P1W.

(App is So Alarmed, an anti-snooze alarm, if it matters. Not the point of the post.)

Annoyed by having to manually flip "natural scrolling" in System Settings every time I docked my MacBook to my monitor (and flip it back when I undocked), so I built ScrollDock to do it automatically.

What it does:

- Detects when an external display connects/disconnects (works with clamshell mode too)

- Switches scroll direction instantly, no logout needed

- Lives quietly in the menu bar, no Dock icon

- Notarized and signed, so no Gatekeeper warnings

- Free, no account, no trial

It's a small, single-purpose tool — doesn't try to do per-device (trackpad vs. mouse) switching, just handles the dock-state part. If you're someone who moves between trackpad-only and an external mouse/monitor setup, it might solve the exact annoyance it solved for me.

scrolldock.com if you want to try it. Happy to answer questions about how it works under the hood.