Overview

I'm building an app that uses PrivateCloudComputeLanguageModel as the primary inference tier with SystemLanguageModel as the fallback. The app is entitled (com.apple.developer.private-cloud-compute, granted and provisioned) and generations serve normally. My question is how a client should decide to fall back because in extended measurement, no public signal ever reflects the blocked state I actually hit. What I measured (macOS 27.0 beta, 26A5416b / Xcode 27 beta 27A5237l, entitled signed bundle constructing PrivateCloudComputeLanguageModel directly): Serving stopped mid-run with no leading signal: request N served normally (1.4 s), request N+1 threw LanguageModelError.rateLimited 494 ms later, at cumulative generation 786 for the day. 100% served → 100% refused between consecutive calls. Every quota signal read healthy the entire time: before, during, and after the block. Across 1,517 readings in a single day: quotaUsage.status = belowLimit, isApproachingLimit = false, isLimitReached = false, resetDate = nil, availability = .available. A preflight on these APIs cannot see the condition. The refusal is enforced locally after first contact: rejections return in ~230 ms vs ~0.9–1.4 s for served calls, so the client appears to cache the verdict rather than ask the server per-request. The trigger is a cumulative ledger, not a request rate: 501 generations at 33/min in one 15-minute sitting was fine, and a later arm sustained 39.7/min; two bursts of 16 concurrent at 5.0 and 5.2 req/s served 32/32; the count that tripped survived a process restart and a 4.9-hour idle gap. But it's not a fixed daily number either. 501 fast was fine earlier the same day; the trip came 285 requests later. A rolling window on the order of hours-to-a-day is consistent with this, but nothing here measures its length. Recovery: still blocked at +41 minutes (probes at +1/2/5/10/20/40 min all refused); fully recovered by +20 h with no intervention and no upgrade. Next day served normally from the first request. quotaLimitReached never occurred: not once in ~800 generations plus the blocked period. The wall is typed as the transient error while carrying what the documentation describes as daily quota semantics ("a person either waits for their usage quota to refresh or they upgrade"). limitIncreaseSuggestion is presence-constant: nil at process start, non-nil on every reading after first PCC contact (identical while fully serving and while fully blocked) so its presence can't gate an upsell affordance. The same signals-read-healthy-while-refusing divergence also reproduces against the developer-tool pool (fm serve), which I've reported separately (FB24273854 covers quota exhaustion surfacing there as a generic server_error/500 while /health reports the model available). Questions: Is attempt-and-classify the intended contract? Given that no preflight can observe the blocked state, should a client simply issue the request, treat the typed error as authoritative, and route to SystemLanguageModel? And is the ~230 ms local fail-fast on the blocked path contractual (cheap and safe to probe) or incidental? This is the one that decides how I ship; the rest are diagnostics behind it. What does quotaUsage actually track, and at what granularity? I have driven the entitled app-tier path to a hard block and the developer-tool pool to exhaustion, and no field ever moved. Is there any consumption pattern that moves isApproachingLimit / isLimitReached / resetDate? If the intended answer is "only the per-person daily quota, which these volumes never approached," what is the wall I am hitting at ~786 cumulative, and why does it surface as rateLimited? Should rateLimited and quotaLimitReached drive different client behavior — and which one is the daily allowance in practice? The documentation distinguishes rate limiting ("wait a period and retry") from daily exhaustion ("wait for refresh or upgrade"), but what I observe is the transient-typed error carrying the multi-hour ledger semantics. Concretely: what retry cadence is recommended after rateLimited (my measured recovery horizon was somewhere between 41 minutes and 20 hours. My current design stays on the on-device model and re-probes PCC at a low fixed interval rather than per-request)? And under what condition is resetDate ever populated, given it was nil even while blocked? (Smaller, design guidance): my app can generate a few hundred requests as one feature batch (quiz generation over a user's imported document). Measured: 501 in a sitting was fine, cumulative 786 in a day was not. Since this allowance belongs to the person and is shared with every Apple Intelligence feature, is a several-hundred-request batch a reasonable use of it, or should features like this generate on demand? (I'm aware of the existing feature request for richer quota reporting (FB23378161); this is a narrower design question.) I can attach the measurement driver and timestamped JSONL logs. The divergence is reproducible on a fresh day, though reaching the wall took ~800 cumulative generations.

