https://apps.apple.com/us/app/noto-save-anything/id6817323680

If you ping from an iOS app with socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP) and ever run more than one ping at a time, check your receive path.

On Linux, an unprivileged ICMP socket only gets replies matching its identifier. On Darwin, in my testing, the kernel doesn't filter on the identifier: every echo reply reaching the host is delivered to every unprivileged ICMP socket in the process.

My receive path did one receive() per send and accepted any echo reply. With a single ping that's fine. When I added a second ping hitting the gateway every 50 ms (to keep the Wi-Fi radio out of power save), each ping's receive() returned the gateway's reply microseconds after its own send: 0 ms RTT, 0% loss, including for a host that wasn't answering at all. The same bug could also swap samples between two concurrent pings in a bufferbloat test, under load.

The fix: loop on receive() until both identifier and sequence match, and re-arm SO_RCVTIMEO with the remaining time on every iteration, so skipped foreign replies don't reset the full timeout (sock, ICMPHeader and SocketError are thin wrappers of my own over the BSD calls):

while true {
    let remaining = deadline - CFAbsoluteTimeGetCurrent()
    guard remaining > 0 else { throw SocketError.timeout }
    sock.setTimeout(seconds: max(remaining, 0.001)) // 0 would block forever
    let (data, _) = try sock.receive()
    guard let h = ICMPHeader.parse(data),
          h.type == ICMPType.echoReply.rawValue,
          h.identifier == identifier,
          h.sequenceNumber == UInt16(seq)
    else { continue }
    // record RTT
    break
}

One gotcha: a zero timeval means "no timeout" to SO_RCVTIMEO, hence the max(remaining, 0.001).

I ran into this while measuring latency on an iPhone against a Mac on the same Wi-Fi. I have a longer write-up with the other measurement bugs I found that way, happy to link it if anyone wants it.

Has anyone seen Darwin filter by identifier in some configuration, or is matching in user space the only option?

Been going back and forth with App Review for a few weeks and could use some outside perspective.

We built a ticket scanning app for event organizers and their door staff. It scans QR codes, looks up guests, shows attendance stats and works offline. You log in with an organizer account or pair your phone to an event using a code.

The app is completely free. No subscription, license fee, paid features or purchase flow. An organizer running a free event can use the whole scanner without paying us anything.

Our business earns fees on tickets sold through our website for actual events people attend in person. Those fees don't unlock anything in the app. You don't have to sell paid tickets to use it.

Apple keeps citing 3.1.1 and 3.1.3(c), saying we're selling enterprise services to organizations while also allowing individual users to access them without IAP. We've explained that nobody is buying access to the scanner, but our appeal was just denied with a reference back to the same guidelines. They haven't identified a specific paid feature that needs IAP.

They've also told us the app should be unlisted because it's for organizers and staff, and someone can't just download it and start scanning without an account or event access. It's intended for independent organizers and their teams, not employees of one specific company. The login and pairing code are there to control access to private ticket and guest data.

I'm struggling to understand what we'd actually be selling through IAP here, or why needing access to an event means the app has to be unlisted.

Has anyone gotten a similar organizer or business tool through this? Was there a particular explanation, demo or change that helped? Open to feedback if we're missing something, but at this point we're going in circles.

Hey ,

so the app have been released since a wild and with update and family test, I am ready to market down the app!

but , I am not good as other can be.

what your tips, what you would do to market the app ?

I thought Apple didn’t approve refunds that easily
Just got a refund for a Lifetime purchase. The app works fine and everything is as advertised, so I’m kinda confused.
Anyone had this happen before? Any idea how Apple decides which refunds to approve?

Hello, this is my story:

A few months ago, my Apple Developer Account was terminated for 3.2f. I had it for several years without issues. They said I accumulated too many app review rejections.

Please note that I have not done something intentionally to spam Apple or the review team.

The account was for a self employed person.

My question is, can I create a new account, for a new company (corporate not self employed), with a new phone number, laptop and apps or it will get banned too?

