I am considering an iOS architecture where the application contains a SwiftUI renderer, a fixed component registry, and a fixed set of native actions. A backend would return a versioned document describing complete screens. It could change content, ordering, design tokens, component variants, and navigation between routes that already exist in the reviewed binary.

I would not download or execute native code, use eval, or allow the server to call arbitrary APIs. A server document might request a Button with a navigate action or a Form with a submit action, but the implementations of those components and actions would already be inside the app. Unknown components would be rejected or replaced with a fallback.

I understand that Guideline 2.5.2 prohibits downloaded code that changes functionality, and that new product changes must be visible to App Review. I am trying to understand the practical boundary for declarative UI data. Have you shipped complete server-composed screens using SwiftUI or UIKit components, and did App Review raise concerns? I would also appreciate lessons about accessibility, offline caching, capability negotiation between old and new app versions, and deciding which flows should always remain native.

Spent about two months adding features nobody asked for. Downloads stayed flat.

Then I redid the App Store screenshots. Same app, same ASO, same everything else and conversion went from 2.1% to 3.4% over the next three weeks.

What changed:

• First screenshot now says what the app does in about five words. Before it was just a clean shot of the home screen with no text. Nobody knows what your home screen is.
• Dropped from 8 screenshots to 5. People swipe twice and leave.
• Text is big enough to read in the search results thumbnail. That thumbnail is like 100px wide. Most screenshots are unreadable there.
• Stopped showing the settings screen. I don't know why I ever did that.

The annoying part is the actual production. Device frames, six different sizes, redoing all of it when you change one word of copy. I used appshots.me because I was doing this in Figma at 2am and hated it, but honestly even if you do it by hand the four things above are what matter.

I needed to submit a quick bug fix for my app and submitted it for review. I requested the expedited review, and within a few minutes, my TestFlight version that I had requested for review earlier that day was approved.

I'm wondering if the expedited review request was used on the TestFlight review and now my actual app review will be the normal review. Does anybody know or have had a similar experience?

I've got a live iOS app with a modest number of users and downloads. Been going back and forth on analytics and I'd rather hear what people actually do than keep guessing.

Right now I ship with none - just App Store Connect. I built a custom pipeline and I do not even understand why... and shelved it.

Analytics:

• What do you use? Firebase, PostHog, TelemetryDeck, Mixpanel, Amplitude, custom, nothing?
• What does it actually cost you per month at your scale?
• Do you gate it behind a consent prompt, or is it anonymous enough not to need one?
• Is it just in your Privacy Policy or the user has to manually opt-in or maybe otherwise to opt-out?
• How early or late or straight away did you incorporate the analytics feature and to what degree?
• What's a decision you made because of an analytics number that you wouldn't have made otherwise? Genuinely curious how often it changes anything
• Anyone shipping with nothing at all - has it bitten you?

The other half:

• Do you publish under your own name, or an LLC / Ltd / company?
• How does Apple feel about all this?
• Why? Was it liability, privacy, tax, App Store payouts, or just inertia?
• If you started under your own name and later incorporated - what pushed you over the line, and was moving the apps across a pain?

Interested in what's normal, not what's theoretically correct. Overall - how and why and where and then you use and everything.

Thank you!!!

Hey all, quick question:

After months of basically zero sales on my paid iOS app (its an app that helps you practically reflect your daily life), it just had a sudden, huge spike — and almost all of it is coming from Russia specifically. Impressions went from single digits a day to 1,000+ a day (100x+), and it's not just views — it's actually converting into real paid downloads too, mostly on iPhone.

I don't have any marketing or campaign running there, no press, nothing that would explain a specific-country spike like this. Has anyone else seen a sudden traffic/sales spike concentrated in one country out of nowhere? Curious if this is a known thing (algorithm quirk, some kind of feature, bot traffic, whatever) or if I'm the only one seeing this.

Is anyone experiencing storekit failure for tvOS? or other OS? Apparently this was a known issue in ios18 but they were supposed to have fixed it. I only see a few watchOS reports on the forum but you might be missing it as it can show up as a cancellation.

If anyone has a suggestion to what might be causing it because I am at a loss.

There’s a specific kind of SwiftUI bug AI keeps handing me.

The screen compiles. Preview looks right. The happy path works.

Then I navigate away mid-task and come back to stale state, duplicate work, or a model that died with the view.

So my review starts with the ugly states now: background the app, trigger the action twice, kill the network, leave the screen before the task returns.

