Overview

I have the typical StoreKit 2 manager class, where I check currentEntitlements for subscription. I have filed a feedback (FB22349195), I hope someone can take a look at it. func updateCustomerProductStatus() async { var activeSubscription: String? = nil // BUG: In some cases the currentEntitlements does not emit a transaction until the device is reboot for await result in Transaction.currentEntitlements { print("Found transaction: \(result)") // This print does not appear until a restart! do { let transaction = try checkVerified(result) // Skip revoked transactions if transaction.revocationDate != nil { print("Skipping revoked transaction for \(transaction.productID)") continue } // Skip expired subscriptions if let expirationDate = transaction.expirationDate, expirationDate < Date() { print("Skipping expired subscription for \(transaction.productID)") continue } // Check product type switch transaction.productType { case .autoRenewable: activeSubscription = transaction.productID default: break } } catch { print("Unable to verify transaction: \(error)") } } // Update state once after processing all entitlements self.activeSubscription = activeSubscription print("updateCustomerProductStatus() activeSubscription: \(activeSubscription ?? "nil")") } There is some unexpected behavior where the currentEntitlements does not emit a result until the iPhone device is reboot. This bug appeared in iOS 26.4 (and in the betas).

This example application crashes when entering any text to the token field with FAULT: NSGenericException: The window has been marked as needing another Update Constraints in Window pass, but it has already had more Update Constraints in Window passes than there are views in the window. The app uses controlTextDidChange to update a live preview where it accesses the objectValue of the token field. If one character is entered, it also looks like the NSTokenFieldDelegate methods tokenField(_:styleForRepresentedObject:) tokenField(_:editingStringForRepresentedObject:) tokenField(_:representedObjectForEditing:) are called more than 10000 times until the example app crashes on macOS Tahoe 26 beta 6. I've reported this issue with beta 1 as FB18088608, but haven't heard back so far. I have multiple occurrences of this issue in my app, which is working fine on previous versions of macOS. I haven't found a workaround yet, and I’m getting anxious of this issue persisting into the official release.

I've been able to run this sample project with the PIRServer. But the urls are still not blocked. https://developer.apple.com/documentation/networkextension/filtering-traffic-by-url https://github.com/apple/pir-service-example I got this on the log Received filter status change: <FilterStatus: 'running'>

The file ~/.CFUserTextEncoding contained a string which I can't understand. It's recreated when a user log in. I had found that the result of CoreFoundation.CFStringGetSystemEncoding() is affected by the content of this file. What is this file used for?

Hello! We built a macOS .pkg using pkgbuild (contains a DMG + postinstall bash script). The pkg works locally on the build machine but fails on other devices manually / via MDM unless signed. We tried signing with a Developer ID Installer certificate, but: security find-identity -p codesigning -v → 0 valid identities security find-identity -v → shows the cert Private key is present in Keychain OpenSSL check shows: X509v3 Extended Key Usage: Critical (Expected one might be: Code Signing) We recreated CSR + cert multiple times (G2 Sub-CA), ensured Login keychain, unlocked keychain, etc., but same result. Question: Why is the Developer ID Installer cert missing Code Signing usage and not recognized for signing? Is there any account restriction or step we might be missing? Any recommendations on resolving this issue. Thanks!

I have been fighting this problem for two months and would love any help, advice or tips. Should I file a DTS ticket? Summary We attach a JPEG image to a local notification using UNNotificationAttachment. iOS reports the delivered notification as having attachments=1, but intermittently no image preview appears in Notification Center. In correlated cases, the attachment’s UNNotificationAttachment.url (which points into iOS’s attachment store) becomes unreadable (Data(contentsOf:) fails) even though the delivered notification still reports attachments=1. This document describes the investigation, evidence, and mitigations attempted. Product / Component UserNotifications framework UNNotificationAttachment rendering in Notification UI (Notification Center / banner / expanded preview) Environment App: OnThisDay (SwiftUI, Swift 6) Notifications: local notifications scheduled with UNCalendarNotificationTrigger(repeats: false) Attachment: JPEG generated from PhotoKit (PHImageManager.requestImage) and written to app temp directory, then passed into UNNotificationAttachment. Test contexts: Debug builds (direct Xcode install) TestFlight builds (production signing) iOS devices: multiple, reproducible with long runs and user clearing delivered notifications Expected Result Delivered notifications with UNNotificationAttachment should consistently show the image preview in Notification Center (thumbnail and expanded preview), as long as the notification reports attachments=1. If the OS reports attachments=1, the attachment’s store URL should remain valid/readable for the lifetime of the delivered notification still present in Notification Center. Actual Result Intermittently: Notification Center shows no image preview even though the app scheduled the notification with an attachment and iOS reports the delivered notification as having attachments=1. When we inspect delivered notifications via UNUserNotificationCenter.getDeliveredNotifications, the delivered notification’s request.content.attachments.first?.url exists but is unreadable (attempting Data(contentsOf:) returns nil / throws), i.e. the backing attachment-store file appears missing or inaccessible. In some scenarios the attachment-store file is readable for hours while the notification is pending, and then becomes unreadable after the notification is delivered. Reproduction Scenarios (Observed) Next-day reminders show attachment-store unreadable after delivery 1. Schedule a one-shot daily reminder for next day (07:00 local time) with UNCalendarNotificationTrigger(repeats: false) and a JPEG attachment. 2. During the prior day, periodic background refresh tasks verify the pending notification’s attachment-store URL is readable (pendingReadable=true). 3. After the reminder is delivered the next morning, the delivered snapshot shows the delivered notification’s attachment-store URL is unreadable (readable=false) and Notification Center shows no preview. Interpretation: the attachment-store blob appears to become inaccessible around/after delivery, despite being readable while pending. Evidence and Instrumentation We added non-crashing diagnostic logging (Debug builds) around: Scheduling time Logged that we successfully created a UNNotificationAttachment from a unique temp file. Logged that UNUserNotificationCenter.add(request) succeeded. Queried pendingNotificationRequests() and logged the scheduled request’s attachment url.lastPathComponent (iOS attachment-store filename). Delivered time (when app becomes active) Called UNUserNotificationCenter.getDeliveredNotifications and logged: delivered count, attachment count attachment url.lastPathComponent whether Data(contentsOf: attachment.url) succeeds (readable=true/false) Content fingerprinting Fingerprinted the exact JPEG bytes we wrote (SHA-256 prefix + byte count). Logged the iOS attachment-store filename (url.lastPathComponent) returned post-scheduling. Decode validation probe (later addition) When Data(contentsOf:) succeeds, we validate it decodes as an image using CGImageSourceCreateWithData and log: UTI (e.g. public.jpeg) pixel width/height magic header bytes What we tried / Mitigations Proactive “self-heal” for pending notifications Change: during background refresh/foreground refresh, verify the pending daily reminder’s attachment-store URL readability. If it’s unreadable, reschedule with a new attachment (same trigger). Rationale: if iOS drops the store file before delivery, recreating could repair it. Result: We observed cases where pending remained readable but delivered became unreadable after delivery, so this doesn’t address all observed failures. It is still valuable hardening. Increase scheduling frequency / reschedule closer to fire time (proposed/considered) We discussed adding a debug mode to always recreate the daily reminder during background refresh tasks (or only within N hours of fire time) to reduce the time window between attachment creation and delivery. Status: experimental; not yet confirmed to resolve the “pendingReadable=true → delivered unreadable after delivery” failure. Impact The primary UX value of the daily reminder is the preview photo; missing previews degrade core functionality. Failures are intermittent and appear dependent on OS attachment-store behavior and Notification Center actions (clearing notifications), making them difficult to mitigate fully app-side. Notes / Questions for Apple 1. Is iOS allowed to coalesce/deduplicate UNNotificationAttachment storage across notifications? If so, what is the retention model when delivered notifications are removed? 2. If a delivered notification still reports attachments=1, should its attachment-store URL remain valid/readable while the notification is still present in Notification Center? 3. In “next-day” one-shot scheduling scenarios, can the attachment-store blob be purged between scheduling and delivery (or immediately after delivery) even if the notification remains visible? 4. Is there a recommended pattern to ensure attachment previews remain stable for long-lived scheduled notifications (hours to a day), especially when using UNCalendarNotificationTrigger(repeats: false)? Minimal Code Pattern (simplified) 1. Generate JPEG (PhotoKit → UIImage → JPEG Data). 2. Write to a unique temp URL. 3. Create attachment: UNNotificationAttachment(identifier: <uuid>, url: <tempURL>, options: [UNNotificationAttachmentOptionsTypeHintKey: "public.jpeg"]) 4. Schedule notification with a calendar trigger for the next morning.

Logic Pro recently changed the way it accepts drag and drop. If the ItemProvider contains UTType.midi, then Logic Pro shows visual feedback for the drop operation, but when the item is dropped, nothing happens. In the past, drag-and-drop used to work. With today's version (Logic Pro 11.2), the only way I was able to successfully drop MIDI was to provide UTType.fileURL and no other data types. But that's not a viable solution; I need other data types to be included too. As a side note, I tested with Ableton Live 12 and it works with no issue. Is this a bug in Logic Pro? What ItemProvider structure does Logic Pro expect to correctly receive the MIDI data?

When a static library is built with Xcode 26 (with deployment target set to iOS 13) and then linked into an app project compiled with Xcode 16, the build process fails with the following linker error: Undefined symbols for architecture arm64: "_swift_coroFrameAlloc" This occurs even though both the static library and the app project have their deployment targets set to iOS 13.0. The static library works on Xcode 26, but fails to link on Xcode 16. This issue shows up with certain Swift syntax. For example, in my case, using a property getter and setter caused the compiler to emit a reference to _swift_coroFrameAlloc, which in turn triggered the issue. This issue prevents us from distributing pre-built static libraries compiled with Xcode 26 to teammates who are still using Xcode 16. I’ve filed feedback for this issue (FB21130604). Is there any way to work around it? For example, by adding specific Build Settings or something similar? A demo project is available here: https://github.com/Naituw/SwiftLibraryDeploymentTargetIssue The demo project includes: StaticLibraryProject: A simple Swift static library with property getter setter usage AppProject: An iOS app that links against the static library verify_compatibility.sh: An automated script to reproduce the issue Method 1: Manual Build and Verification Open StaticLibraryProject/StaticLibraryProject.xcodeproj in Xcode 26 Build the StaticLibraryProject for iOS device (Release configuration) Locate the built libStaticLibraryProject.a in the build products directory Copy libStaticLibraryProject.a to AppProject/AppProject/ directory Open AppProject/AppProject.xcodeproj in Xcode 16 Build the AppProject for iOS device Method 2: Automated Script Edit verify_compatibility.sh to configure the paths to your Xcode installations: Set XCODE_26_PATH to your Xcode 26 installation path (e.g., /Applications/Xcode.app) Set XCODE_16_PATH to your Xcode 16 installation path (e.g., /Applications/Xcode16.app) Run the script: ./verify_compatibility.sh

Environment: Xcode 26.4 (17E192) iOS 26.4.1 iPhone 15 Pro Project uses PBXFileSystemSynchronizedRootGroup (Xcode 26 format) Setup: Widget Extension target named ModusWidgetExtension Bundle ID: com.calvin.Modus.ModusWidget NSSupportsLiveActivities = YES in both main app and widget extension Info.plist Live Activities enabled in Settings → Modus Live Activities enabled in Settings → Face ID & Passcode → Allow Access When Locked Background App Refresh enabled Push Notifications capability on both targets ActivityAttributes struct added to both targets via file target membership Behaviour: ActivityAuthorizationInfo().areActivitiesEnabled returns true Activity.request() succeeds and returns a valid activity ID No error is thrown Nothing appears on lock screen or Dynamic Island in foreground or background Widget preview in Xcode renders correctly for all presentations (compact, minimal, expanded, lock screen) Console output from liveactivitiesd filtered logs: "Foreground process is permitted to update activity" "XPCInputParticipant has no activity for update" (ERROR — repeated) "Received state update for [app<com.calvin.Modus>], running-active-NotVisible" The activity is being created and the system is receiving state updates, but the widget extension is not rendering it. The XPCInputParticipant error suggests the widget extension process cannot find the activity created by the main app.

Hi, I enrolled in the Apple Developer Program a few days ago and completed the payment successfully. I have also received the invoice confirming the $99 charge. However, my account is still showing as “Pending” and has not been activated yet. Here are my details: Enrollment ID: J3Y5R3YB88 Order Number: D004756535 Case ID: 102869013588 It has been several days and I have not received any response from support yet. This delay is blocking my work as I need to proceed with app deployment. Has anyone faced a similar issue? Any help or escalation from Apple would be greatly appreciated. Thank you.

Besides using esf, are there any other ways to perceive process start events in real time? Libbsm is currently disabled by default

Hi everyone, I'm hoping to get some advice or visibility from Apple staff here, as my team is currently completely stuck. On April 10th, we enrolled in the Apple Developer Program. Our credit card was successfully charged $99, and we received the official Apple invoice receipt (Invoice #MC64187422). However, almost a week later, the membership status has not updated to active. The developer portal still prompts us to "Complete your purchase", and if we click it, it gives a warning about withdrawing the enrollment. We are on a very tight schedule to release a gamification app for our corporate clients by late April, and this enrollment delay is severely impacting our deployment timeline. I've already emailed Developer Support but haven't received a response in days. I also tried using the "Request a call" feature. However, because I am the technical lead handling the setup for the team and my name doesn't exactly match the account owner's name, the phone support agent was unable to assist me further due to security policies. Has anyone experienced this kind of "stuck" status after the payment has already been captured and invoiced? Is there a specific way to escalate this pending enrollment so we can meet our project deadline? Any advice would be greatly appreciated. Thanks in advance!

Hi, I’ve been successfully using notarization with notarytool for over a month (20+ submissions, all accepted within minutes). On April 4th around 07:30 (UTC), my last submissions were accepted without any issue: createdDate: 2026-04-04T07:29:08.877Z id: 38d6e6e0-1183-4fe8-ae4a-3036e1f0f025 name: MacOptimizers.dmg status: Accepted -------------------------------------------- createdDate: 2026-04-04T07:26:36.357Z id: 2abf8289-6e00-4b16-9991-fbda7e66a179 name: macopt_notary_payload.UdtfA3 status: Accepted -------------------------------------------- Later that same day (around 16:30 UTC), after minor bug fixes and UI changes, I submitted a new build. Since then, all notarization requests remain stuck in “In Progress” for more than 48 hours: -------------------------------------------- createdDate: 2026-04-05T07:13:03.369Z id: b4872e7a-e2b5-485e-9223-09f3ed94958f name: macopt_notary_payload.mZls1y status: In Progress -------------------------------------------- createdDate: 2026-04-04T20:07:35.937Z id: 375408f2-3c0a-455e-88a1-9cd08ce7dc35 name: macopt_notary_payload.CvrZNt status: In Progress -------------------------------------------- createdDate: 2026-04-04T17:09:47.481Z id: dad888b3-6aff-4c54-9608-da1f86e44db7 name: macopt_notary_payload.IH0RDr status: In Progress -------------------------------------------- createdDate: 2026-04-04T16:28:03.086Z id: 9e129b21-e682-48ce-baa7-8d2d77051bac name: macopt_notary_payload.GsrSa6 status: In Progress No errors are returned, and notarytool log is not yet available. Is this expected behavior (e.g. extended review), or could there be an issue affecting notarization for my team? Thanks for your help.

Dear Apple Support Team, I purchased an Apple Developer account, but it has still not been approved even after 8 days. I have sent more than 10 emails regarding this issue, but I have not received any response so far. I kindly request you to look into this matter and resolve it on priority.

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.

Hello, I made my app icon with Icon Composer and added the .icon file directly to my Xcode project. I noticed that the icon preview in Icon Composer looks one way, while the icon shown on the App Store looks different. Details: I am using the .icon file directly in the project I am not using an exported PNG for the app icon I did not add a separate background image The background was set with fill in Icon Composer The preview in Icon Composer looks as expected The App Store version has a different appearance I would like to ask whether this difference may come from: App Store processing caching or a recommended Icon Composer setup for background fill If anyone has seen something similar, I would appreciate any guidance. I can also share screenshots of the Icon Composer preview and the App Store result.

I hope you are doing well. I am reaching out to inquire about a few aspects of implementing non-renewing subscriptions in our app. Firstly, we have encountered a limitation in App Store Connect where the maximum price tier available for non-renewing subscriptions in Euros is €1199. However, our product is priced at €1799. Could anyone please advise how we can handle this scenario? Is there a way to request custom pricing beyond the available tiers, or is there an alternative approach you would recommend? Additionally, we would like clarification on the following: Promo Codes: Are promo codes supported for each non-renewing subscription product? If so, how can we configure and distribute them? Installment Payments: Is it possible to enable installment-based payments for non-renewing subscriptions? If yes, could you guide us on how to set this up or if there are any prerequisites?

Hello everyone, I’m facing a persistent App Store rejection under Guideline 2.1(b) – App Completeness, related to In-App Purchases, and I’m unable to reproduce the issue on my end. Issue reported by Apple Review Apple Review team reports: “No action occurred when we attempted to buy the subscription.” Device: iPad Air 11-inch (M3) OS: iPadOS 26.4.1 What I have verified from my side I have thoroughly tested the subscription flow under multiple scenarios: Sandbox Testing Using sandbox test accounts Product loads correctly Purchase flow completes successfully Apple payment sheet appears properly TestFlight Testing Installed app via TestFlight Logged in with real Apple ID (Beta tester) Successfully completed subscription purchase Device Testing Tested on multiple iPhones Tested on iPad as well Purchase flow works correctly on all devices App Store Connect Configuration Paid Apps Agreement → Active Banking & Tax → Completed (no pending warnings) In-App Purchase status → “In Review” Product is correctly configured and attached to app What Apple is experiencing Based on their feedback and screenshots: Subscription screen loads correctly Product price is visible When tapping “Subscribe Now” → no action occurs No error message, no purchase sheet Is there a recommended workaround or reviewer instruction to avoid this deadlock? Any insights or real-world experience would be greatly appreciated. Thanks in advance.

Hello, I’m a developer of an iOS app that provides paid educational courses (video-based content). Our recent app update was rejected under guideline 3.1.1 because the app includes paid digital content that is not using Apple’s In-App Purchase system. We fully understand and respect this guideline. However, we are facing a significant limitation: We are based in Iraq, and currently we do not have access to supported financial infrastructure that allows us to: Use Apple In-App Purchase (due to lack of supported banking setup) Use common payment providers like Stripe or similar services At the moment, our app relies on external payments completed outside the app, and users log in to access purchased content. Due to the rejection, our release and marketing plans are currently blocked, and we are looking for a compliant solution.

My current app is a smoking cessation app and it is desgined to help people quit smoking for good. Currently users of the app are expected to set a quit date and then remain quit from cigarettes for 12 weeks. The app helps with this by using badges, notifications and even live chats to stop smoking professionals (depending on your area). The app "frequently" mentions smoking and tobacco, but it never promotes it. It does the opposite. By mentioning the harms of smoking and the benefits of stopping. The app also mentions (and can provide, depending on your area, medical history and a professionals final opinion) about nicotine replacement therapy, which users who are quitting smoking may be interested in. Currently the app is rated 18+ as I have to tick "frequent" mention of drugs/tobacco/alcohol in the age rating questionnaire. Though it does not mention recreational drugs or alcohol. We will soon be adding a large update to the app to add vaping support. The app will change largely in the fact smoking content and vaping content will be siloed from each other. So a user can either be on a smoking support journey (and see stop smoking content), or a vape support journey (and only see vaping content). We need the app to be 13+ on the store and we will enforce age restrictions using the declared age range API as part of the account creation process. If the user is aged 13 - 17, they will only see vape related content, if they are 18+ they can see vaping OR smoking. How negotiable is the age rating certificate, can we change it to 13+ if we implement age restrictions in the app and protect stop smoking related content behind it?