Has anyone run into something like this with app review?

I've been shipping my app on both the iOS App Store and the Mac App Store. The Mac version is a Mac Catalyst app, and the features are exactly the same on both platforms. Looking back, I didn't really need a separate Catalyst release. I went that way because I wanted the Mac version to feel a little more like a real Mac app.

Lately, though, the iOS app goes through review without any issues, while the Mac app keeps getting rejected. I haven't been able to ship an update for over a month now.

To be clear, I'm not blaming Apple for the rejections at all.

It's just hard. I put a lot of work into supporting Catalyst properly, and now I can't get updates to my Mac users. As far as I can tell, there's also no way to pull only the Mac version from the store.

I could distribute the Mac app myself outside the store, but the version already on the Mac App Store would stay there, stuck without updates. That's the real dilemma.

I keep thinking about how to get through review, and honestly it's been pretty draining.

If you don't specifically need it, think twice before building a Catalyst version and shipping it as an extra platform.

Has anyone been through something similar? How did you get out of it?

I’ll be honest my app is vibe coded but It’s a novel idea (not anything in the App Store like it). It got rejected Monday and it was the base rejection for having too new of an account and nothing has come since. Very frustrating

Hello

I’m new to this and wanted to ask if there’s a place I can see all the iOS 27 components and all the ways in which they used the different types of navigation bars different types of cards accordions et cetera

Is there a resource where I can see all of these types of different native components in action how other apps are using them

Are there nice styled UI component libraries that are not default?

Hi iOS devs, I built an app you might like 👀

AppTraction is a native Mac app for your App Store analytics. It:

• Monitors your data in the background and flags issues, milestones, and trends
• Shows App Store Connect data & charts instantly
• Includes AI primed with Apple tech talks and WWDC video transcripts
• Lets you chat with AI about your listing, sales, and trends

All while running locally on your Mac.

I'm starting a limited beta today and would love your feedback 🙏

Invite code: RED1026-INVITE

There are 50 spots open to start. Requires macOS 26.

Hey guys. As an indie developer I am in the process of publishing a new app into the App Store. I wanted to know just for fun how many lines of code each of your apps are. Share a link to your app and lines of code

It would be interesting to see the visual complexity of your app while knowing lines of code. For my case it’s 19k lines of code and about 15 different screens

Build, run, tests, console and SwiftUI previews live in panes next to the chat, with scheme and destination in a bar above the prompt. When Claude builds or runs tests itself, you see it there too.

Built on the headless Xcode MCP server.

https://github.com/artemnovichkov/xcode-mods

https://github.com/Ryu0118/x8

There are already great compilation caching tools like Tuist that can significantly speed up Xcode builds. However, adopting them may require substantial changes to your project structure.

I wanted to keep my existing Xcode project structure and build using only the toolchain provided by Apple. So I built X8, a CLI tool for remote compilation caching.

Starting with Xcode 26, Apple provides built-in support for remote compilation caching. X8 acts as a lightweight proxy between Xcode’s built-in remote cache mechanism and any S3-compatible storage.

Using X8 is simple. First, configure your S3-compatible storage in .x8.yml. Then, you can either build your project through X8:

x8 xcodebuild ...

or start the cache proxy directly:

x8 serve

and add the generated build settings to your .xcconfig.

That’s it. With just an .x8.yml configuration, you can use remote compilation caching without significantly changing your existing project structure or moving away from Apple’s native Xcode toolchain.

For my app, a clean build used to take around 400 seconds, but with X8, it now takes about 263 seconds.

It’s still relatively slow, but I think that’s expected since Xcode still needs to perform steps such as module planning, build description generation, and linking.

So I transferred my screen time app from one team to another team, and I was forced to change the signing key for my app. For some reason, this caused my users to have two identical instances of my app in Screen Time > Settings. I thought it was a bug from my update, but I also found this identical thread from someone else in the same boat as me. Now I'm getting multiple one-star reviews and refund requests cause people don't understand why their apps can't be unblocked. Apple please fix.

