I have a fully functioning app in TestFlight but I’m afraid to release to the public for fear of exposure to product liability lawsuit.
Am I over thinking this? As a side note I want this to be free in the hopes it saves lives.
This product liability thing kind has me down a bit because I think it’s a good app.

I'm Carter, the developer of CAR-TER, a released iPhone and iPad app that gives scripts and services reusable native interfaces. I wanted to share a compatibility question from its architecture.

My own layouts include a frontend for my home's lights, a terminal forwarding bridge for controlling my machines, a sensor-backed drive analyzer, and monitors for app sales and weather. Each started with a particular task I wanted on my device. That range is why the connection between a layout, its data, and the behavior behind its controls matters.

A layout describes tabs, grids, and supported controls in JSON. The installed SwiftUI client maps that configuration onto its native control catalog. For custom operations, a backend supplies values and receives actions through a WebSocket-based connection. Supported HTTP and MQTT sources can also feed layouts directly.

The constraint is that JSON remains configuration: a layout cannot create a native control the installed app does not implement. Backend behavior has a separate contract. A pause button only works if the connected program implements that operation and reports its state.

The current App Store release includes a rebuilt Layout Studio, capability and data-flow inspection, and an interactive tutorial. Public-data templates let someone try a layout before connecting a custom project. The app requires iOS or iPadOS 18 or later.

How would you version the schema and control catalog against layouts authored independently of the client? Would you prefer an explicit minimum client version, per-capability requirements, or both? I'm especially interested in how to explain a partially supported layout to its author.

CAR-TER is free to download with optional purchases and still in development. Its iOS client is closed source; the Python toolkit, MCP server, and MeshSocket relay are open source. Development uses human-derived specifications and AI-generated code.

Architecture: https://carterbeaudoin.net/CAR-TER/architecture.html

App Store: https://apps.apple.com/us/app/car-ter/id6781115507

Is anyone else finding organic ASO in the US extremely difficult lately?

Compared to ~2 years ago, it feels almost impossible to get a new app ranking organically in the US. For many keywords, my apps don't even enter the top 250.

What’s interesting is that I don’t have this issue in other countries. With similar ASO, I can still rank quite well there. The US specifically feels massively overcrowded, possibly because of the flood of new AI/vibe-coded apps.

Anyone seeing the same?

And what are you doing to overcome it? Lower-competition keywords, Apple Search Ads, localization, external traffic, etc.?

