I'm adapting a UIKit app to work with Liquid Glass. In pre-Liquid Glass days, the application window had a tintColor that was passed down to all of its descendant views, resulting in toolbar buttons that match the app's color scheme. In iOS 26, my toolbar buttons are always black, no matter what. I've tried setting the UIBarButtonItem#tintColor on the button and setting UIBarButtonAppearanc#tintColor. The buttons are still black. What am I doing wrong? I see a tintColor modifier for SwiftUI toolbar buttons, so it seems like maybe you can do this with SwiftUI. Many of the built-in apps on iOS 26 beta have only black toolbar buttons - is it not possible to change the toolbar button tint color on iOS 26?

Just posted this feedback regarding macOS 26 "Tahoe" (FB19853155) - please support with additional submissions if you share my view. I will miss the beautiful and individual designed icons of the past! "macOS 26 is enforcing squicles for app icons, falling back to a grey background for 3rd party apps without a compliant AppIcon asset. As a result many original app icons are reduced in size and hard to distinguish because they share the same background color. Although I respect Apple's strive for an iOS-like UI on Macs, a smooth transition path would be more user- and developer-friendly ... e.g. with some info.plist property to opt-out icon migration, potentially ignored by a future macOS version. The current solution causes a bad usability, and makes the system look inconsistent as many - especially free - software will not be updated with new icon designs. Please reconsider this bad design decision!"

Hi, Is it possible to use the iOS26 Liquid Glass icon on iOS 26 (built with Icon Composer), and use the old icon on iOS18 devices? I imported the icon file into my Xcode project and it seems to use the new icon on iOS18 (and earlier) devices as well. Thanks.

On the new macOS Tahoe Beta, we are noticing the prompts coming from macOS like the credential prompts, SFAuthorization prompts are displaying the icons as left aligned. Is this change an intentional change on macOS Tahoe? or is this going to be adjusted in upcoming versions?

Hello everyone, Following the WWDC 2025 announcement of tvOS 26 and the introduction of the new Liquid Glass effect, Apple published a press release mentioning that Liquid Glass is "available on Apple TV 4K (2nd generation and later)". This seems to exclude both the Apple TV HD and the 1st generation Apple TV 4K, even though both devices remain compatible with tvOS 26. Source: Apple Newsroom ( https://www.apple.com/newsroom/2025/06/apple-tv-brings-a-beautiful-redesign-and-enhanced-home-entertainment-experience ) I’m wondering: Will using UIGlassEffect or glassEffect(_:in:) on these older devices cause a crash? If not, will the effect fall back to a simple blur, or render as fully transparent? Is there an API or recommended way to detect whether the Liquid Glass effect is supported on the current device? Thanks in advance for your insights!

The NSTextViewportLayoutControllerDelegate.textViewportLayoutControllerDidLayout(_:) documentation states that Layout information on textViewportLayoutController is up-to-date at the point of this call. however it is easy to put the NSTextViewportLayoutController in a state where after calling textViewportLayoutControllerDidLayout, the value of viewportRange is nil (unexpected) and value of the property viewportBounds is .zero The TextKit2 sample application found at https://developer.apple.com/documentation/uikit/using-textkit-2-to-interact-with-text makes that assumption as well, and in few places force unwrap the value of viewportRange, that leads to runtime crashes. This behavior is also discussed in Developer Forum thread about TextKit2 viewport relocation: https://developer.apple.com/forums/thread/761364?answerId=800516022#800516022 How to reproduce: Run Mac target of LayoutWithTextKit2 sample project found at https://developer.apple.com/documentation/uikit/using-textkit-2-to-interact-with-text locate menu.rtf file and duplicate its content several times - the goal is to increase the length of the layout text quickly resize application window - that results in viewport layouts - that result in out-of-bound viewport - that results ina crash OR quickly scroll down/up to the end of the document using scroller bar on the right side of the window Reproducible 100% The situation occurs when the document is not fully laid out, the estimated size (height) of the content exceeds the final (correct) height, and the layoutViewport() function is executed quickly. Resulting in partial viewport layout, and once the viewport moves outside of the document's total height, the viewportLayoutController starts to report viewportRange = nil. FB19698121 Why does it happen? Is it expected? How to recover from that state? And most importantly, how to make the NSTextLayoutManager display the portion of the document that is currently scrolled to. and how to do it without for ce layout the full document on each viewportLayout()

I have a voice chat app that frequently writes to the universal clipboard. This works fine most of the time, but I've noticed that if I don't touch the screen for a long time, the universal clipboard information I read on my Mac won't update until I touch the app screen again. How can I fix this?

I am developing an app that requires user to turn on overlay permissions (with a prompt provided to the user) as well as accesibility settings. The goal is to display a floating button on screen, which reads screen content only when user taps on that button. It is not a persistant overlay because user can make floating button disappear by turning it off inside the app. I want to know if apple app store policies will be ok with this kind of feature and if there is anything particular I need to comply with to enable my app in the app store?

Trying to get my iPad app to display a different view on connected external display. Info.plist is setup as follows: <dict> <key>UIApplicationSceneManifest</key> <dict> <key>UIApplicationSupportsMultipleScenes</key> <true/> <key>UISceneConfigurations</key> <dict> <key>UIWindowSceneSessionRoleExternalDisplayNonInteractive</key> <array> <dict> <key>UISceneConfigurationName</key> <string>External Display</string> <key>UISceneDelegateClassName</key> <string>$(PRODUCT_MODULE_NAME).SceneDelegate</string> </dict> </array> </dict> </dict> </dict> I have my SceneDelegate setup as the follows: import SwiftUI class SceneDelegate: UIResponder, UIWindowSceneDelegate { var window: UIWindow? func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) { guard let windowScene = scene as? UIWindowScene else { return } if session.role == .windowExternalDisplayNonInteractive { let window = UIWindow(windowScene: windowScene) window.rootViewController = UIHostingController(rootView: ExternalDisplayView()) self.window = window window.makeKeyAndVisible() } } }

