Overview

Hello, I'm currently developing an iOS app that uses SensorKit. Everything works fine in development and testing — the app correctly requests and receives SensorKit permissions on test devices. In my App ID configuration, the SensorKit Reader Access entitlement (com.apple.developer.sensorkit.reader.allow) is included and visible in Xcode under the project’s entitlements list. However, when I try to archive and distribute the app, I get the following errors in Xcode: Provisioning profile failed qualification Profile doesn't support SensorKit Reader Access. Provisioning profile failed qualification Profile doesn't include the com.apple.developer.sensorkit.reader.allow entitlement. Even though my provisioning profile includes this entitlement, Xcode still refuses to distribute the app. Here’s what I’ve confirmed so far: The provisioning profile lists com.apple.developer.sensorkit.reader.allow in its entitlements. SensorKit works perfectly in debug and development builds. The issue only occurs when attempting to distribute (Archive → Distribute App). Could this be because my account has only development entitlement for SensorKit and not the distribution entitlement? If so, how can I verify or request the proper distribution entitlement for SensorKit Reader Access? Thank you for any guidance or confirmation from Apple regarding this entitlement behavior.

Hello! I'm currently working on Liquid Glass support for my app. I understand that starting with iOS 26, standard buttons like "Close" or "Done" have shifted from text buttons to using SF Symbols, as mentioned in the Human Interface Guidelines under "Icons". However, on iOS 18 and earlier, the flat text button style remains the standard. I am unsure about the best approach for backward compatibility: Branch by OS version: Keep text buttons for older OS versions and use SF Symbols for iOS 26+. Concern: This increases the number of conditional branches, potentially reducing code readability and maintainability. Adopt SF Symbols universally: Use SF Symbols for all versions. Concern: I feel that SF Symbols do not fit well (look inconsistent or out of place) with the flat design language of iOS 18 and earlier. What would be the recommended approach in this situation?

Since updating to iOS 26.0 (and confirmed on 26.1), ARBodyTrackingConfiguration no longer detects a valid ARBodyAnchor on devices with LiDAR (e.g., iPhone 15 Pro, iPhone 17 Pro Max). This issue reproduces in custom projects and Apple’s official sample “Capturing Body Motion in 3D”. The AR session runs normally, but the delegate call: func session(_ session: ARSession, didUpdate anchors: [ARAnchor]) never yields an ARBodyAnchor with valid joint transforms. All joints return nil when calling: body.skeleton.modelTransform(for: jointName) resulting in 0 valid joints per frame. Environment • Device: iPhone 17 Pro Max (LiDAR) • iOS: 26.0 / 26.1 • Xcode: 16.0 (stable) • Framework: ARKit + RealityKit • Configuration used: config.worldAlignment = .gravityAndHeading config.isAutoFocusEnabled = true config.environmentTexturing = .none session.run(config) Also tested: with and without frameSemantics = .bodyDetection Expected Behavior ARBodyAnchor should be detected and body.skeleton should contain ~89 valid joints with continuous updates.

I’ve officially given up trying to release my app on iOS. Apple’s latest rejection quotes: • Guideline 5.1.5 – Location Services “The app uses location data for features that are not relevant to a user’s location. Specifically, the app is not functional when Location Services are disabled. To resolve this issue, please revise the app so that the app is fully functional without requiring the user to enable Location Services.” • Guideline 5.1.1 – Data Collection and Storage Complaining that the app “encourages or directs” users to go to Settings to enable location. My app is literally built around live location. The entire point is: you walk the circuit, see telemetry synced with where you are. No location, no app. That is the product. Apple wants the app to be “fully functional” without the one thing it needs to exist. That’s like rejecting a camera app because it doesn’t “fully function” with no camera permission. What makes this worse is the complete lack of consistency. Every time I fix what they ask, the next review comes back with a different problem, instead of a clear list of issues to solve in one go. No stable checklist, no coherent interpretation, just moving goalposts and copy-paste template replies that ignore reviewer notes and how the app actually works. They don’t seem to understand how incapable this process is for serious, niche apps. It’s not about quality or privacy at this point, it’s about box-ticking and cover-your-back behaviour. Meanwhile, small devs are supposed to burn weeks rewriting core flows just to satisfy someone who clearly hasn’t even tried to use the app properly. I’ve decided to keep the app Android-only. iOS simply isn’t worth fighting with a review system that can’t even be consistent with its own guidelines. Has anyone else had similar problems with Apple inventing a new issue every review instead of giving you one clear, stable set of requirements to fix?

