Overview

I'm building a freediving app for Apple Watch Ultra using the shallow depth entitlement (com.apple.developer.submerged-shallow-depth-and-pressure). My app uses WKExtendedRuntimeSession with the underwater-depth background mode, and it works correctly — the session starts, Water Lock activates automatically, and Crown hold water ejection ends the session as expected. However, the app does not appear in Settings > General > Auto-Launch > When Submerged on the watch. Other third-party apps (including one that hasn't been updated in ~2 years and presumably only has the shallow entitlement) do appear in this list. My configuration: WKBackgroundModes: ["underwater-depth", "workout-processing"] WKSupportsAutomaticDepthLaunch: true (Boolean, in watch app Info.plist) Entitlement verified in both the signed binary and provisioning profile watchOS 26.3, Apple Watch Ultra 2 Tested with: development build, TestFlight, and direct Xcode deploy. Watch restarted after each. The app does not appear in any case. The documentation at https://developer.apple.com/documentation/coremotion/accessing-submersion-data states: "Adding the underwater-depth Background Mode capability also adds your app to the list of apps that the system can autolaunch when the wearer submerges the watch." Does auto-depth-launch require the full depth entitlement (com.apple.developer.submerged-depth-and-pressure), or should the shallow entitlement be sufficient? Is there an additional step required for the app to appear in the When Submerged list? Any guidance appreciated.

Description Our app, Octory, allows users to create onboarding and communication workflows composed of slides containing various UI components, including embedded video players powered by AVPlayerView. Since macOS 26.4 Beta, the app crashes at launch whenever a workflow contains a video component. Workflows without video components load and render without issue, which points to a regression in AVKit's player control rendering pipeline. As anyone seen similar behaviour when using AVKit or is it something we do not do properly? Expected Behavior The app opens and renders the workflow, including the embedded video component. Actual Behavior The app briefly launches and immediately crashes with SIGABRT on the main thread. Crash Analysis Key takeaways for anyone investigating: Root cause — abort() inside NSImageSymbolConfiguration The crash occurs entirely within Apple frameworks, with no third-party code in the faulting call chain (aside from the app's entry point). The sequence is: AVPlayerItem finishes loading and fires a KVO notification that it is ready to play (_updateCanPlayAndCanStepPropertiesWhenReadyToPlayWithNotificationPayload:) This KVO chain propagates through NSKeyValueDidChange up to AVPlayerView, which calls _updateVideoGravityType AVPlayerControlsViewController responds by calling _updateZoomButtonImage, which asks AVPlayerControlsConfigurator for a configured SF Symbol via +[NSImage(AVAdditions) avkit_imageWithSymbolName:textStyle:scale:accessibilityDescription:] The symbol rendering hits -[NSImageSymbolConfiguration _getEffectivePointSize:glyphWeight:glyphSize:backfilledWithFont:scale:], which calls abort() The entire crash stack is in AppKit (NSImage / NSImageSymbolConfiguration) and AVKit — no application code is involved in the faulting path. The abort() suggests a precondition or assertion failure inside the symbol configuration logic, possibly due to an invalid or nil font/text style being passed during the zoom button image setup. This is triggered automatically the moment an AVPlayerItem becomes ready to play and AVKit attempts to render its transport controls. There is no way for the application to intercept or work around this. Relevant stack frames (Thread 0 — main thread) 3 AppKit -[NSImageSymbolConfiguration _getEffectivePointSize:glyphWeight:glyphSize:backfilledWithFont:scale:] + 440 ← abort() here 4 AppKit -[NSImageSymbolRepProvider _bestRepresentationForImage:hints:] + 404 11 AVKit +[NSImage(AVAdditions) avkit_imageWithSymbolName:textStyle:scale:accessibilityDescription:] + 332 12 AVKit -[AVPlayerControlsConfigurator configuredSymbolForImageName:] + 92 13 AVKit -[AVPlayerControlsViewController _updateZoomButtonImage] + 160 14 AVKit -[AVPlayerControlsViewController setVideoGravityType:] + 52 15 AVKit -[AVPlayerView _updateVideoGravityType] + 1056 28 AVFCore -[AVPlayerItem didChangeValueForKey:] + 56 29 AVFCore -[AVPlayerItem _updateCanPlayAndCanStepPropertiesWhenReadyToPlayWithNotificationPayload:updateStatusToReadyToPlay:] + 660 Additional Notes Removing the video component from the workflow (i.e. not instantiating AVPlayerView) resolves the crash entirely. The crash is 100% reproducible on every launch. This behavior was not present on macOS 26.3 or any prior release. The app was not recompiled — the same binary that works on 26.3 crashes on 26.4 Beta & 26.4. Environment Detail Value OS macOS 26.4 Hardware MacBook Pro M1 (MacBookPro17,1)