My PreviewCode app provides QuickLook previews and Finder icon thumbnails for source code files written in many popular programming languages. The only one it doesn't work will with is TypeScript, which typically uses the ts file extension. This is because Apple's CoreTypes bundle maps the ts file extension to its own MPEG-4 Transport Stream UTI. Right now I have two UTIs mapped to the ts extension: the above one and another, com.microsoft.typescript. The question is, how can I tell macOS' Launch Services to favour the latter over the former so that PreviewCode's previewer app extension is called whenever then user QuickLooks a TypeScript file and not (as currently happens) macOS' MPEG-4 previewer? I'd like to code this into PreviewCode or at the very least provide the technique in the response to the many tech support requests I get about this ts mix-up specifically.

It appears that starting with macOS Sequoia, Quick Look Preview extension no longer loads MapKit maps correctly anymore. Map tiles do not appear, leaving users with a beige background. Users report that polylines do render correctly, but annotations appears black. This was previously working fine in prior macOS versions including Sonoma. STEPS TO REPRODUCE Create a macOS app project, with an associated document. Ensure project has a Quick Look preview extension, with necessary basic setups. Ensure that the extension mentioned in (2) must have a MKMapView. Any other cosmetic changes, etc, does not need to be implemented to observe the base issue. Do note that it has been reported that in addition to the map tiles not loading, annotations don't render correctly as well.