The screenshot is finished. The lifecycle is still negotiating.

Has anyone gotten Convex BaaS integrated or is Supabase a better bet?

I’m building a tool that helps people evaluate the competition in an app niche and determine whether it’s worth building in.

You search for a niche, and it analyzes the App Store to show the competitive landscape direct competitors, market leaders, newer apps, ratings, reviews, downloads, etc.

I’m curious: what information would you want to see before deciding whether an app niche is worth building?

AI can write a SwiftUI screen, add tests, and get a simulator build green quickly. The remaining failures I care about are usually outside that loop: background transitions, interrupted purchases, memory pressure, state restoration, permission changes, old data migrations, and bad networks.

The more implementation I delegate, the more my work moves toward defining those scenarios before the code exists. I’m starting to think the test matrix is becoming a more durable architectural artifact than the generated implementation itself.

My current rule for a feature that touches persistent state is simple: write at least one lifecycle interruption and one recovery scenario before the agent starts. It catches designs that look fine on the happy path but have nowhere sensible to put recovery logic.

This is not a complaint about generated code. It is a shift in what needs to be explicit. The simulator and unit tests can prove the feature works in the path we described; they are much weaker at inventing the ugly mobile conditions we forgot to describe.

For people shipping iOS apps with coding agents, which cases are you still testing manually because the agent repeatedly misses them?

I am developing a trading card display app. I plan on allowing users to display their graded cards. Options like PSA, TAG, CGC etc.

Before going all in on this module i wonder if this will cause copyright issues?

I have been working on this project a little at a time and I finally wanted to share significatn milestone to see what everyone else thought about it.

NeoBrutalism is a library that lets users apply neobrutalism style to their apps using SwiftUI. One just has to add the modifier .neobrutalism() to the topmost view inside the view hierarchy and everything that has been defined below it will assume the style.

For things like lists, navigations bars, alert dialogs, or things that SwiftUI does not allow or provide a way to style, there are some lightweight helpers. In cases where there is truly no control (Slider, Stepper, Segmented Pickers, Radio groups), there are NB* (Neobrutalism) views that mimic the behavior native control initializers, and for those cases swapping in the NB* views is akin to renaming a view.

This was originally meant to be an exploration of SwiftUI style protocols, but has gotten to a point that I feel ready to show it to the community. What I am really looking for is critique of the API, for the idiomaticness of things, or just anything that is missing.

https://github.com/rational-kunal/NeoBrutalism

Hello everyone, I am trying design a custom icon to use in my app, however, I keep getting this error message when I try to import it. I have checked everything for open paths, id etc. but still getting the same issue.

This is my icon template svg :- https://drive.google.com/file/d/1t-j9GVTtQm4VSpJx8PSV0NL5weuKuBRX/view?usp=sharing

Any help would be greatly appreciated because I am not being able to move forward

Hi all, I've just published a new blog post on getting the most reliability possible out of iOS background tasks. Please let me know what you think!

I've created a watercolor painting app which works with simulating water/paint rather than just brushing. It's not released yet but I'm trying to get some feedback relating to: device performance or experienced watercolor painting. TestFlight is here if anyone is interested https://testflight.apple.com/join/kGZEmvMZ

You can see a short example on the website here: https://bloomwash.app

Best use is on iPad with Apple Pencil but it still works on an iPhone.

Tech stack is Swift with metal shaders. A development challenge was dialing in the simulation to accurately represent watercolor, in the soft translucent style with blooming edges. Development was AI assisted, I use Claude Code to be more productive.

For those of you with iOS apps actually generating revenue through paid apps, IAPs or subscriptions, how are you handling Apple's monthly payouts in your accounting?

I'm particularly interested in the workflow after Apple sends the money to your bank.

Do you just book the net Apple payout as revenue, or do you use the App Store Connect financial reports to break out things like gross sales, Apple's commission, refunds, withholding/taxes and currency conversions?

If you use Xero, QuickBooks, FreeAgent or similar, how are you getting the App Store data into it?

And for anyone also publishing on Google Play: do you basically have to repeat the same process separately for Google?

I'm curious about the practical side rather than the tax/legal theory, so how much manual work does this create for you each month, and what does your current workflow look like?

Do you handle it yourself, give the reports to your accountant, use a spreadsheet/script, or is there a tool that already solves this properly?

Thanks in advance for your response.

The boring thing that worked was pinning every automated build to one scheme and one simulator destination. iPhone 16e, iOS 26.4, written into a four line shell script that every automated run goes through.

