Hi everyone,
I'm trying to add the Side Button Access entitlement to my voice-based conversational app following the documentation, but I'm unable to find it in Xcode.
Steps I followed:
Selected my app target in Xcode project navigator
Went to the Signing & Capabilities tab
Clicked the + Capability button
Searched for "Side Button Access"
Problem:
The "Side Button Access" option does not appear in the capabilities list at all.
Environment:
I'm developing and testing in Japan (where this feature should be available)
Xcode version: Xcode 26.2 beta 3
iOS deployment target: iOS 26.2
Questions:
Is there any pre-registration or special approval process required from Apple before this entitlement becomes available?
Are there any additional requirements or prerequisites I need to meet?
Is this feature already available, or is it still in a limited beta phase?
Any guidance would be greatly appreciated. Thank you!
Posts under Beta tag
200 Posts
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
I’m currently developing an application using WKWebView.
After updating to iOS 26.2 Developer Beta, the following Web API started returning false:
isUserVerifyingPlatformAuthenticatorAvailable
MDN: https://developer.mozilla.org/ja/docs/Web/API/PublicKeyCredential/isUserVerifyingPlatformAuthenticatorAvailable_static
This issue did not occur on iOS 26.1 — it only happens on the beta version.
Has anyone else encountered this problem or is aware of any related changes?
OS: iOS 26.2 beta 3 (23C5044b)
We’ve encountered what appears to be a CoreML regression between macOS 26.0.1 and macOS 26.1 Beta.
In macOS 26.0.1, CoreML models run and produce correct results. However, in macOS 26.1 Beta, the same models produce scrambled or corrupted outputs, suggesting that tensor memory is being read or written incorrectly. The behavior is consistent with a low-level stride or pointer arithmetic issue — for example, using 16-bit strides on 32-bit data or other mismatches in tensor layout handling.
Reproduction
Install ON1 Photo RAW 2026 or ON1 Resize 2026 on macOS 26.0.1.
Use the newest Highest Quality resize model, which is Stable Diffusion–based and runs through CoreML.
Observe correct, high-quality results.
Upgrade to macOS 26.1 Beta and run the same operation again.
The output becomes visually scrambled or corrupted.
We are also seeing similar issues with another Stable Diffusion UNet model that previously worked correctly on macOS 26.0.1. This suggests the regression may affect multiple diffusion-style architectures, likely due to a change in CoreML’s tensor stride, layout computation, or memory alignment between these versions.
Notes
The affected models are exported using standard CoreML conversion pipelines.
No custom operators or third-party CoreML runtime layers are used.
The issue reproduces consistently across multiple machines.
It would be helpful to know if there were changes to CoreML’s tensor layout, precision handling, or MLCompute backend between macOS 26.0.1 and 26.1 Beta, or if this is a known regression in the current beta.
I have been experimenting with the BGContinuedProcessingTask API recently (and published sample code for it https://github.com/infinitepower18/BGContinuedProcessingTaskDemo)
I have noticed that if I lock the phone, the code that runs as part of the task stops executing. My sample code simply updates the progress each second until it gets to 100, so it should be completed in 1 minute 40 seconds. However, after locking the phone and checking the lock screen a few seconds later the progress indicator was in the same position as before I locked it.
If I leave the phone locked for several minutes and check the lock screen the live activity says "Task failed".
I haven't seen anything in the documentation regarding execution of tasks while the phone is locked. So I'm a bit confused if I encountered an iOS bug here?
I've recently installed 26.1 Beta 3 alongside stable 26.0.1
When building my app with 26.0.1 the final .ipa size is ~17mb, however after building my app with 26.1 Beta 3 the size has increased up to ~22mb
The main difference is Assets.car blowing from 1.1mb to 5.6mb (or 8.6mb if I include all icons settings). Upon examining I've found new liquid glass .icon file duplicating itself multiple times as png variants (any, dark, tinted, etc).
Is anyone else experiencing this issue?
Is there a way to check or be notified for new Xcode beta versions?
The only way I know is to manually keep checking the available betas web page to see if anything new is available (while also manually comparing it to the installed version).
Or am I missing something?
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!
Topic:
App Store Distribution & Marketing
SubTopic:
General
Tags:
MetricKit
Beta
Xcode
Declared Age Range
Like any good developer, I try to add tests where I can. The AgeRangeService.AgeRange type does not provide an initializer. I know the routine, create an interface or a simple struct that I control and use that instead. Thanks to extensive time with frameworks like Core Bluetooth or Core Location, this is a well understood practice (looking at you CBPeripheral...).
Great I'll make my own 'AgeRange' struct. Make it Hashable, make it Sendable, use the framework types as properties. Scratch that, most of the properties on AgeRangeService.AgeRange type are not Sendable and many are also not Hashable. This is proving to be challenging.
I hope to open source my little Swift Package wrapper library for DeclaredAgeRange which will add types with full Hashable and Sendable conformance. I hope Apple updates the API and makes this obsolete. I don't see why these simple types can't be Hashable and Sendable. They're structs, enums, and OptionSets (structs).
FB20959748 - DeclaredAgeRange: DeclaredAgeRangeAction is not sendable causing main actor compile errors with default isolation settings
FB20960560 - DeclaredAgeRange: AgeRangeService.AgeRangeDeclaration is not sendable as expected
FB20960574 - DeclaredAgeRange: AgeRangeService.ParentalControls is not sendable as expected
FB20960590 - DeclaredAgeRange: AgeRangeService.ParentalControls is not hashable as expected
On the note of the library and using the types as-is, there are some issues using the new cases in AgeRangeDeclaration and the isEligibelForAgeFeatures property. I started another thread over here: https://developer.apple.com/forums/thread/808144
Topic:
App Store Distribution & Marketing
SubTopic:
General
Tags:
Swift
Beta
Testing
Declared Age Range
I've been writing about the DeclaredAgeRange a bit on LinkedIn and now it is time to take to the developer forums. In my efforts to prepare my apps for new local requirements, I've run across some rough edges.
The DeclaredAgeRange API is missing on several platforms, and extension types.
First and foremost, watchOS. An Apple Watch is a clear single user platform and for standalone apps, the DeclaredAgeRange being absent is felt by developers.
FB20954931 - DeclaredAgeRange: Framework not available on watchOS making compliance a challenge for watchOS standalone apps
In the same vein of thinking, while users on Apple Vision Pro are far fewer numbers than Apple Watch, it is also a miss. The tricky part would be testing on the simulator. So far I haven't gotten the simulator and sandbox testing to work and give real values across any platform. I don't think an Apple Store will let me try my app out via TestFlight on their devices and they're still too expensive to reasonably buy for most developers. Too bad Feedbacks are not a currency that developers can trade in for gear.
FB20955020 - DeclaredAgeRange: Framework not available on visionOS making compliance a challenge for visionOS apps
I'll recognize that the user model is different on tvOS, and that as a user while I have family group setup, I don't have any children on the account. I have to imagine that child accounts on an Apple TV exist and would be able to account for the sharing of age ranges to apps. Yes, the user could just switch profiles, but, app developers could still integrate the age range into their apps. Maybe it needs more robust system level support but here is the feedback just the same.
FB20955029 - DeclaredAgeRange: Framework not available on tvOS making compliance a challenge on tvOS apps
And finally, let's not forget about App Clips. While the App Clips might not be 'downloaded' from App Store itself, it is powered by App Store technologies to an extent. I'd rather not bifurcate my code more than it already is for the shared code between my apps and app clips. Rounding out platform support to App Clips, since it is iOS, would close the loop.
FB20954846 - DeclaredAgeRange / App Clips: Add support for DeclaredAgeRange framework for App Clip targets - capability exist, Xcode cannot generate entitlement for it
Oh wait, actually, not quite. To fully close the loop, make the DeclaredAgeRange work fully on macCatalyst. The documentation says it is compatible, but from my experiments trying to get it to even compile when targeting macCatalyst apps simply doesn't build.
FB21117325 - DeclaredAgeRange: API documentation states available on mac catalyst - but fails to compile in Xcode 26.2
Topic:
App Store Distribution & Marketing
SubTopic:
General
Tags:
App Store
Beta
Privacy
Declared Age Range
The application crashes immediately when the system attempts to display the automatic password input view controller (_SFAutomaticPasswordInputViewController). This occurs during the login or password-filling process.
OS Version: iOS 26.2 Beta 1
Build Number: (23C5027f)
Fatal Exception: NSInvalidArgumentException
*** -[__NSArrayM insertObject:atIndex:]: object cannot be nil
Release notes of Xcode 26.2 https://developer.apple.com/documentation/xcode-release-notes/xcode-26_2-release-notes state that Swift 6.2.3 is shipped with it.
But when trying to check the Swift version with
#if swift(>= 6.2.3)
it returns false.
Running swiftc -version returns
swift-driver version: 1.127.14.1 Apple Swift version 6.2 (swiftlang-6.2.3.3.2 clang-1700.6.3.2)
As you can see, there is a mismatch between the marketing version "6.2" and the build version "6.2.3.3.2".
Being able to check for the 6.2.3 version is important for my team, because we are impatiently awaiting the change to the tabviewbottomaccessory modifier
https://developer.apple.com/documentation/swiftui/view/tabviewbottomaccessory%28isenabled:content:%29
so that it can be hidden when not needed. Without this fix we have the issue that the accessory shows even without content in iOS 26.1.
I'm seeing a lot of unexpected CPU usage when running the iOS 26.1 simulator. Looks like a "MercuryPosterExtension" is crashing over and over, which then causes the "ReportCrash" process to run, presumably to create the crash report.
Doesn't happen on device, nor on iOS 26.0 simulator. I suspect MercuryPoster is related to wallpaper. I also don't see any wallpaper background in my simulator.
Few lines from the stack trace:
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libxpc.dylib 0x18011defc _xpc_api_misuse + 88
1 libxpc.dylib 0x18012e16c _xpc_shmem_create_with_prot.cold.1 + 24
2 libxpc.dylib 0x180113a70 _xpc_shmem_create_with_prot + 276
3 MTLSimDriver 0x23795ed48 -[MTLSimDevice newBufferWithLength:options:pointer:copyBytes:deallocator:] + 260
4 MercuryPosterExtension 0x10081d21c 0x100758000 + 807452
13 PosterKit 0x240d003d8 -[PRRenderer scene:willConnectToSession:options:] + 648
14 UIKitCore 0x1856bcf18 +[UIScene _sceneForFBSScene:create:withSession:connectionOptions:] + 956
All of these issues appear when the search controller is set on the view controller's navigationItem and the search controller's searchBar has its scopeButtonTitles set.
So far the following issues are affecting my app on iOS/iPadOS 26 as of beta 7:
When the scopeBarActivation of UISearchController is set to .onSearchActivation, the preferredSearchBarPlacement of the navigationItem is set to .integratedButton, and the searchBarPlacementAllowsToolbarIntegration is set to false (forcing the search icon to appear in the nav bar), on both iPhones and iPads, the scope buttons never appear. They don't appear when the search is activated. They don't appear when any text is entered into the search bar. FB19771313
I attempted to work around that issue by setting the scopeBarActivation to .manual. I then show the scope bar in the didPresentSearchController delegate method and hide the scope bar in the willDismissSearchController. On an iPhone this works though the display is a bit clunky. On an iPad, the scope bar does appear via the code in didPresentSearchController, but when any scope bar button is tapped, the search controller is dismissed. This happens when the app is horizontally regular. When the app on the iPad is horizontally compact, the buttons work but the search bar's text is not correctly aligned within the search bar. Quite the mess really. I still need to post a bug report for this issue. But if issue 1 above is fixed then I don't need this workaround.
When the scopeBarActivation of UISearchController is set to .onSearchActivation, the preferredSearchBarPlacement of the navigationItem is set to .stacked, and the hidesSearchBarWhenScrolling property of the navigationItem is set to false (always show the search bar), and this is all used in a UITableViewController, then upon initial display of the view controller on an iPhone or iPad, you are unable to tap on the first row of the table view except on the very bottom of the row. The currently hidden scope bar is stealing the touches. If you activate and then cancel the search (making the scope bar appear and then disappear) then you are able to tap on the first row as expected. The initially hidden scope bar also bleeds through the first row of the table. It's faint but you can tell it's not quite right. Again, this is resolved by activating and then canceling the search once. FB17888632
When the scopeBarActivation of UISearchController is set to .onSearchActivation, the preferredSearchBarPlacement of the navigationItem is set to integrated or .integratedButton, and the toolbar is shown, then on iPhones (where the search bar/icon appears in the toolbar) the scope buttons appear (at the top of the screen) the first time the search is activated. But if you cancel the search and then activate it again, the search bar never appears a second (or later) time. On an iPad the search bar/icon appears in the nav bar and you end up with the same issue as #1 above. FB17890125
Issues 3 and 4 were reported against beta 1 and still haven't been fixed. But if issue 1 is resolved on iPhone, iPad, and Mac (via Mac Catalyst), then I personally won't be affected by issues 2, 3, or 4 any more (but of course all 4 issues need to be fixed). And by resolved, I mean that the scope bar appears and disappears when it is supposed to each and every time the search is activated and cancelled (not just the first time). The scope bar doesn't interfere with touch events upon initial display of the view controller. And there are no visual glitches no matter what the horizontal size class is on an iPad.
I really hope the UIKit team can get these resolved before iOS/iPadOS 26 GM.
This is really odd. If you setup a UISearchController with a preferredSearchBarPlacement of .stacked and you setup the search bar with scope buttons, then when the view controller is initially displayed, the currently hidden scope buttons block touch events from reaching the main view just below the search bar. But once the search is activated and dismissed, then the freshly hidden scope buttons no longer cause an issue.
This is easily demonstrated by putting a UITableViewController in a UINavigationController. Setup the table view to show a few simple rows. Then setup a search controller using the following code:
func setupSearch() {
// Setup a stacked search bar with scope buttons
// Before the search is ever activated, the hidden scope buttons block any touches in the main view controller
// in the area just below the search bar.
// Once the search is activated and dismissed, the problem goes away. It seems that displaying and hiding the
// scope buttons at least once fixes the issue that exists beforehand.
// This issue only exists in iOS/iPadOS 26, not iOS/iPadOS 18 or earlier.
let search = UISearchController(searchResultsController: UIViewController())
search.hidesNavigationBarDuringPresentation = true
search.obscuresBackgroundDuringPresentation = true
search.scopeBarActivation = .onSearchActivation // Ensure button appear immediately
let searchBar = search.searchBar
searchBar.scopeButtonTitles = [ "One", "Two", "Three" ]
self.navigationItem.searchController = search
self.navigationItem.hidesSearchBarWhenScrolling = false // Issue appears even if this is true
self.navigationItem.preferredSearchBarPlacement = .stacked
}
When first shown, before any attempt is made to activate the search, any attempt to tap on the upper 2/3 of the first row in the table view (which is just below the search bar) fails. If you tap on the lower 1/3 of the first row it works fine. If you then activate the search (now the scope buttons appear) and then dismiss the search (now the scope buttons are hidden again), then there is no issue tapping anywhere on the first row of the table. But if you restart the app, the problem starts over again.
This problem happens on any iPhone or iPad, real or simulated, running iOS/iPadOS 26 RC. This is a regression from iOS 18 or earlier.
Hello,
I'm currently setting up an external TestFlight testing phase for my iOS app and need some clarification on the release process after App Review approval.
For App Store releases, I know I can manually release the app at my preferred time. However, when submitting an external TestFlight build for review, there is an option to "Notify testers". If this is selected, the build seems to be automatically made available to testers immediately upon approval.
My concern is:
If I uncheck the "Notify testers" option, will the build still become available on TestFlight, allowing testers who proactively check the app to download the update, even though they don't receive a notification?
Is there a way to completely control the exact release time (similar to the manual App Store release) for external testers?
We need to manage the release timing to align with backend production deployment. We want to ensure the app update is released only after our backend is fully ready.
Any insights into how to best manage this timing would be greatly appreciated! Thank you.
I am using SwiftData for my model. Until Xcode 15 beta 4 I did not have issues. Since beta 5 I am receiving the following red warning multiple times:
'NSKeyedUnarchiveFromData' should not be used to for un-archiving and will be removed in a future release
This seems to be a CoreData warning. However, I am not using CoreData directly. I have no way to change the config of CoreData as used by SwiftData.
My model just uses UUID, Int, String, Double, some of them as optionals or Arrays. I only use one attribute (.unique).
I didn't run benchmarks before update, but it seems at least 5x slower. Of course all the LLM work is on remote servers, so is non-intuitive to me this should be happening.
Had updated MacOS and Xcode to 26.1RC at the same time, so can't even say I think it is MacOS or I think it is Xcode.
Before the update the progress indicator for each piece of code might seem to get stuck at the very end (and toggling between Navigators and Coding Assistant) in Xcode UI seemed to refresh the UI and confirm coding complete... but now it seems progress races to 50%, then often is stuck at 75%... well earlier than used to get stuck. And it like something is legitimately processing not just a UI glitch.
I'm wondering if this is somehow tied to visual rendering of the code in the little white window? CMD-TAB into Xcode seems laggy. Xcode is pinning a CPU. Why, this is all remote LLM work?
MacBook Pro 2021 M1 64GB RAM. Went from 26.01 to 26.1RC. Didn't touch any of the betas until RC1.
I've encountered a major issue with the iOS 18.1 RC and watchOS 11.1 RC. It appears that complications running on WidgetKit cannot be synced as .watchface to these new release candidates. The error message indicates that "the Watch Faces app and complication are not available," which is affecting all apps utilizing WidgetKit.
This issue renders all WidgetKit-based complications unusable on watchOS 11.1 RC. It’s a serious problem for those of us who rely on these complications for our apps and for users expecting consistent functionality.
APPLE, PLEASE FIX THIS ISSUE ASAP!
This bug is a significant setback for developers and users alike, and any guidance or updates would be greatly appreciated.
iphone 15 pro max
ios 26
Stuck at the developer mode startup interface and unable to swipe up.
I downloaded the Xcode Beta 3 on my MacBook Pro M4 Base today and tested out some iOS26 mechanics of my app. And when I came back to my main Xcode to continue developing in iOS18, I couldn't build my app. I went to Product > Destination > Manage run destinations and then tried to create a simulator with iOS18 but it didn't show up, only choice that's showing up was iOS26. I tried deleting iOS18 platform and downloading it again but it didn't solve, I tried deleting Xcode Beta but it didn't solve the problem either. I deleted Runtimes folder, it didn't solve too. I can not create a simulator of iOS18 or below too, the error says "The iOS 18.5 simulator runtime is not available. Try reinstalling Xcode or the simulator runtime." How can I fix this problem?