How can we performantly scroll to a target location using TextKit 2? Hi everyone, I'm building a custom text editor using TextKit 2 and would like to scroll to a target location efficiently. For instance, I would like to move to the end of a document seamlessly, similar to how users can do in standard text editors by using CMD + Down. Background: NSTextView and TextEdit on macOS can navigate to the end of large documents in milliseconds. However, after reading the documentation and experimenting with various ideas using TextKit 2's APIs, it's not clear how third-party developers are supposed to achieve this. My Code: Here's the code I use to move the selection to the end of the document and scroll the viewport to reveal the selection. override func moveToEndOfDocument(_ sender: Any?) { textLayoutManager.ensureLayout(for: textLayoutManager.documentRange) let targetLocation = textLayoutManager.documentRange.endLocation let beforeTargetLocation = textLayoutManager.location(targetLocation, offsetBy: -1)! textLayoutManager.textViewportLayoutController.layoutViewport() guard let textLayoutFragment = textLayoutManager.textLayoutFragment(for: beforeTargetLocation) else { return } guard let textLineFragment = textLayoutFragment.textLineFragment(for: targetLocation, isUpstreamAffinity: true) else { return } let lineFrame = textLayoutFragment.layoutFragmentFrame let lineFragmentFrame = textLineFragment.typographicBounds.offsetBy(dx: 0, dy: lineFrame.minY) scrollToVisible(lineFragmentFrame) } While this code works as intended, it is very inefficient because ensureLayout(_:) is incredibly expensive and can take seconds for large documents. Issues Encountered: In my attempts, I have come across the following two issues. Estimated Frames: The frames of NSTextLayoutFragment and NSTextLineFragment are approximate and not precise enough for scrolling unless the text layout fragment has been fully laid out. Laying out all text is expensive: The frames become accurate once NSTextLayoutManager's ensureLayout(for:) method has been called with a range covering the entire document. However, ensureLayout(for:) is resource-intensive and can take seconds for large documents. NSTextView, on the other hand, accomplishes the same scrolling to the end of a document in milliseconds. I've tried using NSTextViewportLayoutController's relocateViewport(to:) without success. It's unclear to me whether this function is intended for a use case like mine. If it is, I would appreciate some guidance on its proper usage. Configuration: I'm testing on macOS Sonoma 14.5 (23F79), Swift (AppKit), Xcode 15.4 (15F31d). I'm working on a multi-platform project written in AppKit and UIKit, so I'm looking for either a single solution that works in both AppKit and UIKit or two solutions, one for each UI framework. Question: How can third-party developers scroll to a target location, specifically the end of a document, performantly using TextKit 2? Steps to Reproduce: The issue can be reproduced using the example project (download from link below) by following these steps: Open the example project. Run the example app on a Mac. The example app shows an uneditable text view in a scroll view. The text view displays a long text. Press the "Move to End of Document" toolbar item. Notice that the text view has scrolled to the bottom, but this took several seconds (~3 seconds on my MacBook Pro 16-inch, 2021). The duration will be shown in Xcode's log. You can open the ExampleTextView.swift file and find the implementation of moveToEndOfDocument(_:). Comment out line 84 where the ensureLayout(_:) is called, rerun the app, and then select "Move to End of Document" again. This time, you will notice that the text view moves fast but does not end up at the bottom of the document. You may also open the large-file.json in the project, the same file that the example app displays, in TextEdit, and press CMD+Down to move to the end of the document. Notice that TextEdit does this in mere milliseconds. Example Project: The example project is located on GitHub: https://github.com/simonbs/apple-developer-forums/tree/main/how-can-we-performantly-scroll-to-a-target-location-using-textkit-2 Any advice or guidance on how to achieve this with TextKit 2 would be greatly appreciated. Thanks in advance! Best regards, Simon

