“build disappears”

I'm building an app that heavily relies on EKEventStore for calendar and reminder integration. The API is simple - and limited. Change notifications amount to something changed, you'd better refetch everything you care about. There's no way to know whether the calendar was updated while your app was closed or backgrounded. EKEvents and EKReminders don't trigger SwiftUI view updates, so you end up shunting them into your own observable state and keeping the two in sync. My app is fairly complex rendering-wise, and I lament being locked into treating EKEventStore as a first-class citizen of my view and data layer. It makes everything clunkier, essentially shuts the door on modern features like undo/redo, and makes integrating with other calendar providers that much harder. I'm exploring a custom SwiftData DataStore ↔ EKEventStore sync engine, but this is no easy task. There are still many unknowns I'd need to spike out before I can even attempt a proper implementation. Still, I'm curious - is this some

Hello, I am writing to ask for assistance regarding two of my apps that have been stuck in “Waiting for Review” for an extended period. At the moment: App ID 6497716649 — Waiting for Review since Feb, 19 at 11:45 AM App ID 6743224713 — Waiting for Review since Feb, 15 at 10:26 PM There are no warnings, Resolution Center messages, or visible issues in App Store Connect. All Agreements, Tax, and Banking information are active and up to date. The builds were uploaded successfully, and no further action appears to be required on my side. Could you please help confirm: Whether there is any hidden blocker or account-related issue? Or if this delay is currently due to review queue processing times? If additional details are needed (bundle IDs, app category, sign-in requirements, encryption/export compliance, etc.), I will be happy to provide them immediately. Thank you very much for your time and support. Best regards,

Hello, I have a policy-related question regarding App Store Review for dating apps. As a development agency, we build apps based on client requirements. Recently, we received feedback from App Review stating that the dating app category is saturated and that the app should demonstrate unique features to avoid being considered spam or a duplicate of existing apps. In such cases, what is the recommended approach for developers working on client projects? If a client requests a standard dating app with common features (profiles, matching, chat, etc.), is it likely to be rejected under the spam/duplicate guideline (4.3)? Should developers proactively advise clients to include clearly differentiated features before submission, even if the app is functionally complete and complies with technical guidelines? Any clarification on how App Review evaluates dating apps for uniqueness under Guideline 4.3 would be very helpful. Thank you.

After nearly ten years in Android development, I finally built a native iOS app, sharing the journey publicly while learning Swift and SwiftUI, using AI selectively, and finding the platform familiar yet different in tooling, concurrency, and culture. I reached production without initially buying a developer account and faced a stricter, iterative App Store review process than the Play Store, with several rejections that ultimately clarified Apple’s quality standards and expectations.

Since macOS 26.4 Beta 1, virtual HID devices created via DriverKit can no longer intercept key events from the built-in MacBook keyboard. External keyboards still work. This is confirmed and tracked here: https://github.com/pqrs-org/Karabiner-Elements/issues/4402 One possible lead (from LLM-assisted analysis of Apple's open-source IOHIDFamily code and cross-referencing community reports): macOS 26.4 Beta may have introduced or modified a security policy referred to as com.apple.iohid.protectedDeviceAccess, which could block IOHIDDeviceOpen for the Apple Internal Keyboard connected via SPI transport (AppleHIDTransportHIDDevice). This appears related to a GamePolicy check in IOHIDDeviceClass.m that gates whether processes can open HID devices. This has not been independently verified and may or may not be the root cause. This has far-reaching consequences. Karabiner-Elements alone has over 21,000 GitHub stars and is used by hundreds of thousands of macOS users for keyboard customization, accessibility workflows

Hi everyone, I am trying to submit the first version of my app with auto-renewable subscriptions, but I am stuck in a loop. Both of my subscriptions (Yearly and Monthly) are stuck with the status Developer Action Needed. Because of this status, they do not appear in the list of available In-App Purchases when I try to attach them to my app binary on the App Store Connect submission page. Here is what I have already done/checked: All metadata is filled out (Display Name, Description, Pricing). Review Information is complete (Screenshot and Review Notes are provided). My Paid Applications agreement in the Agreements, Tax, and Banking section is Active. I contacted Apple Developer Support by phone, but they were unable to resolve the issue and suggested I post here for help. Has anyone experienced this limbo before? How can I trigger the status to change to Ready to Submit so I can finally attach them to my build and send the app for review? (I have attached screenshots of my App Store Connect dashboard

I installed the latest build of Tahoe (25E5218f) yesterday on our test machine, an M1 Pro MacBook Pro and have been having a hard time getting my WiFi network to work. It's especially noticeable in Mail and Safari. Mail shows it can't connect to the designated server, and Safari simply can't connect to most sites. None of my other devices or computers are having problems, so I have to assume it's this last build that is the culprit. When I tether to my iPhone Air, everything pops back into place and I can access Mail and use Safari. I've reported the problem with FBA, but wanted to know if anyone else is experiencing the same thing.

I develop and build the DeepSkyStacker application on an M4 Mac Mini. A user reports that with a given set of data files and application settings, that it crashes on his M4 MAX. He sent me his data files, and I can't provoke a crash on my M4. He also sent an App Crash report file which I attach. Any insight into the likely cause of the problem will be appreciated (yes, I know it is a segfault in code called from Avx256Stacking::pixelPartitioning - probably a lambda ...). dss-6.1.3-crash.log

Recursive and Self-Referential Data Structures Combining recursive and self-referential data structures with frameworks like Accelerate, SwiftMacros, and utilizing SwiftUI hooks can offer significant benefits in terms of performance, maintainability, and expressiveness. Here is how Apple Intelligence breaks it down. Benefits: Natural Representation of Complex Data: Recursive structures, such as trees and graphs, are ideal for representing hierarchical or interconnected data, like file systems, social networks, and DOM trees. Simplified Algorithms: Many algorithms, such as traversals, sorting, and searching, are more straightforward and elegant when implemented using recursion. Dynamic Memory Management: Self-referential structures can dynamically grow and shrink, making them suitable for applications with unpredictable data sizes. Challenges: Performance Overhead: Recursive algorithms can lead to stack overflow if not properly optimized (e.g., using tail recursion). Self-referential structures can introduce m