I am waiting my app update 2nd or 3rd week, and also I tried to change my country inside apple dev account, it's really hard to reach full support of the account, sending request and not getting back proper actions.

Here is a natural, professional English translation suitable for a bug report (such as filing via Apple's Feedback Assistant): Title / Summary Photos app defaults to creation time instead of EXIF date when region and time format are mismatched Bug Description Photos saved or received in the system Photos app (via downloads, AirDrop, etc.) use the saving timestamp as their capture date instead of preserving the photo's original metadata/EXIF timestamp. Steps to Reproduce Go to Settings > General > Language & Region. Set a Region whose default time format differs from your custom toggle (e.g., set Region to Japan, which defaults to a 24-hour clock, but manually switch the time format toggle to 12-Hour Time). Save or receive an image via AirDrop/download. Observe that the photo's original date metadata is ignored and replaced by the current timestamp. Root Cause Analysis The bug occurs when the device's custom time format (12/24-hour) mismatches the default time format of the selected Region, causing date metadata parsing to fail in the Photos app. Workaround Resetting the time format back to match the Region's default setting resolves the issue. Expected Result The system should correctly parse and preserve original image creation dates regardless of custom region or time format overrides. This issue should be resolved in a future software update. Affected OS Versions iOS 17+ iPadOS 17+ macOS 14 (Sonoma)+

Hey everyone, hoping to compare notes on something we have been chasing since beta 5. We have a Mac app that uses FoundationModels with @Generable types for structured output. Starting with macOS 27 beta 5, guided generation requests began logging tokenizer errors and our longer structured requests slowed from seconds to minutes. We are still seeing the same thing on beta 6 and beta 7. We filed it as FB24310823 on August 11 with a sysdiagnose and log captures. The signature is easy to check if you want to see whether your machine does it too. Stream the log while your app generates: log stream --predicate 'subsystem == "com.apple.tokengenerationcore"' --style compact On our machine the inference service (TGOnDeviceInferenceProviderService, category guided) prints these two lines in matched pairs, thousands of times: Generated an empty mask at recognizer index N allowedTokenIDs is empty. Something is likely wrong with the tokenizer Some numbers from beta 7 today: 9,008 of those pairs in about five and a half minutes. The errors start about one second into the first request after a fresh app launch. Requests that normally finish in 4 to 12 seconds take 77 to 170 seconds or longer. On beta 5 we measured decode at roughly 0.3 tokens per second on the worst requests. Short requests still finish at normal speed but they emit the same errors while they run, and the structured content they return looks degraded to us. On betas 5 and 6 we also saw repeated asset release errors for instruct_300m.tokenizer and the instruct_3b tokenizer saying the asset is not marked as in use. For what it is worth, a build that ran clean on beta 4 shows the same behavior on beta 5 and later with no app changes, and the same @Generable schema drives both the fast and the slow requests. But we know that does not rule out something on our side, and we would honestly be happy to learn this is our own bug since that would mean we can fix it. So two questions. Is anyone else seeing this since beta 5? And if you spot something we might be doing wrong on our end, sessions we should be recreating, schema patterns that stress the constrained decoder, anything at all, we would really appreciate the feedback. If it does turn out you are hitting the same thing, a Feedback referencing FB24310823 would help a lot. Thanks!

Hey everyone, hoping to compare notes on something we have been chasing since beta 5. We have a Mac app that uses FoundationModels with @Generable types for structured output. Starting with macOS 27 beta 5, guided generation requests began logging tokenizer errors and our longer structured requests slowed from seconds to minutes. We are still seeing the same thing on beta 6 and beta 7. We filed it as FB24310823 on August 11 with a sysdiagnose and log captures. The signature is easy to check if you want to see whether your machine does it too. Stream the log while your app generates: log stream --predicate 'subsystem == "com.apple.tokengenerationcore"' --style compact On our machine the inference service (TGOnDeviceInferenceProviderService, category guided) prints these two lines in matched pairs, thousands of times: Generated an empty mask at recognizer index N allowedTokenIDs is empty. Something is likely wrong with the tokenizer Some numbers from beta 7 today: 9,008 of those pairs in about five and a half minutes. The errors start about one second into the first request after a fresh app launch. Requests that normally finish in 4 to 12 seconds take 77 to 170 seconds or longer. On beta 5 we measured decode at roughly 0.3 tokens per second on the worst requests. Short requests still finish at normal speed but they emit the same errors while they run, and the structured content they return looks degraded to us. On betas 5 and 6 we also saw repeated asset release errors for instruct_300m.tokenizer and the instruct_3b tokenizer saying the asset is not marked as in use. For what it is worth, a build that ran clean on beta 4 shows the same behavior on beta 5 and later with no app changes, and the same @Generable schema drives both the fast and the slow requests. But we know that does not rule out something on our side, and we would honestly be happy to learn this is our own bug since that would mean we can fix it. So two questions. Is anyone else seeing this since beta 5? And if you spot something we might be doing wrong on our end, sessions we should be recreating, schema patterns that stress the constrained decoder, anything at all, we would really appreciate the feedback. If it does turn out you are hitting the same thing, a Feedback referencing FB24310823 would help a lot. Thanks!

Has anyone else hit this? We have a Mac app that uses FoundationModels with @Generable types for structured output. Starting with macOS 27 beta 5 every guided generation request began logging tokenizer errors and long structured requests slowed from seconds to minutes. Beta 6 and beta 7 both still have it. Filed as FB24310823 on August 11 with a full sysdiagnose and log captures, and we have appended evidence from each beta since. The signature is easy to check. Stream the log while your app generates: log stream --predicate 'subsystem == "com.apple.tokengenerationcore"' --style compact On an affected machine the inference service (TGOnDeviceInferenceProviderService, category guided) prints these two lines in matched pairs, thousands of times: Generated an empty mask at recognizer index N allowedTokenIDs is empty. Something is likely wrong with the tokenizer What we measured on beta 7 today: 9,008 of those pairs in about five and a half minutes of scanning. The errors start about one second into the first request after a fresh app launch, so it needs no warmup. Requests that normally finish in 4 to 12 seconds take 77 to 170 seconds or longer. On beta 5 we measured decode at roughly 0.3 tokens per second on the worst requests. Short requests still finish at normal speed but they emit the same errors while they run, and the quality of the structured content they return is degraded. On betas 5 and 6 we also saw repeated asset release errors for instruct_300m.tokenizer and the instruct_3b tokenizer saying the asset is not marked as in use. For what it is worth, a build that ran clean on beta 4 shows the same behavior on beta 5 and later with no app changes, and the same @Generable schema drives both the fast and the slow requests. But we know that does not rule out something on our side, and we would honestly be happy to learn this is our own bug since that would mean we can fix it. So two questions. Is anyone else seeing this since beta 5? And if you spot something we might be doing wrong on our end, sessions we should be recreating, schema patterns that stress the constrained decoder, anything at all, we would really appreciate the feedback. If it does turn out you are hitting the same thing, a Feedback referencing FB24310823 would help a lot. Thanks!

We ship an App Clip with our iOS app and want the App Clip card to appear when users share our website's links in Messages. Instead, recipients only get a plain link preview. The App Clip was approved and has been live on the App Store for over a week. We've verified every requirement from the docs ("Associating your App Clip with your website" and the Messages invocation requirements): The invocation page's server-rendered HTML (no JS needed) contains the meta tag: apple-itunes-app with app-id and app-clip-bundle-id set correctly. /.well-known/apple-app-site-association has an "appclips" section listing the clip's app ID, and Apple's AASA CDN (app-site-association.cdn-apple.com/a/v1/) serves the same content. The App Clip's entitlements include appclips: and the correct parent application identifier. Via the App Store Connect API, the currently live build contains the APP_CLIP build bundle, and the live version has a default App Clip experience (action OPEN, with localizations). The default experience link https://appclip.apple.com/id?p= returns 200 and shows the clip. Tested in Messages between two devices whose owners are in each other's contacts, in brand-new conversations, on current iOS. However, on-device App Clip diagnostics (Settings > Developer > App Clips Testing > Diagnostics) for the invocation URL show the "App Clip Published on App Store" and "Associated Domains" checks not passing, even though everything above is verified correct. ("No Advanced Experience registered" also appears, but as we understand it advanced experiences are only needed for QR/NFC/App Clip Codes, not Messages.) Has anyone seen device-side association fail like this when the server-side config is demonstrably correct? Is there a known propagation delay after releasing a new app version, or a way to force the device to refresh its App Clip association cache beyond rebooting? Any pointers on what the diagnostics tool checks that isn't covered by the list above would be appreciated.

Hi, I have an iOS app already released on the App Store and I am preparing an update for version 1.1. The problem is that my Mac is currently running a macOS beta. Because of that, the stable public version of Xcode does not work correctly on this system due to version compatibility issues. I can build and archive the app only with Xcode beta. However, when I upload the archive made with Xcode beta to App Store Connect, the upload is rejected because builds for App Store distribution cannot be submitted from a beta version of Xcode. So I am stuck in this situation: stable Xcode cannot be used on my current macOS beta installation; Xcode beta can build and archive the app; App Store Connect does not accept archives built with Xcode beta; the app update is ready, but I cannot submit it. What is the recommended solution in this case? Can I use Xcode Cloud or another Apple-supported cloud build option to archive the app with a stable Xcode version, even if my local Mac is running macOS beta? If Xcode Cloud is the correct approach, how can I enable it when I do not see the Xcode Cloud option inside Xcode and App Store Connect only shows the general Xcode Cloud introduction page? I would like to avoid downgrading macOS if possible, but I need to submit a valid App Store build made with a supported non-beta Xcode version. Thanks.

Hi all, Our app has been stuck since a Guideline 3.1.1 / 3.1.3(c) enterprise-services question was raised on Aug 17. We replied the same week with clarification, sent a follow-up on Aug 19 with no response, and resubmitted the build on Aug 21 with the clarification added directly to the App Review Information notes. Still no response as of today. We also opened a Developer Support escalation (Case ID: 20000143108217) confirming they were ready to help, but have not received any follow-up since. Apple ID: 6799377443 Submission ID: 1522a8de-defd-44f8-92e8-9edbb0d85c28 Current status: Waiting for Review Is there anything else we should try, or can someone from the App Review team take a look at this case? Happy to provide any additional information needed — we just want to understand what's needed to move forward. Thanks in advance for any help.

I specifically requested a Developer Support callback for an active App Review rejection, not general Apple Support. My issue wasn’t with my Apple ID, billing, or my account—it was about an App Review clarification that appears to be stuck in a loop. The rejection itself wasn’t because of a crash or missing functionality. It was another request for information that I had already provided in previous App Review responses. It genuinely felt like the reviewer was only looking at the latest message instead of the full review history and previous attachments. To try to resolve it, I called Developer Support and selected the App Review option. I waited on hold for over 3 hours. When someone finally answered, instead of helping with App Review or escalating the case, they transferred me to Apple Account Support. The representative there immediately told me they couldn’t help because my issue had nothing to do with Apple accounts, and they also couldn’t transfer me back to the App Review queue. So after waiting more than three hours, I was effectively back at square one and had to start over. Has anyone else experienced: Reviewers seemingly not seeing previous App Review responses or attachments? Being stuck in repeated clarification requests for information you’ve already provided? Being transferred from Developer Support to the wrong department after waiting hours? I’m trying to figure out whether this is an isolated incident or whether the App Review support process has been breaking down recently.

Per Apple documentation, The system supports use of NFCPaymentTagReaderSession only within the European Union (EU). To develop and test an app that uses this feature, see Request the NFCTagReaderSession Development Entitlement. People using your app must have an account registered in the EU, and their device must be located within the EU. If the device isn’t currently eligible to use NFCPaymentTagReaderSession, the NFCPaymentTagReaderSession.readingAvailable property is false. When submitting Request the NFCTagReaderSession Development Entitlement form, is it different from this capability that can be enabled through Xcode's Signing & Capabilities tab: com.apple.developer.nfc.readersession.formats TAG

It is literally taking forever to get my application on the App Store. They keep finding problems and another 3 day wait.

Hello, I had filled up the application to convert my Apple Developer account from individual to a Organisational account. But haven't heard back from Apple yet regarding this. How do I check the latest status? Thanks.

I submitted my first app just in time for week 0 of college football. It's still in the original status of pending review. When I submitted the message said most apps are reviewed in 24 hours of less, but can take up to 48 hours. Is there something on my end I need to do differently? Thanks for the help.

StoreKit 2 returns zero subscription products in Sandbox/TestFlight — FB24199369 I’m experiencing an issue where StoreKit 2 returns zero subscription products in both Sandbox and TestFlight for my iOS app. App: Bundle ID: com.sleeplessnight.naengbiseo Subscription group: Naengbiseo Premium Product IDs: naengbiseo_premium_monthly naengbiseo_premium_yearly Although the production app uses RevenueCat, I reproduced the same issue in a separate minimal native SwiftUI app using StoreKit 2 directly, with no RevenueCat, Expo, React Native, or other third-party SDK involved. Native StoreKit 2 call: let products = try await Product.products(for: [ "naengbiseo_premium_monthly", "naengbiseo_premium_yearly" ]) Current native test result: STOREKIT_COUNTRY_CODE: KOR STOREKIT_STOREFRONT_ID: 143466 DIRECT_STOREKIT_COUNT: 0 Returned products: None Test environment: Physical iPhone StoreKit Configuration: None Sandbox Apple Account signed in Storefront: KOR In-App Purchase capability enabled Correct Bundle ID and Product IDs I have rechecked the following configuration: The subscriptions are available in the test storefront Subscription pricing is configured Subscription localization is configured Paid Apps Agreement, banking, and tax information are active App ID has In-App Purchase enabled The App Store/TestFlight build has the expected Bundle ID, provisioning, and signing configuration I also created a StoreKit Configuration file using “Sync this file with an app in App Store Connect”. The sync completed, but the resulting configuration contained: products: [] subscriptionGroups: [] The same subscriptions also fail to load in TestFlight. The subscription products currently show Rejected in App Store Connect because the associated app version was rejected. App Store Connect states that the subscriptions were returned because the associated app was rejected and will remain Rejected until resubmitted for review. However, App Review also stated: “In-App Purchase products do not need prior approval to function in review.” I have reviewed TN3186 and have not found a remaining developer-side configuration issue that explains why Product.products(for:) returns zero products. Since the issue reproduces in a minimal native StoreKit 2 app, this does not appear to be caused by RevenueCat or another third-party SDK. Feedback Assistant: FB24199369 Could an App Store Commerce / StoreKit engineer advise whether there is any remaining developer-side configuration that could cause this, or whether the subscription catalog / app association may need to be reprocessed on Apple’s side? Thank you.

Callkit returns error code=106. I can't find what this error code means in official documents. What is this error code? Has anybody seen this error code so far? My app is VoIP app using APNs VoIP push. Below is log example of my app. 2026/04/26 09:01:45.752 [436:103]CallManager incomingCall(::::_:completion:):228: error Error Domain=com.apple.CallKit.error.incomingcall Code=106 "(null)"

Good day, I'm trying to resolve the EU "Digital Services Act" compliance for my employer's Apple Developer account, but I'm stuck on verifying the phone number. The email verification code came through without any issue. We are located in South Africa, with a "+27" area code and the number I need to use here is a landline that comes through to the receptionist at our head office. This number does not have the ability to receive text messages, so I selected the "Didn't get a verification code?" link and chose the receive a phone call instead, however the call never comes through. Calling the number from my cellphone goes straight through to the receptionist, there are no digital switchboard prompts for the caller to select from. I tried this numerous times this Friday just past, and again twice now today, still no luck. I've requested an official document from my manager to see if I can go that route to verify the details, but so far nobody seems to be able to find an appropriate document for me to use... :( Is there anything else that I can do here?

I am seeing a weird crash from Xcode 27 Beta 3 when building a variadic type DynamicProperty that also needs SwiftUI.State. This does not crash from Xcode 26. Here is a repro: import SwiftUI struct Repeater<each Input>: DynamicProperty { @State private var storage = Storage() private var input: (repeat each Input) init(_ input: repeat each Input) { self.input = (repeat each input) } } extension Repeater { final class Storage { } } @main struct CrashDemoApp: App { private var repeater = Repeater(1) var body: some Scene { WindowGroup { EmptyView() } } } Here is the crash: Thread 1 Queue : com.apple.main-thread (serial) #0 0x000000019a93aec0 in swift::TargetMetadata<swift::InProcess>::isCanonicalStaticallySpecializedGenericMetadata () #1 0x000000019a946b38 in performOnMetadataCache<swift::MetadataResponse, swift_checkMetadataState::CheckStateCallbacks> () #2 0x000000019a8c85f0 in swift_checkMetadataState () #3 0x00000001004a2c78 in type metadata completion function for Repeater () #4 0x000000019a94cfe4 in swift::GenericCacheEntry::tryInitialize () #5 0x000000019a94c870 in swift::MetadataCacheEntryBase<swift::GenericCacheEntry, void const*>::doInitialization () #6 0x000000019a94f820 in swift::LockingConcurrentMap<swift::GenericCacheEntry, swift::LockingConcurrentMapStorage<swift::GenericCacheEntry, (unsigned short)14>>::getOrInsert<swift::MetadataCacheKey, swift::MetadataRequest&, swift::TargetTypeContextDescriptor<swift::InProcess> const*&, void const* const*&> () #7 0x000000019a93c714 in _swift_getGenericMetadata () #8 0x00000001004a4190 in __swift_instantiateGenericMetadata () #9 0x00000001004a2a5c in type metadata accessor for Repeater () #10 0x00000001004a5094 in type metadata accessor for Repeater<Pack{Int}> () #11 0x00000001004a4fcc in type metadata completion function for CrashDemoApp () #12 0x000000019a9543bc in swift::MetadataCacheEntryBase<(anonymous namespace)::SingletonMetadataCacheEntry, int>::doInitialization () #13 0x000000019a8d2ae0 in swift_getSingletonMetadata () #14 0x00000001004a479c in type metadata accessor for CrashDemoApp () #15 0x00000001004a473c in static CrashDemoApp.$main() () #16 0x00000001004a4a34 in main () #17 0x0000000186e47e00 in start () Here is a repo to demo: https://github.com/vanvoorden/2026-07-17 Please let me know if you have any ideas about that. Thanks!

I've discovered an issue with using iOS 16's Transferable drag-and-drop APIs for SwiftUI. The dropDestination modifier does not work when applied to a subview of a List. This code below will not work, unless you replace the List with a VStack or any other container (which, of course, removes all list-specific rendering). The draggable modifier will still work and the item will drag, but the dropDestination view won't react to it and neither closure will be called. struct MyView: View { var body: some View { List { Section { Text("drag this title") .font(.largeTitle) .draggable("a title") } Section { Color.pink .frame(width: 400, height: 400) .dropDestination(for: String.self) { receivedTitles, location in true } isTargeted: { print($0) } } } } } Has anyone encountered this bug and perhaps found a workaround?

I am currently on Apple's Dev Beta V4 for iOS 27. The first version I installed was the Dev Beta V2, I am desperate to try out the new Siri AI Beta, but it's just not installing for me. I have the ability to "turn siri off" then "on again" and find I get the 2024 Apple Intelligence version fine. But if I choose to try out the new AI Beta, I'm left with "Adding support for Siri is in progress. Siri will be unavailable until the update is complete." It's been in that state for over 48 hours in Beta 4 and I'm left with the OLD OLD Siri globe from pre-Apple intelligence. Am I being too keen and just not leaving it long enough? Or is there a genuine issue at Apple's end, in regard to getting the new Siri to actually fully install?