Overview

Post

Replies

Boosts

Views

Activity

Apple Developer Program enrollment stuck in Pending — payment never charged and support not responding
Hello, I’m having an issue enrolling in the Apple Developer Program as an Individual / Sole Proprietor. I completed the enrollment process and submitted the $99 membership purchase. Apple sent me an order acknowledgement saying that the order would be processed within 2 business days. However: My credit card has never been charged. My Developer account remains in Pending status. The account still shows “Purchase your membership”. Trying to continue or restart the enrollment sometimes results in “We are unable to process your request. An unknown error occurred.” I have already contacted Apple Developer Program Support, but so far I have only received the automatic confirmation and no actual response. My support case ID is 102955478572. It has now been several days with no progress. I have also seen other recent posts describing very similar enrollment/payment issues. Has anyone recently managed to resolve this? Is there currently a known issue with Apple Developer Program enrollment or payment processing? I would appreciate any guidance from Apple Developer Support on how to either complete the existing enrollment/payment or reset the stuck enrollment so I can try again.
1
1
317
10h
Sandbox allows free trial again on resubscribe to the same subscription
Title: Sandbox allows free trial again on resubscribe to the same subscription Hi everyone, I'm testing an auto-renewable subscription using App Store Connect with a Sandbox tester (not a local StoreKit configuration file). My subscription has an introductory free trial configured. Scenario: Purchase the subscription for the first time using a Sandbox Apple ID. The user receives the introductory free trial as expected. Let the subscription expire. Purchase the same subscription product again using the same Sandbox Apple ID. I receive an App Store Server Notification with Notification Type = RESUBSCRIBE, and the transaction appears to have a price of 0, making it look like the user received another free trial. From Apple's documentation, my understanding is that an introductory offer can only be redeemed once per subscription group per Apple ID. Based on that, I expected the second purchase to be charged immediately rather than receive another free trial. My questions are: Is this expected behavior in the Sandbox environment? Does Sandbox sometimes allow introductory offers to be redeemed multiple times for testing? Or am I misinterpreting the RESUBSCRIBE notification and the $0 transaction? I did not intentionally reset the Sandbox tester's introductory offer eligibility, and I'm purchasing the same product in the same subscription group with the same Sandbox Apple ID. Has anyone observed this behavior or can clarify whether this is expected in Sandbox versus production? Thanks!
1
0
322
11h
NSUnknownKeyException error when uploading with altool
I am attempting to upload a new version of an existing App. The build and upload technique is one that we've used for many years for many of the Apps we manage including this one. I've built the IPA file. I upload the IPA file using "xcrun altool" but I keep getting the error shown below. (Note, I have no issues uploading another one of our Apps using the same command.) AI is suggesting that the problem may be caused by the name of the App. The App name is "@1 Access". It is suggesting that the current version of the altool may not be handling the name starting with '@'. If I run in verbose mode I can see in the WEB SERVICE RESPONSE headers... "Applications = { "@1 Access 1.0 (iOS App)" = xxxxxxxxx; };". But the error message omits the '@'... "...for the key 1 Access 1.0 (iOS App)". Can anyone help me get passed this issue ? If this is a bug with altool, who do I contact as I tried Apple Developer Support but they just refer me to this Developer Forum ? ERROR: *** Terminating app due to uncaught exception 'NSUnknownKeyException', reason: '[<__NSDictionaryM 0x71248d360> valueForUndefinedKey:]: this class is not key value coding-compliant for the key 1 Access 1.0 (iOS App).' *** First throw call stack: ( 0 CoreFoundation 0x000000018444ebf0 __exceptionPreprocess + 176 1 libobjc.A.dylib 0x0000000183eda91c objc_exception_throw + 88 2 CoreFoundation 0x00000001844725c8 _CFBundleGetValueForInfoKey + 0 3 Foundation 0x000000018665eeb8 -[NSObject(NSKeyValueCoding) valueForUndefinedKey:] + 196 4 Foundation 0x0000000185bfd71c -[NSObject(NSKeyValueCoding) valueForKey:] + 280 5 Foundation 0x0000000185be1ea4 -[NSDictionary(NSKeyValueCoding) valueForKey:] + 144 6 ContentDelivery 0x0000000100b73528 -[NSDictionary(ContentDelivery) sanitize] + 276 7 ContentDelivery 0x0000000100b73590 -[NSDictionary(ContentDelivery) sanitize] + 380 8 ContentDelivery 0x0000000100b73590 -[NSDictionary(ContentDelivery) sanitize] + 380 9 ContentDelivery 0x0000000100b3ef48 -[CDWebService invokeJsonWithServiceURL:operationName:params:] + 14328 10 ContentDelivery 0x0000000100b43c40 -[CDWebService makeServiceCall:params:] + 4272 11 ContentDelivery 0x0000000100b45190 -[CDWebService(lookupSoftwareForBundleID) lookupSoftwareForBundleID:] + 380 12 ContentDelivery 0x0000000100b51d84 -[CDAuthContext providerPublicIDForBundleID:] + 404 13 altool 0x000000010047fb48 altool + 31560 14 altool 0x000000010048dbfc altool + 89084 15 altool 0x0000000100495b9c altool + 121756 16 altool 0x0000000100496f5c altool + 126812 17 altool 0x000000010049b909 altool + 145673 18 altool 0x0000000100483a59 altool + 47705 19 libswift_Concurrency.dylib 0x00000002883f2f45 _ZL22completeTaskAndReleasePN5swift12AsyncContextEPNS_10SwiftErrorE + 1 ) libc++abi: terminating due to uncaught exception of type NSException zsh: abort xcrun altool --upload-app -f "Access1.ipa" -t ios -u -p xxxxxx
4
0
346
11h
Sign in with Apple: "Sign Up Not Completed" for every App ID in our team — framework returns canceled (1001) with empty userInfo
Sign in with Apple fails for every App ID in our team (K9UFUZF2XW), on every device and every Apple ID we have tried. The system sheet appears, the user authenticates successfully, the sheet then shows "Sign Up Not Completed", and no credential is returned. The failure happens after authentication — this is not a client-side rejection. I have spent several days isolating this and have ruled out everything on my side. Posting the full evidence in case an Apple engineer can look at the server-side state for our team, and in case it helps others hitting the same wall. WHAT THE FRAMEWORK ACTUALLY RETURNS The client library we use (expo-apple-authentication) discards the original NSError, so I patched its native layer to surface the raw error verbatim. This is what ASAuthorizationController hands back to didCompleteWithError, immediately after the user authenticated and the sheet displayed "Sign Up Not Completed": ASAuthorizationError .canceled (rawValue = 1001) domain = com.apple.AuthenticationServices.AuthorizationError code = 1001 desc = The operation couldn't be completed. (com.apple.AuthenticationServices.AuthorizationError, error 1001) userInfo: NSUnderlyingError: So the framework reports a user cancellation that never happened, with a completely empty userInfo and no underlying error. There is no diagnostic information on the client at all — I cannot debug this any further from my side, because the information does not exist there. Note: the same failure surfaces as a different error code depending on the client library version — .unknown (1000) with the older version, .canceled (1001) with the current one. The user-visible behaviour ("Sign Up Not Completed") is identical in both. So the error code is not a reliable signal here. WHAT I RULED OUT Not the App ID. I created a brand-new App ID (kz.auraai.ios) with Sign in with Apple enabled as a primary App ID, built a fresh binary, tested on the same device with the same Apple ID — identical failure. Two independent App IDs in the same team fail the same way. Not the entitlement. Verified inside the signed binary, not just in the portal: application-identifier = K9UFUZF2XW.kz.auraai.ios com.apple.developer.applesignin = ["Default"] I also tried the workaround suggested elsewhere on these forums (removing the entitlement while keeping the capability in the portal). That made it strictly worse: iOS then rejects the request instantly, without showing the sheet at all. Which confirms iOS reads the entitlement correctly, the sheet works, and the user authenticates — the failure is downstream of all of that. No stray or wildcard App IDs. A commonly cited cause is other App IDs in the team lacking the entitlement. I enumerated the whole team via the App Store Connect API: it contains exactly two App IDs, both with APPLE_ID_AUTH = PRIMARY_APP_CONSENT. No wildcard identifiers exist. Not the Apple ID, the device, or the iOS version. The same Apple ID, on the same device, with the same iOS, signs in successfully through another app belonging to a different team (Expo Go, host.exp.Exponent) — a valid identity token is returned. A second, unrelated Apple ID on another device fails in my app in exactly the same way. So this is not scoped to one account: it affects every user of the app. Agreements and membership are in good standing. Program License Agreement accepted 30 June 2026; Developer Agreement accepted 26 June 2026; membership active. Both distribution types fail. TestFlight and ad-hoc. WHAT IS LEFT After all of the above, the only variable that differs between the working case (a different team's app, same device, same Apple ID) and the failing case (my app) is the Apple Developer team itself. This exact signature — sheet renders fully, final server submit fails, "Sign Up Not Completed", delegate reports canceled with no userInfo, not reproducible in other apps on the same device — is documented in thread 122458 ("Error: Sign-Up Not Completed"). In that case it affected multiple developers, including Apple's own sample app, and was ultimately resolved by Apple on the server side, with a recurrence reported in June 2025. THE ASK Could someone from Apple check the server-side Sign in with Apple registration for team K9UFUZF2XW (App IDs kz.auraai.app and kz.auraai.ios)? I am not looking for configuration advice — I have exhausted the client side and there is nothing left to configure. This looks like the same server-side state that was fixed in the referenced cases. Feedback Assistant: FB23716661 (includes sysdiagnose with the Accounts/AuthKit profile, timestamp, and video of the failure). This is currently blocking us: because Sign in with Apple works for none of our users, guideline 4.8 prevents us from offering Google Sign-In, so we are shipping with email-only login. Happy to provide the binary, entitlements dump, or a fresh sysdiagnose on request.
75
5
13k
11h
Feature Request: Native Lisu (Fraser Script) Keyboard Support for iOS
To the Apple iOS Development and Accessibility Teams, I am writing to formally request the addition of a native Lisu keyboard to iOS. As Apple continues to expand its global accessibility and language support, adding the Lisu language would bridge a significant communication gap for a vibrant and growing community. About the Lisu People: The Lisu are a Tibeto-Burman ethnic group with an estimated population of over 1.4 million. They traditionally inhabit the mountainous regions of Myanmar (Burma), Southwest China (particularly the Yunnan and Sichuan provinces), Thailand, and the Indian state of Arunachal Pradesh. They possess a rich cultural heritage, passed down through generations via extensive oral traditions, songs, and clan histories. The Lisu Language and Fraser Script: The Lisu language is officially supported by the Unicode Consortium. The writing system, known as the Fraser script, was developed in 1914 and was officially added to the Unicode Standard in Version 5.2. Unicode Reference: The Lisu block is designated at U+A4D0 – U+A4FF. Official Chart: Unicode [Lisu Chart (PDF)] https://www.unicode.org/charts/PDF/UA4D0.pdf Current Industry StandardsOther major operating systems have already recognized the importance of supporting the Lisu community: Microsoft Windows: Currently comes with a pre-installed Lisu keyboard, allowing users to type seamlessly out of the box. Android (Google): The default Gboard natively supports the Lisu keyboard, offering full mobile typing capabilities for Android users. Currently, iOS users who speak and write in Lisu must rely on third-party workarounds, which often lack the security, privacy, and seamless integration of Apple’s native keyboards. By implementing the Lisu keyboard, Apple would greatly enhance the iOS experience for over a million people, allowing them to communicate natively on their iPhones and iPads.Thank you for your time, consideration, and ongoing commitment to making technology accessible to everyone. I look forward to seeing Lisu supported in a future iOS update. Sincerely, Si_Gwa
3
2
1.5k
12h
Live Activity ending immediately after being created
I'm seeing a Live Activity that's ended almost immediately after I'm creating it. I'm not ending the activity in my code, so something is happening at the system level. iOS version is 18.3.1. Looking at the logs for liveactivitiesd, I see that it was successfully created: default 12:57:34.837266-0800 liveactivitiesd Created activity: 22713DF6-E853-4B34-85FA-CD08D8FCA91B default 12:57:34.837639-0800 liveactivitiesd Starting activity: identifier: 22713DF6-E853-4B34-85FA-CD08D8FCA91B; createdDate: 2025-02-17 20:57:34 +0000; state: active; deviceIdentifier: local; resolvedContentSources: [ActivityKit.ActivityContentSource.process(target: <snip>), ActivityKit.ActivityContentSource.sync]; lastUpdateDate: 2025-02-17 20:57:34 +0000; endingOptions: nil default 12:57:34.858701-0800 liveactivitiesd Activity did start 22713DF6-E853-4B34-85FA-CD08D8FCA91B But then moments later, it's immediately ended: default 12:57:34.933963-0800 liveactivitiesd Ending activity 22713DF6-E853-4B34-85FA-CD08D8FCA91B for XPC participant content source <private> default 12:57:34.933983-0800 liveactivitiesd Stopping activity: 22713DF6-E853-4B34-85FA-CD08D8FCA91B default 12:57:34.934019-0800 liveactivitiesd Activity: identifier: 22713DF6-E853-4B34-85FA-CD08D8FCA91B; createdDate: 2025-02-17 20:57:34 +0000; state: active; deviceIdentifier: local; resolvedContentSources: [ActivityKit.ActivityContentSource.process(target: <snip>), ActivityKit.ActivityContentSource.sync]; lastUpdateDate: 2025-02-17 20:57:34 +0000; endingOptions: nil should be discarded now default 12:57:34.934442-0800 liveactivitiesd Activity discarded: 22713DF6-E853-4B34-85FA-CD08D8FCA91B Again, I'm not ending this activity in my code. I'll occasionally see this happen in my app, and the only solution I've found is to restart my device. Afterwards, everything seems fine. Is this a bug?
2
2
704
13h
App Review Delay and No Response from Support
App has been in review with no change in status for 2 weeks now. I contacted support and have heard nothing back on case ID is 102950117204. Even a simple reply that you are backed up and an acknowledgment that my app is in the queue would be appreciated. I've read advice on the forums about cancelling and resubmitting, but I've already waited 2 weeks and don't want to go the back of the queue. The status has been "waiting for review" for this period, so I assume you have it and it's in a queue.
3
0
564
13h
Developer Account Membership Expired – Cannot Find Renewal Option (Team ID: 532YXBDAKC)
Hi everyone, My Apple Developer Program membership has expired on March 11, 2026, and I am unable to find any option to renew it. Team ID: 532YXBDAKC I have checked the following places but there is no renewal option available anywhere: The Apple Developer website (developer.apple.com) – no renewal button or prompt visible in my account The Apple Developer app on Mac – no renewal option found The Apple Developer app on iPhone – no renewal option found I would like to renew my membership as soon as possible, but I am completely stuck as there is no clear path to do so. Has anyone else faced this issue? How can I get this resolved? Is there a direct way to contact Apple Developer support for membership renewal? Any help would be greatly appreciated. Thank you.
4
0
446
13h
AASA CDN intermittently times out / requests wrong path (/apple-app-site-association vs /.well-known/...)
Hi Everyone, We are tinkering on an App using associated domains with the working name "uff2.de". We have configured our Webserver (Caddy) to restrict all URIs except for /.well-known/apple-app-site-association using Www-Authenticate. Recently our associated domains started becoming flaky, which we believe has to do with requests from Apple’s CDN failing: The following example uses a query string to trigger a fresh request by Apple’s CDN. curl -sD - "https://app-site-association.cdn-apple.com/a/v1/uff2.de?foobar" -o /dev/null HTTP/1.1 404 Not Found Server: AppleHttpServer/7b3d349ae60c243cdd677edbde3e93e460f75820 Date: Sat, 05 Sep 2026 12:01:16 GMT Content-Type: text/plain; charset=utf-8 Content-Length: 10 Apple-Failure-Details: {"cause":"Connection timed out"} Apple-Failure-Reason: SWCERR00301 Timeout Apple-From: https://uff2.de/.well-known/apple-app-site-association Apple-Try-Direct: true Cache-Control: max-age=3600,public Vary: Accept-Encoding X-B3-TraceId: 457b6172513a930f Strict-Transport-Security: max-age=31536000 Age: 32 Via: https/1.1 defra2-vp-vst-018.ts.apple.com (acdn/331.16659), https/1.1 defra2-vp-vfe-016.ts.apple.com (acdn/331.16659), https/1.1 gbslo5-xdc-mx-020.ts.apple.com (acdn/331.16659), https/1.1 uklon5-edge-fx-024.ts.apple.com (acdn/331.16659) X-Cache: miss, miss, miss, miss CDNUUID: df5ac203-4188-4722-8bbc-68e9d9fd0b33-1118024500 Connection: keep-alive To investigate this further we enabled access logging and are seeing the following request that is blocked by us: 2026/09/05 12:01:16.824 INFO http.log.access.log0 handled request {"request": {"remote_ip": "57.103.82.202", "remote_port": "48366", "client_ip": "57.103.82.202", "proto": "HTTP/1.1", "method": "GET", "host": "uff2.de", "uri": "/apple-app-site-association", "headers": {"User-Agent": ["AASA-Bot/1.0.0"], "Accept-Encoding": ["gzip"]}, "tls": {"resumed": false, "version": 772, "cipher_suite": 4865, "proto": "", "server_name": "uff2.de"}}, "bytes_read": 0, "user_id": "", "duration": 0.000083782, "size": 0, "status": 401, "resp_headers": {"Server": ["Caddy"], "Alt-Svc": ["h3=\":443\"; ma=2592000"], "Www-Authenticate": ["Basic realm=\"restricted\""]}} But this seems to be the wrong URI (/apple-app-site-association instead of /.well-known/apple-app-site-association). When swapping ?foobar for other query strings like ?foobar2 or ?foobar3, some requests randomly work and some don’t. We’re also seeing flakiness for the same path (both with and without a query string) across time, but this is harder to test due to caching. For reference this is a correct request: 2026/09/05 17:54:26.075 INFO http.log.access.log0 handled request {"request": {"remote_ip": "57.103.81.17", "remote_port": "8692", "client_ip": "57.103.81.17", "proto": "HTTP/1.1", "method": "GET", "host": "uff2.de", "uri": "/.well-known/apple-app-site-association", "headers": {"User-Agent": ["AASA-Bot/1.0.0"], "Accept-Encoding": ["gzip"]}, "tls": {"resumed": false, "version": 772, "cipher_suite": 4865, "proto": "", "server_name": "uff2.de"}}, "bytes_read": 0, "user_id": "", "duration": 0.000088472, "size": 469, "status": 200, "resp_headers": {"Accept-Ranges": ["bytes"], "Content-Length": ["469"], "Server": ["Caddy"], "Alt-Svc": ["h3=\":443\"; ma=2592000"], "Vary": ["Accept-Encoding"], "Etag": ["\"dgrdbiykgv3ad1\""], "Content-Type": [], "Last-Modified": ["Sun, 01 Mar 2026 10:19:41 GMT"]}} Did we misread the documentation and should also serve /apple-app-site-association? Why would requests sometimes be made to /.well-known/apple-app-site-association and sometimes to /apple-app-site-association? Thank you!
2
1
95
13h
App Clip: “Invalid Entitlement: Unknown ID” despite valid AASA file and Apple CDN access
I am experiencing an App Clip domain verification issue in App Store Connect. App: Bini Music Version: 4.1.0 Build: 6 Main App Bundle ID: ninja.wpapp.appbinimusikcom App Clip Bundle ID: ninja.wpapp.appbinimusikcom.Clip Team ID: DY8SYXAUKN Domain: binimusik.com The Associated Domains capability is enabled on both the main app target and the App Clip target with: appclips:binimusik.com The AASA file is publicly accessible at: https://binimusik.com/.well-known/apple-app-site-association The AASA file contains: DY8SYXAUKN.ninja.wpapp.appbinimusikcom.Clip I have also verified the AASA file through Apple's associated-domains CDN, and Apple's CDN returns the correct AASA content and App Clip identifier. Build 6 has been successfully uploaded to App Store Connect and its Binary State is “Validated”. However, in TestFlight → Build 6 → Build Metadata → App Clip → Domain Status, App Store Connect continues to report: Cache Status: Cannot Reach AASA File Debug Status: Invalid Entitlement: Unknown ID The Cache Status has not refreshed and still says: “Cache status updated on Sep 2, 2026 at 3:58 PM.” I checked again on September 7 and the status remains unchanged. Apple Developer Support referred me to the Developer Forums because this appears to require technical assistance. Has anyone encountered “Invalid Entitlement: Unknown ID” with an App Clip even though the AASA file is reachable by Apple's CDN? Is there anything else that needs to be configured, or could this be an App Store Connect domain-validation issue?
1
0
77
14h
CPListItem and CPListImageRowItem text limited to 1 line on iOS 27
On iOS 27, CPListItem.text and CPListImageRowItem.text` are rendered as single-line with ellipsis truncation, regardless of the available vertical space. On iOS 26 and earlier, these properties wrapped to 2 lines before truncating. There is no public API (numberOfLines, lineLimit, or similar) on CPListItem, CPListImageRowItem, or CPListSection to control the number of text lines. The change appears to be a platform-level rendering default with no app-side opt-out. Steps to Reproduce Create a CPListTemplate with sections containing CPListItem or CPListImageRowItem items. Set the text property to a string long enough to require wrapping. Present the template via CPInterfaceController. Run on iOS 27. Expected Results The text property should wrap to multiple lines (2-3 lines) before truncating with an ellipsis, consistent with iOS 26 behavior. Row height should adjust dynamically to accommodate the wrapped text. Actual Results The text property is truncated to a single line with ellipsis. Row height remains fixed at a larger size, creating excessive vertical spacing between items. Environment iOS 27.0 (CarPlay) - issue present Xcode 27.0 beta 4 (27A5218g) Tested on physical CarPlay head unit and CarPlay Simulator
5
0
984
14h
smbfs silently zero-fills already-written data after cached file size regresses on reopen
Hello everyone, I've been chasing a nasty silent data corruption bug in the macOS SMB client (smbfs.kext) and wanted to share what I found, in case someone else has hit it and in the hope that someone from the SMB team sees it. What happens Under concurrent writes with repeated reopens, the client can regress its cached file size (np->n_size) to an earlier, smaller value - behind data it has already written and flushed to the server. The next write then treats the already-written range as a hole, zero-fills it via IO_HEADZEROFILL, and sends the zeros to the server, right on top of the correct bytes it transmitted moments earlier. No write(2) fails and nothing is logged - the file just quietly comes back with a chunk-aligned run of zeros in the middle, at the correct overall length. Environment macOS 26.5 (Darwin 25.5.0), Apple silicon (16 KiB VM pages), SMB 2.1 Sources referenced: SMB client 538.121.1, xnu 12377.121.6 How to reproduce Mount an SMB 2.1(2.0.2 has the same issue as well) share. Have several threads write the same files in 8 KiB chunks, each chunk via its own open/lseek/write/close (so the file is reopened constantly as it fills), while the files are concurrently resolved by name (stat / directory enumeration). Read the files back through a cache-cold path (second mount, or F_NOCACHE) and compare. Roughly 1 file in several hundred came back corrupted for me. The core of the write pattern: CHUNK = 8192 # 2 chunks per 16 KiB page def write_chunk(path, data, offset): fd = os.open(path, os.O_CREAT | os.O_RDWR) # own handle per chunk try: os.lseek(fd, offset, os.SEEK_SET) os.write(fd, data) finally: os.close(fd) # per file: content = os.urandom(random.randint(265000, 300000)); # chunks written in batches of 8 threads, joined between batches; # each file written twice from the same buffer: NAME, then NAME.copy In my runs the corruption always landed on the second (.copy) write. One caveat: I reproduced this against a third-party SMB server, not against macOS File Sharing (smbd), and I don't expect it to reproduce against smbd directly. The stale size arrives via reopen-via-lookup (smbfs_update_size <- smbfs_nget <- smbfs_vnop_lookup) on a freshly instantiated vnode, whose n_sizetime lets the freshness guard pass. smbd instead reopens via vnop_compound_open -> smbfs_attr_cacheenter (warm vnode; the guard rejects it) - the same stale-size candidates occur, they just all get rejected. The server merely steers the client onto the vulnerable path; the bug itself is entirely client-side. What I observed I captured the kernel side with dtrace fbt probes on smbfs_setsize() / smbfs_update_size() (os_log drops events under this load). Timeline for one corrupted file, correlating pcap and dtrace (dtrace has whole-second resolution, marked ".x"): [pcap] = network packet capture of the SMB traffic between client and server [dtrace] = kernel-side trace of the smbfs size-update functions; timestamps only have whole-second resolution, so ".x" marks an unknown sub-second time :39.778 [pcap] — client sends WRITE off=32768 len=32768 with the correct data, covering [40960:65536). :39.777–.860 [pcap] — throughout, the server's CREATE/CLOSE responses report a strictly monotonic EOF: 0, 8192, 40960, 65536, ... 288255. :39.x [dtrace] — on a reopen, smbfs_update_size applies EOF 40960 (a superseded value), regressing n_size from 65536 to 40960. :39.x [dtrace] — the next write starts past the regressed size, so zero_head_off = 40960 and IO_HEADZEROFILL is set. :39.804 [pcap] — client sends WRITE off=32768 len=57344, ALL ZEROS over [40960:65536), on top of the correct data it sent 26 ms earlier. End result: the file is 288255 bytes (correct length) with 24 KiB of zeros at [40960:65536) - three consecutive 8 KiB chunks, i.e. 1.5 x 16 KiB VM pages. Worth stressing: the server's own responses reported a strictly monotonic EOF the whole time, so the regression to 40960 was purely the client applying a superseded value. Expected, obviously: the file reads back byte-for-byte identical to what was written. Where I think the bug is From reading the smbfs and xnu sources, three things combine: np->n_size isn't consistently synchronized - read under the node lock only (smbfs_vnops.c:7329/7387/7391) but written under f_clusterWriteLock (:7411) and by smbfs_vnop_strategy under the cluster lock, so the reader deciding the zero-fill has no ordering guarantee. Possible fix: read it once under f_clusterWriteLock in smbfs_vnop_write so the snapshot, extend, and zero_head_off stay consistent. The freshness guard checks the wrong thing - smbfs_update_size's reqtime <= n_sizetime guard validates the reply's request time, not whether the value is still current, so a superseded (smaller) size applied later still passes and calls smbfs_setsize(smaller). Possible fix: never shrink n_size from fa_size while the vnode has dirty pages or in-flight writes beyond that size. The zero-fill is destructive - zero_head_off = np->n_size (smbfs_vnops.c:7391) feeds IO_HEADZEROFILL, and cluster_write zeros [n_size, uio_offset) without checking whether the UBC already holds those pages as valid/dirty (vfs_cluster.c), then flushes the zeros to the server. A defensive check there would neutralize the corruption regardless of cause. Has anyone else seen silent zero-runs in files written over SMB under concurrent access? Thanks!
0
0
24
14h
iOS26 beta: AppClips are not working properly
Hi, As a company, we have several apps in the AppStore that contain AppClips. With the latest iOS18 it works without any problems. With all iOS26 betas so far, however, there is always the problem “ASDErrorDomain- Error 507” and the AppClip cannot be opened. You can easily test this by scanning the following QR code with the system camera: You only ever get this error instead of the option to open the AppClip. As the iOS26 beta phase is already at an advanced stage, we are naturally concerned as to whether the problem will be solved.
18
4
1.6k
14h
Notarization error 7000 for Team F587Y8G7S4 — case 102932780546 open 66 days, "escalated to engineering" twice, no ticket number
Can someone at Apple please help move this case forward? Team F587Y8G7S4 (Individual membership, active since 3 July 2026) has never been able to notarize. Every submission, including an empty test zip, is rejected before scanning with: statusCode 7000 — "Team is not yet configured for notarization" issues: null, ticketContents: null Latest test: submission 08e5b2a7-db7d-4a3c-b760-fbe97266ad0a, 7 September 2026, 18:10 UTC. First occurrence: submission f2331ba3-65e0-4513-aa46-da98ecc6d742, 3 July 2026. Signing: Developer ID Application (G2), hardened runtime, uploads succeed. Membership and all agreements are active. Developer Programs Support case 102932780546 has been open since 4 July. It was escalated on 25 July, then "escalated to our engineering team" on 18 August and again on 2 September. No internal ticket number, no timeline, and no engineer has contacted me. I have supplied every detail requested (repro steps, timestamps, screenshots). Please: Escalate case 102932780546 to the team responsible for Notary Service provisioning. Confirm Team F587Y8G7S4's notarization provisioning is being reviewed or reset. Provide the internal ticket number and the current next step. This is blocking a commercial macOS release. If you need anything else, tell me exactly what to provide.
0
0
204
14h
ppq.apple.com unavailable — developer-signed apps cannot be verified
Hello, ppq.apple.com appears to be unavailable. The issue is reproducible from multiple networks/devices. Requests to https://ppq.apple.com fail, preventing iOS from verifying developer-signed applications. This results in the device displaying an error indicating that an Internet connection is required to verify the developer/app. The issue appears to be server-side rather than related to the developer certificate or provisioning profile. Affected: (tested on) ppq.apple.com HTTPS / TCP 443 iOS 9.3.4 iPhone 5S [07/09/2026/20:07 + Zurich] Example: curl -I https://ppq.apple.com Response: HTTP/2 404 server: Apple date: Mon, 07 Sep 2026 18:08:13 GMT content-type: text/plain; charset=UTF-8 content-length: 0 x-b3-spanid: bdf368a2edbdbef7 x-b3-traceid: bdf368a2edbdbef7 x-b3-sampled: 1 strict-transport-security: max-age=31536000; includeSubdomains x-frame-options: SAMEORIGIN x-content-type-options: nosniff x-xss-protection: 1; mode=block Please investigate the availability of the PPQ service.
0
0
214
14h
iOS27, CIRAWFilter RAW9 broken/missing in latest dev beta
In the WWDC talk: https://developer.apple.com/videos/play/wwdc2026/305/?time=350 "Enhance RAW image processing with Core Image" there is a section on the new RAW9 processing APIs and how to enable them. First off, the sample code compiles on iOS18 but causes a runtime exception because the .version9 symbol cannot be found, looks like the header definition is missing a version check for this value, so I'm not sure how to use this code if you need to support iOS18. Also on later dev betas (I tried the latest beta7) now trying to check if version9 is available the value is no longer present in the supported list: guard filter.supportedDecoderVersions.contains(.version9) else { ... There is another value .version9DNG that resolves to true but if I try to use that decoder the colors on the RAW image are wrong and the image becomes corrupted. How to use the RAW9 decoder in the latest dev betas, what should the final code before production because the WWDC sample now seems out of date and was always wrong wrt. iOS18.
3
0
988
15h
AccessorySetupKit connects and disconnects BLE accessory before .accessoryAdded when using .bluetoothPairingLE
I am using AccessorySetupKit on iOS 26 to set up a BLE accessory. My discovery descriptor includes .bluetoothPairingLE the bonding mechanism is LESC (Just Works without IO capability). let descriptor = ASDiscoveryDescriptor() descriptor.bluetoothServiceUUID = NordicServiceUUID.nus.toCBUUID() descriptor.supportedOptions = [.bluetoothPairingLE] My peripheral shows up in the picker and after selecting it ASK goes through a connection and disconnection cycle before calling .accessoryAdded event within my app. Logging on the peripheral side (nRF5 SDK 17) shows that the ASK picker connected, bonded successfully, and then triggered a remote terminated connection event (0x13). Prior implementation without .bluetoothPairingLE flag used did not disconnect from the peripheral before calling .accessoryAdded. The issue I found with this implementation is that the Pairing Modal would not always be presented and thus we are trying to leverage .bluetoothPairingLE flag for consistent behaviour across various iPhones / iOS combinations. My question, is it expected behaviour for AccessorySetupKit to connect, perform bonding, then disconnect from the peripheral prior to providing said accessory to the app via .accessoryAdded callback? I could find no documentation or community discussion discussing this behaviour or flow.
0
0
23
15h
crash when trying to show NSAlert with Mac 27 beta with European and russian languages
Feedback Assistant Submission ID Reference : FB24634485 Attached is a sample code where after setting setlocale() to any of European languages or Russian language results in crash when calling NSAlert. Here is code snippet and crash log for reference. #import <Cocoa/Cocoa.h> int main(int argc, const char * argv[]) { @autoreleasepool { NSString* locale = @“fr_FR.UTF8"; setlocale(LC_ALL, locale.UTF8String); return NSApplicationMain(argc, argv); } } (IBAction)showAlertButtonTapped:(id)sender { NSAlert *alert = [[NSAlert alloc] init]; alert.messageText = NSLocalizedString(@"alert_title", nil); alert.informativeText = NSLocalizedString(@"alert_message", nil); alert.alertStyle = NSAlertStyleInformational; [alert addButtonWithTitle:NSLocalizedString(@"alert_ok_button", nil)]; [alert runModal]; } Crashlog
0
0
22
15h
Most trial conversions failing with billing errors on annual subscription
We offer a monthly subscription and an annual subscription with a 3-day free trial. Most of our trial users are not converting. They don't cancel — auto-renew stays on, Apple attempts the charge, and it fails with a billing error. The subscription goes into billing retry instead of converting. Our monthly product converts fine. Only the annual with the trial is failing. We've audited our implementation. We use an introductory offer only — no promotional offers, no signatures, no StoreKit configuration overrides. The initial purchases all complete successfully in the payment sheet. Nothing on our side participates in the renewal charge. Two questions: Has anyone seen this pattern, and is there anything on the developer side that can influence it? What actually happens to these subscriptions? Does Apple eventually collect and we get paid, or is this revenue simply lost? What percentage typically recovers during the billing retry period?
1
0
112
15h
Apple Developer Program enrollment stuck in Pending — payment never charged and support not responding
Hello, I’m having an issue enrolling in the Apple Developer Program as an Individual / Sole Proprietor. I completed the enrollment process and submitted the $99 membership purchase. Apple sent me an order acknowledgement saying that the order would be processed within 2 business days. However: My credit card has never been charged. My Developer account remains in Pending status. The account still shows “Purchase your membership”. Trying to continue or restart the enrollment sometimes results in “We are unable to process your request. An unknown error occurred.” I have already contacted Apple Developer Program Support, but so far I have only received the automatic confirmation and no actual response. My support case ID is 102955478572. It has now been several days with no progress. I have also seen other recent posts describing very similar enrollment/payment issues. Has anyone recently managed to resolve this? Is there currently a known issue with Apple Developer Program enrollment or payment processing? I would appreciate any guidance from Apple Developer Support on how to either complete the existing enrollment/payment or reset the stuck enrollment so I can try again.
Replies
1
Boosts
1
Views
317
Activity
10h
Sandbox allows free trial again on resubscribe to the same subscription
Title: Sandbox allows free trial again on resubscribe to the same subscription Hi everyone, I'm testing an auto-renewable subscription using App Store Connect with a Sandbox tester (not a local StoreKit configuration file). My subscription has an introductory free trial configured. Scenario: Purchase the subscription for the first time using a Sandbox Apple ID. The user receives the introductory free trial as expected. Let the subscription expire. Purchase the same subscription product again using the same Sandbox Apple ID. I receive an App Store Server Notification with Notification Type = RESUBSCRIBE, and the transaction appears to have a price of 0, making it look like the user received another free trial. From Apple's documentation, my understanding is that an introductory offer can only be redeemed once per subscription group per Apple ID. Based on that, I expected the second purchase to be charged immediately rather than receive another free trial. My questions are: Is this expected behavior in the Sandbox environment? Does Sandbox sometimes allow introductory offers to be redeemed multiple times for testing? Or am I misinterpreting the RESUBSCRIBE notification and the $0 transaction? I did not intentionally reset the Sandbox tester's introductory offer eligibility, and I'm purchasing the same product in the same subscription group with the same Sandbox Apple ID. Has anyone observed this behavior or can clarify whether this is expected in Sandbox versus production? Thanks!
Replies
1
Boosts
0
Views
322
Activity
11h
NSUnknownKeyException error when uploading with altool
I am attempting to upload a new version of an existing App. The build and upload technique is one that we've used for many years for many of the Apps we manage including this one. I've built the IPA file. I upload the IPA file using "xcrun altool" but I keep getting the error shown below. (Note, I have no issues uploading another one of our Apps using the same command.) AI is suggesting that the problem may be caused by the name of the App. The App name is "@1 Access". It is suggesting that the current version of the altool may not be handling the name starting with '@'. If I run in verbose mode I can see in the WEB SERVICE RESPONSE headers... "Applications = { "@1 Access 1.0 (iOS App)" = xxxxxxxxx; };". But the error message omits the '@'... "...for the key 1 Access 1.0 (iOS App)". Can anyone help me get passed this issue ? If this is a bug with altool, who do I contact as I tried Apple Developer Support but they just refer me to this Developer Forum ? ERROR: *** Terminating app due to uncaught exception 'NSUnknownKeyException', reason: '[<__NSDictionaryM 0x71248d360> valueForUndefinedKey:]: this class is not key value coding-compliant for the key 1 Access 1.0 (iOS App).' *** First throw call stack: ( 0 CoreFoundation 0x000000018444ebf0 __exceptionPreprocess + 176 1 libobjc.A.dylib 0x0000000183eda91c objc_exception_throw + 88 2 CoreFoundation 0x00000001844725c8 _CFBundleGetValueForInfoKey + 0 3 Foundation 0x000000018665eeb8 -[NSObject(NSKeyValueCoding) valueForUndefinedKey:] + 196 4 Foundation 0x0000000185bfd71c -[NSObject(NSKeyValueCoding) valueForKey:] + 280 5 Foundation 0x0000000185be1ea4 -[NSDictionary(NSKeyValueCoding) valueForKey:] + 144 6 ContentDelivery 0x0000000100b73528 -[NSDictionary(ContentDelivery) sanitize] + 276 7 ContentDelivery 0x0000000100b73590 -[NSDictionary(ContentDelivery) sanitize] + 380 8 ContentDelivery 0x0000000100b73590 -[NSDictionary(ContentDelivery) sanitize] + 380 9 ContentDelivery 0x0000000100b3ef48 -[CDWebService invokeJsonWithServiceURL:operationName:params:] + 14328 10 ContentDelivery 0x0000000100b43c40 -[CDWebService makeServiceCall:params:] + 4272 11 ContentDelivery 0x0000000100b45190 -[CDWebService(lookupSoftwareForBundleID) lookupSoftwareForBundleID:] + 380 12 ContentDelivery 0x0000000100b51d84 -[CDAuthContext providerPublicIDForBundleID:] + 404 13 altool 0x000000010047fb48 altool + 31560 14 altool 0x000000010048dbfc altool + 89084 15 altool 0x0000000100495b9c altool + 121756 16 altool 0x0000000100496f5c altool + 126812 17 altool 0x000000010049b909 altool + 145673 18 altool 0x0000000100483a59 altool + 47705 19 libswift_Concurrency.dylib 0x00000002883f2f45 _ZL22completeTaskAndReleasePN5swift12AsyncContextEPNS_10SwiftErrorE + 1 ) libc++abi: terminating due to uncaught exception of type NSException zsh: abort xcrun altool --upload-app -f "Access1.ipa" -t ios -u -p xxxxxx
Replies
4
Boosts
0
Views
346
Activity
11h
Sign in with Apple: "Sign Up Not Completed" for every App ID in our team — framework returns canceled (1001) with empty userInfo
Sign in with Apple fails for every App ID in our team (K9UFUZF2XW), on every device and every Apple ID we have tried. The system sheet appears, the user authenticates successfully, the sheet then shows "Sign Up Not Completed", and no credential is returned. The failure happens after authentication — this is not a client-side rejection. I have spent several days isolating this and have ruled out everything on my side. Posting the full evidence in case an Apple engineer can look at the server-side state for our team, and in case it helps others hitting the same wall. WHAT THE FRAMEWORK ACTUALLY RETURNS The client library we use (expo-apple-authentication) discards the original NSError, so I patched its native layer to surface the raw error verbatim. This is what ASAuthorizationController hands back to didCompleteWithError, immediately after the user authenticated and the sheet displayed "Sign Up Not Completed": ASAuthorizationError .canceled (rawValue = 1001) domain = com.apple.AuthenticationServices.AuthorizationError code = 1001 desc = The operation couldn't be completed. (com.apple.AuthenticationServices.AuthorizationError, error 1001) userInfo: NSUnderlyingError: So the framework reports a user cancellation that never happened, with a completely empty userInfo and no underlying error. There is no diagnostic information on the client at all — I cannot debug this any further from my side, because the information does not exist there. Note: the same failure surfaces as a different error code depending on the client library version — .unknown (1000) with the older version, .canceled (1001) with the current one. The user-visible behaviour ("Sign Up Not Completed") is identical in both. So the error code is not a reliable signal here. WHAT I RULED OUT Not the App ID. I created a brand-new App ID (kz.auraai.ios) with Sign in with Apple enabled as a primary App ID, built a fresh binary, tested on the same device with the same Apple ID — identical failure. Two independent App IDs in the same team fail the same way. Not the entitlement. Verified inside the signed binary, not just in the portal: application-identifier = K9UFUZF2XW.kz.auraai.ios com.apple.developer.applesignin = ["Default"] I also tried the workaround suggested elsewhere on these forums (removing the entitlement while keeping the capability in the portal). That made it strictly worse: iOS then rejects the request instantly, without showing the sheet at all. Which confirms iOS reads the entitlement correctly, the sheet works, and the user authenticates — the failure is downstream of all of that. No stray or wildcard App IDs. A commonly cited cause is other App IDs in the team lacking the entitlement. I enumerated the whole team via the App Store Connect API: it contains exactly two App IDs, both with APPLE_ID_AUTH = PRIMARY_APP_CONSENT. No wildcard identifiers exist. Not the Apple ID, the device, or the iOS version. The same Apple ID, on the same device, with the same iOS, signs in successfully through another app belonging to a different team (Expo Go, host.exp.Exponent) — a valid identity token is returned. A second, unrelated Apple ID on another device fails in my app in exactly the same way. So this is not scoped to one account: it affects every user of the app. Agreements and membership are in good standing. Program License Agreement accepted 30 June 2026; Developer Agreement accepted 26 June 2026; membership active. Both distribution types fail. TestFlight and ad-hoc. WHAT IS LEFT After all of the above, the only variable that differs between the working case (a different team's app, same device, same Apple ID) and the failing case (my app) is the Apple Developer team itself. This exact signature — sheet renders fully, final server submit fails, "Sign Up Not Completed", delegate reports canceled with no userInfo, not reproducible in other apps on the same device — is documented in thread 122458 ("Error: Sign-Up Not Completed"). In that case it affected multiple developers, including Apple's own sample app, and was ultimately resolved by Apple on the server side, with a recurrence reported in June 2025. THE ASK Could someone from Apple check the server-side Sign in with Apple registration for team K9UFUZF2XW (App IDs kz.auraai.app and kz.auraai.ios)? I am not looking for configuration advice — I have exhausted the client side and there is nothing left to configure. This looks like the same server-side state that was fixed in the referenced cases. Feedback Assistant: FB23716661 (includes sysdiagnose with the Accounts/AuthKit profile, timestamp, and video of the failure). This is currently blocking us: because Sign in with Apple works for none of our users, guideline 4.8 prevents us from offering Google Sign-In, so we are shipping with email-only login. Happy to provide the binary, entitlements dump, or a fresh sysdiagnose on request.
Replies
75
Boosts
5
Views
13k
Activity
11h
Feature Request: Native Lisu (Fraser Script) Keyboard Support for iOS
To the Apple iOS Development and Accessibility Teams, I am writing to formally request the addition of a native Lisu keyboard to iOS. As Apple continues to expand its global accessibility and language support, adding the Lisu language would bridge a significant communication gap for a vibrant and growing community. About the Lisu People: The Lisu are a Tibeto-Burman ethnic group with an estimated population of over 1.4 million. They traditionally inhabit the mountainous regions of Myanmar (Burma), Southwest China (particularly the Yunnan and Sichuan provinces), Thailand, and the Indian state of Arunachal Pradesh. They possess a rich cultural heritage, passed down through generations via extensive oral traditions, songs, and clan histories. The Lisu Language and Fraser Script: The Lisu language is officially supported by the Unicode Consortium. The writing system, known as the Fraser script, was developed in 1914 and was officially added to the Unicode Standard in Version 5.2. Unicode Reference: The Lisu block is designated at U+A4D0 – U+A4FF. Official Chart: Unicode [Lisu Chart (PDF)] https://www.unicode.org/charts/PDF/UA4D0.pdf Current Industry StandardsOther major operating systems have already recognized the importance of supporting the Lisu community: Microsoft Windows: Currently comes with a pre-installed Lisu keyboard, allowing users to type seamlessly out of the box. Android (Google): The default Gboard natively supports the Lisu keyboard, offering full mobile typing capabilities for Android users. Currently, iOS users who speak and write in Lisu must rely on third-party workarounds, which often lack the security, privacy, and seamless integration of Apple’s native keyboards. By implementing the Lisu keyboard, Apple would greatly enhance the iOS experience for over a million people, allowing them to communicate natively on their iPhones and iPads.Thank you for your time, consideration, and ongoing commitment to making technology accessible to everyone. I look forward to seeing Lisu supported in a future iOS update. Sincerely, Si_Gwa
Replies
3
Boosts
2
Views
1.5k
Activity
12h
Live Activity ending immediately after being created
I'm seeing a Live Activity that's ended almost immediately after I'm creating it. I'm not ending the activity in my code, so something is happening at the system level. iOS version is 18.3.1. Looking at the logs for liveactivitiesd, I see that it was successfully created: default 12:57:34.837266-0800 liveactivitiesd Created activity: 22713DF6-E853-4B34-85FA-CD08D8FCA91B default 12:57:34.837639-0800 liveactivitiesd Starting activity: identifier: 22713DF6-E853-4B34-85FA-CD08D8FCA91B; createdDate: 2025-02-17 20:57:34 +0000; state: active; deviceIdentifier: local; resolvedContentSources: [ActivityKit.ActivityContentSource.process(target: <snip>), ActivityKit.ActivityContentSource.sync]; lastUpdateDate: 2025-02-17 20:57:34 +0000; endingOptions: nil default 12:57:34.858701-0800 liveactivitiesd Activity did start 22713DF6-E853-4B34-85FA-CD08D8FCA91B But then moments later, it's immediately ended: default 12:57:34.933963-0800 liveactivitiesd Ending activity 22713DF6-E853-4B34-85FA-CD08D8FCA91B for XPC participant content source <private> default 12:57:34.933983-0800 liveactivitiesd Stopping activity: 22713DF6-E853-4B34-85FA-CD08D8FCA91B default 12:57:34.934019-0800 liveactivitiesd Activity: identifier: 22713DF6-E853-4B34-85FA-CD08D8FCA91B; createdDate: 2025-02-17 20:57:34 +0000; state: active; deviceIdentifier: local; resolvedContentSources: [ActivityKit.ActivityContentSource.process(target: <snip>), ActivityKit.ActivityContentSource.sync]; lastUpdateDate: 2025-02-17 20:57:34 +0000; endingOptions: nil should be discarded now default 12:57:34.934442-0800 liveactivitiesd Activity discarded: 22713DF6-E853-4B34-85FA-CD08D8FCA91B Again, I'm not ending this activity in my code. I'll occasionally see this happen in my app, and the only solution I've found is to restart my device. Afterwards, everything seems fine. Is this a bug?
Replies
2
Boosts
2
Views
704
Activity
13h
App Review Delay and No Response from Support
App has been in review with no change in status for 2 weeks now. I contacted support and have heard nothing back on case ID is 102950117204. Even a simple reply that you are backed up and an acknowledgment that my app is in the queue would be appreciated. I've read advice on the forums about cancelling and resubmitting, but I've already waited 2 weeks and don't want to go the back of the queue. The status has been "waiting for review" for this period, so I assume you have it and it's in a queue.
Replies
3
Boosts
0
Views
564
Activity
13h
Developer Account Membership Expired – Cannot Find Renewal Option (Team ID: 532YXBDAKC)
Hi everyone, My Apple Developer Program membership has expired on March 11, 2026, and I am unable to find any option to renew it. Team ID: 532YXBDAKC I have checked the following places but there is no renewal option available anywhere: The Apple Developer website (developer.apple.com) – no renewal button or prompt visible in my account The Apple Developer app on Mac – no renewal option found The Apple Developer app on iPhone – no renewal option found I would like to renew my membership as soon as possible, but I am completely stuck as there is no clear path to do so. Has anyone else faced this issue? How can I get this resolved? Is there a direct way to contact Apple Developer support for membership renewal? Any help would be greatly appreciated. Thank you.
Replies
4
Boosts
0
Views
446
Activity
13h
AASA CDN intermittently times out / requests wrong path (/apple-app-site-association vs /.well-known/...)
Hi Everyone, We are tinkering on an App using associated domains with the working name "uff2.de". We have configured our Webserver (Caddy) to restrict all URIs except for /.well-known/apple-app-site-association using Www-Authenticate. Recently our associated domains started becoming flaky, which we believe has to do with requests from Apple’s CDN failing: The following example uses a query string to trigger a fresh request by Apple’s CDN. curl -sD - "https://app-site-association.cdn-apple.com/a/v1/uff2.de?foobar" -o /dev/null HTTP/1.1 404 Not Found Server: AppleHttpServer/7b3d349ae60c243cdd677edbde3e93e460f75820 Date: Sat, 05 Sep 2026 12:01:16 GMT Content-Type: text/plain; charset=utf-8 Content-Length: 10 Apple-Failure-Details: {"cause":"Connection timed out"} Apple-Failure-Reason: SWCERR00301 Timeout Apple-From: https://uff2.de/.well-known/apple-app-site-association Apple-Try-Direct: true Cache-Control: max-age=3600,public Vary: Accept-Encoding X-B3-TraceId: 457b6172513a930f Strict-Transport-Security: max-age=31536000 Age: 32 Via: https/1.1 defra2-vp-vst-018.ts.apple.com (acdn/331.16659), https/1.1 defra2-vp-vfe-016.ts.apple.com (acdn/331.16659), https/1.1 gbslo5-xdc-mx-020.ts.apple.com (acdn/331.16659), https/1.1 uklon5-edge-fx-024.ts.apple.com (acdn/331.16659) X-Cache: miss, miss, miss, miss CDNUUID: df5ac203-4188-4722-8bbc-68e9d9fd0b33-1118024500 Connection: keep-alive To investigate this further we enabled access logging and are seeing the following request that is blocked by us: 2026/09/05 12:01:16.824 INFO http.log.access.log0 handled request {"request": {"remote_ip": "57.103.82.202", "remote_port": "48366", "client_ip": "57.103.82.202", "proto": "HTTP/1.1", "method": "GET", "host": "uff2.de", "uri": "/apple-app-site-association", "headers": {"User-Agent": ["AASA-Bot/1.0.0"], "Accept-Encoding": ["gzip"]}, "tls": {"resumed": false, "version": 772, "cipher_suite": 4865, "proto": "", "server_name": "uff2.de"}}, "bytes_read": 0, "user_id": "", "duration": 0.000083782, "size": 0, "status": 401, "resp_headers": {"Server": ["Caddy"], "Alt-Svc": ["h3=\":443\"; ma=2592000"], "Www-Authenticate": ["Basic realm=\"restricted\""]}} But this seems to be the wrong URI (/apple-app-site-association instead of /.well-known/apple-app-site-association). When swapping ?foobar for other query strings like ?foobar2 or ?foobar3, some requests randomly work and some don’t. We’re also seeing flakiness for the same path (both with and without a query string) across time, but this is harder to test due to caching. For reference this is a correct request: 2026/09/05 17:54:26.075 INFO http.log.access.log0 handled request {"request": {"remote_ip": "57.103.81.17", "remote_port": "8692", "client_ip": "57.103.81.17", "proto": "HTTP/1.1", "method": "GET", "host": "uff2.de", "uri": "/.well-known/apple-app-site-association", "headers": {"User-Agent": ["AASA-Bot/1.0.0"], "Accept-Encoding": ["gzip"]}, "tls": {"resumed": false, "version": 772, "cipher_suite": 4865, "proto": "", "server_name": "uff2.de"}}, "bytes_read": 0, "user_id": "", "duration": 0.000088472, "size": 469, "status": 200, "resp_headers": {"Accept-Ranges": ["bytes"], "Content-Length": ["469"], "Server": ["Caddy"], "Alt-Svc": ["h3=\":443\"; ma=2592000"], "Vary": ["Accept-Encoding"], "Etag": ["\"dgrdbiykgv3ad1\""], "Content-Type": [], "Last-Modified": ["Sun, 01 Mar 2026 10:19:41 GMT"]}} Did we misread the documentation and should also serve /apple-app-site-association? Why would requests sometimes be made to /.well-known/apple-app-site-association and sometimes to /apple-app-site-association? Thank you!
Replies
2
Boosts
1
Views
95
Activity
13h
App Clip: “Invalid Entitlement: Unknown ID” despite valid AASA file and Apple CDN access
I am experiencing an App Clip domain verification issue in App Store Connect. App: Bini Music Version: 4.1.0 Build: 6 Main App Bundle ID: ninja.wpapp.appbinimusikcom App Clip Bundle ID: ninja.wpapp.appbinimusikcom.Clip Team ID: DY8SYXAUKN Domain: binimusik.com The Associated Domains capability is enabled on both the main app target and the App Clip target with: appclips:binimusik.com The AASA file is publicly accessible at: https://binimusik.com/.well-known/apple-app-site-association The AASA file contains: DY8SYXAUKN.ninja.wpapp.appbinimusikcom.Clip I have also verified the AASA file through Apple's associated-domains CDN, and Apple's CDN returns the correct AASA content and App Clip identifier. Build 6 has been successfully uploaded to App Store Connect and its Binary State is “Validated”. However, in TestFlight → Build 6 → Build Metadata → App Clip → Domain Status, App Store Connect continues to report: Cache Status: Cannot Reach AASA File Debug Status: Invalid Entitlement: Unknown ID The Cache Status has not refreshed and still says: “Cache status updated on Sep 2, 2026 at 3:58 PM.” I checked again on September 7 and the status remains unchanged. Apple Developer Support referred me to the Developer Forums because this appears to require technical assistance. Has anyone encountered “Invalid Entitlement: Unknown ID” with an App Clip even though the AASA file is reachable by Apple's CDN? Is there anything else that needs to be configured, or could this be an App Store Connect domain-validation issue?
Replies
1
Boosts
0
Views
77
Activity
14h
Delete build Apple Store Connect TestFlight
One build has version 1.0 the other has version 1.01. Both has status Complete. How to remove the version 1.0 one ?
Replies
7
Boosts
1
Views
343
Activity
14h
CPListItem and CPListImageRowItem text limited to 1 line on iOS 27
On iOS 27, CPListItem.text and CPListImageRowItem.text` are rendered as single-line with ellipsis truncation, regardless of the available vertical space. On iOS 26 and earlier, these properties wrapped to 2 lines before truncating. There is no public API (numberOfLines, lineLimit, or similar) on CPListItem, CPListImageRowItem, or CPListSection to control the number of text lines. The change appears to be a platform-level rendering default with no app-side opt-out. Steps to Reproduce Create a CPListTemplate with sections containing CPListItem or CPListImageRowItem items. Set the text property to a string long enough to require wrapping. Present the template via CPInterfaceController. Run on iOS 27. Expected Results The text property should wrap to multiple lines (2-3 lines) before truncating with an ellipsis, consistent with iOS 26 behavior. Row height should adjust dynamically to accommodate the wrapped text. Actual Results The text property is truncated to a single line with ellipsis. Row height remains fixed at a larger size, creating excessive vertical spacing between items. Environment iOS 27.0 (CarPlay) - issue present Xcode 27.0 beta 4 (27A5218g) Tested on physical CarPlay head unit and CarPlay Simulator
Replies
5
Boosts
0
Views
984
Activity
14h
smbfs silently zero-fills already-written data after cached file size regresses on reopen
Hello everyone, I've been chasing a nasty silent data corruption bug in the macOS SMB client (smbfs.kext) and wanted to share what I found, in case someone else has hit it and in the hope that someone from the SMB team sees it. What happens Under concurrent writes with repeated reopens, the client can regress its cached file size (np->n_size) to an earlier, smaller value - behind data it has already written and flushed to the server. The next write then treats the already-written range as a hole, zero-fills it via IO_HEADZEROFILL, and sends the zeros to the server, right on top of the correct bytes it transmitted moments earlier. No write(2) fails and nothing is logged - the file just quietly comes back with a chunk-aligned run of zeros in the middle, at the correct overall length. Environment macOS 26.5 (Darwin 25.5.0), Apple silicon (16 KiB VM pages), SMB 2.1 Sources referenced: SMB client 538.121.1, xnu 12377.121.6 How to reproduce Mount an SMB 2.1(2.0.2 has the same issue as well) share. Have several threads write the same files in 8 KiB chunks, each chunk via its own open/lseek/write/close (so the file is reopened constantly as it fills), while the files are concurrently resolved by name (stat / directory enumeration). Read the files back through a cache-cold path (second mount, or F_NOCACHE) and compare. Roughly 1 file in several hundred came back corrupted for me. The core of the write pattern: CHUNK = 8192 # 2 chunks per 16 KiB page def write_chunk(path, data, offset): fd = os.open(path, os.O_CREAT | os.O_RDWR) # own handle per chunk try: os.lseek(fd, offset, os.SEEK_SET) os.write(fd, data) finally: os.close(fd) # per file: content = os.urandom(random.randint(265000, 300000)); # chunks written in batches of 8 threads, joined between batches; # each file written twice from the same buffer: NAME, then NAME.copy In my runs the corruption always landed on the second (.copy) write. One caveat: I reproduced this against a third-party SMB server, not against macOS File Sharing (smbd), and I don't expect it to reproduce against smbd directly. The stale size arrives via reopen-via-lookup (smbfs_update_size <- smbfs_nget <- smbfs_vnop_lookup) on a freshly instantiated vnode, whose n_sizetime lets the freshness guard pass. smbd instead reopens via vnop_compound_open -> smbfs_attr_cacheenter (warm vnode; the guard rejects it) - the same stale-size candidates occur, they just all get rejected. The server merely steers the client onto the vulnerable path; the bug itself is entirely client-side. What I observed I captured the kernel side with dtrace fbt probes on smbfs_setsize() / smbfs_update_size() (os_log drops events under this load). Timeline for one corrupted file, correlating pcap and dtrace (dtrace has whole-second resolution, marked ".x"): [pcap] = network packet capture of the SMB traffic between client and server [dtrace] = kernel-side trace of the smbfs size-update functions; timestamps only have whole-second resolution, so ".x" marks an unknown sub-second time :39.778 [pcap] — client sends WRITE off=32768 len=32768 with the correct data, covering [40960:65536). :39.777–.860 [pcap] — throughout, the server's CREATE/CLOSE responses report a strictly monotonic EOF: 0, 8192, 40960, 65536, ... 288255. :39.x [dtrace] — on a reopen, smbfs_update_size applies EOF 40960 (a superseded value), regressing n_size from 65536 to 40960. :39.x [dtrace] — the next write starts past the regressed size, so zero_head_off = 40960 and IO_HEADZEROFILL is set. :39.804 [pcap] — client sends WRITE off=32768 len=57344, ALL ZEROS over [40960:65536), on top of the correct data it sent 26 ms earlier. End result: the file is 288255 bytes (correct length) with 24 KiB of zeros at [40960:65536) - three consecutive 8 KiB chunks, i.e. 1.5 x 16 KiB VM pages. Worth stressing: the server's own responses reported a strictly monotonic EOF the whole time, so the regression to 40960 was purely the client applying a superseded value. Expected, obviously: the file reads back byte-for-byte identical to what was written. Where I think the bug is From reading the smbfs and xnu sources, three things combine: np->n_size isn't consistently synchronized - read under the node lock only (smbfs_vnops.c:7329/7387/7391) but written under f_clusterWriteLock (:7411) and by smbfs_vnop_strategy under the cluster lock, so the reader deciding the zero-fill has no ordering guarantee. Possible fix: read it once under f_clusterWriteLock in smbfs_vnop_write so the snapshot, extend, and zero_head_off stay consistent. The freshness guard checks the wrong thing - smbfs_update_size's reqtime <= n_sizetime guard validates the reply's request time, not whether the value is still current, so a superseded (smaller) size applied later still passes and calls smbfs_setsize(smaller). Possible fix: never shrink n_size from fa_size while the vnode has dirty pages or in-flight writes beyond that size. The zero-fill is destructive - zero_head_off = np->n_size (smbfs_vnops.c:7391) feeds IO_HEADZEROFILL, and cluster_write zeros [n_size, uio_offset) without checking whether the UBC already holds those pages as valid/dirty (vfs_cluster.c), then flushes the zeros to the server. A defensive check there would neutralize the corruption regardless of cause. Has anyone else seen silent zero-runs in files written over SMB under concurrent access? Thanks!
Replies
0
Boosts
0
Views
24
Activity
14h
iOS26 beta: AppClips are not working properly
Hi, As a company, we have several apps in the AppStore that contain AppClips. With the latest iOS18 it works without any problems. With all iOS26 betas so far, however, there is always the problem “ASDErrorDomain- Error 507” and the AppClip cannot be opened. You can easily test this by scanning the following QR code with the system camera: You only ever get this error instead of the option to open the AppClip. As the iOS26 beta phase is already at an advanced stage, we are naturally concerned as to whether the problem will be solved.
Replies
18
Boosts
4
Views
1.6k
Activity
14h
Notarization error 7000 for Team F587Y8G7S4 — case 102932780546 open 66 days, "escalated to engineering" twice, no ticket number
Can someone at Apple please help move this case forward? Team F587Y8G7S4 (Individual membership, active since 3 July 2026) has never been able to notarize. Every submission, including an empty test zip, is rejected before scanning with: statusCode 7000 — "Team is not yet configured for notarization" issues: null, ticketContents: null Latest test: submission 08e5b2a7-db7d-4a3c-b760-fbe97266ad0a, 7 September 2026, 18:10 UTC. First occurrence: submission f2331ba3-65e0-4513-aa46-da98ecc6d742, 3 July 2026. Signing: Developer ID Application (G2), hardened runtime, uploads succeed. Membership and all agreements are active. Developer Programs Support case 102932780546 has been open since 4 July. It was escalated on 25 July, then "escalated to our engineering team" on 18 August and again on 2 September. No internal ticket number, no timeline, and no engineer has contacted me. I have supplied every detail requested (repro steps, timestamps, screenshots). Please: Escalate case 102932780546 to the team responsible for Notary Service provisioning. Confirm Team F587Y8G7S4's notarization provisioning is being reviewed or reset. Provide the internal ticket number and the current next step. This is blocking a commercial macOS release. If you need anything else, tell me exactly what to provide.
Replies
0
Boosts
0
Views
204
Activity
14h
ppq.apple.com unavailable — developer-signed apps cannot be verified
Hello, ppq.apple.com appears to be unavailable. The issue is reproducible from multiple networks/devices. Requests to https://ppq.apple.com fail, preventing iOS from verifying developer-signed applications. This results in the device displaying an error indicating that an Internet connection is required to verify the developer/app. The issue appears to be server-side rather than related to the developer certificate or provisioning profile. Affected: (tested on) ppq.apple.com HTTPS / TCP 443 iOS 9.3.4 iPhone 5S [07/09/2026/20:07 + Zurich] Example: curl -I https://ppq.apple.com Response: HTTP/2 404 server: Apple date: Mon, 07 Sep 2026 18:08:13 GMT content-type: text/plain; charset=UTF-8 content-length: 0 x-b3-spanid: bdf368a2edbdbef7 x-b3-traceid: bdf368a2edbdbef7 x-b3-sampled: 1 strict-transport-security: max-age=31536000; includeSubdomains x-frame-options: SAMEORIGIN x-content-type-options: nosniff x-xss-protection: 1; mode=block Please investigate the availability of the PPQ service.
Replies
0
Boosts
0
Views
214
Activity
14h
iOS27, CIRAWFilter RAW9 broken/missing in latest dev beta
In the WWDC talk: https://developer.apple.com/videos/play/wwdc2026/305/?time=350 "Enhance RAW image processing with Core Image" there is a section on the new RAW9 processing APIs and how to enable them. First off, the sample code compiles on iOS18 but causes a runtime exception because the .version9 symbol cannot be found, looks like the header definition is missing a version check for this value, so I'm not sure how to use this code if you need to support iOS18. Also on later dev betas (I tried the latest beta7) now trying to check if version9 is available the value is no longer present in the supported list: guard filter.supportedDecoderVersions.contains(.version9) else { ... There is another value .version9DNG that resolves to true but if I try to use that decoder the colors on the RAW image are wrong and the image becomes corrupted. How to use the RAW9 decoder in the latest dev betas, what should the final code before production because the WWDC sample now seems out of date and was always wrong wrt. iOS18.
Replies
3
Boosts
0
Views
988
Activity
15h
AccessorySetupKit connects and disconnects BLE accessory before .accessoryAdded when using .bluetoothPairingLE
I am using AccessorySetupKit on iOS 26 to set up a BLE accessory. My discovery descriptor includes .bluetoothPairingLE the bonding mechanism is LESC (Just Works without IO capability). let descriptor = ASDiscoveryDescriptor() descriptor.bluetoothServiceUUID = NordicServiceUUID.nus.toCBUUID() descriptor.supportedOptions = [.bluetoothPairingLE] My peripheral shows up in the picker and after selecting it ASK goes through a connection and disconnection cycle before calling .accessoryAdded event within my app. Logging on the peripheral side (nRF5 SDK 17) shows that the ASK picker connected, bonded successfully, and then triggered a remote terminated connection event (0x13). Prior implementation without .bluetoothPairingLE flag used did not disconnect from the peripheral before calling .accessoryAdded. The issue I found with this implementation is that the Pairing Modal would not always be presented and thus we are trying to leverage .bluetoothPairingLE flag for consistent behaviour across various iPhones / iOS combinations. My question, is it expected behaviour for AccessorySetupKit to connect, perform bonding, then disconnect from the peripheral prior to providing said accessory to the app via .accessoryAdded callback? I could find no documentation or community discussion discussing this behaviour or flow.
Replies
0
Boosts
0
Views
23
Activity
15h
crash when trying to show NSAlert with Mac 27 beta with European and russian languages
Feedback Assistant Submission ID Reference : FB24634485 Attached is a sample code where after setting setlocale() to any of European languages or Russian language results in crash when calling NSAlert. Here is code snippet and crash log for reference. #import <Cocoa/Cocoa.h> int main(int argc, const char * argv[]) { @autoreleasepool { NSString* locale = @“fr_FR.UTF8"; setlocale(LC_ALL, locale.UTF8String); return NSApplicationMain(argc, argv); } } (IBAction)showAlertButtonTapped:(id)sender { NSAlert *alert = [[NSAlert alloc] init]; alert.messageText = NSLocalizedString(@"alert_title", nil); alert.informativeText = NSLocalizedString(@"alert_message", nil); alert.alertStyle = NSAlertStyleInformational; [alert addButtonWithTitle:NSLocalizedString(@"alert_ok_button", nil)]; [alert runModal]; } Crashlog
Replies
0
Boosts
0
Views
22
Activity
15h
Most trial conversions failing with billing errors on annual subscription
We offer a monthly subscription and an annual subscription with a 3-day free trial. Most of our trial users are not converting. They don't cancel — auto-renew stays on, Apple attempts the charge, and it fails with a billing error. The subscription goes into billing retry instead of converting. Our monthly product converts fine. Only the annual with the trial is failing. We've audited our implementation. We use an introductory offer only — no promotional offers, no signatures, no StoreKit configuration overrides. The initial purchases all complete successfully in the payment sheet. Nothing on our side participates in the renewal charge. Two questions: Has anyone seen this pattern, and is there anything on the developer side that can influence it? What actually happens to these subscriptions? Does Apple eventually collect and we get paid, or is this revenue simply lost? What percentage typically recovers during the billing retry period?
Replies
1
Boosts
0
Views
112
Activity
15h