Intro I am reporting multiple persistent UI animation issues observed in tvOS 26 (Beta 6). These issues have been reproducible across multiple tvOS releases. They are subtle but noticeable, and they affect the overall polish and perceived quality of the system. I am happy to provide high-quality video captures for each of the issues described below. ⸻ Bug #1: App launch animation stutter/jump Summary: The zoom-in animation from a Springboard icon to full-screen app stutters or jumps at the moment the app becomes full screen. Steps to reproduce: 1. On Springboard, select any app icon. 2. Observe the zoom-in animation. Expected result: Smooth, continuous zoom without frame drops or jumps. Actual result: Animation visibly stutters/jumps at the full-screen transition. Possible cause: Timing issue in Core Animation interpolation or abrupt view hierarchy switch. ⸻ Bug #2: Text rendering weight change (“jump”) during transitions Summary: Text inside apps changes visual weight mid-transition from scaled preview to full screen. Steps to reproduce: 1. From Springboard or App Switcher, launch an app with visible text. 2. Observe text during the zoom animation — initially slightly bolder, then thinner once full screen. Also occurs in: • Top Shelf banners in the Dock • App Switcher → full-screen transitions Expected result: Consistent text rendering throughout the transition. Actual result: Visible “pop” in text weight/anti-aliasing during transition. Possible cause: Different rasterization/anti-aliasing mode between preview snapshot (CALayer.contents) and live CoreText/UIKit rendering. ⸻ Bug #3: Focus shadow jumps instead of interpolating smoothly Summary: Shadows around focused UI elements (icons, buttons) change abruptly during focus transitions. Steps to reproduce: 1. Navigate between focusable UI elements on Springboard or in apps. 2. Observe the shadow effects. Expected result: Shadows interpolate smoothly (offset, opacity, radius) during focus transitions. Actual result: Shadows “jump” abruptly, breaking animation smoothness. Possible cause: UIFocusEngine not interpolating shadow parameters consistently. ⸻ Bug #4: Abrupt jumps when swiping horizontally between content items Summary: In horizontally scrollable poster/content rows, focus snaps abruptly instead of scrolling smoothly. Steps to reproduce: 1. In the TV app or any app with horizontal poster rows, swipe left/right. 2. Observe the transition between focused items. Expected result: Smooth horizontal navigation with continuous motion. Actual result: Occasional abrupt snapping/jumping between items. ⸻ Impact While none of these bugs block core functionality, they degrade the premium feel and visual polish of tvOS. They are persistent across releases and occur in core system UI, so they are visible to all users. Note I can provide video recordings for each bug to assist engineering in reproducing and analyzing the issues.

Hey, After installing iOS 26 public beta, when using carplay on an aftermarket head unit resolution looks too small. I know it has to with smart zoom setting and disabling it fixes. The problem is that it comes enabled by default with the beta but i can’t disable it. Not because of the small screen but the iPhone can’t handle the high resolution rendering when going on settings and crashes. Does anyone know how to fix this issue? It would be nice if carplay options could be modified from the iPhone directly. Thank you

