Overview

I've been trying for a while now, and I haven't found any button or route to actually renew my membership on any device. Please help.

Hello, My app Air Finder - My Device Tracker (Apple ID: 1490211589) seems to be stuck in the App Review process and I'd like to check if something might be wrong with my submission. Timeline: Submission for review: Jul 30, 2026 Current status: Waiting for Review Waiting time: 7 days as of Aug 6, 2026 My app reviews are typically approved within 1-2 business days, so I suppose this delay seems to be unusual. Please help review this submission as soon as possible! I have a timeline for publishing app version that cannot be delayed for this long. Any guidance would be very appreciated. Thank you in advance!

I am investigating premature DeviceActivityMonitor.eventDidReachThreshold callbacks on physical devices running iOS 26.x. I have also observed similar overcounting behavior on iOS 18.x. In one repeatable test, an all-activity event configured with a 10-minute threshold fired after approximately 5 minutes of actual unlocked usage. The event was created with: A single completion threshold. includesPastActivity: false. A nonrepeating DeviceActivitySchedule. A unique activity and event identity for each monitoring generation. However, eventDidReachThreshold could still arrive significantly earlier than expected. Defensive mitigation I have been testing a defensive mechanism that treats eventDidReachThreshold only as a wake-up signal, rather than authoritative proof that the configured usage duration has elapsed. When the callback arrives, the monitor extension independently validates the duration against locally persisted timing state. The flow is: Each logical work cycle has a unique cycle identifier and generation number. The app stores a local timing anchor when monitoring begins or resumes. When the threshold callback arrives, the extension verifies: The cycle identifier. The generation number. The activity name. The current application state. The extension calculates a locally trusted elapsed duration. If the local duration has not reached the configured duration: It does not send a notification. It does not apply any user-visible action. It persists only the locally trusted progress. It increments the generation number. It stops the previous monitor. It registers a new event for only the locally remaining duration. Completion is accepted only when the locally calculated duration is due. Delayed callbacks from previous generations are ignored. Simplified pseudocode: override func eventDidReachThreshold( _ event: DeviceActivityEvent.Name, activity: DeviceActivityName ) { let state = loadPersistedState() guard eventMatchesCurrentGeneration( event: event, activity: activity, state: state ) else { // Ignore stale or duplicated callbacks. return } let now = Date() let trustedElapsed = calculateLocallyAccountedElapsed( state: state, now: now ) let tolerance: TimeInterval = 3 if trustedElapsed + tolerance < state.configuredDuration { let remaining = state.configuredDuration - trustedElapsed var nextState = state nextState.confirmedElapsed = trustedElapsed nextState.generation += 1 // Persist the new generation before replacing the monitor. persistAtomically(nextState) center.stopMonitoring([activity]) let nextActivity = makeActivityName( cycleID: nextState.cycleID, generation: nextState.generation ) let completionEvent = DeviceActivityEvent( threshold: normalizedDateComponents(remaining), includesPastActivity: false ) do { try center.startMonitoring( nextActivity, during: makeNonRepeatingSchedule(), events: [ makeCompletionEventName(nextState): completionEvent ] ) } catch { // Persist a recoverable unavailable state. recordMonitoringFailure(error) } return } transitionToCompletedState() scheduleUserNotification() } Durations are normalized before creating the event: func normalizedDateComponents( _ duration: TimeInterval ) -> DateComponents { let seconds = max(1, Int(duration)) return DateComponents( minute: seconds / 60, second: seconds % 60 ) } This avoids using values such as second: 300. Example For a configured duration of 10 minutes: DeviceActivity incorrectly delivers the completion callback after approximately 5 minutes. Local accounting reports only approximately 5 minutes. No notification or other user-visible action is performed. The previous monitor is replaced with a new generation configured for the remaining approximately 5 minutes. Completion is accepted only after the locally trusted timing state is due. This mechanism has so far prevented premature DeviceActivity callbacks from producing premature notifications during my physical-device testing on iOS 26.x. Additional precautions The implementation also uses the following precautions: Only one completion event is registered instead of multiple minute checkpoints. includesPastActivity is explicitly set to false. Every replacement monitor has a new generation identity. Generation state is persisted before the old monitor is replaced. Callbacks from an old cycle, generation, or activity name are ignored. The extension performs only small, bounded state updates. User-visible actions occur only after local validation succeeds. Limitations This is a defensive workaround, not a fix for the underlying DeviceActivity or Screen Time accounting issue. Known limitations include: It cannot prevent iOS from delivering an incorrect callback. If the system never delivers another callback, completion may be delayed or missed. If every new event immediately fires, repeated re-registration may occur. startMonitoring may fail if the system considers the activities too numerous or too tightly scheduled. Local unlocked-time accounting depends on reliable lock and unlock observations. Wall-clock calculations must consider manual system-time changes. The approach cannot correct Screen Time’s internal activity data. For modes that intentionally count locked time, absolute local-notification scheduling may be more reliable and may avoid DeviceActivity thresholds entirely. All processing in this mitigation occurs on-device. It does not require uploading activity tokens, Screen Time data, user identifiers, or diagnostic logs. The implementation uses only public APIs. Questions for Apple Is treating eventDidReachThreshold as a wake-up signal and validating it against locally persisted timing state an acceptable design? Is stopping the current monitor and registering a new generation for only the locally remaining duration from the monitor extension considered a supported recovery pattern? Are there documented or recommended limits, rate controls, or backoff requirements for this type of defensive re-registration? Is there a more reliable supported API for usage-based completion when eventDidReachThreshold fires prematurely on iOS 26? I would appreciate confirmation from Apple engineers or feedback from other developers who have tested a similar approach.

We are implementing In-App Provisioning functionality for our Bank but there is always 500 Internal Server Error respond by Apple server once we tried to add card to apple wallet. Our code let request = PKAddPaymentPassRequest() request.activationData = try decodeBase64(payload.activationDataText, field: "activationDataText") request.encryptedPassData = try decodeBase64(payload.encryptedDataText, field: "encryptedDataText") request.ephemeralPublicKey = try decodeBase64(payload.ephemeralPublicKeyText, field: "ephemeralPublicKeyText") return request Because of fPanId is not required so we are not pass it to Apple server and that field generated once the card already added to wallet. Please help us investigate the issue, thanks! FeedbackId 24065847 (In-App Provisioning 500 Internel Error)

It has been a week since we submitted our app update, and the app is still in Pending Review. We previously contacted Apple Support regarding this issue and received a case ID via email. However, we have not received any response or update on the status of our case. We also could not find any place to track the case using the case ID that was provided.

Hi Apple team, App: DEADGRID Version: 2.0.1 App Apple ID: 6790152649 I'm reaching out in the hope that someone from the App Review team can take a look at my submission or advise whether there's an issue with it. My app has been in "Waiting for Review" for over a week and has not yet entered the "In Review" stage. I understand review times can vary, but this is significantly longer than what I've experienced previously. I've done my best to follow all App Store Review Guidelines and have provided complete review notes. As far as I'm aware, there isn't anything unusual about this submission that would explain the delay. Unfortunately, this update contains a fix for an issue currently affecting my users. While it's waiting to be reviewed, I'm seeing a decline in daily active users and user retention because I'm unable to release the fix. If someone from Apple is able to check whether my submission is simply waiting in the normal queue or if there's another issue preventing it from being reviewed, I would be very grateful. I'd also be interested to hear from other developers: Have you experienced similar review delays recently? Is there anything that can help move a submission forward when it's been waiting for this long? Are there any common reasons for an app to remain in "Waiting for Review" for more than a week? I appreciate the work of the App Review team and understand the volume of submissions you process every day. I'm mainly hoping someone can verify that my submission hasn't become stuck or overlooked. Thank you for your time. Afonso Quinaz

Filed FB24179855 for this. Posting here so others hitting similar limitations can track and/or reference it (Apple's triage reportedly weighs duplicate count). Issue <stdbit.h>, the C23 standard header for bit-manipulation utilities (stdc_leading_zeros, stdc_count_ones, stdc_bit_width, etc.) from C23 §7.18, is not present in the macOS SDK libSystem. Worth noting this is a libc/SDK gap, not a compiler gap. Apple Clang accepts -std=c23 fine, and <stdckdint.h> (also C23, also library-level, e.g. ckd_add) is already present and working correctly. So C23 library headers are clearly being landed in libSystem incrementally. stdbit.h just hasn't made it in yet. If anyone's found a workaround (other than falling back to __builtin_clz/__builtin_popcount etc.) or has visibility into whether this is scheduled, would be good to hear. Repro #include <stdbit.h> int main(void) { return stdc_leading_zeros((unsigned)0); } $ /usr/bin/cc -std=c23 repro.c repro.c:1:10: fatal error: 'stdbit.h' file not found 1 | #include <stdbit.h> | ^~~~~~~~~~ 1 error generated. Environment Apple clang version 21.0.0 (clang-2100.1.1.101) Target: arm64-apple-darwin25.6.0

I've got a single-window app whose main ContentView is a table of records. It has some menu commands, defined in my App file, that allow record-level operations (add, delete, process, etc). It also uses some framework-provided editing views (i.e. TextFieldView) for individual fields on each record. I'm having a lot of trouble implementing undo/redo. The menu commands don't have access to the Environment to obtain the undoManager there. The undoManager is nil during onAppear of the ContentView, so I can't set it into my view model before running some user-initiated action on the view itself. If I wire up custom Undo/Redo menu items with my own UndoManager, the TextFieldView undo no longer works. I even tried getting at the underlying NSWindowDelegate to provide my own UndoManager in windowWillReturnUndoManager, but that never gets called. What's the correct pattern to use here?

My first notarization submissions have been stuck at "In Progress" for over 24 hours. This is a brand-new Apple Developer Program membership (enrolled this week), and these are the account's first submissions. Team ID: TSH4QXMCU8 Submission IDs (oldest first): c74c1f21-9847-44e7-96f6-a7370fff4fab (created 2026-08-05T00:20:22Z) 182000c9-abd8-47eb-b3fe-45ced930f4c5 (created 2026-08-05T00:58:55Z) d8f3f404-5fe8-47f3-9da3-8e1b278aa7a7 (created 2026-08-05T01:04:52Z) The app is a signed Electron desktop application (Developer ID Application certificate, hardened runtime enabled), submitted as a zip via notarytool through electron-builder. The three submissions are the same app; the duplicates exist because interrupted builds resubmitted. notarytool history shows all three as In Progress. I understand first submissions from new accounts can take longer for in-depth analysis, but at 24+ hours I'd appreciate someone taking a look. Happy to provide any further information.

Hi — first-time notarization for a newly enrolled individual team. Three submissions, none have resolved. The oldest has been In Progress for just over 18 hours. Team ID: MYFWTHMK9U Submissions (all still "In Progress" as of 2026-08-06T00:29Z): id: 2cab98b4-530c-4b82-9b2f-6580687d935a name: Sunnyside.zip createdDate: 2026-08-05T06:15:41.200Z elapsed: ~18h 13m id: 2d84505e-2379-4633-ab2d-271f7c8c6c50 name: Sunnyside AI.zip createdDate: 2026-08-05T06:28:55.557Z elapsed: ~18h 00m id: 67c5f798-6f33-4da1-94b9-8ed1f8706498 name: SunnysideAI-0.5.0-arm64.dmg createdDate: 2026-08-06T00:19:02.679Z elapsed: ~10m The first two are zipped .app bundles submitted by electron-builder. The third is a DMG I submitted manually, to rule out anything specific to the zip path. No submission from this team has ever reached Accepted or Invalid — every one has stayed In Progress. Environment: macOS 15.7.7 (24G720) Xcode 16.2 (16C5032a) notarytool 1.0.0 (37) Electron 32, electron-builder 25.0.5 Auth: notarytool keychain profile (App Store Connect API key, Developer role) The submissions upload cleanly and notarytool returns a submission ID each time, so credentials and the upload path appear fine. Signing looks correct to me. From the packaged app: $ codesign -dv --verbose=4 "Sunnyside AI.app" Identifier=com.trysunnyside.desktop Format=app bundle with Mach-O thin (arm64) CodeDirectory v=20500 size=772 flags=0x10000(runtime) hashes=13+7 location=embedded Authority=Developer ID Application: Deepu Nair (MYFWTHMK9U) Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=5 Aug 2026 at 1:05:39 PM TeamIdentifier=MYFWTHMK9U $ codesign --verify --deep --strict --verbose=2 "Sunnyside AI.app" Sunnyside AI.app: valid on disk Sunnyside AI.app: satisfies its Designated Requirement Hardened Runtime is enabled, the signature carries a secure timestamp, and the nested helper binaries (a Swift ScreenCaptureKit helper in Contents/Resources, plus better_sqlite3.node) are all re-signed under the same Developer ID identity with the runtime flag — I checked each one individually rather than relying on --deep. I've read thread 821552, which describes a very similar situation on a new team. I understand from that thread that first submissions from a new team can be routed for in-depth analysis and take longer than usual. I'm not assuming this is a configuration error on my end — I'd just like to know whether these three are actually progressing, or whether they're wedged and I should resubmit. Since notarytool only reports "In Progress" with no queue position or estimate, there's no way for me to distinguish "still being analyzed" from "stuck". Any visibility into these submission IDs would be appreciated. Thanks.

I have a few crashes on my project that happen in the wild, and the stack trace looks like this, from a thread that is not the main thread: Crashed: com.apple.SwiftUI.AsyncRenderer 0 libdispatch.dylib 0x36f1c _dispatch_assert_queue_fail + 120 1 libdispatch.dylib 0x37988 dispatch_assert_queue$V2.cold.2 + 114 2 libdispatch.dylib 0x5094 dispatch_assert_queue + 108 3 libdispatch.dylib 0x5094 dispatch_assert_queue$V2 + 108 4 libswift_Concurrency.dylib 0xedfc _swift_task_checkIsolatedSwift + 48 5 libswift_Concurrency.dylib 0x6fc4 swift_task_isCurrentExecutorWithFlagsImpl(swift::SerialExecutorRef, swift::swift_task_is_current_executor_flag) + 356 6 Xogot 0x2585a78 closure #1 in Toolbar3D.dockedBody.getter + 195 (Toolbar3D.swift:195) 7 SwiftUI 0xeae60 ScrollView.init(_:showsIndicators:content:) + 136 8 Xogot 0x2585798 Toolbar3D.body.getter + 207 (Toolbar3D.swift:207) 9 SwiftUICore 0x31614 closure #1 in ViewBodyAccessor.updateBody(of:changed:) + 1068 10 SwiftUICore 0x311b0 ViewBodyAccessor.updateBody(of:changed:) + 348 11 SwiftUICore 0x30f48 protocol witness for BodyAccessor.updateBody(of:changed:) in conformance ViewBodyAccessor<A> + 16 12 SwiftUICore 0x24aa4 closure #1 in DynamicBody.updateValue() + 1136 13 SwiftUICore 0x24224 DynamicBody.updateValue() + 1220 14 SwiftUICore 0x4fffd0 partial apply for implicit closure #1 in closure #1 in closure #1 in Attribute.init<A>(_:) + 32 I have watched the 2025 WWDC Video "Explore Concurrency in SwiftUI" and it does point out that in certain places SwiftUI will use a background thread to run its operations and the documented idiom is that the protocols are non isolated. The issue is that ScrollView is @MainActor, and the content: argument has no special annotations, so it it flagged as @MainActor, and the new Swift dynamic test asserts. My class it not that interesting, it looks like this: struct Toolbar3D: View { var body: some View { #if macOS dockedBody #else someOtherBody #endif } var dockedBody: some View { ScrollView { ... } } } For a second I thought maybe the second layer was the problem, but the stack trace still shows my @MainActor body being invoked by SwiftUI on the background thread. This is happening in iOS 26.5.0, 26.5.1, iOS 26.5.2, iOS 26.2.0 I am not quite sure how to fix this, short of disabling Swift's dynamic actor isolation (which will probably just crash in a more obscure place at a later point in time).

We're working on an iOS app distributed through the App Store and installed on an MDM-enrolled device. Our MDM server uses InstallApplication to take management of the already-installed and running app. On iOS 27 betas 3 and 4, processing this command causes iOS to terminate the app and its extensions with SIGKILL. The same flow and MDM payload work without terminating the app on earlier iOS versions (iOS <=26). Environment OS: iOS 27 betas 3 and 4 Does not happen: iOS 26 or iOS 16.7.15 Device: iPhone SE 2nd Gen Enrollment: MDM-enrolled device Distribution: App Store app App state: Already installed and running when management is requested MDM command: InstallApplication Minimal MDM command The MDM server sends an InstallApplication command for the already-installed app: Attributes = { Removable = false; }; ChangeManagementState = Managed; Identifier = "APP_BUNDLE_ID"; InstallAsManaged = true; ManagementFlags = 1; RequestType = InstallApplication; We also tested the equivalent command using iTunesStoreID = APP_STORE_ID instead of Identifier, and removing InstallAsManaged. The targeted running app was terminated in the same way. Steps to reproduce Install and launch the App Store app as an unmanaged app. Enroll the iPhone in MDM. While the app is running, send the MDM InstallApplication command to take management of the existing installation. Observe the unified logs for mdmd, appstored, manageddeviced, installcoordinationd, and runningboardd. The issue can also be reproduced by initiating the same server-side flow while the app is already in the background. iOS 27 log sequence The command is accepted and appstored starts the managed-app tasks. manageddeviced then attempts to mark the app as managed using a null persona (this differs from iOS <26): The running app has a valid persona. After the failed mapping, installcoordinationd explicitly asks RunningBoard to terminate the app to disassociate that persona: After termination, removing the valid persona also fails. The managed-app task later reports success despite the mapping failures and termination. Earlier iOS comparison As an example, on iOS 16.7.15, using the same MDM command, **iOS routes the request through dmd with persona: default. The app remains alive and receives managed-app change notifications. Expected The existing installation becomes managed without terminating the running app, consistent with the behavior on earlier iOS versions. Actual manageddeviced tries to associate the app with persona (null) and fails with MIInstallerErrorDomain Code 191. That failure causes installcoordinationd to request termination of the app and its extensions to disassociate their valid persona. runningboardd terminates them with SIGKILL (isUserKill=0). The subsequent removal of the only valid persona fails with Code 242, although the managed-app task later reports success. Documentation checked The payload follows the documented InstallApplication flow for taking management of an existing app: Apple Docs WWDC26 app MDM updates We have not found a malformed field that explains the iOS 27-only failure. More info Detailed logs and additional info can be found on the Feedback report.

An image file whose data is cut in half is accepted by insertOrUpdateAssets, produces no error, and is reported as an image containing zero faces. That result is indistinguishable from a photograph that genuinely has no people in it. In my measurement the intact file reported 4 faces and a copy truncated to half its bytes reported 0 faces — both without throwing. Why this is worse than an error. A client that receives "zero faces, no error" will record the asset as analysed, no people present. That is a permanent, silent, incorrect result: the file is never revisited, and the people in it are lost from the catalogue with no diagnostic anywhere. An error would have been recorded as a failure and retried later. Silence is the one outcome that cannot be recovered from. The failure mode is also inconsistent. Other kinds of damaged input do throw — a zero-byte file, a text file with a .jpg extension, and a file whose interior bytes have been destroyed all raise MediaIntelligenceError.faceGroupProcessing. Truncation is the case that silently succeeds, and truncation is precisely the damage that partial downloads, interrupted copies and failing disks produce — the most common form of corruption in a real photo archive, and the one I have to handle in 97 libraries of mixed provenance. My current workaround is to fully decode every image myself before handing it to the framework, purely to detect truncation. That means every file is decoded twice, which roughly doubles the I/O of the analysis pass. Feedback: FB24174749

If a single asset in the array passed to insertOrUpdateAssets cannot be read, the returned AsyncSequence throws and delivers zero elements — including for the valid assets that appear before the offending one in the array. In my measurement a batch of 5 — two valid photographs, one zero-byte .jpg, then two more valid photographs — delivered 0 of 5 elements and reported 0 faces. The framework's own stdout log shows it had already processed the valid photographs before failing, so the work was done and then thrown away. This is the behaviour I would expect from a function returning [Result] after processing everything, not from a streaming AsyncSequence. The whole reason to expose an async sequence is to deliver results as they are produced; here the sequence produces nothing at all, which makes the streaming shape actively misleading. Why this matters at library scale. I am cataloguing 97 photo libraries, many of them archives of scanned family photographs going back to the 1970s, where a handful of damaged files is normal rather than exceptional. As the API stands, the batch size I choose for throughput is also the amount of work a single corrupt file destroys — with a batch of 100, one bad file costs 100 images. The only safe strategy is to catch the failure and re-submit the batch one asset at a time to find the culprit, which turns a rare bad file into a full re-run of that batch and makes the worst case quadratic in the number of bad files. Note also that the error gives no indication of which asset failed (see the related enhancement request on error taxonomy), so isolating the culprit by re-submission is the only option available. Feedback: FB24174733

insertOrUpdateAssets(_:) is async throws and returns an AsyncSequence, so by the Swift Concurrency contract I expected it to observe cancellation of the enclosing Task and throw CancellationError. It does not. The call runs to completion and returns successfully, with the full result set, as though the cancellation had never happened. In my measurement the cancel was delivered at 2.7 s and the call returned successfully at 19.0 s, having processed all 150 assets and reported 550 faces. The practical consequence for an app is that a "Stop" button cannot stop work that is already in flight. The only way to get responsive cancellation is to slice the work into many small calls and check Task.checkCancellation() between them — which means the batch size, which should be tuned for throughput, ends up being dictated by how long a user is willing to wait after pressing Stop. For me that is the difference between a batch of 150 (≈19 s to react) and a batch of 25 (≈3 s). The store is left in a consistent state, which is good: the assets processed before cancellation remain, and state correctly becomes .stale. So this is specifically about the cancellation signal being ignored, not about data integrity. One detail worth knowing when reproducing this insertOrUpdateAssets is declared nonisolated(nonsending), so it executes on the caller's executor. My first attempt at this reproducer used a plain Task { } created from @MainActor top-level code — which inherits main-actor isolation — and the detection therefore ran on the main actor and starved the very code that was supposed to cancel it: a Task.sleep(2.5s) on the main actor did not resume until the 19-second call had already finished, so the cancel was not even delivered until 19.0 s. The attached reproducer uses Task.detached to avoid that confound, and the cancel is correctly delivered at 2.7 s. I mention it because anyone reproducing this from a @MainActor context will see a different and misleading timeline. Feedback: FB24174707

Constructing a second FaceGroupAnalyzer while a first one is still alive registers the framework's Core Data managed object model a second time. Core Data can then no longer resolve +[MIManagedFace entity], and the process is terminated with SIGTRAP (exit status 133). Three things make this worse than a normal API misuse: It happens with completely separate working directories. The two instances are logically independent — different directories, different stores, no shared state that the API surface exposes. Nothing in the signature of init(workingDirectory:) suggests that two of them cannot coexist, and the parameter's existence implies the opposite. There is no way to detect or prevent it from a library. FaceGroupAnalyzer is not a singleton and offers no way to ask whether an instance already exists in the process. Any two independent subsystems in an app — say, a background analysis service and a foreground preview — that each construct an analyzer will terminate the app. In my case the app must now enforce single-instance access through its own serial queue and lock, which is a constraint the framework imposes but does not state. Construction alone does not fail, so the problem surfaces later and elsewhere. Both instances construct successfully; Core Data only emits warnings at that point. The abort comes when both are alive and one of them does real work (update() and reading the grouping). So the crash lands far from its cause, in code that is individually correct. Feedback: FB24174678

Many times the device totally lost connectivity, WIFI is completely down, no ip was assigned after device wakeup. From system log I can see BPF socket for DHCP was closed and detached right after attached to en0 in DHCP INIT phase, as result even the DHCP server sent back OFFER(I see server sent OFFER back from packet capture), but there is no persistent BPF socket since it is closed reception during the entire INIT phase. It is definitely an OS issue, is it a known issue? Please help understand Why BPF socket was close right after sending DISCOVER? Default 0x0 0 0 kernel: bpf26 attached to en0 by configd:331 2026-03-25 14:06:33.625851+0100 0x31dea Default 0x0 0 0 kernel: bpf26 closed and detached from en0 fcount 0 dcount 0 by configd:331 System log and packet capture attach, please check.

I am the developer of MIDIDeviceManager, an iOS and iPadOS application used by musicians to control external MIDI hardware during live performance. Before enabling any background execution mode, I would like to ask which architecture Apple intends for this type of application. What the application does The app organises the patches of a musician's MIDI instruments into Pads, Scenes and Setlists so they can be recalled during a performance. It sends MIDI to external hardware such as guitar processors, synthesisers and vocal processors, and it also receives incoming MIDI that triggers its own Scenes — typically from a Bluetooth foot controller, a wired MIDI controller, or another app on the same device. Its purpose is to function as the software equivalent of a programmable hardware MIDI controller. It is not a lyrics app or an audio player, and it produces no audio. The problem During a performance, musicians commonly run more than one app. A typical setup is lyrics or chord charts displayed in one app while a Bluetooth foot controller recalls presets on a Line 6 Helix through MIDIDeviceManager. This requires the app to keep receiving and processing incoming CoreMIDI events while another app is frontmost. Once iOS suspends the app, those events are no longer delivered and the foot controller stops working. This affects iPhone as much as iPad. Several of my TestFlight users perform with iPhone alone, where the device sits on a stand and is not touched during a song. What I have observed I tested this directly on an iPhone 17 Pro Max. With two apps running simultaneously, an app legitimately using the audio background mode continued to receive and act on incoming CoreMIDI events from a Bluetooth foot controller while backgrounded. At the same moment, MIDIDeviceManager received nothing once iOS suspended it. This suggests that, under certain circumstances, an app executing under an appropriate background mode may continue receiving CoreMIDI while backgrounded. Background modes considered audio — appears to provide the required behaviour, but my app produces no audio output. I do not wish to declare a background capability that does not accurately describe what the app does. bluetooth-central — does not appear applicable, since Bluetooth MIDI connections are established through CoreMIDI and managed by the system MIDI server rather than by my own Core Bluetooth session. I have not been able to identify any mode intended for continuous MIDI reception, so UIBackgroundModes is currently empty. A previous rejection An earlier submission did declare audio, and was rejected under Guideline 2.5.4 on 7 July 2026 (submission ID eab58179-8177-4d05-9c37-5e1006828a96): "The app declares support for audio in the UIBackgroundModes key in the Info.plist but we are unable to locate any features that require persistent audio. Background audio is intended for use by apps that provide audible content to the user while in the background, such as music player, music creation, or streaming audio apps." That assessment is correct — the app produces no audio, and I removed the key. But the functional requirement remains: the app needs to receive MIDI while another app is frontmost. I am asking here rather than resubmitting, because I would rather understand the intended architecture than guess again. My questions Which background mode, if any, is appropriate for an app whose purpose is to continue receiving and processing incoming CoreMIDI events while another app is frontmost? If background MIDI reception is supported, is CoreMIDI expected to continue delivering incoming MIDI to a backgrounded app, or is there a different recommended architecture for apps of this type? If the answer is that no background mode applies and this capability is not available to apps of this kind, I would very much appreciate knowing that clearly. I can then document the limitation for my users and design accordingly rather than pursue an unsupported approach. My objective is not to find a workaround, but to implement this the way Apple intends professional MIDI applications to work. Thank you.

Is anyone else completely stuck trying to enroll in the Apple Developer Program and trapped in an endless Tier 1 support loop? I am trying to complete my enrollment, but I am entirely blocked at the final step. I can select my entity and agreement, but before any payment screen even loads, the system crashes and throws this modal: "Contact Us to Continue - There may be an issue with your account that needs to be resolved before you can continue." Our app is already live on other platforms, and this backend block is actively delaying our iOS launch. I contacted Developer Support over a week ago, and the responses have been entirely automated scripts that ignore the actual technical issue: First response: Asked for my SEID, device model, serial number, government ID, and screen recordings. I provided all of it immediately. Second response: "Great news. We've made some changes on our end... try again." (Nothing changed. The exact same error appeared. I sent a screenshot proving it.) Third response: Completely ignored the screenshot and told me to "do the manual payment... Try to use different payment methods." The core issue: It is physically impossible to try a different payment method because the system errors out before the payment page even exists. For context, I am doing this on a MacBook Pro M4 and have replicated the exact same bug across multiple devices. Has anyone successfully gotten a backend account block like this escalated past Tier 1 support? How do I get an actual engineer or account specialist to look at this instead of getting a generic script every 24 hours? Any help or escalation advice would be massively appreciated.

Hi everyone, I’m trying to enroll in the Apple Developer Program using the Apple Developer app on my MacBook. Originally, my enrollment became stuck before the payment step. Apple Developer Support withdrew my previous enrollment and confirmed that I could enroll again through the Developer app. The app now correctly shows “Enroll Now”, but when I click it, it immediately displays: “Unable to Continue. Contact support.” The error appears immediately, and the enrollment flow never starts—I don’t reach the terms, identity verification, or payment screens. I’ve already: Updated to the latest macOS. Installed the latest Apple Developer app. Verified that iCloud is enabled. Confirmed I’m using the same Apple ID everywhere (I only have one Apple ID). Restarted my Mac and signed out/in again. Tried different internet connections. Apple Developer Support has already reset my enrollment once, but the issue still persists. I’ve also replied to my support case with screenshots showing the problem. Has anyone experienced this after an enrollment reset? If so, what resolved it? Any advice would be greatly appreciated. Thank you!