Hola, compre el 25 de marzo la membresía de desarrollador, pero aun mi cuenta sale pendiente, no subo datos de empresa ya que soy freelance. Cuanto podría tardar la aprobación de la cuenta. Ya mande dos ticket a soporte pero nada responden

When launching an app, AppStore Connect has some very specific requirements to the media (screenshots) used for the store listing. Right now the primary screenshots requires a 6.5 inch size. This is fine, of course, but why doesnt it list which iphones has this size, so I dont have to google my way to this answer? Its such a small thing, but would help so much

Hi everyone, I am an iOS developer from Ecuador and I am writing to ask if there's any way to fix my issue. After some initial struggling with my phone number not being able to receive Apple verification messages, I was able to register an Apple ID and use that Apple ID to enroll into the Apple Developer Program. Currently, I am stuck at the step of paying the subscription fee. When I try to pay for the 99$ enrollment fee, I receive an "Order Acknowledgement" e-mail from Apple but the payment is never processed. I have tried with multiple debit cards: 2 times with my main crypto debit card emitted from a Hong Kong bank 1 time with a debit card emitted from a local Ecuadorian bank 1 time with a debit card emitted from a US bank In all these cases the result is the same: the same order acknowledgement e-mail but nothing more happens. I even tried asking the support via e-mail (the only method that is supported in my country), but no one replies. Does anyone have any tip on how to overcome this situation?

After updating to Xcode 26.4 and also the update on the simulator the copy paste feature in the simulators doesn't work anymore and i can't build my app without it because the user has to copy and paste api keys in it. Is there an solution for it I have tried to install an other simulator ios version but then the simulator doesn't work on the the new xcode. Have someone already found an solution?

Hello, I am facing a critical technical blocker regarding the Family Controls (Screen Time API) entitlement for my app extensions. Current Situation: My parent app (com.hayashikento.FocusPact) is already approved for the Family Controls (Distribution) entitlement. However, the associated DeviceActivityMonitorExtension (com.hayashikento.FocusPact.FocusPActMonitor) and ReportExtension (com.hayashikento.FocusPact.ReportExtension) are still pending entitlement approval. Technical Issue: Because the extensions lack the Distribution entitlement, ManagedSettings and DeviceActivity triggers (like intervalWillEndWarning) are ignored by the system when testing via TestFlight or in a non-development environment. As a result, I am unable to verify the core "automatic re-blocking" logic and "usage reporting" features in a real-world scenario. This has completely halted the final QA and TestFlight phase of my project. Requests: Could an Apple engineer verify if these extension IDs can be linked to my existing approved parent app entitlement? Is there a specific process to expedite the "linking" of extensions when the main app is already authorized? App Details: Parent App Bundle ID: com.hayashikento.FocusPact Extension IDs: com.hayashikento.FocusPact.FocusPActMonitor, com.hayashikento.FocusPact.ReportExtension Apple ID (App)6759132649 I have already submitted the web request forms, but the lack of synchronization between the parent app and extensions is preventing my MVP launch. Any assistance would be greatly appreciated. Thank you.

Hello. Our application performs encoding and decoding of large json files which sometimes may take up to 1,5GB of RAM memory. We understand that this may be a problem for devices with low RAM memory (3GB). But before iOS 26.4 we didn't have much occurrences (3 for the last 90 days). Starting from iOS 26.4 it started to crash a lot. Can the reason be that iOS 26.4 occupies more RAM memory so there is less memory left for our app? Or maybe starting from iOS 26.4 there is less RAM memory allocated per app? The crash message is Fatal error: failed to allocate 392 bytes of memory with alignment 8