Using desaturated mode on an image in a widget will break any links or buttons that use the image as their 'label'. Using the following will just open the app as if there was no link at all - therefore just using the fallback userActivity handler, or any .widgetURL() urls provided. Link(destination: URL(string: "bug://never-works")!) { Image("puppy") .widgetAccentedRenderingMode(.desaturated) } The same goes for buttons: Button(intent: MyDemoIntent()) { Image("puppy") .widgetAccentedRenderingMode(.desaturated) } I've tried hacky solutions like putting the link behind the image using a ZStack, and disabling hit testing on the image, but they don't work. Anything else to try? Logged as Feedback #15152620.

Hi Apple Staff / App Review Team, We’re following up because we haven’t received a substantive reply to our previous forum post or our messages in App Store Connect. Context (unchanged): Our last update focused on performance/stability, bug fixes, and numeric balance tuning (difficulty/rewards). We also added a small, user-initiated News panel (globe icon in the main menu) that displays one static announcement image and can be closed at any time. There are no links, no navigation, no login/UGC/ads, and no executable content in that panel. We don’t collect personal data (no IDFA/ATT). Safeguards already in place: Post-release changes are restricted to numeric balance values only (no feature toggles, no navigation changes). The announcement is strictly read-only (one static asset from our own domain) with an offline fallback. Internal release policy forbids any post-review feature switches or concept changes. What we’re asking for: Specific guidance on what observation(s) led to the 3.2(f) determination. Whether a resubmission under the constraints above is acceptable (we can tighten further if preferred). We’re ready to provide any materials immediately and submit a new build as soon as we receive direction. Thank you for your help—could you please escalate or advise on next steps?

Hi there. I work for a company that develops a SaaS service. Users have to register before using the SaaS as all the data they save in the application must be linked to their account. Why that? Because it is a multi-platform SaaS currently running on web and Android, so, the user must have access to his/her contents on every platform he/she intends to use. Also, some features depend on our back-end system to process the data and return an analysis based on them. That said, Apple is rejecting our app claiming that we should not require the user to register an account before purchasing a subscription. The problem is: how can the user store their data in our servers without an account? We do offer a free tier account, but the users must be logged in to have access to their data and have the analysis performed by the back-end service. Does anybody have gone through a similar issue? I need clarifications on how to solve this. Thanks in advance.

My app has been waiting for review for over 7 days. I know it's nearing the holidays but at most I think it should take 5d. Should I maybe developer reject my app and resubmit it? I have already tried expedited review.

