Overview

Post

Replies

Boosts

Views

Activity

Guidance on implementing Declared Age Range API in response to Texas SB2420
I've spent the last few days researching the upcoming laws in Texas and other US states, and how these laws will impact on developers around the world. I want to share what I've learned so far with the community and get feedback on my current understanding. This post is not so much focused on a single API, but more of the bigger picture. Background The law essentially mandates that: (1) app store platforms implement age categorization and verification mechanisms, and (2) developers implement logic to listen to age categorization signals provided by the platform and respond accordingly. You can read the law itself here: https://capitol.texas.gov/tlodocs/89R/billtext/html/SB02420S.HTM Most people seem to be interpreting the law as follows: All developers who distribute apps in the USA are effectively required to implement the new APIs (required by Texas, not by Apple). The penalties are heavy, but it's unclear whether developers would actually be pursued and by whom (e.g. would someone seriously pursue an alarm clock app because it could be accessed by a minor?). Putting aside the ethical, privacy, and legal issues (and the damaging precedents this law sets), most people seem to agree that, from a technical perspective, this is a very silly way to implement age blocking (app store collects the info and passes it to dev, dev is responsible for blocking access). It would make way more sense for the platform to block the app directly for affected users (with optional API support for developers who wish to use it). However, I believe the law has specifically mandated that this is how they expect the system to work, so Apple's hands have been tied. Apple has basically complied with their obligations by providing the relevant APIs to developers. Because the law is vague and open-ended, there are a lot of legal and technical uncertainties about what developers actually need to do to be compliant. Understandably, Apple seems reticent to provide any guidance to developers that could be interpreted as legal advice. Apple's docs simply describe what the APIs do with no guidance on what the overall flow is meant to look like or how and when the APIs should actually be used in practice. Americans familiar with the political situation seem to think there's the possibility of an injunction before this law goes into effect, but that looks increasingly unlikely given that it's two weeks away. Developer solutions Many devs seem to be exploring two main workarounds, at least as temporary solutions: (1) Raise your app's rating to 18+. Putting aside the fact that Texas law would effectively be forcing developers to raise their global age rating (resulting in lost revenue that extends far beyond Texas), it remains unclear whether this solution is actually legally compliant, since the law specifically mandates that apps must implement logic to respond to signals from the platform. (2) Geo-block Texas. Again, it remains unclear if this is compliant because geo-blocking is not 100% accurate and it doesn't actually do what the law says you have to do. It also creates issues if you already have users in Texas, and it means performing additional privacy-hostile checks (i.e., detecting the user's location, even users who are not subject to the law). The DeclaredAgeRange API is actually pretty straight-forward to use – although there is still a lack of documentation on certain edge cases and it's difficult to test. In addition, the new APIs are only available in iOS 26.2, so it's unclear what you need to do if you're still supporting < iOS 26.2. Some people are of the opinion that developers can only reasonably respond to the signals that are available, thus pushing responsibility back to the platforms in regards to earlier OS versions. The API provides a bool (AgeRangeService.shared.isEligibleForAgeFeatures), which allows you to determine if the user is someone to whom age checks need to be applied. https://developer.apple.com/documentation/declaredagerange/agerangeservice/iseligibleforagefeatures I'm not 100% sure, but perhaps the simplest action you can take is to check this bool on launch and block access if it's true. In any case, it looks like this API will be very useful because it means we can avoid applying the checks in other jurisdictions and for grandfathered-in users without needing to implement custom geo-tracking code (albeit only in iOS 26.2+). To implement the API, my current thinking is that, on every launch, I should first check the above bool and, if it's true, do the following: (1) get the App Store age rating with let appStoreAgeRating = await AppStore.ageRatingCode ?? 18, (2) request the user's age with let ageRangeResponse = try await AgeRangeService.shared.requestAgeRange(ageGates: appStoreAgeRating), (3) check that the user has agreed to share their age, (4) check that lowerBound >= appStoreAgeRating, and (5) check that the verification method is not one of the self-declared methods. If this procedure fails, I should block access to the app and provide a link to Apple's support page: https://support.apple.com/en-us/122770 I stress, however, that this is just my current idea and there are some edge cases I'm unsure about. Other issues It is possible to do some basic testing of the API, but only using a sandbox App Store account on a physical device. From the Developer section in iOS Settings, you can select from a few different scenarios, like "Texas user aged 14 without parental consent", etc. There's also a whole separate aspect to this law relating to "significant updates". Everyone seems kinda confused about this, but it seems like the general idea is that, if your app's age classification changes in the future, the app should be responsive to that change. My current interpretation is that if I use the AppStore.ageRatingCode as the age gate (as described above) then that should allow me to comply, but I haven't really looked into this aspect of the law yet. There's also another aspect to this law requiring developers to revoke access to the app when requested by the parent. I have not looked into this yet, but as noted above, it doesn't make sense to me why this is the developer's responsibility given that the platforms already provide solid parental controls. Do I need to something else in addition to what I've sketched out above? It goes without saying, of course, that everything above is not legal advice, and I still have some gaps in my understanding. I would really appreciate any feedback on the above, perhaps with recommendations about better ways to approach this.
8
1
636
1d
CarPlay not working on iOS 26 beta
Just wanted to check here to see if anyone else is running into the issue of CarPlay not working at all on iOS 26 Beta 1, even with the update on Friday. I plug my phone in (wired) and CarPlay never shows up. I've seen a Reddit thread where other folks are seeing the same thing.
4
1
349
2w
OTP AutoFill Fails to Distribute Code Across Multiple UITextFields on iOS 26.x
Issue Summary: On iOS 26.0.1 to 26.3, apps using multiple UITextFields for OTP input face a critical issue where the system autofill pastes the entire OTP string into a single text field, usually the focused one, rather than splitting digits across fields. Delegate events like textDidChange: do not trigger consistently on autofill, breaking existing input handling logic. Expected Behavior: OTP autofill should distribute each digit correctly across all OTP UITextFields. Delegate or control events should fire on autofill to enable manual handling. (BOOL)textField:(UITextField *)textField shouldChangeCharactersInRange:(NSRange)range replacementString:(NSString *)string { if (string.length > 1) { // Autofill detected - distribute OTP manually for (int i = 0; i < string.length && i < self.arrayOTPText.count; i++) { UITextField *field = self.arrayOTPText[i]; field.text = [NSString stringWithFormat:@"%c", [string characterAtIndex:i]]; } UITextField *lastField = self.arrayOTPText[string.length - 1]; [lastField becomeFirstResponder]; return NO; } // Handle normal single character or deletion input here return YES; } // // Setup UITextFields - set .oneTimeCode on first field only for (int i = 0; i < self.arrayOTPText.count; i++) { UITextField *field = self.arrayOTPText[i]; field.delegate = self; if (@available(iOS 12.0, *)) { field.textContentType = (i == 0) ? UITextContentTypeOneTimeCode : UITextContentTypeNone; } } What We’ve Tried: Setting textContentType properly. Handling OTP distribution in delegate method. Verifying settings and keyboard use. Testing on multiple iOS 26.x versions. Impact: Major usability degradation during OTP entry. Forces fragile workarounds. Inconsistent autofill reduces user confidence. Request: Request Apple fix OTP autofill to natively support multi-field UITextField OTP input or provide enhanced delegate callbacks for consistent behavior. Did any one face this issue in recent time with iOS 26.0.1 to 26.3 beta version
1
3
107
1d
Swipe to go back still broken with Zoom navigation transition.
When you use .navigationTransition(.zoom(sourceID: "placeholder", in: placehoder)) for navigation animation, going back using the swipe gesture is still very buggy on IOS26. I know it has been mentioned in other places like here: https://developer.apple.com/forums/thread/796805?answerId=856846022#856846022 but nothing seems to have been done to fix this issue. Here is a video showing the bug comparing when the back button is used vs swipe to go back: https://imgur.com/a/JgEusRH I wish there was a way to at least disable the swipe back gesture until this bug is fixed.
2
0
182
1w
Reoccurring World Tracking / Scene Exceeded Limit Error
Hi, We’ve been successfully using the RoomPlan API in our application for over two years. Recently, however, users have reported encountering persistent capture errors during their sessions. Specifically, the errors observed are: CaptureError.worldTrackingFailure CaptureError.exceedSceneSizeLimit What we have observed: Persistent Errors: The errors continue to occur even after initiating new capture sessions. Normal Usage: Our implementation adheres to typical usage patterns of the RoomPlan API without exceeding any documented room size limits. Limited Feature Usage: We are not utilizing the WorldTracking feature for the StructureBuilder functionality to stitch rooms together. Potential State Caching: Given that these errors persist across sessions, we suspect that there might be memory or state cached between sessions that is not being cleared, particularly since we are not taking advantage of StructureBuilder. Request: Could you please advise if there is any internal caching or memory retention between capture sessions that might lead to these errors? Additionally, we would appreciate guidance on how to clear or manage this state when the StructureBuilder feature is not in use. Here is a generalised version of our capture session initialization code to help diagnose the issue. struct RoomARCaptureView: UIViewRepresentable { typealias Handler = (CapturedRoom, Error?) -> Void @Binding var stop: Bool @Binding var done: Bool let completion: Handler? func makeUIView(context: Self.Context) -> RoomCaptureView { let view = RoomCaptureView(frame: .zero) view.delegate = context.coordinator view.captureSession.run(configuration: .init()) return view } func updateUIView(_ uiView: RoomCaptureView, context: Self.Context) { if stop { // Stop the session only once, multiple times causes issues with the final presentation uiView.captureSession.stop() stop = false done = true } } static func dismantleUIView(_ uiView: RoomCaptureView, coordinator: Self.Coordinator) { uiView.captureSession.stop() } func makeCoordinator() -> ARViewCoordinator { ARViewCoordinator(completion) } @objc(ARViewCoordinator) class ARViewCoordinator: NSObject, RoomCaptureViewDelegate { var completion: Handler? public required init?(coder: NSCoder) {} public func encode(with coder: NSCoder) {} public init(_ completion: Handler?) { super.init() self.completion = completion } public func captureView(shouldPresent roomDataForProcessing: CapturedRoomData, error: (Error)?) -> Bool { return true } public func captureView(didPresent processedResult: CapturedRoom, error: (Error)?) { completion?(processedResult, error) } } } Thank you for your assistance.
6
3
691
1w
Apple's PCC + Foundation Models
Hi, I am developing an iOS application that utilizes Apple’s Foundation Models to perform certain summarization tasks. I would like to understand whether user data is transferred to Private Cloud Compute (PCC) in cases where the computation cannot be performed entirely on-device. This information is critical for our internal security and compliance reviews. I would appreciate your clarification on this matter. Thank you.
1
0
303
2w
Age declaration not working when using Sandbox account with TestFlight builds
Hello I'm using this sdk DeclaredAgeRange to get the user age range When I'm doing in debug mode using sandbox account it is working as expected and I can get the user age range But when I tried in TestFlight build using sandbox account it is not working and it is always return the age range 18+ and also isEligibleForAgeFeatures API is always returning false Any advise on this?
3
3
857
3d
KDK for current stable version (26.1) missing
The current stable macOS version, 26.1 (build 25B78) is missing a corresponding Kernel Debug Kit (KDK) on the developer downloads page. This means I can't do any kernel-level development tasks currently. For example, if I try to build a new kernel collection with kmutil I get the message Missing Developer Kit: As of macOS 13.0, you will need to install a KDK matching your build 25B78 to rebuild kernel collections. but there is no build 25B78 KDK available to download. The latest 26.1 KDK on the download page is 25B5062e (from a beta I believe) and the final stable KDK for build 25B78 (which kernel development tools require) was never published. Is there any workaround for this to correctly do kernel-level development targeting the latest stable release, or a timeline for when the KDK will release? Thanks!
0
3
91
3w
Nonprofit Enrollment 28 Days in "Processing" After Continuing - UH4UT85YS3
I'm looking for advice or anyone who's experienced similar delays with nonprofit developer account enrollments. Timeline: In mid-September, we had some initial email validation issues during our nonprofit organization enrollment. Senior Advisor Kevin (case 102691832489) resolved those issues and cleared us to continue enrollment on September 16-17. We continued immediately on September 17th, and our status changed to "Your enrollment is being processed" with enrollment ID UH4UT85YS3. It's now been 28 days with no status changes, no requests for additional information, and no timeline. Follow-up attempts: I've called support three times (Sept 19, 26, and Oct 7). Each time I was told the application is "with a separate department they can't contact." They created additional cases but couldn't provide any updates or access to the reviewing team. Questions for the community: Is 28 days normal for nonprofit enrollment processing after continuing? Has anyone found a way to get status updates when regular support can't access the reviewing team? Is there a specific escalation path for nonprofit accounts that differs from standard enrollments? We're a 501(c)(3) church launching an app for a capital campaign, so the delay is starting to impact our timeline. Any insights or experiences would be greatly appreciated. Details: Enrollment ID: UH4UT85YS3 Organization Type: Nonprofit 501(c)(3) Continued enrollment: Sept 17, 2025 Current status: "Your enrollment is being processed" Thanks in advance for any guidance.
5
3
189
1d
Persistent Tokens for Keychain Unlock in Platform SSO
While working with Platform SSO on macOS, I’m trying to better understand how the system handles cases where a user’s local account password becomes unsynchronized with their Identity Provider (IdP) password—for example, when the device is offline during a password change. My assumption is that macOS may store some form of persistent token during the Platform SSO user registration process (such as a certificate or similar credential), and that this token could allow the system to unlock the user’s login keychain even if the local password no longer matches the IdP password. I’m hoping to get clarification on the following: Does macOS actually use a persistent token to unlock the login keychain when the local account password is out of sync with the IdP password? If so, how is that mechanism designed to work? If such a capability exists, is it something developers can leverage to enable a true passwordless authentication experience at the login window and lock screen (i.e., avoiding the need for a local password fallback)? I’m trying to confirm what macOS officially supports so I can understand whether passwordless login is achievable using the persistent-token approach. Thanks in advance for any clarification.
1
3
180
2w
App store error: "This build is using a beta version of Xcode and can’t be submitted."
Strangely today, I suddenly found I was unable to submit a new build of my iOS app to the app store. It builds perfectly well in Xcode Cloud, launches from TestFlight without issue, but when attempting to submit the app for App Review, I get this error: "This build is using a beta version of Xcode and can’t be submitted." Of course, the version of Xcode I'm using is not Beta - and I tried this on both public releases of Xcode 16.1 and Xcode 16.2. Has anyone else seen this, and if so, did you figure out a workaround?
1
0
389
4d
iOS 18.1 crash UIHostingView.layoutSubviews() / swift_unknownObjectWeakAssign / objc_storeWeak
We're seeing sporadic crashes on devices running iOS 18.1 - both beta and release builds (22B83). The stack trace is always identical, a snippet of it below. As you can tell from the trace, it's happening in places we embed SwiftUI into UIKit via UIHostingController. Anyone else seeing this? 4 libobjc.A.dylib 0xbe2c _objc_fatalv(unsigned long long, unsigned long long, char const*, char*) + 30 5 libobjc.A.dylib 0xb040 weak_register_no_lock + 396 6 libobjc.A.dylib 0xac50 objc_storeWeak + 472 7 libswiftCore.dylib 0x43ac34 swift_unknownObjectWeakAssign + 24 8 SwiftUI 0xeb74c8 _UIHostingView.base.getter + 160 9 SwiftUI 0x92124 _UIHostingView.layoutSubviews() + 112 10 SwiftUI 0x47860 @objc _UIHostingView.layoutSubviews() + 36
9
1
1.3k
2w
Crash (KERN_INVALID_ADDRESS) on IOS 26.2 GM when calling isEligibleForAgeFeatures
We recently released an update to our app to prepare for TX SB2420. Almost immediately on release, we started getting crash reports of crashes when calling isEligibleForAgeFeatures. Crashed: com.apple.root.user-initiated-qos.cooperative EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000000000004 Is it possible that these are beta users that have IOS 26.2 RC or is there a bug in the release version of IOS 26.2? Note: The crash reports are coming from Crashlytics so we are not getting OS build identifiers other than version "26.2"
2
2
111
5d
DeclaredAgeRange framework new cases and properties cause runtime crash with missing symbol
I'm making a wrapper library to abstract away some of the 'missing platform support' of DeclaredAgeRange until hopefully it expands to additional platforms. When I'm trying to fully enumerate all of the cases of AgeRangeDeclaration, which they all state available starting 26.0 (mysteriously added in Xcode 26.2 beta), the app crashes due to a missing symbol at launch time. This happens both for Xcode 26.1, 26.2 beta 2, and matching Xcode Cloud builds. So I've isolated it beyond "doesn't work on my machine". I just made a handful of crashes and attached a sysdiagnose to a fresh feedback. FB21121092 - DeclaredAgeRange: Eligibility property and new declaration cases unavailable on iOS 26.1 device contradicting documentation - causes runtime symbol not found crash If anyone is curious what these crashes look like I've attached the DiagnosticPayload.jsonRepresentation() generated from one of my favorite frameworks, MetricKit. Very clearly articulated in the diagnostic metadata you can see the symbol not found. "diagnosticMetaData" : { "platformArchitecture" : "arm64e", "terminationReason" : "Symbol not found: _$s16DeclaredAgeRange0bC7ServiceV0bC11DeclarationO14paymentCheckedyA2EmFWC\nReferenced from: <1894EDCB-3263-3604-8938-97D465FF3720> \/Volumes\/VOLUME\/*\/PerformanceOrganizer.app\/PerformanceOrganizer\nExpected in: <B8FD2C23-0CC9-3D94-902D-875900307A7A> \/System\/Library\/Frameworks\/DeclaredAgeRange.framework\/DeclaredAgeRange", "exceptionType" : 10, "appBuildVersion" : "745", "isTestFlightApp" : true, "osVersion" : "iPhone OS 26.1 (23B85)", "bundleIdentifier" : "dev.twincitiesapp.performanceorganizer", "deviceType" : "iPhone18,1", "exceptionCode" : 0, "signal" : 6, "regionFormat" : "US", "appVersion" : "2.0.0", "pid" : 22987, "lowPowerModeEnabled" : false } DiagnosticPayload.json This is the offending code in a type I control and make available on other platforms but leave unused. extension AgeRangeDeclaration { // A factory or initializer that takes the AgeRangeService.AgeRangeDeclaration and maps to the common AgeRangeDeclaration type public init?(platform value: AgeRangeService.AgeRangeDeclaration?) { guard let value else { return nil } switch value { // Xcode 26.1 visible cases case .selfDeclared: self = .selfDeclared case .guardianDeclared: self = .guardianDeclared // Xcode 26.2 visible cases // This is the first culprit, all of the following symbols would crash, this is just the first case .checkedByOtherMethod: self = .checkedByOtherMethod case .guardianCheckedByOtherMethod: self = .guardianCheckedByOtherMethod case .governmentIDChecked: self = .governmentIDChecked case .guardianGovernmentIDChecked: self = .guardianGovernmentIDChecked case .paymentChecked: self = .paymentChecked case .guardianPaymentChecked: self = .guardianPaymentChecked @unknown default: // Apple added new cases in Xcode 26.2 betas that were available in iOS 26.0, // so it is probable that this could happen again. If it does, assert to let developers // bring it to my attention. assertionFailure("Invalid or out of date knowledge of age range declaration \(value)") self = .unknown } } } For what it is worth, the same is also true for isEligibleForAgeFeatures which I suspect was also added to Xcode 26.2 somehow but not made available to real devices running [26.0 - 26.2). As a side note, thank you for this property, it will let me check what states I need to perform extra checks for in a clean way, I just will need it to now not crash my app on 26.0 and 26.1 runtime devices. :) Edit: DTS did confirm on a comment I had in another thread that this is a bug. Now just to wait for an Xcode beta update. https://developer.apple.com/forums/thread/807906?answerId=867205022#867205022 In any case, this is a great example of how MetricKit totally rocks capturing things other off the shelf crash tools might not have a chance to get. I did have to roll back my TestFlight to an earlier build, but MetricKit was there to send me the previous crashes as soon as the app could launch. Thanks MetricKit team!
5
1
809
4d
App Clip Advanced Experiences don't get published
We have an app with a few App Clip Advanced Experiences. Since around 28th of August the status of the experiences seems to be stuck in either CREATE_SUBMITTED or UPDATE_SUBMITTED and they don't get updated to PUBLISHED anymore. I found this in the experiences JSON loaded by AppStoreConnect when editing the experiences: "statuses": { "doc_count_error_upper_bound": 0, "sum_other_doc_count": 0, "buckets": [ { "key": "PUBLISHED", "doc_count": 182 }, { "key": "CREATE_SUBMITTED", "doc_count": 7 }, { "key": "UPDATE_SUBMITTED", "doc_count": 3 } ] }, This shows that 10 experiences are stuck in other status than PUBLISHED. I created a Feedback with ID FB15041208 and a DTS last week. This is REALLY important for us to be fixed immediately since we have customers that rely on this!
21
6
2.2k
5d
Final reminder: Answer the updated age ratings questions
I have already submitted the updated age rating options and even published a new version of the app after doing so. However, I still received an email with the subject “Final reminder: Answer the updated age ratings questions,” stating that the age rating options have not been submitted. I checked the App Information section, and all the required age rating options are correctly selected. Has anyone else received a similar email? Is there any additional action that needs to be taken?
3
2
261
5d
Xcode 26 CompileMetalFile failed
"EnableLiveAssetServerV2-com.apple.MobileAsset.MetalToolchain" = on; ProductName: macOS ProductVersion: 26.0.1 BuildVersion: 25A362 The MetalToolchain is installed, however I keep getting error that MetalToolchain cannot be found by the Xcode "Command CompileMetalFile failed with a nonzero exit code" error: error: cannot execute tool 'metal' due to missing Metal Toolchain; use: xcodebuild -downloadComponent MetalToolchain ❯ xcodebuild -downloadComponent MetalToolchain 2025-10-31 11:18:29.004 xcodebuild[6605:45524] IDEDownloadableMetalToolchainCoordinator: Failed to remount the Metal Toolchain: The file “com.apple.MobileAsset.MetalToolchain-v17.1.324.0.k9JmEp” couldn’t be opened because you don’t have permission to view it. Beginning asset download... 2025-10-31 11:18:29.212 xcodebuild[6605:45523] IDEDownloadableMetalToolchainCoordinator: Failed to remount the Metal Toolchain: The file “com.apple.MobileAsset.MetalToolchain-v17.1.324.0.k9JmEp” couldn’t be opened because you don’t have permission to view it. Downloaded asset to: /System/Library/AssetsV2/com_apple_MobileAsset_MetalToolchain/4ab058bc1c53034b8c0a9baca6fba2d2b78bb965.asset/AssetData/Restore/022-17211-415.dmg Done downloading: Metal Toolchain 17A324.
5
2
495
5d