Team ID: MB9VR977ND We have changed apple developer account for the our application, after changing account we have submitted app for notarization multiple times but all showing in-progress without any logs. do we need to wait until this passed from apple side ? does submitting many request has any issue ? Submission id: 8c5ac51d-bcd3-4fc4-9b38-671e5ea2bf14

Inquiry) Inquiry Regarding USB Network Connectivity Between an iPad (Wi‑Fi Model) and an Embedded Linux Device An embedded device (OS: Linux) is connected to an iPad (Wi‑Fi model) using a USB‑C cable. The ipheth driver is installed on the embedded device, and the iPad is recognized correctly. A web server is running on the embedded device. To launch a browser on the iPad and access the web server running on the embedded device via a USB network connection. Based on our verification, the iPad is not assigned an IP address, and therefore communication with the web server on the embedded device is not possible. We would appreciate it if you could provide guidance on the following questions. We would like to assign an IP address to the iPad (Wi‑Fi Model) so that it can communicate with the embedded device over a USB network connection. Is there a way to achieve this through the standard settings on the iPad? If this cannot be achieved through settings alone, are there any existing applications that provide this functionality? If no such application currently exists, is it technically possible to develop an application that enables this capability on iPadOS? Information) The USB‑C port on the embedded device is fixed in HOST mode. The embedded device operates as the USB host, and the iPad operates as a USB device. When a cellular model iPad is connected and “Personal Hotspot” is enabled, an IP address is assigned via DHCP, and we have confirmed that the web server can be accessed from the iPad’s browser. We are investigating whether a similar solution is possible with a Wi‑Fi model iPad.

When opening a project or workspace in Xcode 26.4 the most recently active scheme is not restored. Instead, the scheme reverts to the first scheme in the list. I've tried opening and closing Xcode a few times, and removing the user data for a workspace. No luck. Any suggestions or workarounds?

Hi, I have an app that displays lines of text, that I want to make accessible with VoiceOver. It's based on a UITextView. I have implemented the UIAccessibilityReadingContent protocol, following the instructions in https://developer.apple.com/videos/play/wwdc2019/248 and now users can see the screen line by line, by moving their fingers on the screen. That works fine. However, users would also like to be able to use left-flick and right-flick to move to the previous or next line on the screen, and I haven't been able to make this work. I can see that left-flick triggers accessibilityPreviousTextNavigationElement and right-flick triggers accessibilityNextTextNavigationElement, but I don't understand what these variables should be.

DJI's DNG files display abnormally in the Apple Photos app on iOS devices, with dark areas showing as very black, but the same files appear normal in Photoshop. I'm curious about what causes this issue.

Hello, I am facing a critical technical blocker regarding the Family Controls (Screen Time API) entitlement for my app extensions. Current Situation: My parent app (com.hayashikento.FocusPact) is already approved for the Family Controls (Distribution) entitlement. However, the associated DeviceActivityMonitorExtension (com.hayashikento.FocusPact.FocusPActMonitor) and ReportExtension (com.hayashikento.FocusPact.ReportExtension) are still pending entitlement approval. Technical Issue: Because the extensions lack the Distribution entitlement, ManagedSettings and DeviceActivity triggers (like intervalWillEndWarning) are ignored by the system when testing via TestFlight or in a non-development environment. As a result, I am unable to verify the core "automatic re-blocking" logic and "usage reporting" features in a real-world scenario. This has completely halted the final QA and TestFlight phase of my project. Requests: Could an Apple engineer verify if these extension IDs can be linked to my existing approved parent app entitlement? Is there a specific process to expedite the "linking" of extensions when the main app is already authorized? App Details: Parent App Bundle ID: com.hayashikento.FocusPact Extension IDs: com.hayashikento.FocusPact.FocusPActMonitor, com.hayashikento.FocusPact.ReportExtension Apple ID (App)6759132649 I have already submitted the web request forms, but the lack of synchronization between the parent app and extensions is preventing my MVP launch. Any assistance would be greatly appreciated. Thank you.