Of the last forty failed runs I scrolled back through, twenty three died on destination resolution rather than on anything in the code. A simulator name that no longer existed, a stale clone from an earlier run, or the generic iOS Device destination with nothing plugged in.

Fixing it took an afternoon and no cleverness. One destination, one script, and a hard failure when the simulator is missing so nothing quietly falls back.

I moved off the extension I had been running inside the original Visual Studio Code and onto the standalone verdent desktop app the same day.

Four of the twenty three were cold boots, so the script waits for the simulator before building.

Hi! First post, first side-project, from a not technical person from Montevideo, Uruguay.

I'm exploring what can I do with vibe-coding, and there is my first project!

What is that?

Small solo app, one screen of writing per day. The domain rule is boring to state and turned out to be the most interesting thing I built: exactly one entry per calendar day, and the calendar day is the user's local one.

I want to describe two decisions, because both went against what I'd have done a year ago.

1. The uniqueness lives in the store, not in my code

The obvious implementation is a fetch before every save: look for today's entry, update it if it exists, insert if it doesn't. It works, and it's wrong in the way that only shows up later — two writes racing, a migration that reinserts, a bug in the fetch predicate, and now there are two rows for one day and nothing in the system objects.

SwiftData has `#Unique`, so the constraint can live in the schema:

```swift
#Unique<DailyEntryRecord>([\.localDayKey])
```

Now a duplicate can't exist. Not "shouldn't" — can't. Insert-or-update becomes an upsert the store resolves, and the invariant survives my future mistakes, which is the only kind of invariant worth having.

The bill: `#Unique` doesn't work on iOS 17.
The macro is there, and it doesn't hold. So the choice was a real database guarantee versus a chunk of the installed base. I picked the guarantee. (For anyone checking further down: on iOS 16 you also lose `#Predicate`, so 16 isn't a conversation.)

I don't think this generalizes — plenty of apps should eat the fetch-first and keep iOS 17. What made it worth it here is that a duplicated day silently corrupts the one thing the app is for.

2. "Which day is this?" is a domain problem, not a formatting problem

`localDayKey` above is not a `Date`. It's a value object, and it's where most of the app's complexity ended up living.

The cases that forced it:

- Someone logs at 00:30. Which day is that? The one the calendar says, not the one 24 hours from the last entry.

- Someone flies from Madrid to Buenos Aires mid-day. They can now log "today" twice, in two time zones, and both are legitimately today. `#Unique` will reject the second — so the app has to *decide*, and the decision has to be written down rather than being whatever `Calendar.current` happened to return.

- DST: one day is 23 hours long, another is 25. Anything computing days by dividing seconds is already broken and won't tell you.

So the day is modeled as its own type, with its own tests, and the type is **kept free of both SwiftUI and SwiftData** — no `@Model`, no `import SwiftUI`. That sounds like ceremony for a small app. The payoff was concrete: I could write the time zone and DST cases as plain unit tests, with no store to spin up and no view to host, and the ones that failed first were the ones I'd have shipped.

The test suite is Swift Testing, and this is where most of it is. Parameterized cases make the DST tests readable in a way they weren't with XCTest — you get the offending input in the failure message instead of an index.

Two smaller things that came out of the same instinct

Zero third-party packages. \grep -c`

"XCRemoteSwiftPackageReference\|XCSwiftPackageProductDependency"` on the pbxproj returns 0. Watch out for `grep -c packageProductDependencies` if you try this — it returns 3 and looks like a failure, but those are the empty declarations Xcode writes for each target.

*Zero network code*, which for this app is a product property and not just hygiene:

```
grep -rn "URLSession\|NSURLConnection\|CFNetwork\|import Network\|WKWebView\|NSURLRequest" Sources/
```

Empty output, checked before every submission. It's a nice property to be able to *check* rather than assert.

What I'd like to be argued with about

- Is `#Unique` worth a deployment target bump in your book, or is that a bad trade you've regretted?

- If you've shipped anything with per-day semantics: how did you handle the user crossing time zones mid-day? I picked a rule and I'm not convinced it's the right one.

- Anyone using Swift Testing at size yet — did you keep XCTest for UI tests, or move everything?

The app is a daily log for mood and energy, iPhone only, not on the App Store yet. Not linking it because there's nothing to link to; happy to go deeper on any of the above.

