Overview

In iOS 26, with the introduction of the new prominent style buttons like system done, how to apply the tint color for these buttons in globally at app level. We are only able to set for individual buttons using barButtonItem.tintColor and need a way to apply globally. We’ve tried: UIBarButtonItem.appearance().tintColor UIBarButtonItem.appearance(whenContainedInInstancesOf: [UINavigationController.self]).tintColor but nothing worked. sample code: let doneButton = UIBarButtonItem(barButtonSystemItem: .done, target: nil, action: nil) doneButton.tintColor = .systemPink Is there a new recommended way to globally style UIBarButtonItem with the prominent style in iOS 26?

I am handling the buy subscription with this function const handleBuySubscription = async (productId) => { try { await requestSubscription({ sku: productId, }); setLoading(false); } catch (error) { setLoading(false); if (error instanceof PurchaseError) { errorLog({ message: [${error.code}]: ${error.message}, error }); } else { errorLog({ message: "handleBuySubscription", error }); } } }; but the requestSubscription({ sku: productId, }) does not return anything, and it is stuck at await

This new modifier is supposedly backported to iOS 17, but on attempting to use it on the latest iOS 18.5, this happens: Symbol not found: _$s7SwiftUI17EnvironmentValuesV33_navigationIndicatorVisibilityABIAA0G0OvpMV This happens with any usage of the modifier. An availability check won't save you either. The cruelest part of this is that I only need the modifier on iOS 26, lmao. Am I just missing something?

While using react-native-iap and being successfully connected with initConnection() I'm not receiving information on subscriptions with requestSubscription(). Attaching the code here, if anyone could assist asap please would be really grateful thanks! Been at it all day and just can't figure. const handleBuySubscription = async (productId) => { try { await requestSubscription({ sku: productId, }); setLoading(false); } catch (error) { setLoading(false); if (error instanceof PurchaseError) { errorLog({ message: [${error.code}]: ${error.message}, error }); } else { errorLog({ message: "handleBuySubscription", error }); } } }; but the requestSubscription({ sku: productId, })

I sent this feedback some time ago and still haven't received an answer. Can someone poke someone internally please? Thank you! FB18815675 I have no idea what exactly is going on but after 5 days I found the culprit and I have a reproducible sample project. In the project is a package that does some basic NFC NDEF encoding. I put a commented out method in there and when you comment that in then the app starts crashing at runtime when scanning an NFC tag. Please check out the project and see yourself. Thanks https://github.com/NickAtGit/iOS26-CoreNFC-Crash

Since publishing new record types to my CloudKit schema in production, a previously unchanged record type has stopped indexing new records. While records of this type are successfully saved without errors, they are not returned in query results—they can only be accessed directly via their recordName. This issue occurs exclusively in the Production environment, both in the CloudKit Console and our iOS app. The problem began on July 21, 2025, and continues to persist. The issue affects only new records of this specific record type; all other types are indexing and querying as expected. The affected record's fields are properly configured with the appropriate index types (e.g., QUERYABLE) and have been not been modified prior to publishing the schema. With this, are there any steps I should take to restore indexing functionality for this record type in Production? There have been new records inserted, and I would prefer to not have to reset the production database, if possible.