Hello, I recently was rejected for the following reason: However, your app does not comply with: Legal 5.1.1 We noticed that your app requires users to register with personal information to access the app’s content and purchase in-app purchase products that are not account based. Apps cannot require user registration prior to allowing access to app content and features that are not associated specifically to the user. User registration that requires the sharing of personal information must be optional or tied to account-specific functionality. To resolve this issue, please revise your app to not require users to register before purchasing in-app purchase products that are not account based. You may explain to the user that registering will enable them to access the purchased content from any of their iOS devices and provide them a way to register at any time, if they wish to later extend access to additional devices. Resources See guideline 5.1.1(v) - Account Sign-In to learn more about our requirements for apps with account-based content and features. I replied: We require the user to login/sign up because it relates directly to the core functionality of our App. If the user deletes the App and chooses to reinstall it, his data will be saved on our server because the sign up system allows their data to be saved. This allows the User to restore all his in-app purchases and for our database to always keep track of the User’ in-app purchased consumable items. Apple requires a restore feature for in app purchases and we allow the user to restore his in app purchases by tying their account to an email or social media login. The login is required to prevent users from hacking the app. The diamond and coin systems are stored on our back end database servers. Once a user logins in, the back end stores how much coins and diamonds are associated with that account. This prevents users from manually altering how many coins or diamonds they have. It preserves the integrity of the app and the Apple App Store itself. Our servers store all user progression and data. Without the login / sign up system, we cannot sync the back end database. The login / sign up feature is crucial to the functionality of the app to prevent hacking and to keep track of the users database and more importantly, keep account and restore capabilities available for any in app purchases. To which the review board responded with: Although requesting that users register to for tracking users’ purchases and game progresses is acceptable, requiring users to fully register for an account before entering the game is not. Users should be allowed to access none account-based features before registration and login. You may also choose to alert users that accessing game without binding an account may result in losing game progress or in-app purchase items. To resolve this issue, please revise your app to let users freely access your app’s non account-based features, such as accessing the game, prior to registration or login. Once the user decides to use account-based features, the app may present the registration or login feature at that time. My understanding is this... I need to implement a "play as guest" mode where Users do not need to register. This will automatically generate an account for that User. However, am I allowed to require the user to register before conducting any in-app purchases, or other activities on the app?? What is this asking for? Do I need to allow the guest user to be able to purchase and do all the things a registered user can?

Testing Environment: iOS: 26.0 Beta 7 Xcode: Beta 6 Description: We are implementing the new BGContinuedProcessingTask API introduced in iOS 26. We have followed the official documentation and WWDC session guidance to configure our project. The Background Modes (processing) and Background GPU Access capabilities have been added in Xcode. The com.apple.developer.background-tasks.continued-processing.gpu entitlement is present and set to in the .entitlements file. The provisioning profile details viewed within Xcode explicitly show that the "Background GPU Access" capability and the corresponding entitlement are included. Despite this correct configuration, when running the app on supported hardware (iPhone 16 Pro), a call to BGTaskScheduler.supportedResources.contains(.gpu) consistently returns false. This prevents us from setting request.requiredResources = .gpu. As a result, when the BGContinuedProcessingTask starts without the GPU resource flag, our internal Metal-based exporter attempts to access the GPU and is terminated by the system, throwing an IOGPUMetalError: Insufficient Permission (to submit GPU work from background). We have performed extensive debugging, including a full reset of the provisioning profile (removing/re-adding capabilities, toggling automatic signing, cleaning build folders, and reinstalling the app), but the issue persists. This strongly suggests a bug in the iOS 26 beta where the runtime is failing to correctly validate a valid entitlement. Additionally, we've observed inconsistent behavior across devices. On an A16-based iPad, the task submits successfully (BGTaskScheduler.submit does not throw an error), but the launch handler is never invoked by the system. On the iPhone 16 Pro, the handler is invoked, but we encounter the supportedResources issue described above. This leads us to ask for clarification on the exact hardware requirements for this feature. We hypothesize that it may be limited to devices that support Apple Intelligence (A17 Pro and newer). Could you please confirm this and provide official documentation on the device support criteria? Steps to Reproduce: Create a new Xcode project. In Signing & Capabilities, add "Background Modes" (with "Background processing" checked) and "Background GPU Access". Add a permitted identifier (e.g., "com.company.test.*") to BGTaskSchedulerPermittedIdentifiers in Info.plist. In application(_:didFinishLaunchingWithOptions:) or a ViewController's viewDidLoad, log the result of BGTaskScheduler.shared.supportedResources.contains(.gpu). Build and run on a physical, supported device (e.g., iPhone 16 Pro). Expected Results: The log should indicate that BGTaskScheduler.shared.supportedResources.contains(.gpu) returns true. Actual Results: The log shows that BGTaskScheduler.shared.supportedResources.contains(.gpu) returns false.