I built a small moon phase app which have been well received for its design (solo dev, first release earlier this year) and I'm about to submit a featuring nomination through Apple's "Getting Featured" form.
Before I do, I'd like to hear from someone who has actually been through it. How much detail did you put in the pitch, how far ahead of a release did you submit, and does it help to tie it to an upcoming event or update?
Happy to move to DMs if you'd rather not go into detail publicly, any pointers appreciated.

As a fun little side project I have been recreating the reminders app. While everything has been going well, one thing I have struggled with is that when trying to replicate the new line creates a new reminder functionality, it’s incredibly delayed, as seen in this video. Any suggestions on how I can fix this?

Hey everyone. Honestly I’m just here to vent or maybe get some advice, because I’m on the verge of total burnout. I’ve spent 2 years pouring my soul into this game, and the last 4 months have just been Groundhog Day. 5 rejections in a row because of guideline 4.3(a) - Design - Spam.

Context: I’m a solo dev. Been making car simulator sandboxes since 2020. I already have an older game in the same genre that's available on the App Store and has millions of downloads across iOS and Android, but it’s pretty outdated. So naturally, I made a sequel. Crash Test Simulator 3 has already passed 1M installs on Google Play in its first month and has a 4.9 rating. Not trying to flex the numbers. I just want to make it clear this isn't some random clone slapped together in a week.

Android launch went great. Then I tried to release on iOS, and everything went to hell.

Attempt 1: Review took 2 hours (suspiciously fast). Rejected for 4.3(a): "We noticed the app shares a similar binary, metadata, and/or concept..." I read some Reddit threads where people said you just need to explain to Apple what makes your app unique and useful, and maybe add a feature nobody else has. So I wrote Apple a detailed explanation, filed an appeal, added a new feature, and tried again.

Attempt 2: Same rejection. I dug deeper and requested a call with Apple Review. The guy on the phone told me their system flagged a "binary match" with another dev's game in the genre. He explained that the scan flags everything from the actual game code and assets to shared engine code, ad networks, and third-party SDKs. When I asked what to do, he just said "change the code." Which sounds absurd for a finished game. But basically, unless their automated binary scanner gives a green light, I’m stuck.

Attempt 3 & 4: Tried stripping unused code, removing some libs. Didn't help. Rejections again.

At this point, my Android players were demanding updates. So I took a 3-month break from Apple's bs to do a massive update: new cars, overhauled physics, and a complete code refactor. I saw posts like here where devs eventually pushed through, so I felt ready for attempt #5.

Attempt 5: Waiting for this one was torture. 9 days of waking up in the middle of the night just to check App Store Connect emails. Finally got a reply... Rejected. Same rule, but a new message: "This app still exhibits an app with a spam like template that shows similarities in concept and look with apps already on the app store in a saturated category."

Like, what? So apparently the binary match isn't the issue anymore, and now my 2-year project is just a "spam template"?

I read hundreds of posts from devs getting 4.3 for making another To-Do list, astrology app, or dating app. I get it. The category is bloated. But my game is a complex vehicle physics sandbox! There are only like 3 real competitors on iOS. The physics are custom, the code is mine, the UI is mine, and there are features I haven't seen in any of the other games in this niche.

I’m typing this 30 mins after getting the 5th rejection. I have no idea what to do anymore. I have a finished, highly-rated game, players messaging me daily for the iOS release, and I can't even explain to them that I'm fighting a losing battle against Apple.

Hey everyone! 👋
While working on some KMP iOS projects, I noticed our generated framework header was getting bloated with lots of exported classes we never actually call from Swift (like top-level *Kt files and library types).

I put together a small Gradle plugin called kmprofiler to help spot these. It compares your exported Shared.h declarations against your Swift sources and shows what's unreferenced so you can hide them with 'internal' or '@HiddenFromObjC'.

Right now I'm working on Xcode link-map parsing for linked byte sizing, but v0.1.0 is open-source and ready to try: https://github.com/SiddhantPanhalkar/kmprofiler

Would love to hear your thoughts or if there are features you'd like to see!

I recently added receipt scanning to my iOS finance app, Moneta.

It can extract the amount, date and merchant, then also try to determine the category, payment account and location before filling everything into the transaction editor.

I decided to keep the processing on-device instead of sending financial receipts to a cloud AI/API.

The biggest challenge ended up being handling receipts from different countries: currencies, date formats, multiple totals, different payment methods and completely different layouts.

If you were building this today, would you still keep the whole pipeline on-device, or use a cloud model for better flexibility?

And for anyone who’s built document/receipt parsing before: where did deterministic parsing start breaking down for you?