By setting the PKCanvasView background color to blue, I can tell that the PKCanvasView for each PDFPage is created normally, but it does not respond to touch. Specifically, whether it is finger or applepencil, all the responses of the page occur from PDFView(such as zoom and scroll), and PKCanvasView can not draw, please how to solve? class PDFAnnotatableViewController: UIViewController, PDFViewDelegate { private let pdfView = PDFView() private var pdfDocument: PDFDocument? let file: FileItem private var userSettings: UserSettings @Binding var selectedPage: Int @Binding var currentMode: Mode @Binding var latestPdfChatResponse: LatestPDFChatResponse @State private var pdfPageCoordinator = PDFPageCoordinator() @ObservedObject var userMessage: ChatMessage init(file: FileItem, userSettings: UserSettings, drawDataList: Binding<[DrawDataItem]>, selectedPage: Binding<Int>, currentMode: Binding<Mode>, latestPdfChatResponse: Binding<LatestPDFChatResponse>, userMessage: ChatMessage) { self.file = file self.userSettings = userSettings self._selectedPage = selectedPage self._currentMode = currentMode self._latestPdfChatResponse = latestPdfChatResponse self.userMessage = userMessage super.init(nibName: nil, bundle: nil) DispatchQueue.global(qos: .userInitiated).async { if let document = PDFDocument(url: file.pdfLocalUrl) { DispatchQueue.main.async { self.pdfDocument = document self.pdfView.document = document self.goToPage(selectedPage: selectedPage.wrappedValue - 1) } } } } required init?(coder: NSCoder) { fatalError("init(coder:) has not been implemented") } override func viewDidLoad() { super.viewDidLoad() setupPDFView() } private func setupPDFView() { pdfView.delegate = self pdfView.autoScales = true pdfView.displayMode = .singlePage pdfView.displayDirection = .vertical pdfView.backgroundColor = .white pdfView.usePageViewController(true) pdfView.displaysPageBreaks = false pdfView.displaysAsBook = false pdfView.minScaleFactor = 0.8 pdfView.maxScaleFactor = 3.5 pdfView.pageOverlayViewProvider = pdfPageCoordinator if let document = pdfDocument { pdfView.document = document goToPage(selectedPage: selectedPage) } pdfView.frame = view.bounds pdfView.autoresizingMask = [.flexibleWidth, .flexibleHeight] view.addSubview(pdfView) NotificationCenter.default.addObserver( self, selector: #selector(handlePageChange), name: .PDFViewPageChanged, object: pdfView ) } // Dealing with page turning @objc private func handlePageChange(notification: Notification) { guard let currentPage = pdfView.currentPage, let document = pdfView.document else { return } let currentPageIndex = document.index(for: currentPage) if currentPageIndex != selectedPage - 1 { DispatchQueue.main.async { self.selectedPage = currentPageIndex + 1 } } } func goToPage(selectedPage: Int) { guard let document = pdfView.document else { return } if let page = document.page(at: selectedPage) { pdfView.go(to: page) } } // Switch function func togglecurrentMode(currentMode: Mode){ DispatchQueue.main.async { if self.currentMode == .none{ self.pdfView.usePageViewController(true) self.pdfView.isUserInteractionEnabled = true } else if self.currentMode == .annotation { if let page = self.pdfView.currentPage { if let canvasView = self.pdfPageCoordinator.getCanvasView(forPage: page) { canvasView.isUserInteractionEnabled = true canvasView.tool = PKInkingTool(.pen, color: .red, width: 20) canvasView.drawingPolicy = .anyInput canvasView.setNeedsDisplay() } } } } } } class MyPDFPage: PDFPage { var drawing: PKDrawing? func setDrawing(_ drawing: PKDrawing) { self.drawing = drawing } func getDrawing() -> PKDrawing? { return self.drawing } } class PDFPageCoordinator: NSObject, PDFPageOverlayViewProvider { var pageToViewMapping = [PDFPage: PKCanvasView]() func pdfView(_ view: PDFView, overlayViewFor page: PDFPage) -> UIView? { var resultView: PKCanvasView? = nil if let overlayView = pageToViewMapping[page] { resultView = overlayView } else { let canvasView = PKCanvasView(frame: view.bounds) canvasView.drawingPolicy = .anyInput canvasView.tool = PKInkingTool(.pen, color: .systemYellow, width: 20) canvasView.backgroundColor = .blue pageToViewMapping[page] = canvasView resultView = canvasView } if let page = page as? MyPDFPage, let drawing = page.drawing { resultView?.drawing = drawing } return resultView } func pdfView(_ pdfView: PDFView, willEndDisplayingOverlayView overlayView: UIView, for page: PDFPage) { guard let overlayView = overlayView as? PKCanvasView, let page = page as? MyPDFPage else { return } page.drawing = overlayView.drawing pageToViewMapping.removeValue(forKey: page) } func savePDFDocument(_ pdfDocument: PDFDocument) -> Data { for i in 0..<pdfDocument.pageCount { if let page = pdfDocument.page(at: i) as? MyPDFPage, let drawing = page.drawing { let newAnnotation = PDFAnnotation(bounds: drawing.bounds, forType: .stamp, withProperties: nil) let codedData = try! NSKeyedArchiver.archivedData(withRootObject: drawing, requiringSecureCoding: true) newAnnotation.setValue(codedData, forAnnotationKey: PDFAnnotationKey(rawValue: "drawingData")) page.addAnnotation(newAnnotation) } } let options = [PDFDocumentWriteOption.burnInAnnotationsOption: true] if let resultData = pdfDocument.dataRepresentation(options: options) { return resultData } return Data() } func getCanvasView(forPage page: PDFPage) -> PKCanvasView? { return pageToViewMapping[page] } } Is there an error in my code? Please tell me how to make PKCanvasView painting normally?

Hello Apple Developer Team, I kindly ask if you could allow developers to access the same Arabic keyboard used in iOS — with the exact layout, design, and smooth performance as the default iPhone keyboard. Currently, building a custom Arabic keyboard that replicates Apple’s layout results in severe lag and a frustrating user experience. Despite many attempts, it’s nearly impossible to match the original keyboard’s speed, size, and feel — especially for Arabic. I fully understand your security concerns. To ensure safety, Apple could prevent typing in password fields and clearly mark the keyboard as customized (e.g., a red Send button). That would be completely acceptable. I am not planning to publish anything on the App Store. This is purely for personal use only — to play and experiment with friends on platforms like Discord, by adding simple tools like repeating each word twice or splitting typed words into separate letters. Honestly, I am mentally exhausted from trying to rebuild something that already exists. Every attempt leads to slow performance and disappointment. I just want the real keyboard — the same one we already use — and the ability to build basic features on top of it. Thank you very much for your time and understanding. Best regards, Abdullah Abdulrahman Aljurayyad

We're seeing a sharp uptick in BaseBoard/FrontBoardServices crashes since we migrated from UIApplicationDelegate to UIWindowSceneDelegate. Having exhausted everything on my end short of reverse engineering BaseBoard or making changes without being able to know if they work, I need help. I think all I need to get unstuck is an answer to these questions, if possible: What does -[BSSettings initWithSettings:] enumerate over? If I know what's being enumerated, I'll know what to look for in our app. What triggers FrontBoardServices to do this update? If I can reproduce the crash--or at least better understand when it may happen--I will be better able to fix it Here's two similar stack traces: App_(iOS)-crashreport-07-30-2025_1040-0600-redacted.crash App_(iOS)-crashreport-07-30-2025_1045-0600-redacted.crash Since these are private trameworks, there is no documentation or information on their behavior that I can find. There are other forum posts regarding this crash, on here and on other sites. However, I did not find any that shed any insight on the cause or conditions of the crash. Additionally, this is on iPhone, not macOS, and not iPad. This post is different, because I'm asking specific questions that can be answered by someone with familiarity on how these internal frameworks work. I'm not asking for help debugging my application, though I'd gladly take any suggestions/tips! Here's the long version, in case anyone finds it useful: In our application, we have seen a sharp rise in crashes in BaseBoard and FrontBoardServices, which are internal iOS frameworks, since we migrated our app to use UIWindowSceneDelegate. We were using exclusively UIApplicationDelegate before. The stack traces haven't proven very useful yet, because we haven't been able to reproduce the crashes ourselves. Upon searching online, we have learned that Baseboard/Frontsoardservices are probably copying scene settings upon something in the scene changing. Based on our crash reports, we know that most of our users are on an iPhone, not an iPad or macOS, so we can rule out split screen or window resizing. Our app is locked to portrait as well, so we can also rule out orientation changes. And considering the stack trace is in the middle of an objc_retain_x2 call, which is itself inside of a collection enumeration, we are assuming that whatever is being enumerated probably was changed or deallocated during enumeration. Sometimes it's objc_retain_x2, and sometimes it's a release call. And sometimes it's a completely different stack trace, but still within BaseBoard/FrontBoardServices. I suspect these all share the same cause. Because it's thread 0 that crashed, we know that BaseBoard/FrontBoardServices were running on the main thread, which means that for this crash to occur, something might be changing on a background thread. This is what leads me to suspect a race condition. There are many places in our app where we accidentally update the UI from a background thread. We've fixed many of them, but I'm sure there are more. Our app is large. Because of this, I think background UI are the most likely cause. However, since I can't reproduce the crash, and because none of our stack traces clearly show UI updates happening on another thread at the same time, I am not certain. And here's the stack trace inline, in case the attachments expire or search engines can't read them: Thread 0 name: Thread 0 Crashed: objc_retain_x2 (libobjc.A.dylib) BSIntegerMapEnumerateWithBlock (BaseBoard) -[BSSettings initWithSettings:] (BaseBoard) -[BSKeyedSettings initWithSettings:] (BaseBoard) -[FBSSettings _settings:] (FrontBoardServices) -[FBSSettings _settings] (FrontBoardServices) -[FBSSettingsDiff applyToMutableSettings:] (FrontBoardServices) -[FBSSettingsDiff settingsByApplyingToMutableCopyOfSettings:] (FrontBoardServices) -[FBSSceneSettingsDiff settingsByApplyingToMutableCopyOfSettings:] (FrontBoardServices) -[FBSScene updater:didUpdateSettings:withDiff:transitionContext:completion:] (FrontBoardServices) __94-[FBSWorkspaceScenesClient _queue_updateScene:withSettings:diff:transitionContext:completion:]_block_invoke_2 (FrontBoardServices) -[FBSWorkspace _calloutQueue_executeCalloutFromSource:withBlock:] (FrontBoardServices) __94-[FBSWorkspaceScenesClient _queue_updateScene:withSettings:diff:transitionContext:completion:]_block_invoke.cold.1 (FrontBoardServices) __94-[FBSWorkspaceScenesClient _queue_updateScene:withSettings:diff:transitionContext:completion:]_block_invoke (FrontBoardServices) _dispatch_client_callout (libdispatch.dylib) _dispatch_block_invoke_direct (libdispatch.dylib) __FBSSERIALQUEUE_IS_CALLING_OUT_TO_A_BLOCK__ (FrontBoardServices) -[FBSMainRunLoopSerialQueue _targetQueue_performNextIfPossible] (FrontBoardServices) -[FBSMainRunLoopSerialQueue _performNextFromRunLoopSource] (FrontBoardServices) __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ (CoreFoundation) __CFRunLoopDoSource0 (CoreFoundation) __CFRunLoopDoSources0 (CoreFoundation) __CFRunLoopRun (CoreFoundation) CFRunLoopRunSpecific (CoreFoundation) GSEventRunModal (GraphicsServices) -[UIApplication _run] (UIKitCore) UIApplicationMain (UIKitCore) (null) (UIKitCore) main (AppDelegate.swift:0) 0x1ab8cbf08 + 0

I am trying to add a pinned(always visible and not moving) toolbar to the bottom of UISheetPresentationController or presentationDetent. This is achievable when the user is dragging to change the size of the sheet. But when changing the detent by code, it does not work. For example, when changing from medium to large, the ViewController's size is changed to large then moved up to the position. From the user's POV, anything at the bottom to disappear for a few frames then reappears. From my testing, when using UISheetPresentationController, ViewController only knows the medium and large state's frame and bounds, so manually setting it up won't work. Is there a way to keep views at the bottom always visible in this case? The sample code below is in SwiftUI for easy recreation, and the responses can be in UIKit. Sample Code: struct ContentView: View { @State var showSheet: Bool = true @State var detent: PresentationDetent = .medium var body: some View { EmptyView() .sheet(isPresented: $showSheet) { ScrollView { } .safeAreaInset(edge: .bottom) { Button { detent = (detent == .medium) ? .large : .medium } label: { Text("Change Size") } .buttonStyle(.borderedProminent) .presentationDetents([.medium, .large], selection: $detent) .presentationBackgroundInteraction(.enabled) } } } }

Multitasking & Gestures >> Seeing the app icon instead of contact info when drag-and-dropping contacts into my Calendar view in iOS 26.0 Beta? In Settings Multitasking & Gestures >> Select Full-screen Apps then worked fine. But when Multitasking & Gestures >> select Windowed Apps then any suggestion how to handle on app development for one or two screen?

https://developer.apple.com/documentation/callkit/preparing-your-app-to-be-the-default-calling-app I have 2 accounts, one for App store and one for tesing (Inhouse type). I added the capability in the Xcode project, and can run it. But when I run a Inhouse build for it on my CI server, it failed. So is the Inhouse build support this "com.apple.developer.calling-app"?