Overview

Hi. The WWDC video of the v2 weatherkit api showed some examples for the REST API. However, they were very limited. The documentation for the REST API is currently for the v1 weatherkit API. When will the documentation for the v2 API be released? There are some new features of the v2 that I would really like to use, but I can't without knowing the new v2 REST API specifications. Any guidance would be much appreciated. Thanks!

When a UIVisualEffect with glass effect view is added with opacity 0, it remains hidden as expected. But when changing it back to 1 should make it visible, but currently it stays hidden forever. The bug is only reproducible on iOS 26.1 and iOS 26.2. It does not happen on iOS 26.0. The issue is also not reproducible with UIBlurEffect. Only happens for Glass effect Here is the repro link

Hi everyone. I've downloaded the the 26.2 beta 2 and installed it on a device in the settings after i create a new sandbox test account i see the options in Age Assurance. The problem is i got the popup the first time i opened the application and decided to share, but after that i always get the following error: DeclaredAgeRange.AgeRangeService.Error.notAvailable I tried testing with different bundle id and different sandbox test account but still it doesn't work. How can i test the cases without erasing the device ?

My client has provided me with admin access to the Apple Developer console. However, when I log in, I am prompted to enroll in the Apple Developer Program. Should I proceed with the enrollment myself, or does the client need to complete the enrollment from their own account?

Using Xcode 26.1.1 on macOS 26.1 Tahoe, I noticed the ability to add a new value seems hidden or disabled. I'm unable to scrolling horizontally to view the rest of the values in each row and notice an overlap between the target properties and document types section.

I’m on the Apple Developer application on the Mac Mini, and I’m getting the option “Continue your enrollment.” When I click it, I’m shown a “Subscription Fee” button. After clicking that, I receive this message: “An Apple Developer Program membership subscription is already associated with your iTunes & App Store account.” The only option I have is to click OK, and when I do that, it takes me back to the same Subscription screen. The enrollment is not getting completed, and I’m stuck in a loop. Could you please help me with this?