I try saving the value of NSURLVolumeURLKey when creating a bookmark. When resolving the bookmark later I pass the bookmark data to +resourceValuesForKeys:fromBookmarkData: but always pull out "file:///" which is wrong. In contrast the value for NSURLVolumeURLForRemountingKey is properly saved and restored using the same method.

I have a search field and a List of search results. As the user types in the search field, the List is updated with new results. Crucially, with each update, I want to reset the List's scroll position back to the top. To achieve this, I'm using the following .onChange() modifier along with a ScrollViewReader: .onChange(of: searchQuery) { _, newQuery in Task { searchResults = await searchLibrary(for: newQuery) scrollViewProxy.scrollTo(0, anchor: .top) } } My List uses index-based IDs, so scrolling to 0 should always go to the first item. The above code works, but crashes if searchResults is empty because there is no item in the List with an ID of 0. (As a side note, it seems rather excessive for the scrollTo() method to trigger a full-on crash just because the ID is not found; I don't think this should be anything more than a warning, or the method should throw an error that can be caught). To work around this, I added an isEmpty check, so we only attempt the scroll if the array is not empty: .onChange(of: searchQuery) { _, newQuery in Task { searchResults = await searchLibrary(for: newQuery) if !searchResults.isEmpty { scrollViewProxy.scrollTo(0, anchor: .top) } } } However, even with this check, I was seeing rare crashes in production, consistent with a race condition. My guess is that when searchResults is updated, the view is not recreated immediately, so if scrollTo() is called too quickly, the List may not yet be seeing the latest update to the searchResults array. I figured that I could try to delay the calling of scrollTo() to give the view time to update: .onChange(of: searchQuery) { _, newQuery in Task { searchResults = await searchLibrary(for: newQuery) if !searchResults.isEmpty { DispatchQueue.main.async { scrollViewProxy.scrollTo(0, anchor: .top) } } } } However, even with this, I've just received a crash report pointing to the same issue (the first in about four months). I'm not able to reproduce the bug myself – so it definitely seems like a rare race condition, probably relating to the timing of view updates. I guess, I can insert another isEmpty check before calling scrollTo(), but I'm starting to wonder if it's even possible to guarantee that the item will be in the List when scrollTo() performs its action, and because this is so hard to reproduce, I can't really test any ideas. Does anyone have any idea how (and at what point) the ScrollViewReader reads the view's current state? What's the right way to approach debugging a problem like this? Moreover, does anyone have any better suggestions about how to handle resetting the List position? The reason I want to do this is because, if the user types, scrolls a bit, and then types some more, the new results appear above the fold where the user can't see them, leading to a confusing experience. I thought about switching to the newer .scrollPosition() modifier, but that's only iOS 18+ and only for ScrollViews, not Lists. Cheers!

A user of one of my apps reported that since the update to macOS 26.1 they are no longer able to scan Macintosh HD: the app used to work, but now always reports that Macintosh HD contains a single empty file named .nofollow, or rather the path is resolved to /.nofollow. Initially I thought this could be related to resolving the file from the saved bookmark data, but even restarting the app and selecting Macintosh HD in an open panel (without resolving the bookmark data) produces the same result. The user tried another app of mine with the same issue, but said that they were able to scan Macintosh HD in other App Store apps. I never heard of this issue before and my apps have been on the App Store for many years, but it looks like I might be doing something wrong, or the APIs that I use are somehow broken. In all my apps I currently use getattrlistbulk because I need attributes that are not available as URLResourceKey in all supported operating system versions. What could be the issue? I'm on macOS 26.1 myself and never experienced it.

I am new to Swift and iOS development, and I have a question about video capture performance. Is it possible to capture video at a resolution of 4032×3024 while simultaneously running a vision/ML model on the video stream (e.g., using Vision or CoreML)? I want to know: whether iOS devices support capturing video at that resolution, whether the frame rate drops significantly at that scale, and whether it is practical to run a Vision/ML model in real-time while recording at such a high resolution. If anyone has experience with high-resolution AVCaptureSession setups or combining them with real-time ML processing, I would really appreciate guidance or sample code.

iPhone, iPad, MacOS Build numbers are all the same but each actual platform reports the actual version.

Hey, There seems to be an inconsistency when capturing a photo using QualityPrioritization.Quality on the iPhone 17 Pro Main wide Lens. If you zoom above "2x" the output image always has "-2.0ev" bias in the meta data and looks underexposued. This does not happen at zoom levels above 2, or if you set the QualityPrioritization to .Balanced. See below: with .Quality with .Balanced This does not happen on the other lenses. I'm using a simple set up and it is consistent across JPEG and ProRAW capture. I have a demo project if that is useful. Thanks, Alex

在 iOS 平台使用 WKWebView 通过file://协议加载本地 HTML 文件时，存储在localStorage中的数据会在 App 后台切换、进程重启后偶尔丢失；但相同代码在安卓 / 鸿蒙平台无此问题。 现在的文档 仅明确了「默认数据存储（defaultDataStore）可将网站数据持久化到磁盘，非持久化存储（nonPersistent）仅存内存」的基础规则； 未提及「file://协议内容即使使用默认持久化存储，也会被归为临时内存存储」这一关键场景限制； 仅在WKURLSchemeHandler关联说明中隐含「自定义 URL 协议可处理 WebKit 原生不支持的 URL 方案」，但未直接关联file://的存储问题。 我找不到如何处理这个问题的官方文档，仅仅有其他的博客说需要增加http/https加载就没有这个问题。 请提供给我官方文档或者官方回复 关于出现这种file:/加载html出现问题的处理办法

The maximumExtendedDynamicRangeColorComponentValue should provide some value between 1.0 and maximumPotentialExtendedDynamicRangeColorComponentValue depending on the available EDR headroom if there is any content on-screen that uses EDR. This works fine in most scenarios but in macOS 26 Tahoe (including in 26.2) this seemingly breaks down when a third party external display is in HDR mode and the Mac goes to sleep and wakes up. After wake only a value of 1.0 is provided by the third party external display's NSScreen object, no matter what (although when the SDR peak brightness is being changed using the brightness slider, didChangeScreenParametersNotification is firing and the system should provide a proper updated headroom value). This makes dynamic tone-mapping that adapts to actual screen brightness impossible. Everything works fine in Sequoia. In Tahoe the user needs to turn off HDR, then go through a sleep/wake cycle and turn HDR back on to have this fixed, which is obviously not a sustainable workaround.

The top toolbar looks fine, but in the bottom toolbar, one of the layers is stretched into a capsule shape instead of an ellipse. Is this intended?

I'm using this library: https://github.com/Yummypets/YPImagePicker to capture photos. I've modified it slightly, and I'm using an older version. When testing on my iPhone 16e, ios 26, whenever I take a photo, I get the following two error messages: <<<< FigXPCUtilities >>>> signalled err=-17281 at <>:302 <<<< FigCaptureSourceRemote >>>> Fig assert: "err == 0 " at bail (FigCaptureSourceRemote.m:569) - (err=-17281) These error messages appear, but as far as I can tell, the photo comes through OK, and I can save the data no problem. I've even removed all my handling code to see if it was something I was doing. I don't really want to ship with these errors showing, but I also have no idea what can be causing this error to appear. chatgpt was not helpful diagnosing this. Does anyone know what can cause this error Is there a way I can see the source code to figure out if there's something I'm doing wrong here? It really seems like this is an internal apple error, or else I would have expected more details on the error relating to the code I've written. Any clues would be appreciated!