Hi everyone, I recently got rejected under Guideline 1.1.1 - Safety - Objectionable Content and I'm struggling to understand how my app falls under this category. Looking for advice from anyone who's dealt with similar rejections. What the app does: AutoSignal is a vehicle notification app designed for the Bulgarian market. It solves a very common real-world problem - needing to contact a car owner when their vehicle is double-parked, blocking you in, has its lights left on, or has been hit/damaged while parked. The core flow is: A user scans a license plate using their phone camera If the car owner is registered in the app, they receive an anonymous push notification (e.g., "Your car with plate XX 1234 XX is blocking someone" or "Your lights are on") The car owner can then take action Users can also report vehicle damage cases with temporary witness notes that auto-expire after 7 days. Why I believe it doesn't violate 1.1.1: The app does not expose any personal information. Notifications are fully anonymous - the sender never sees the car owner's identity, phone number, or any personal details. License plates are public information - they are visible on every car on every street. The app doesn't scrape or store plate databases. The use cases are entirely constructive: notifing someone their car is being towed, blocked in, damaged or has lights on. There is no messaging or direct contact between users - only predefined notification templates. Damage case witness notes are temporary (7-day expiry) and designed to help with insurance claims, not harassment (everything is opt-in model). What Apple said: "Issue Description The app includes content that could be considered defamatory or mean-spirited. Specifically, your app allows users to collect license plate information and send activity associated with the license plate. Content that is likely to humiliate, intimidate, or harm a targeted individual or group is not appropriate for the App Store." What I've tried/considered: Adding content moderation and reporting features Limiting notification frequency (rate limiting on the backend) Requiring car owners to opt-in by registering their own plates before they can receive any notifications Has anyone successfully appealed a 1.1.1 rejection for a similar use case? Should I request a call with the App Review Board? Any suggestions on what additional safeguards I could highlight or implement to address their concerns? Thanks in advance for any guidance.

Region: Türkiye Hello, My Digital Services Act verification has been in review for an extended period of time, and I am unable to proceed. I have submitted my official residence document obtained via e-Government (QR-verified). However, in Türkiye, these documents are only issued in Turkish and cannot be provided in English. To assist with the review, I also included a manual English translation of the document, while keeping the original file unchanged. Despite this, my submission remains in review without any feedback or request for additional information. Has anyone experienced a similar issue with address verification in Türkiye? Is there any specific format or document that Apple accepts in this case? Any guidance would be greatly appreciated. Thank you.

We probably triggered a bug within Rosetta: https://github.com/docker/desktop-feedback/issues/230

Environment Xcode 26.5 beta iOS 26.5 beta Using AccessorySetupKit + AccessoryTransportExtension framework Three extensions: AccessoryTransportAppExtension, AccessoryTransportSecurityExtension, AccessoryDataProviderExtension Background Everything worked correctly on iOS 26.4 beta. All three extensions shared the entitlement com.apple.developer.accessory-transport-extension, and the system launched them as expected. After upgrading to iOS 26.5 beta (both Xcode and device), the app compiles and runs, the accessory pairs and connects successfully (state = authorized, BLE connected, notification forwarding = allow), but none of the extensions are launched by the system. Investigation Captured system Console logs from the device and found these errors from deviceaccessd: error deviceaccessd ### Extension 'com.huami.NotificationForwardingDemo.AccessoryDataProviderExtension' is missing entitlement: com.apple.developer.accessory-data-provider for com.apple.accessory-data-provider error deviceaccessd ### Extension 'com.huami.NotificationForwardingDemo.AccessoryTransportSecurityExtension' is missing entitlement: com.apple.developer.accessory-transport-security for com.apple.accessory-transport-security It appears that iOS 26.5 now requires per-extension-type entitlements instead of the shared one. On iOS 26.4, all three extensions used com.apple.developer.accessory-transport-extension and it worked. On iOS 26.5, deviceaccessd now expects com.apple.developer.accessory-transport-security for the security extension and com.apple.developer.accessory-data-provider for the data provider extension. The transport app extension did not report an error, so it may still accept the old entitlement. Attempted Fix Changed the entitlement keys in the .entitlements files to match what deviceaccessd expects. Xcode fails to build with: ▎ Entitlement com.apple.developer.accessory-data-provider not found and could not be included in profile. This likely is not a valid entitlement and should be removed from your entitlements file. Root Cause Checked Apple Developer Portal — only one capability is available: "Accessory Transport Extension", which maps to com.apple.developer.accessory-transport-extension. There are no separate capability options for the new entitlements. The iOS 26.5 beta system requires new per-extension-type entitlements, but the provisioning system does not yet support them. This makes it impossible to build a working AccessoryTransport app on iOS 26.5 beta. Request Please either add the new entitlement capabilities (com.apple.developer.accessory-transport-security, com.apple.developer.accessory-data-provider) to the Apple Developer Portal, or restore backward compatibility with com.apple.developer.accessory-transport-extension in deviceaccessd.