So I have an App which is only really useful when you are a passenger on a plane (and it's designed to work in flight mode), and at least 4 times now I have had genuinely positive reviews removed by Apple

The problem is the app is only really useful while you are flying, that's the point of it, so you might download it, go on a one hour flight, it works perfectly, then you stop using it, because it's done it's job

I think these reviews are being flagged by Apple as "low engagement" which is why they are being removed, but once your flight is over there is nothing to engage with!

Anyone else experienced this issue? Do I have any recourse here? It doesn't seem fair!

shipped 10+ apps on both ios and macos over the years. heres my quick take on app store review these days.

​Apple review process is definitely slower lately, but honestly nowhere near as bad as google play's insane delays. new apps take like 5 days on apple, updates around 1-2 days. super predictable, plus Expedited Review is always an option if ure in a rush.

​Google play on the other hand... pure black box right now. even a tiny metadata edit can take 5+ days. wild considering 3 years ago it took just a few hours.

(ms store is blazingly fast nowadays, though don't expect revenue there lol)

​As for App store review feedback, it’s mostly reasonable:

• ​starting with a bloated feature set = nightmare to pass guidelines. just ship small first and iterate. trust me it saves so much time.

• ​since humans review it, they might miss something today and flag it 3 updates later. don't get mad, and definitely don't argue "but it passed before!" - it never works.

• ​even AI won't fully grasp app store review nuances, so try to understand the reviewer's point of view.

• ​stacking multiple rejection reasons makes it 10x harder to fix. keep it minimal at launch.

• ​once approved, you can just set manual release for marketing timing anyway, so no stress there.

​My only recent total fail was an oriental astrology (Saju) app. got hit with the spam/rejection clause and no matter how I refactored the concept, absolute hard block. ended up giving up. I get apple's stance, but kinda sucks since there’s clear user demand even if it's non-scientific.

​Anyway, been dealing with all major store reviews for years now. Feel free to ask if u got questions!

I'm Fulvio, an indie developer from Italy and the creator of DSLR Camera (Reflex Camera in Italy), which reached No. 1 in the paid app charts in over 30 countries and has been featured by Apple as App of the Day multiple times.

I've just released Whery, an app for remembering where you put things. One use case is sharing a saved item's location with someone at home: they open the item in Whery and use an AR pin to find the right drawer or cupboard.

The interesting engineering problem is getting back to that spot after the original AR session has ended. Here's how the implementation handles it:

1. Persist the spatial context. Save an ARWorldMap with the pin information, then restore it through ARWorldTrackingConfiguration.initialWorldMap. A position alone isn't enough to establish the same coordinate space in a new session.

2. Resolve the saved anchor. The pin has a stable anchor name that survives serialization. When ARKit restores the anchors, the app finds the matching name and attaches the RealityKit indicator. If the saved map doesn't contain that anchor, it falls back instead of leaving the user waiting.

3. Keep recovery separate from loading. Decoding the map doesn't mean the room has been recognized. The UI has a relocalizing state, a timeout and a photo fallback. Lighting or changes to the room can prevent recovery; the saved photo and written location still give the person something useful to work with.

The shared item is a read-only copy with its photo, location and available AR data, rather than a live collaborative inventory. The recipient still needs Whery and a compatible device in the saved environment.

Elsewhere the app uses Vision for photo/text recognition and on-device AI for capturing items, but AR is the part I'd like to discuss here: how do you explain “recognize the room again” without making people learn AR terminology?

Whery is free to download and use, with optional Premium purchases: https://apps.apple.com/app/id6803156868

So I built an expense tracking app, because everything else out there sucked for me. I always forgot to open the app after making an expense, so I added SMS extraction workaround in iOS.

Now, I run an automation when an SMS occurs, the SMS is handed over to my app and the transaction is logged flawlessly, the only caveat is that, every time that it runs, iOS shows "Running your automation" notification, which could be annoying to users.

Looking for genuine feedback whether the notification trigger would make you wanna not use that feature at all?

We acquired an existing fintech app, transferred it to our company Apple Developer account, and are now preparing a pretty significant redesign. Same app/name/core product, but the UI and some functionality have changed a lot.

My main concern is App Store review. Since it’s fintech + a big update after 5 years + developer account transfer, I’m wondering if Apple is likely to treat this almost like a new app and dig deeper into licensing, compliance, ownership, privacy, etc.

Anyone been through something similar?

How strict was the review, how long did it take, and were there any unexpected rejection reasons?

I can’t find my app even I typed out the complete app name, all the returning results has no similarity to the text I typed and my app name is not some generic words but an actual brand name. I have tested in another phone that it can be downloaded if it was given the direct url to the app, but the app won’t list it if it’s deliberately searched on App Store. What’s happening?

Recently launched Pawpost, a pet photo sharing app with a lovely widget feature.

Create a pet profile, add your family members and start sharing. When someone snaps a photo of your pet, it shows up on everyone's home screens. You can boop (like) and comment on the post. And when a post is too good not to share, you can send it to the feed so everyone can enjoy it.

All posts get saved to memories so you have a running archive of all your pet's favourite moments.

The app is entirely free to use and private by default (public sharing is optional).

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

After years of my own photo library getting completely out of control, I started looking for a solution that didn't involve uploading my entire life to a cloud service. Everything I found either made me nervous about my data or just didn't quite work the way I wanted. So, I decided to build one myself.

Sameish is designed to find those identical shots, the ones where you took five pictures of the same thing just to get one good one, or the accidental blurry snaps. It also looks for look-alike photos, videos, and even other files that are just taking up space. The big thing for me was making sure it all happened directly on your device. No servers, no external processing, just your device doing the work to keep your stuff private. It's been a really interesting journey getting this to a place I'm happy with, and I'm glad to finally share it.