“build disappears”

The man page of copyfile sates the following: COPYFILE_CLONE [..] Note also that there is no support for cloning directories COPYFILE_CLONE_FORCE [...] Note also that there is no support for cloning directories: if a directory is provided as the source, an error will be returned. Now the man page for clonefile: > Cloning directories with these functions is strongly discouraged. Use copyfile(3) to clone directories instead. -- So am I to enumerate the content of a directory build subfolders along the way in the target destination and clone each file inside individually? If I recall NSFileManager seems to clone a large directory instantly (edit actually I remembered wrong NSFileManager does not do this. Finder seems to copy instead of clone as well). On further inspection, clonefile states that it can do this, but it is discouraged. Interesting. I wonder why. If src names a directory, the directory hierarchy is cloned as if each item was cloned individually. However, the use of clonefile(2) to clone

Hi everyone 👋 I’m a new iOS developer working on my first app and I’ve run into a frustrating visual bug involving my app icon during the launch/close transition. Issue: When I use Icon Composer (the new tool introduced for iOS 26) to generate my app icon, I consistently see a thin white border or “fringe” around the icon only during the transition animation (when the app opens or closes). It disappears once the animation ends. What I tested and confirmed: • I exported the exact same design directly from Adobe Illustrator as a 1024×1024 PNG, fully opaque, RGB color mode, background color filling the entire canvas (no transparency, no borders, no rounded corners). • When I place that exported PNG directly into the AppIcon asset catalog in Xcode, the icon renders perfectly — no white fringe appears, just a slightly darker shade of blue during transitions (expected and acceptable). • But when I generate the icon using Icon Composer, the white edge always appears, even if I disable effects, use full cov

Hello everyone, I would like to ask if other developers are currently experiencing unusually long App Review delays for new apps. Here is my timeline for this app (Apple ID: 6758083858): Jan 22, 2026: Initial build submitted Jan 22 – Mar 7, 2026: Status remained “Waiting for Review” and never entered the “In Review” stage Mar 7, 2026: Cancelled and resubmitted a new build Current status: Still “Waiting for Review” During this period, I have already tried several ways to resolve the issue: Contacted Apple Developer Support multiple times Submitted an expedited review request Sent follow-up emails regarding the delay Contacted Apple support by phone and asked them to leave a message for the App Review team Each time I was told that the situation would be checked or that the review team would look into it. However, it has now been about two weeks since my last contact and there has been no update or progress. While browsing the Developer Forums, I also noticed that many recent posts seem to des

Hello Apple Developer community, I’m reaching out because I’m currently experiencing an unusually long delay in the App Review process. My app (App ID: 6748461479) has been stuck in “Waiting for Review” since February 23, and there has been no change of status, no approval, no rejection, and no message from the App Review team. This situation is becoming problematic because I have publication deadlines and release planning that depend on this update being reviewed and approved. According to Apple’s own information, around 90% of apps are reviewed within 24 hours. I completely understand that some cases may take longer depending on workload or additional checks, but remaining in “Waiting for Review” for several weeks without any update is quite concerning. Current situation: Status has remained “Waiting for Review” since February 26 No request for additional information The build follows the App Store Review Guidelines Previous versions of the app were approved without issues Has anyone experienced si

Hello, I'm a first time developer and both of my submissions for NexFi - Portfolio Tracker have been suck in Waiting for Review for an extended time. TestFlight: My first build was submitted on Feb 15th (25+ days) and still Waiting for Review Production/Distribution: Submitted March 2nd (10 days) and still Waiting for Review. It is a finance category app (portfolio tracker) that requires no login, no account creation, and no server side user data so I figured it should be a relatively quick process as there is a minimal privacy footprint. App Name: NexFi - Portfolio Tracker Platform: iOS App ID: 6759226354

All of my notarization submissions have been stuck at In Progress for over a week. I have 6 submissions spanning from March 4 to March 10, 2026, and none of them have completed or returned any errors. Affected submissions: 685708f6 — MeetingRecorder-1.5.0.dmg (submitted Mar 10) — In Progress 6ade1490 — MeetingRecorder-1.5.0.dmg (submitted Mar 10) — In Progress 99d39bd0 — MeetingRecorder-1.4.12.dmg (submitted Mar 6) — In Progress e65f95e1 — MeetingRecorder-1.4.9.dmg (submitted Mar 6) — In Progress eb51b220 — MeetingRecorder-1.4.9.dmg (submitted Mar 5) — In Progress 9cc33cfd — MeetingRecorder-1.4.9.dmg (submitted Mar 4) — In Progress Running notarytool log returns Submission log is not yet available. Team ID: HXVLV4P425 The app is a macOS menu bar application for meeting recording and transcription. It is signed with a valid Developer ID certificate and has been built with hardened runtime enabled. I've tried resubmitting multiple times across different builds (1.4.9, 1.4.12, 1.5.0), but all submission

The second time i start a workout session, the beginCollection instance method on HKLiveWorkoutBuilder freezes. To recreate run the Apple Sample Project Building a multidevice workout app. It looks like a bug with the HealthKit SDK and not the code but i could be wrong. The only workaround i found was erasing the simulator and reinstalling the app.

We've got an in-house Swift macOS desktop app with a FileProvider extension, which has been working fine on various machines up through Sonoma (and still does). We've just installed it on a Sequoia machine, and on it the FileProvider extension has lost the ability to access the shared app group. It can neither log to the Group Containers folder under ~/Library, nor access the pipe to the main app. The group name is formatted as group.XXXXXXXXXX.com.orgname.appname in both targets. I'm not sure why it combines the iOS and macOS conventions, with both the group prefix and the teamIdentifier one -- it was first built some time before the point in 2025 when macOS supported iOS-style groups -- but again, it's been working. For the record, The provisioning profile for EMPFileProvider has the App Groups capability enabled, and the App Groups capability is present in both build targets in Xcode. The existing group identifier is registered on the website; I've also manually registered the team-ID-less group n

Hello, We are experiencing repeated notarization delays for our macOS app distributed outside the Mac App Store. Current submission ID: 45d7cac0-bd8a-4d48-b886-1cad7649adf4 Previous affected submission ID: ff61de1e-15f5-4bbe-8b34-a91a6f73b978 Issue description: xcrun notarytool submit succeeds and returns a submission ID. xcrun notarytool info keeps returning In Progress for a very long time. In the current case, the submission has remained In Progress for more than 45 minutes. This issue has happened repeatedly across multiple submissions. What we have already checked: We are not using a local proxy for notarization requests. We separated submit and polling in our build script to verify the exact stage. We retried multiple times. We reduced package contents to rule out newly introduced app content. Could someone from Apple please help check whether these submission IDs are stuck in the notarization pipeline, or advise what additional diagnostics we should provide? Thank you.