“Apple Maps Guides”

Description: I’m developing a tvOS app using SwiftUI where we play background audio (music) in the Welcome screen, with support for offline playback via local caching. 🔹 Feature Overview App fetches audio metadata from API Starts streaming audio (HLS .m3u8) immediately In parallel, downloads the raw audio file (.mp3) Once download completes: Switches playback from streaming → local file On next launch (offline mode), app plays audio from local storage 🔹 Issue This flow works perfectly on the Simulator, but on a real Apple TV device: Audio plays for a few seconds (2–5 sec) and then stops Especially after switching from streaming → local file No explicit AVPlayer error is logged Playback sometimes stops after UI updates or periodic API refresh 🔹 Implementation Details Using AVPlayer with AVPlayerItem Background audio controlled via a shared manager (singleton) Files stored locally using FileManager (currently using .cachesDirectory) Switching playback using: player.replaceCurrentItem(with: AVPlayerI

Hi all, Apple dropping on-going development for FireWire devices that were supported with the Core Audio driver standard is a catastrophe for a lot of struggling musicians who need to both keep up to date on security updates that come with new OS releases, and continue to utilise their hard earned investments in very expensive and still pristine audio devices that have been reduced to e-waste by Apple's seemingly tone-deaf ignorance in the cries for on-going support. I have one of said audio devices, and I'd like to keep using it while keeping my 2019 Intel Mac Book Pro up to date with the latest security updates and OS features. Probably not the first time you gurus have had someone make the logical leap leading to a request for something like this, but I was wondering if it might be somehow possible of shoe-horning the code used in previous versions of Mac OS that allowed the Mac to speak with the audio features of such devices to run inside the Ventura version of the OS. Would it possible

I am writing to share my frustration regarding the app review process for my application. My current submission has been stuck in Waiting for Review for nearly 7 weeks, starting from February 5th. Although I have attempted to cancel and resubmit periodically, there were significant gaps of 10 and 21 days between submissions where no action was taken. Currently, I am stuck again. The situation is critical for the following reasons: Critical Bug: The update includes a necessary fix for an In-App Purchase bug that is preventing users from accessing paid features. No Communication: I have sent four inquiries regarding this delay. I received only one generic response asking me to wait, and my subsequent follow-ups have been completely ignored. Expedited Review Request: My requests for an Expedited Review have also gone unanswered. Apple’s standard review time is typically 24-48 hours, but my experience is far from that. I am not asking for special treatment; I am asking for basic transparency regarding wh

Hello Apple Developer Community and App Review Team, I'm writing to seek guidance regarding my app Lookify: AI Virtual Try-On (App ID: 6757718224), which has been caught in an ongoing review cycle since February 15, 2026 — nearly two months ago. Submission History: Date Version Status Feb 15 iOS 1.1.0 Removed Feb 19 iOS 1.1.0 Removed Feb 21 iOS 1.1.0 Removed Apr 3 (2:21 AM) iOS 1.1.0 Removed Apr 3 (1:17 PM) iOS 1.1.0 Removed Apr 6 (current) iOS 1.1.0 Waiting for Review Each submission was either self-removed after extended waiting periods with no reviewer feedback, or removed to address potential issues — only to re-enter the queue with the same outcome. The current submission has now been in Waiting for Review status since April 6 with no activity, no messages, and no indication of progress. What I've done to comply: Updated the Privacy Policy to be fully GDPR and KVKK compliant Provided clear demo account credentials and usage instructions for the AI try-on feature Ensured all metadata, screenshots

Apple review usually takes a couple hours or even 2 days or less to review my submissions but it’s taking them 4 days to review it I submitted on a Wednesday. should I re-submit?

Hello, The issues we previously identified still need your attention. If you have any questions, we are here to help. Reply to this message in App Store Connect and let us know. Review Environment Submission ID: f14dec0a-1269-438e-b483-6d806b3d17bf Review date: April 13, 2026 Review Device: iPhone 17 Pro Max Version reviewed: 1.0 Guideline 4.3(a) - Design - Spam Issue Description We noticed the app shares a similar binary, metadata, and/or concept as other apps you already submitted to the App Store, with only minor differences. Submitting similar or repackaged apps is a form of spam that creates clutter and makes it difficult for users to discover new apps. Next Steps Since we do not accept spam apps on the App Store, we encourage you to review the app concept and submit a unique app with distinct content and functionality. Resources Some factors that contribute to a spam rejection may include: Submitting an app with the same source code or assets as other apps already submitted to the App Store Creating and

I’m submitting an iOS app that uses Family Controls / DeviceActivity APIs, and App Store Connect rejects the archive during distribution with this error: Invalid Info.plist value. The value of the NSExtensionPointIdentifier key, com.apple.deviceactivity.monitor, in the Info.plist of “activity-tracking.app/PlugIns/ScheduleMonitorExtension.appex” is invalid. What I’ve already verified: Family Controls capability is approved for our team App IDs and distribution provisioning profiles were regenerated The source Info.plist for the extension contains: NSExtensionPointIdentifier = com.apple.deviceactivity.monitor The archived .appex inside the .xcarchive also contains the same exact value Signed entitlements in the archived .appex include: com.apple.developer.family-controls = true app group entitlement Main app archive is signed correctly as well Latest stable Xcode used This makes it look like the archive is configured correctly, but App Store Connect still rejects the Device Activity Monitor extension point itse

Fellow Apple Developers and Apple Developer Support Team, If you’re seeing the message **“Your enrollment is being processed. Your enrollment ID is **” for weeks (or longer) with no updates, no follow-up emails, and no access to App Store Connect, you are not alone. I’m posting this in the hope of helping everyone experiencing the same frustrating delay and giving Apple a clear, visible signal that this is impacting real developers right now. My Situation (and Why It Matters) I submitted my Apple Developer Program enrollment several weeks ago, completed payment successfully, and have since sent two support emails requesting an update. The status remains unchanged. Meanwhile, my app is already live and performing well on Google Play. I’m ready to submit the iOS version, but I cannot even reach TestFlight or App Store Connect because the enrollment is still “processing.” Like many of you, I’ve read dozens of identical threads here on the forums and on Reddit in the past month

Hi everyone, I'm building an iOS app that uses a DeviceActivityMonitor app extension as part of the Screen Time / Family Controls API. Every time I try to upload my IPA to App Store Connect, the validation fails with this error: Invalid Info.plist value. The value of the NSExtensionPointIdentifier key, com.apple.deviceactivity.monitor, in the Info.plist of 'Alexandria.app/PlugIns/AlexandriaActivityMonitor.appex' is invalid. Error Domain=IrisAPI Code=-19241, iris-code=STATE_ERROR.VALIDATION_ERROR What I have verified (everything looks correct): NSExtensionPointIdentifier = com.apple.deviceactivity.monitor NSExtensionPrincipalClass = AlexandriaActivityMonitor.AlexandriaActivityMonitorExtension (correctly resolved in the compiled binary, verified with plutil -p) The Swift class correctly subclasses DeviceActivityMonitor CFBundleShortVersionString matches the main app Both the main app and extension provisioning profiles explicitly contain com.apple.developer.family-controls = true (verified by inspecting embedde