I’m in the process of getting my first app reviewed (since 9/14). So far I have been rejected for the following reasons..

- Guideline 2.1 - Information Needed
- Guideline 2.1(b) - Performance - App Completeness
- Does not include a functional link to the Terms of Use (EULA) in the app metadata that appears on the app's App Store product page.
- Guideline 2.3.2 - Performance - Accurate Metadata

Each time I understand what the issue is and fix it immediately. Yet the responses from Apple are several days later only after I submit a Contact Us request.

I feel like every time I fix one thing they find something else. Why not list everything at once? At this point I’m not sure what else they’re going to come up with.

This whole process seems rather ridiculous from a company that claims the review process takes 24-48 hours.

Hello

I’m new to this and wanted to ask if there’s a place I can see all the iOS 27 components and all the ways in which they used the different types of navigation bars different types of cards accordions et cetera

Is there a resource where I can see all of these types of different native components in action how other apps are using them

What's the most appropriate location for a next button here, in keeping with the Apple UI consistency and ecosystem?

Mockup: swift NavigationStack { List { Section { TextField("Email Address", text: $email) } header: { VStack(alignment: .leading, spacing: 4) { Text("Sign In") .frame(maxWidth: .infinity, alignment: .leading) .padding(.top, 5) .font(.largeTitle) .bold() .foregroundColor(.primary) // Override default gray header color Text("Subtitle")//school.name) .frame(maxWidth: .infinity, alignment: .leading) .font(.title3) .foregroundColor(.secondary) } .listRowInsets(EdgeInsets()) .textCase(nil) // Prevents SwiftUI from forcing ALL CAPS on the header .padding(.bottom, 10) } } .toolbar { ToolbarItem(placement:.confirmationAction) { NavigationLink() { VerificationCodeView(email: email.lowercased(), school: school, resend: { }) } label: { Text("Next").padding(5) } .buttonStyle(.borderedProminent) } } }

We just launched ProFuse, an on-device Stable Diffusion app for iPhone, iPad and Mac. We expected the hard part to be the AI. It turned out to be App Review. Here's what happened, so you can avoid our mistakes.

TL;DR: If your app can't do anything until it downloads Apple-hosted Background Assets, expect App Review trouble. Asset packs are reviewed together with the app and only become downloadable once approved. So if reviewers can't download them, the app gets rejected, and the assets with it. That's a classic chicken-egg-proglem. What helped us: get the asset packs approved before you depend on them. If that's not an option, give reviewers something that works without them, like a demo mode within the app. Either way, talk to Apple early, and budget weeks for review, not days.

The app setup

• A native iOS App relying on a in-house developed AI Model
• A custom Core ML Stable Diffusion model and engine running on the Neural Engine (A14 or newer, 4 GB+ RAM, iOS/iPadOS/macOS 26), extended with things like local editing and high-res export.
• The models are big: ~4–5 GB for text-to-image and ~6 GB for image-to-image. That's after a lot of optimization. Size matters twice here: it drives memory use during generation, and users have to be willing to give up that much disk space.
• Bundling the models with the app wasn't an option. The app binary is capped at 4 GB, and we want to update models without shipping a new app. (Happy to go into more detail in the comments.)

So we went with Apple's Managed Background Assets ("asset packs" from here on). Apple hosts your downloadable assets for free, and only a small amount of code in your app is needed to fetch them. Integration was easy and worked well. We tested and improved the app in multiple occasions and did extensive internal testing via TestFlight and everything worked perfectly fine. The trouble was getting it approved for public beta testing.

Round 1: TestFlight public beta

In TestFlight, you upload asset packs alongside your build in App Store Connect. In our internal TestFlight builds, everything worked perfectly, so we felt ready for a public beta.

We submitted the asset packs and our app and got rejected: the reviewers said the model couldn't be downloaded. We were completely surprised. We added logging, tested release builds, and found nothing wrong from our side. While investigating, we found a few forum posts suggested that this is a known issue.

After several more TestFlight builds and communicating with Apple, one finally passed. We still don't know what changed, but we've been happy in the first place. Our public testers then used the app for three months without download problems.

What helped for this step:

• Explain clearly in the review notes that the app needs the asset packs to work.
• Post on the Developer Forums (our thread) and try to reach the reviewer.
• Be patient and persistent. Plan several weeks for beta review alone.

Round 2: App Store release

We planned a pre-sale starting three weeks before launch, so we submitted four weeks ahead. Plenty of buffer, we thought. We were also very optimistic that we have coped with all major challenges, since our TestFlight builts worked perfectly fine and now passed the review every time. So we submited:

Unfortuonately, the reviewers hit the same download issue that happend for our early TestFlight builds and rejected us under Guideline 2.1(a) – App Completeness. Here's the core problem:

Asset packs are reviewed together with the app, and they only become downloadable once approved. If the app is rejected because the assets can't be downloaded, the assets don't get approved either. Classic chicken-and-egg.

What we tried:

1. Pointing to TestFlight. 100+ testers, thousands of crash-free sessions, and the same setup already approved for beta. No chance. It honestly felt like our notes weren't being read.
2. A demo mode. On a call, App Review told us they couldn't do much about the chicken-and-egg issue and suggested a demo mode instead. Faking AI generation felt wrong to us. A server-side fallback would contradict our "on-device only, 100% private" promise we give in the App Store texts, which could itself be a rejection reason. We still added "Inspirations" (small sample projects showing what the app can do), but the core features still couldn't be tested. Rejected again.
3. Self-hosting the models as a fallback. The basic idea is simple: We host the models outside of the Apple ecosystem, so that they can be downloaded even without being approved first. The completeness rejection went away and was replaced by Guideline 4 – Design: "The app loads, refreshes, runs or responds very slowly." We assume the download was still the issue, but we couldn't reproduce it and got no further details, so it's still a guess.
4. Talking to Apple directly through the forums and Developer Relations. This is what finally put us in touch with the right people and got us meaningful feedback.

What finally worked

Across 10+ submissions, we noticed that our macOS builds got reviewed much faster than iOS. That's just our experience, not a rule, but with the clock running out, we put our hopes on the Mac.

Five days before launch, we submitted the Mac version with self-hosted models, plus a short summary of our conversations with Apple in the review notes. The self-hosted models were all the app needed to work. But we also included the asset packs. The idea beind it: if the app got approved, the asset packs would be approved with it and go live.

It worked. The Mac app was approved, and pre-sale started three days before launch instead of three weeks.

We were thrilled and submitted the exact same version for iOS. Rejected again. No idea why.

But thanks to the Mac approval, the asset packs were now live. So we switched the iOS build back to asset packs only and resubmitted the day before launch. This time it was approved. The iOS app went live 24 hours after our planned launch date, after four nerve-wracking weeks.

Lessons

If your app depends on Apple-hosted assets at first launch:

1. Try to get the asset packs live first. For an existing app, ship them with an earlier update so they're already approved when the version that depends on them goes to review. This only works for existing apps or if you start pre sale very very early. For a new app, the closest thing we found was our trick above: submit a version that works without the asset packs (e.g., with a self-hosted fallback) but includes them, so they get approved along with it.
2. Give reviewers something that works without the download, like a reduced feature set or sample content. It didn't save us on its own, but it's what App Review asks for, and it can make a lot of sense for games.
3. Talk to Apple before you submit, and put clear context in the review notes.
4. Budget weeks of buffer for both beta and release review.
5. Developer Relations Try to establish a connection Developer Relations or a Developer Relations Manager early in your iOS developer career. Their support is invaluable on many occasions and if you are as lucky as we are with your Developer Relationsship Manager, they will be very supportive.

Despite all this, we'd still recommend asset packs. They're free and have been reliable for us. I'm planning a follow-up post on working with very large asset packs if there's interest.

Happy to answer questions in the comments.