Hi all, After upgrading to the iOS 26 beta, the scrolling in my SwiftUI chat view is completely broken. The exact same code works perfectly on iOS 18. Context: I have a chat view using ScrollViewReader and a vertically-reversed ScrollView (with .rotationEffect(.degrees(180))). Each message row (MessageBubble) uses multiple simultaneousGesture handlers: Horizontal drag for swipe-to-reply (and other actions: pin, delete) Long press for showing popover/actions Vertical scroll for normal chat scrolling This was working great on iOS 18. In iOS 26 beta, the vertical scroll is either completely disabled, jittery, or hijacked by the message row’s drag gestures, even though .simultaneousGesture is used (see code below). Minimal Repro Sample MessageListView.swift swift Copy Edit ScrollViewReader { proxy in ScrollView(.vertical, showsIndicators: false) { LazyVStack(spacing: 0) { // ... grouped messages ForEach(...) { ... MessageBubble(...) // see below } Color.clear.frame(height: 8).id("BOTTOM_ANCHOR") } .padding(.horizontal, 4) .rotationEffect(.degrees(180)) } .rotationEffect(.degrees(180)) } MessageBubble.swift struct MessageBubble: View { // ... var body: some View { // horizontal swipe-to-reply gesture let dragGesture = DragGesture(minimumDistance: 10) // ... ZStack { // ... HStack { ... } // ... .simultaneousGesture( DragGesture(minimumDistance: 0) // for long press // ... ) .simultaneousGesture(dragGesture) // for horizontal swipe } // ... } }

My app (com.onon.app) consistently fails App Store Connect validation (ITMS-90207: Invalid Bundle) despite passing all local diagnostics (valid arm64 binary, correctly signed, appropriate entitlements). Is there a known issue with Apple's validation server, or are there obscure validation rules I might be missing?" Diagnosic info Architecture Check (lipo -info Runner): Non-fat file: Runner is architecture: arm64 Code Signing Verification (codesign -vvv Runner): Runner: valid on disk Runner: satisfies its Designated Requirement Local Environment Details: Operating System: macOS 15.5 24F74 (arm64) Xcode Version: 16.3 (16E140) Transporter Version: 1.3.3-13326 Flutter Version: 3.29.0 CocoaPods Version: 1.16.2 Has anyone encountered a similar issue with a Flutter app that passes local code signing checks but is rejected by App Store Connect? Are there any known edge cases or obscure validation rules that aren't covered by standard code signing diagnostics?" I've also opened a Technical Support Incident with Apple Support and am waiting to hear back from them. (Apple developers: my case number is 102647258274)

Based on the documentation, I understand that the UnwantedCommunicationReporting extension works with SMS and MMS messages. However, I'd like official confirmation about support for different message types: SMS: Appears to be supported ✅ MMS: Appears to be supported ✅ RCS (Rich Communication Services): Support unclear ❓ iMessage: Support unclear ❓

When building with the iOS 26 SDK (currently beta 4), the navigation title is often illegible when rendering a Map view. For example, note how the title "Choose Location" is obscured by the map's text ("South America") in the screenshot below: This screenshot is the result of the following view code: import MapKit import SwiftUI struct Demo: View { var body: some View { NavigationStack { Map() .navigationTitle(Text("Choose Location")) .navigationBarTitleDisplayMode(.inline) } } } I tried using the scrollEdgeEffectStyle(_:for:) modifier to apply a scroll edge effect to the top of the screen, in hopes of making the title legible, but that doesn't seem to have any effect. Specifically, the following code seems to produce the exact same result shown in the screenshot above. import MapKit import SwiftUI struct Demo: View { var body: some View { NavigationStack { Map() .scrollEdgeEffectStyle(.hard, for: .top) // ⬅️ no apparent effect .navigationTitle(Text("Choose Location")) .navigationBarTitleDisplayMode(.inline) } } } Is there a recommended way to resolve this issue so that the navigation title is always readable?

Several app developers are struggling with the inability to provide a separate app icons that looks nice on older macOS versions while at the same time provide Icon Composer icons that look great on macOS Tahoe 26. An ability to provide separate icons is super important to those who have app icons that follow the curvature of the default icon borders (as the corner rounding radius is different for Sequia and Tahoe). Take a look at this for example: https://github.com/ghostty-org/ghostty/issues/7564#issuecomment-3042061547 Question: Is there a definitive/recommended way to address this issue? How can a developer add a glass icon variant that looks good on Tahoe and provide a bitmap icon for older macOS versions? Some background info: Prior to Xcode 26 beta 4, one could add an App Icon to Assets to be used as app icon for legacy macOS versions (Sequia and older) and use a new Icon Composer icon (placed in the project root) for macOS Tahoe 26. Enabling "Include all app icon assets" under target settings ensured that older macOS versions would use the old app icons while Tahoe the new Icon Composer glass one. Since Xcode beta 4 this technique no longer works. Xcode instead insists on populating Assets.car with Icon Composer generated variants, disregarding the App Icon provided in Assets. Although the App Icon in Assets makes its way to a .incs file in the app bundle's Contents/Resources folder, but that is not used by macOS anymore and is there for some compatibility purposes. The Assets.car file (which matters) only contains the variants generated by Icon Composer and does not contain the png icons provided in the Assets.

when we use raise in GCD, the signal handler is executed asynchronously, whereas in pthread, it is executed synchronously as expected. example: #include <Foundation/Foundation.h> #include <pthread/pthread.h> static void HandleSignal(int sigNum, siginfo_t* signalInfo, void* userContext) { printf("handle signal %d\n", sigNum); printf("begin sleep\n"); sleep(3); printf("end sleep\n"); } void InstallSignal(void) { static const int g_fatalSignals[] = { SIGABRT, SIGBUS, SIGFPE, SIGILL, SIGPIPE, SIGSEGV, SIGSYS, SIGTRAP, }; int fatalSignalsCount = sizeof(g_fatalSignals) / sizeof(int); struct sigaction action = {{0}}; action.sa_flags = SA_SIGINFO | SA_ONSTACK; #if defined(__LP64__) action.sa_flags |= SA_64REGSET; #endif sigemptyset(&action.sa_mask); action.sa_sigaction = &HandleSignal; struct sigaction pre_sa; for(int i = 0; i < fatalSignalsCount; i++) { int sigResult = sigaction(g_fatalSignals[i], &action, &pre_sa); } } void* RaiseAbort(void *userdata) { raise(SIGABRT); printf("signal handler has finished\n"); return NULL; } int main(int argc, const char * argv[]) { InstallSignal(); dispatch_async(dispatch_get_global_queue(0, 0), ^{ raise(SIGABRT); // abort(); // abort() is ok RaiseAbort(nullptr); }); // pthread is ok // pthread_t tid; // int ret = pthread_create(&tid, NULL, RaiseAbort, NULL); // if (ret != 0) { // fprintf(stderr, "create thread failed\n"); // return EXIT_FAILURE; // } [[NSRunLoop mainRunLoop] run]; return 0; } console log: signal handler has finished handle signal 6 begin sleep end sleep

I’m still using Xcode 15 to build my mac apps. My icons use the rounded rect style but Tahoe still wraps them in its own rounded rect (even when I use the official Sketch template (1)). I made an .icon with Icon Composer and added it to my project. When building in Xcode 26, that works fine: It uses the .icon in Tahoe and the .icns in older systems. But: I need to compile my app with Xcode 15 (need supports for older MacOS). Xcode 15 doesn’t know about the .icon files and so it ignores them. So I have two questions: How does Tahoe check if it can use the .icns files as is or when it needs to add the rounded rect? Is there a way to make the .icon files work in Xcode 15? (1) It works when the icon has an opaque background. But when adding a slight alpha, it doesn’t. Same file, same setting otherwise.

With the correct corner radius changing in iOS 26, I wondered if there is a way to get properly rounded corners inside containers like sheets without hard-coding a constant value. Here's the results of some experiments I did, example code below. The new in Beta 4 ConcentricRectangle seems nice. Notable here is that it doesn't pick up the larger corner radii from the device corners: If you want all the corners rounded, the isUniform parameter of ConcentricRectangle seems helpful. It doesn't apply the corners in a View in the middle though, not sure if this is an oversight or if this has some purpose: ContainerRelativeShape looks ... interesting ... as of Beta 4, with the larger bottom corners rounded according to the device corners, but the actual bottom corners not fitting the device corners. With ContainerRelativeShape one can also get the middle part to have proper rounded corners in this example ... if you set the outer .containerShape(RoundedRectangle(cornerRadius: 36)) yourself. Notable here is that it then actually adapts all corners of the last card to the larger device corner radius - why it does that even with the smaller radius being explicitly set as containerShape is beyond my imagination. ContainerRelativeShape and ConcentricRectangle both feel quite similar to me, but different in ways that are not clear to me after reading the documentation. I wouldn't know when to pick which / I am not sure if these two should really be two separate things... Any insights here? I was also hoping to find a way to read the cornerRadius (both device corner radius and sheet container radius) for more complex custom-shaped views, but currently there seems no way to do that. The new in iOS 26 Beta 4 GeometryReader containerCornerInsets sounded a bit like it, but it seems of no use here, it's always zero. docs talk about windowing controls and values can be seen on iPad when the red/yellow/green window buttons become visible, so it seems unrelated here. Example code AdaptiveCorners.swift import SwiftUI enum Experiment: String, CaseIterable, Identifiable { case form case concentricRect case uniformConcentricRect case containerRelative case containerRelativeWithContainerShape case containerCornerInsets var title: String { self.rawValue } var id: String { self.rawValue } } struct ContentView: View { @State var experiment : Experiment? = .concentricRect var body: some View { NavigationStack { Form { Picker("Experiment", selection: $experiment) { ForEach(Experiment.allCases, id: \.self) { experiment in Text(experiment.title).tag(experiment) } } .pickerStyle(.inline) } } .sheet(item: $experiment) { experiment in Group { switch(experiment) { case .form: Form { Section { Text("Form + Section") Text("Form + Section") } } case .concentricRect: ShapeView { ConcentricRectangle() } case .uniformConcentricRect: ShapeView { ConcentricRectangle(corners: .concentric, isUniform: true) } case .containerRelative: ShapeView { ContainerRelativeShape() } case .containerRelativeWithContainerShape: ShapeView { ContainerRelativeShape() } .containerShape(RoundedRectangle(cornerRadius: 36)) case .containerCornerInsets: GeometryReader { geometry in Form { Text(String(describing: geometry.containerCornerInsets)) } } } } .presentationDetents([.medium, .large]) } } } struct ShapeView<S : Shape> : View { @ViewBuilder let content: () -> S var body: some View { ScrollView([.vertical]) { VStack { HStack { content() .fill(Color.yellow) .frame(height: 80) .frame(maxWidth: .infinity) content() .fill(Color.orange) .frame(height: 80) .frame(maxWidth: .infinity) } content() .fill(Color.green) .frame(height: 80) .frame(maxWidth: .infinity) } .padding() } } } #Preview { ContentView() }

Problem: We trained a LoRA adapter for Apple's FoundationModels framework using their TAMM (Training Adapter for Model Modification) toolkit v0.2.0 on macOS 26 beta 4. The adapter trains successfully but fails to load with: "Adapter is not compatible with the current system base model." TAMM 2.0 contains export/constants.py with: BASE_SIGNATURE = "9799725ff8e851184037110b422d891ad3b92ec1" Findings: Adapter Export Process: In export_fmadapter.py def write_metadata(...): self_dict[MetadataKeys.BASE_SIGNATURE] = BASE_SIGNATURE # Hardcoded value The Compatibility Check: - When loading an adapter, Apple's system compares the adapter's baseModelSignature with the current system model - If they don't match: compatibleAdapterNotFound error - The error doesn't reveal the expected signature Questions: - How is BASE_SIGNATURE derived from the base model? - Is it SHA-1 of base-model.pt or some other computation? - Can we compute the correct signature for beta 4? - Or do we need Apple to release TAMM v0.3.0 with updated signature?

I use spm manage swift package, now i want my macos app support arm64e,so i add arm64e in Build Srtting -> Architectures. but i got error Could not find module 'SwiftyJSON' for target 'arm64e-apple-macos'; found: arm64-apple-macos, x86_64-apple-macos Apparently, if no limit in Package.swift, SPM will only compile versions for x86 and ARM64 architectures by default. now, how should I configure SPM to compile the arm64e version? thanks

Call blocking using a third-party CallKit app is not longer working with the latest iOS 26 Public Beta (23A5297m). We've tried several different Call Blocking apps (that used to work fine on iOS 18.5) and their call blocking functionality is not working anymore. All calls pass through and the phone rings on those "blocked" numbers. We got several user complaints about our app that is not working on iOS 26 Public Beta. We've filed 2 bug reports with Feedback Assistant: FB19140680 FB19140594 Please fix this issue in the next Beta versions of iOS 26 to have a stable iOS 26 release in the future. Thank you in advance.

Hi, I'm using one ttf font that simulate a bitmap look in my app. However, macOS renders all font with anti-aliasing. On those kind of font, that introduce some artefacts. Is there a way to disable anti-aliasing or some tricks that would make like there were no anti-aliasing? Thanks.

On an iPad running iPadOS 26 beta 4, when tapping the Game Center Access Point, the overlay doesn’t show the configured achievements, leaderboards or challenges. I should specify this is an in-development app and the achievements and leaderboards are in the “Not Live” state, however they show on other devices running iOS 18 in the Access Point UI. Anyone else having this issue? If so, how should I test achievements and leaderboards while iOS 26 beta is out? The UI looks like this on iPadOS 26:

Hello, We’ve resumed the migration process after a break. Since my colleague is no longer with us, I had to go through the steps again myself. As before, we’re trying to migrate "Sign In with Apple" users from tenant TENANT_A with client_id=CLIENT_ID_A to tenant TENANT_B with client_id=CLIENT_ID_B I followed the procedure described here: [Apple Developer Documentation](https://developer.apple.com/documentation/technotes/tn3159-migrating-sign-in-with-apple-users-for-an-app-transfer – Migrating Sign In with Apple Users, essentially repeating what my coworker previously attempted in coordination with your employee Stephanie. Here’s a summary of the steps and the issue we’re facing: STEP 1 - get authcode for TEAM A curl --location 'https://appleid.apple.com/auth/token' --header 'Content-Type: application/x-www-form-urlencoded' --data-urlencode 'grant_type=client_credentials' --data-urlencode 'scope=user.migration' --data-urlencode 'client_id=pl.CLIEND_ID_A' --data-urlencode 'client_secret=<TEAM_A_SECRET>' I receive response: { "access_token": "<ACCESS_TOKEN_TEAM_A>", "token_type": "Bearer", "expires_in": 3600 } STEP 2 - get authcode for TEAB B curl --location 'https://appleid.apple.com/auth/token' --header 'Content-Type: application/x-www-form-urlencoded' --data-urlencode 'grant_type=client_credentials' --data-urlencode 'scope=user.migration' --data-urlencode 'client_id=CLIENT_ID_B' --data-urlencode 'client_secret=<TEAB_B_SECRET>' I receive response: { "access_token":"<ACCESS_TOKEN_TEAB_B>", "token_type": "Bearer", "expires_in": 3600 } STEP 3 - get transfer_sub from TEAM A curl --location 'https://appleid.apple.com/auth/usermigrationinfo' --header 'Authorization: Bearer <ACCESS_TOKEN_TEAM_A>' --header 'Content-Type: application/x-www-form-urlencoded' --data-urlencode 'client_id=CLIENT_ID_A' --data-urlencode 'client_secret=<TEAM_A_SECRET>' --data-urlencode 'sub=USER_SUB_FROM_TEAM_A' --data-urlencode 'target=TENANT_B' I receive response: { "transfer_sub": "USER_SUB_FROM_TEAM_B" } STEP 4 - Team B exchanges transfer identifers curl --location 'https://appleid.apple.com/auth/usermigrationinfo' --header 'Authorization: Bearer <ACCESS_TOKEN_TEAM_B' --header 'Content-Type: application/x-www-form-urlencoded' --data-urlencode 'client_id=CLIENT_ID_B' --data-urlencode 'client_secret=<TEAM_B_SECRET>' I receive response: { "error": "invalid_request" } We’ve created a new client_id under tenant B and want to migrate users there. However, we skipped the step described in Step 3 of the documentation(https://developer.apple.com/documentation/technotes/tn3159-migrating-sign-in-with-apple-users-for-an-app-transfer#3-Team-A-initiates-app-transfer-to-Team-B), which involves initiating an app transfer. The reason is that this client_id is used solely for web authentication, not for a mobile app, so we don’t have an app to transfer. Based on our analysis and your documentation, it seems this flow only works if the client_id matches across both tenants, which can only be achieved through an app transfer, something we cannot proceed with. Apple previously insisted that we migrate these users, but as shown above, we’re stuck. Is there any alternative flow available, or can you assist us in completing this migration?