“build disappears”

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

We are building an AI-powered smart glasses companion app, similar to Meta Ray-Ban. We want to provide true hands-free calling support. Right now, whenever the app tries to dial a native cellular call, iOS shows a confirmation screen that requires the user to tap to start the call. If the user always has to confirm/tap on the phone screen, there is no real point in using smart glasses for making calls. How can we initiate a native outgoing call without any confirmation dialog or extra tap, exactly like Siri does it, or like the Meta Ray-Ban glasses do when the user says “Hey Meta, call [name]” Please guide us on the correct APIs, entitlements, or integration path to achieve this behavior. Thank you.

All of my notarization submissions have been stuck at In Progress for up to 10 days. I have 6 submissions spanning from March 4 to March 11, 2026, and none of them have completed or returned any errors. Affected submissions: dbf20b57-0073-444a-b09a-ac6747b7398e (submitted Mar 4) — In Progress d5886683-be64-455c-805d-cd8b12bbcd35 (submitted Mar 4) — In Progress 10bfa709-da17-49cf-9c89-63f93b5fb756 (submitted Mar 4) — In Progress e8d0866e-43f8-4a18-8129-64e6c5d3895a (submitted Mar 9) — In Progress f9526f25-5650-4c45-98ae-d778c58a2ffa (submitted Mar 9) — In Progress 82ec211f-9179-41fd-afe0-937c9b2c2750 (submitted Mar 11) — In Progress Running `notarytool log` returns Submission log is not yet available. Team ID: CB4U5M6U9H It is an Electron-based app built with electron-builder. Steps taken to ensure compliance: Signed with a valid Developer ID Application certificate Hardened runtime enabled (hardenedRuntime: true) Proper entitlements configured (com.apple.security.cs.allow-jit, com.apple.security.cs.allow-unsi

Popular automated testing systems like FireBase [1] and WeTest [2] expect the uploaded test to include the Debug-iphoneos directory generated by Xcode. However, in all of our builds on Xcode 26.3, this folder is created but remains empty. There are some other folders with the same name in subdirectories, but these only contain intermediate build files. Now we're looking for configuration or settings in Xcode to restore the original behavior, where the top-level Debug-iphoneos directory gets populated with a complete image of the test target, include the binary and resource files. Any suggestions would be much appreciated! [1] https://firebase.google.com/docs/test-lab/ios/run-xctest [2] https://www.wetest.net/documents/detail/automation/d8yaA7yz

Hi Writing an app in Swift on Xcode for my iPhone, all software is the latest version. If after making a minor change and re-building all the application data has disappeared, is there a way to see if it is still in the .modelContainer and just not showing up?

Hey everyone 👋 I have 14 years of experience in iOS development, starting in my mid-teens and later working as a senior and lead developer with Fortune 50 companies. Around 1.5 years ago I began my indie journey as a side hustle, and for the past 3 months I have been building apps full time with a growing portfolio and increasing revenue 📈 I currently handle everything myself including development, ASO, and design, with marketing planned for later 🚀 I just shipped a major release last week and taking a relaxed week now, so feel free to ask anything about iOS development, indie life, ASO, monetization, or related topics 💬

When building a SwiftUI project in Xcode 26.3, Swift compilation fails in the Release configuration with Optimization Level set to -O, when the iOS deployment target is lower than iOS 26 (e.g. iOS 16, 17, or 18). The failure occurs when using a generic class conforming to ObservableObject that contains a @Published property. The same code: Compiles successfully in Xcode 16.3 (Release, -O) with iOS 16/17/18 Compiles successfully in Xcode 26.x when the deployment target is set to iOS 26 Compiles successfully in Xcode 26.x Debug configuration (-Onone) Compiles successfully in Xcode 26.x Release when optimization is disabled (-Onone) However, in Xcode 26.3, the build consistently fails in Release (-O) when targeting iOS 16, 17, or 18. This appears to be a Swift compiler optimization issue related to generics, ObservableObject, @Published, and back-deployment to iOS versions prior to iOS 26. STEPS TO REPRODUCE Create a new SwiftUI App project using Xcode 26.3. Leave all project settings at defaul

While Apple prides itself on providing the ultimate experience for both users and developers, many find themselves trapped in a technical black hole with no exit. The issue isn't just the complexity of the systems, but the sheer inability of these systems to handle a developer’s most basic need: accessing their account to manage their business. The Dead-End Loop: Too Many Verification Codes The disaster begins with a seemingly harmless but business-destroying message: You have sent too many verification codes. Please try again later. At this point, Apple’s system—with its supposed intelligence—decides to freeze your account for two days or more. You wait patiently, return after 48 hours to log in, only to be met by the exact same message. This isn’t security; it’s primitive technical failure. How can a company of Apple’s magnitude fail to program a smart system that distinguishes between a breach attempt and a developer trying to access their work tools? Persistent failure for over a month without a root solu