Hello, I noticed the Product.SubscriptionInfo subscriptionPeriod (of type Product.SubscriptionPeriod) is different for the same product between StoreKit Testing in Xcode and the sandbox/App Store (production) environment. For a “1 week” auto-renewable subscription, we get the following: StoreKit Testing in Xcode: 1 week gives a subscriptionPeriod with value of 1 and a unit of Product.SubscriptionPeriod.Unit.week Sandbox/App Store: 1 week gives a subscriptionPeriod with value of 7 and a unit of Product.SubscriptionPeriod.Unit.day This created issues in my app because I used the localizedDescription of a Product.SubscriptionPeriod to display a text similar to “$4.99 per week”. This is what I obtain with the StoreKit Testing in Xcode, but in the Sandbox/App Store environment, it displays “$4.99 per day” (because the subscriptionPeriod is “7 Days” and the unit is then .day). Obviously, this is not what I wanted to display. Other periods like “1 month”, “2 months”, “3 months”, “6 months, and “1 year”, the period provided by both StoreKit Testing and Sandbox/App Store correspond to the period unit specified in App Store Connect. In addition, I want to report that for a weekly subscription/offer or a 2 weeks offer, Product.SubscriptionInfo.subscriptionPeriod or Product.SubscriptionOffer.period == .weekly or .everyTwoWeeks is always false. We observe the following: With Sandbox or App Store live production: 1 week, Product.SubscriptionInfo.subscriptionPeriod == .weekly is false (because it’s “7 days”) 1 week, Product.SubscriptionOffer.period == .weekly is false (because it’s “7 days”) 2 weeks (offer), Product.SubscriptionInfo.subscriptionPeriod == .everyTwoWeeks is false (because it’s “14 days”) 2 weeks (offer), Product.SubscriptionOffer.period == .everyTwoWeeks is false (because it’s “14 days”) But with an Xcode StoreKit configuration file: 1 week, Product.SubscriptionInfo.subscriptionPeriod == .weekly is true (because it’s “1 week”) 1 week, Product.SubscriptionOffer.period == .weekly is true (because it’s “1 week”) 2 weeks, Product.SubscriptionInfo.subscriptionPeriod == . everyTwoWeeks is true (because it’s “2 weeks”) 2 weeks, Product.SubscriptionOffer.period == . everyTwoWeeks is true (because it’s “2 weeks”) So in sandbox and production, .weekly and .everyTwoWeeks is never possible. If someone from Apple could check the feedback FB19605865 🙂 Thank you Regards, Axel, @alpennec Code: do { let productIDs: [String] = ["revenueSocks_weekly_trial"] let products: [StoreKit.Product] = try await Product.products (for: productIDs) let weeklySubscription: StoreKit.Product = products.first! let displayPrice: String = weeklySubscription.displayPrice // For a weekly subscription in App Store Connect // With an Xcode StoreKit configuration file: subscriptionPeriod unit is Week (week), value is 1 → "1 Week" // With the Sandbox + App Store: subscriptionPeriod unit is Day (.day), value is 7 → "7 Days" let unitString: String = weeklySubscription.subscription!.subscriptionPeriod.unit.localizedDescription print("\(displayPrice) per \(unitString.localizedLowercase)") // StoreKit configuration file → "$4.99 per week" // Sandbox + App Store → "$4.99 per day" } catch { print(error) }

Is there any way to forcibly disable using QUIC? I've noticed this ends up causing issues with our ISP / router, and noticed for many of our customers as well. Creating an ephemeral session doesn't change things, and setting the request to "assumeHttp3Capable" to false doesn't fix things either. We are using Cloudflare Workers as the URL we are hitting, and thus aren't able to disable this server-side.

Hi, We identified massive amounts of leaked memory with the tvOS 26 standard player user interface as soon as chapters (navigation markers) are involved. Artwork images associated with chapters are not correctly released anymore, leaking memory in chunks of several MiBs. Over time apps will be terminated by the system due to excessive memory consumption. The issue was reported to Apple as tvOS 26 regression: Huge memory leaks associated with navigation marker artworks displayed in the tvOS standard user interface, filed under FB21160665.

What is the correct way to implement scrolling in a looong list that uses ScrollView and LazyVstack Imagine I have some api that returns a longs list of comments with replies The basic usecase is to scroll to the bottom(to the last comment) Most of the time this works fine But, imagine some of the comments have many replies like 35 or more (or even 300) User expands replies for the first post, then presses scroll to bottom. The scrollbar reaches the bottom and I see the blank screen. Sometimes the scrollbar may jump for a while before lazyvstack finishes loading or until I manually scroll up a bit or all the way up and down What should I do in this case? Is this the swiftui performance problem that has no cure? Abstract example: ScrollViewReader { proxy in ScrollView { LazyVStack { ForEach(comments) { comment in CommentView(comment: comment) .id("comment-\(comment.id)") } } } } struct CommentView: View { let comment: Comment @State var isExpanded = false var body: some View { VStack { Text(comment.text) if isExpanded { RepliesView(replies: comment.replies) // 35-300+ replies } } } } ... scroll proxy.scrollTo("comment-\(lastComment.id)", anchor: .bottom)

Good morning, We are implementing Live Activities in a push-to-start flow. We wrap the listener for push to start tokens in a high priority task: if ptsListenerTask == nil || ptsListenerTask?.isCancelled == true { ptsListenerTask = Task(priority: .high) { [weak self] in for await pushToken in Activity<LiveAuctionAttributes>.pushToStartTokenUpdates { //Send token to back-end } } I've tried a few variations of this and they work well on most devices. I have seen a couple of devices that refuse to issue a push to start token. The user will have logging for the init flow and starting the PTS listener then the logs just go silent, nothing happens. One thing that seemed to work was getting the user to start a Live Activity manually (from our debugging tool) then the PTS token gets issued. This is not very reliable and working a mock live activity into the flow for obtaining a PTS token is a poor solution. Is anyone else seeing this and is there a known issue with obtaining PTS tokens? Thanks! Brad

Hi, We recently updated our app icon, but the push notification icon has not been updated on some devices. It still shows the old icon on: • iPhone 16 Pro — iOS 26 • iPhone 14 — iOS 26 • iPad Pro 11” (M4) — iOS 18.6.2 • iPhone 16 Plus — iOS 18.5 After restarting these devices, the push notification icon is refreshed and displays the new version correctly. Could you advise how we can ensure the push notification icon updates properly on all affected devices without requiring users to restart? Thank you.

Hi, We recently updated our app icon, but the push notification icon has not been updated on some devices. It still shows the old icon on: • iPhone 16 Pro — iOS 26 • iPhone 14 — iOS 26 • iPad Pro 11” (M4) — iOS 18.6.2 • iPhone 16 Plus — iOS 18.5 After restarting these devices, the push notification icon is refreshed and displays the new version correctly. Could you advise how we can ensure the push notification icon updates properly on all affected devices without requiring users to restart? Thank you.

Hello everyone, We wanted to share our situation and see if anyone has had a similar experience. Our app was submitted to the App Store on Monday, November 20th, and its status has remained "Waiting for Review" ever since. Based on Apple's typical review times of 24-48 hours, we're a bit concerned that the review process hasn't even started after several days. Has anyone else encountered similar delays recently? We would greatly appreciate any advice or insight into what might be causing this. Thank you!

Hello, I’m seeking help regarding an App Review situation that has become increasingly difficult to resolve. Our app has been in review since July 29, and despite multiple rounds of communication, detailed explanations, updated builds, and full implementation of all required changes, the review process continues to stall without clear feedback. Most recently, we received new review questions regarding the External Purchase entitlement and the “Notify Me When Open” feature. We provided a detailed explanation addressing each point, including clarification that: All digital purchases, including Online Groups, use the StoreKit External Purchase API. The External Purchase Modal Sheet appears before every purchase flow. The “Notify Me When Open” feature does not initiate or bypass a payment flow; it only notifies users when a time-scheduled course becomes available, after which the user proceeds through the standard StoreKit External Purchase Modal Sheet. After submitting these explanations, our app returned to the “In Review” state. However, it has now remained there for five consecutive days, again with no further questions or updates. When combined with the previous review cycles, the total delay is approaching five months. This extended review period is causing significant challenges for our service, as users have been unable to access essential updates and continue facing issues in the outdated version of the app. Has anyone experienced a similar situation where the review remains stuck even after addressing all feedback and providing the required materials? Is there any additional way to escalate or request deeper assistance beyond the standard channels? Any guidance or shared experience would be greatly appreciated. Thank you.

Hi all, Our app has been in review since November 1st, and the process has been very slow. We often wait several days between responses, and we keep receiving questions we’ve already answered - even when we point this out in our replies. We’ve contacted Developer Support by email, but the only reply we received was that they’re sorry for the delay and will look into it. We’re unsure whether requesting a phone call might help or if it could pause or reset the review process, and since we’re hoping the next response will finally approve the app, we’ve hesitated to use that option. Has anyone experienced something similar, or does anyone know whether requesting a call has any impact on the current review status? Thanks for any guidance.

The review team rejected our application wrinting this : We have started our review, but we need additional information to continue. Specifically, it appears your app may access or include paid digital content or services, and we want to understand your business model before completing our review. Our app is free and doesn't include any payement package or page But we are coupled to another application for the login. And this other application has a trial period and effectively needs payment after. Do i need to explain in my app all the payment process of the other app ?

Summary I am investigating a change in macOS 26.1 (Tahoe) where plain (non-bundled) executables that request screen recording access no longer appear under: System Settings → Privacy & Security → Screen & System Audio Recording This behavior differs from macOS Sequoia, where these executables did appear in the list and could be managed through the UI. Tahoe still prompts for permission and still allows the executable to capture the screen once permission is granted, but the executable never shows up in the UI list. This breaks user expectations and removes UI-based permission management. To confirm the behavior, I created a small reproduction project with both: a plain executable, and an identical executable packaged inside an .app bundle. Only the bundled version appears in System Settings. Observed Behaviour 1. Plain Executable (from my reproduction project) When running a plain executable that captures the screen: macOS displays the normal screen-recording permission prompt. Before granting permission: screenshots show only the desktop background. After granting permission: screenshots capture the full display. The executable does not appear under “Screen & System Audio Recording”. Even when permission is granted manually (e.g., dragging the executable into the pane), the executable still does not appear, which prevents the user from modifying or revoking the permission through the UI. If the executable is launched from inside another app (e.g., VS Code, Terminal), the parent app appears in the list instead, not the executable itself. 2. Bundled App Version (from the reproduction project) I packaged the same code into a simple .app bundle (ScreenCaptureApp.app). When running the app: The same permission prompt appears. Pre-permission screenshots show the desktop background. Post-permission screenshots capture the full display. The app does appear under “Screen & System Audio Recording”. This bundle uses the same underlying executable — the only difference is packaging. Hypothesis macOS 26.1 (Tahoe) appears to require app bundles for an item to be shown in the Screen Recording privacy UI. Plain executables: still request and receive permission, still function correctly after permission is granted, but do not appear in the System Settings list. This may be an intentional change, undocumented behavior, or a regression. Reproduction Project The reproduction project includes: screen_capture.go A simple Go program that captures screenshots in a loop. screen_capture_executable Plain executable built from the Go source. ScreenCaptureApp.app/ App bundle containing the same executable. build.sh Builds both the plain executable and the app bundle. Permission reset and TCC testing scripts. The project demonstrates the behavior consistently. Steps to Reproduce Plain Executable Build: ./build.sh Reset screen capture permissions: sudo tccutil reset ScreenCapture Run: ./screen_capture_executable Before granting: screenshots show desktop only. Grant permission when prompted. After granting: full screenshots. Executable does not appear in “Screen & System Audio Recording”. Bundled App Build (if not already built): ./build.sh Reset permissions (optional): sudo tccutil reset ScreenCapture Run: open ScreenCaptureApp.app Before granting: screenshots show desktop. After granting: full screenshots. App bundle appears in the System Settings list. Additional Check I also tested launching the plain executable as a child process of another executable, similar to how some software architectures work. Result: Permission prompt appears Permission can be granted Executable still does not appear in the UI, even though TCC tracks it internally → consistent with the plain-executable behaviour. This reinforces that only app bundles are listed. Questions for Apple Is the removal of plain executables from “Screen & System Audio Recording” an intentional change in macOS Tahoe? If so, does Apple now require all screen-recording capable binaries to be packaged as .app bundles for the UI to display them? Is there a supported method for making a plain executable (launched by a parent process) appear in the list? If this is not intentional, what is the recommended path for reporting this as a regression? Files Unfortunately, I have discovered the zip file that contains my reproduction project can't be directly uploaded here. Here is a Google Drive link instead: https://drive.google.com/file/d/1sXsr3Q0g6_UzlOIL54P5wbS7yBkpMJ7A/view?usp=sharing Thank you for taking the time to review this. Any insight into whether this change is intentional or a regression would be very helpful.

I submitted my app for review on November 12, but I still haven’t received any response. It’s now November 25, and the review is still pending. Android is much faster with reviews, it took them 2 days. Could someone from the App Review Team please check my submission? Thank you very much! 🙏 Apple Id: 6753878193

Hi everyone, I’m currently facing a blocking issue during App Review, and I’d really appreciate some help from anyone who has experienced something similar. My app was rejected under Guideline 2.1 – App Completeness with the following message: “An error message appeared after trying to Sign in with Apple. Device: iPad Air (5th generation), iPadOS 26.1.” The problem is: I cannot reproduce this bug at all, even when testing under the same conditions. ✔ What I tested: Physical iPad Air M2 on iPadOS 26.1 Physical iPhone devices iOS/iPadOS simulators (latest Xcode) TestFlight build (clean install) Debug build installed via Xcode (device connected) In every case, Sign in with Apple works correctly: Authentication sheet displays properly Callback returns the credential User is created/logged in without error No crash, no rejected promise, no empty credential ✔ Environment Using ASAuthorizationAppleIDProvider + ASAuthorizationController Default Apple Sign In button No custom nonce/redirect modifications No backend processing at login (client-side only) Works 100% on iPhone and iPad on my side ✔ Additional context The app review team also noted a second point: They couldn’t locate a secondary subscription paywall, which is displayed only after dismissing the first paywall. I already clarified this with them, but I'm mentioning it in case it's related to the Sign in with Apple issue — maybe something in the sandbox environment is causing unexpected UI behavior. ❓ My question Has anyone already seen Sign in with Apple fail ONLY for the App Review team, while: It works in TestFlight It works via Xcode installs It works on the same OS version It works on the same hardware Could it be an issue related to: Sandbox Apple ID? iPadOS 26.1 on App Review internal builds? Reviewers blocking popup presentation context? Missing entitlement although everything is configured correctly? Presentation anchor issues specific to iPad? Any help or ideas would be greatly appreciated. I’ve been trying to reproduce this bug for hours without success, so any insight is welcome. Thanks!