I purchased the Apple Developer Program on March 26, 2026. Payment went through immediately. I have the invoice (UA31019584), the order confirmation (W1318171870), and €99 charged to my card. Apple had no problem taking my money within seconds. Five days later: Account status: Pending Portal still says "Purchase your membership" and asks me to pay again App Store Connect: inaccessible TestFlight: inaccessible I contacted Apple Developer Support on day one — both by email and callback request. I now have three open cases and have received exactly zero responses: Case ID: 102856462218 — Program Purchase and Renewal Case ID: 102853916886 — Program Purchase and Renewal Case ID: 102853919455 — Program Enrolment Not a single acknowledgment. Not even an automated "we're looking into it." Nothing. My app is built and ready. I have testers waiting. I cannot distribute anything — not even through TestFlight — because Apple took my payment and then stopped responding. I see dozens of threads on this forum from developers with the exact same problem going back months. Paid memberships stuck on Pending, no activation, support completely unresponsive. This is not an isolated case — this is a systemic failure in the enrollment system that Apple has apparently chosen to ignore. I am based in the EU and I am fully prepared to pursue this through consumer protection channels if this is not resolved. You cannot charge someone for a service and then refuse to provide it or even respond to inquiries. For the world's biggest tech company that is built on software, this is practically a joke. I don't remember the last time seeing an issue like this from any other company in my whole life living on this planet. New developers practically cannot join and publish apps on Apple anymore. But if you are happy to pay, they will let you. And after payment, they will put a notice at the top reminding you to 'complete your purchase' and pay again. Is this really Apple or has this company been hijacked by some retard?

Hello Apple Developer Support / StoreKit Team, We recently observed a behavior regarding the appAccountToken in App Store Server Notifications v2 that seems to completely contradict the official documentation. According to the Set App Account Token documentation: The same appAccountToken continues to apply to renewal transactions if the customer upgrades, downgrades, or cross-grades the subscription. However, we encountered a scenario where an active in-app crossgrade resulted in an updated/overwritten appAccountToken inside the subsequent JWSRenewalInfoDecodedPayload, despite our backend never calling the Set App Account Token REST API. Our Observation: A user subscribes to our 1-month plan (Product A). Apple generates an originalTransactionId bound to their initial appAccountToken (Token A). Later, a crossgrade to a 1-year plan (Product B) is initiated from within the app while the user is logged into a different account in our system (Token B), but using the same underlying Apple ID on the device. When the crossgrade takes effect at the next renewal date, we receive a DID_RENEW webhook. The Anomaly (See Attached Screenshots): Upon decoding the JWSRenewalInfoDecodedPayload from the webhook, we noticed that the appAccountToken had unexpectedly changed to the new token (Token B). As shown in the attached redacted screenshots: Screenshot 1 (Before/Original): JWSRenewalInfoDecodedPayload for Product 00001 shows the appAccountToken ending in ...e9a. Screenshot 2 (After Crossgrade): JWSRenewalInfoDecodedPayload for Product yearly_saver shows the appAccountToken has mutated to ending in ...507, even though the originalTransactionId remains exactly the same. To reiterate, our server did not call the POST /inApps/v1/subscriptions/appAccountToken/{originalTransactionId} endpoint to manually overwrite this token at any point. Our Questions: Is this the intended StoreKit 2 behavior? Does Apple automatically overwrite the base appAccountToken in the RenewalInfo if a new token is somehow associated during an active in-app crossgrade transaction? If this is intended, could the documentation be clarified? The current phrasing strongly suggests the token is permanently locked to the initial purchase and will never change during crossgrades unless the REST API is explicitly called. While this behavior is actually quite helpful for our backend to track multi-account users, we want to ensure we aren't relying on an undocumented bug that might be patched unexpectedly. Any insights from the StoreKit engineering team would be highly appreciated. Thank you!