This topic area is about the programming languages themselves, not about any specific API or tool. If you have an API question, go to the top level and look for a subtopic for that API. If you have a question about Apple developer tools, start in the Developer Tools & Services topic. For Swift questions: If your question is about the SwiftUI framework, start in UI Frameworks > SwiftUI. If your question is specific to the Swift Playground app, ask over in Developer Tools & Services > Swift Playground If you’re interested in the Swift open source effort — that includes the evolution of the language, the open source tools and libraries, and Swift on non-Apple platforms — check out Swift Forums If your question is about the Swift language, that’s on topic for Programming Languages > Swift, but you might have more luck asking it in Swift Forums > Using Swift. General: Forums topic: Programming Languages Swift: Forums subtopic: Programming Languages > Swift Forums tags: Swift Developer > Swift website Swift Programming Language website The Swift Programming Language documentation Swift Forums website, and specifically Swift Forums > Using Swift Swift Package Index website Concurrency Resources, which covers Swift concurrency How to think properly about binding memory Swift Forums thread Other: Forums subtopic: Programming Languages > Generic Forums tags: Objective-C Programming with Objective-C archived documentation Objective-C Runtime documentation Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

Circling back on the LocalLM Lab arc. With v0.7, we've moved from prompt experimentation into real app development on Apple's Foundation Models local AI. The LocalLM Lab SDK lets you build that same on-device model and MCP client this thread has covered directly into your own app, with real tool and data access (Slack, Todoist, GitHub, Notion, Linear, plus Calendar, Reminders, Contacts and Location). And you can ship your app including through the Mac App Store. This is a big improvement over version 0.6, where the localai-cli toolkit needed LocalLM Lab installed and running. On the other hand, the SDK (LocalLMLabSDKCore) doesn't relay through anything; it links FoundationModels and a real MCP client directly into your own binary and is totally self-contained. The example included in the SDK, Plate Today, has actually been built into a sandboxed test app and verified working, with a signed path to a Mac App Store .pkg (Apple Distribution signing + provisioning profile pipeline). That's "verified signable and sandbox-compatible," to be precise. Entitlements (from personal experience: always a complicated topic): com.apple.security.app-sandbox + com.apple.security.network.client for the app itself, plus the standard personal-information entitlements per connector used (com.apple.security.personal-information.calendars, .addressbook, .location) and matching NS*UsageDescription strings in Info.plist. The one worth flagging specifically: the network entitlement is easy to miss and fails silently rather than throwing. Without it, MCP connections and Weather calls just hang with no error surfaced. OAuth handling requires the app delegate callback (application(_:open:)), not SwiftUI's .onOpenURL. Worth knowing before wiring it up if you're SwiftUI-only. Full entitlements list + SDK guide: https://github.com/ancientcomputing/locallm/blob/main/docs/sdk-guide.md Feature page: thisbrain.ai/locallm/sdk.html I hope the availability of the SDK (free, Apache 2.0 license) will give folks further incentive to explore local AI-enabled applications on the Mac. What else would you want to do that the SDK doesn't currently support? File picker? Calendar/Reminders/Contacts edits & writes?

I’m developing a small macOS workflow utility for Final Cut Pro and I’d like to confirm whether there is a supported API for a particular project-management workflow before relying on macOS Accessibility automation. The utility is intended to take an existing Final Cut Pro project and create multiple native duplicates at different custom frame sizes — for example: 1920 × 1080 1080 × 1920 1080 × 1350 1080 × 1080 custom banner dimensions The desired operation is essentially the equivalent of Final Cut Pro’s Duplicate Project As… command: duplicate the selected project, assign a new name, set a custom video resolution, and optionally enable or disable Smart Conform. It is important that Final Cut Pro itself performs a native project duplication so that all existing project data is retained, including effects, grades, plug-ins, keyframes, compound clips, retiming and Magnetic Masks. I initially prototyped the workflow using FCPXML, which works very well for creating the differently sized projects. However, Apple’s documentation notes that Magnetic Masks are not included in XML exports, so an FCPXML round-trip is not suitable for this use case. I’ve reviewed the documentation for FCPXML, Workflow Extensions / ProExtensionHost, and programmatic communication with Final Cut Pro using Apple Events, but I haven’t found a documented API that allows an application to: Duplicate the currently selected Final Cut Pro project natively. Rename the duplicated project. Change its video format to an arbitrary custom width and height. Optionally control Smart Conform. I currently have a working proof of concept using the macOS Accessibility API to invoke and operate Final Cut Pro’s native Duplicate Project As… interface. Before developing that approach further, I’d like to confirm that I’m not overlooking a supported Final Cut Pro API or Workflow Extension capability that would accomplish the same thing more directly and robustly. Is there a supported public API for this workflow, either through the Workflow Extension SDK, ProExtensionHost, Apple Events, scripting support, or another Professional Video Applications framework? If not, is using macOS Accessibility to automate Final Cut Pro’s native project-duplication interface an appropriate approach for a third-party macOS workflow utility? Many thanks, James

I add a series of buttons in the UIToolbar of accessoryView. Before liquidGlass (Xcode 26.6, iOS 26), I get this: Buttons are properly stacked, allowing up to 8 buttons, which is what I need. But with liquidGlass, buttons are now enclosed in a useless bubble, and thus take much more space. No way to accommodate 8 buttons anymore, they are displayed in the "…" followup section, which is very inconvenient. In iOS 26, I can still set UIDesignRequiresCompatibility to true and get the expected presentation. But that does not work in Xcode 27 / iOS 27. Code is essentially the following: let bar = UIToolbar(frame:CGRect(x: 0, y: 0, width: 200, height: 44)) let letterBack = UIImage(named: "letterBackground")! let targetSize = CGSize(width: 36, height: 36) let scaledImage = letterBack.scalePreservingAspectRatio( targetSize: targetSize ) let letterI = UIBarButtonItem(title: "I", style: .plain, target: self, action: #selector(letterTapped(_:))) letterI.setBackgroundImage(scaledImage, for: .normal, barMetrics: .default) // Same for other letters bar.items = [letterI, letterV, letterX, letterL, letterC, flexibleSpace, peseudoReturn] bar.sizeToFit() aTextField.inputAccessoryView = bar I have tried to use barMetrics: .compact to no avail So, a few questions: Is it possible, with liquidGlass, to have the buttons displayed without their ellipse bubble, so that they stack against each other ? Is there other appearence setting to set ? Or should I give up toolbar and create a collectionView that I will place atop keyboard ? In anycase, liquidGlass is really problematic in term of screen estate use.

Using Xcode 27.0ß4. I set a textField text with an emoji: statusReponseLabel.text = "👍" In iOS 27, I get the expected result (on the left). In iOS 26.3 (simulator), I just get a question mark. I have tested with a print, the text is properly set. I replaced with: statusReponseLabel.text = "A👍B" In iOS 26.3, I get A followed by the question mark, B is skipped as well. Is it an iOS issue or just a simulator issue in beta version ?

I would appreciate some feedback on this simple technical point. When a gesture is defined in code, it is simply added to the view with myFirstView.addGestureRecognizer(someGesture) That's fine. But, if by mistake, the same gesture is added later to another view myOtherView.addGestureRecognizer(someGesture) myFirstView will not receive anymore the notification. That's well known and documented, because in fact the gesture references the view and can only reference one. So my point: this may be a bit misleading, as API let one believe that the gesture is attached to the view ; hence, why not attach to a second view ? wouldn't it be better to have API where view is explicitly "attached" to gesture ? someGesture.attach(to: myFirstView) Doing so, if I later someGesture.attach(to: myOtherView) it would be clearer I am changing the attached view. I noted that when we define a gesture in IB, we can only connect from the view to the gesture, not from gesture to the view which seems to follow the same logic. A simple extension does it: extension UITapGestureRecognizer { func attach(to view: UIView) { view.addGestureRecognizer(self) } } Any thought ? PS: I'm amazed by code completion. I just typed extension UITapGestureRecognizer { func attach(to view: UIView) and it completed automatically the code with view.addGestureRecognizer(self)

I’m seeing inconsistent UISegmentedControl background-color behavior on certain devices running iOS 26. The same code works as expected on other devices and iOS versions, but on affected devices the control does not display the assigned backgroundColor. The issue occurs using standard UIKit colors and does not depend on custom fonts, images, or appearance extensions. Here is a simplified example using only public UIKit APIs: private let segmentedControl = UISegmentedControl(items: ["Card", "Email"]) private func setupSegmentedControl() { segmentedControl.selectedSegmentIndex = 0 guard let cardIcon = UIImage( systemName: "creditcard.fill", withConfiguration: UIImage.SymbolConfiguration( pointSize: 14, weight: .semibold ) ), let emailIcon = UIImage( systemName: "envelope.fill", withConfiguration: UIImage.SymbolConfiguration( pointSize: 14, weight: .semibold ) ) else { return } segmentedControl.setImage( cardIcon, forSegmentAt: 0 ) segmentedControl.setImage( emailIcon, forSegmentAt: 1 ) segmentedControl.backgroundColor = .systemGray5 segmentedControl.selectedSegmentTintColor = .systemBlue segmentedControl.layer.cornerRadius = 8 segmentedControl.clipsToBounds = true let font = UIFont.systemFont( ofSize: 14, weight: .medium ) segmentedControl.setTitleTextAttributes( [ .foregroundColor: UIColor.label, .font: font ], for: .normal ) segmentedControl.setTitleTextAttributes( [ .foregroundColor: UIColor.white, .font: font ], for: .selected ) segmentedControl.addTarget( self, action: #selector(segmentChanged(_:)), for: .valueChanged ) view.addSubview(segmentedControl) } @objc private func segmentChanged( _ sender: UISegmentedControl ) { print("Selected segment: \(sender.selectedSegmentIndex)") } UISegmentedControl Apple Documentation

Does iOS support launching of 2 MFMessageComposeViewControllers back to back i.e without dismissing the previous one? We are integrating an SDK from a vendor who, inside the SDK is presenting the MFMessageComposeViewController 2 times back to back, and one of the MFMessageComposeViewController is getting dismissed but the other one doesn't, their standalone app does the same but it works there, not inside the SDK, Just wanted to know why the second MFMessageComposeViewController doesn't dismiss, or is it the correct approach to do so.

Summary We have identified a reproducible world tracking drift regression in ARKit on LiDAR-equipped iOS devices running iOS 26.4 and later. A static virtual node anchored at the world origin visually drifts from its initial position as the user moves around a real-world scene, despite the scene remaining physically static. The same code produces stable, drift-free results on non-LiDAR devices running identical OS versions. Device & OS Observations Testing was performed across four devices on iOS 26.4 using the same application build and ARWorldTrackingConfiguration settings. Non-LiDAR devices — iPhone 14 and iPhone 15 — produced stable, drift-free tracking in all test runs. No world origin displacement was observed regardless of how long or how far the user walked. LiDAR-equipped devices — iPhone 14 Pro and iPhone 16 Pro — exhibited consistent, reproducible drift. A static node placed at the world origin visually shifted from its initial position as the user moved through the scene. The same devices were stable on earlier iOS versions, confirming this is a regression introduced in iOS 26.4. Technical Observations Nature of drift: A SCNNode placed statically at the ARKit world origin (SCNVector3(0, 0, 0)) visually displaces from its original position as the user walks around a static real-world scene. The displacement is not random — it accumulates directionally as the user moves, consistent with a sensor fusion or coordinate anchoring error. Trigger condition: The drift occurs during normal walking motion around a fixed point of interest, such as circling a parked vehicle. It does not appear when the device is held still. LiDAR specificity: The drift is exclusive to devices with a LiDAR scanner. Identical hardware configurations — same iOS build, same ARWorldTrackingConfiguration settings — on non-LiDAR devices produce no drift whatsoever. This isolates the regression to the LiDAR sensor's contribution to ARKit's internal Visual-Inertial Odometry (VIO) fusion pipeline. No API-level workaround found: There is currently no public ARKit API to selectively disable the LiDAR scanner's contribution to VIO. All available configuration-level options have been evaluated without resolving the drift. ARWorldTrackingConfiguration Options Evaluated The following configuration changes were applied individually and in combination. None resolved the drift on LiDAR devices: isAutoFocusEnabled = false — No improvement videoHDRAllowed = false (disabled) — No improvement planeDetection = [] (disabled) — No improvement sceneReconstruction = .mesh — No improvement worldAlignment: .gravity vs .gravityAndHeading — No improvement Minimal Reproduction Case The drift can be reproduced with a minimal ARKit scene: Create an ARSCNView with ARWorldTrackingConfiguration using default settings. Add a single static SCNNode (e.g., a small sphere or axes geometry) at SCNVector3(0, 0, 0) when the session starts. Run the app on a LiDAR-equipped device (iPhone Pro, iPad Pro with LiDAR) on iOS 26.4 or later. Walk in a circle around the node's approximate real-world position. Expected: The node remains visually fixed at its world position throughout the walkthrough. Actual: The node drifts from its initial position, increasingly displaced from its world origin anchor as walking continues. We want to know if Apple has made any internal updates to ARKit, particularly after the OS 26.4 upgrade. Thanks!

Emoji are very convenient to be used instead of image, directly as String. In some cases, a variation to show them rotated (but still as String, not converted as image) would be useful. Examples may be arrows or flags if you need to show them floating from the top and not from the side of the pole. And I would declare: flag = "🇺🇸" or So the question; is it possible to generate new emoji as rotated initial emojis ? Or better, do such extensions already exist.

This is UIKit app, in Xcode 26.3 (but same issue in 16.4). I create (in IB) a segmentedControl, with 2 segments. I set the images that are stored in assets. They show properly in Xcode. But when running (26.1 simulator), they just show a black image. In Xcode                                                                           On simulator at runtime I've tried to set background to clear as well as tint, to no avail. What am I missing ?

Hi everyone, I'm Alexsander. My friends call me Lexie. I have been working as software developer since 6 years ago, I have a lot of experience with Java and I started working with Angular since the last year. I am new in the Apple ecosystem and I have a question about best practices in full native Swift apps. There is any source (blogs, youtube channels, books, et al.) where I can understand the best practices? Like, I've heard about MVVM to scalable apps but I don't know exactly how to apply it. I think it's because usually I do not have my front-end components in the same project of my backend. I've been watching some videos from Apple Developer youtube channel and they are absolutely amazing, but they only keep teaching people to use the "raw" resources, not matching with the best practices. For example, I saw using swift data we do not need to write any SQL Query, unlike Java Ecossystem where even we use a ORM we usually write our queries natively, whether creating a table or fetching data.

iOS 27 Beta 4: Native Liquid Glass UITabBar renders with opaque milky/frosted background while identical code renders correctly on iOS 26.5 Environment Xcode 27 Beta 4 iOS 27 Beta 4 UIKit UITabBarController Storyboard based application Native UITabBar (no custom tab bar implementation) Device: iPhone 17 Pro Simulator (also reproducible on other iPhone simulators) Problem After upgrading to iOS 27 Beta 4, the native Liquid Glass tab bar appears significantly more opaque (milky/frosted gray) than on iOS 26.5. The exact same application binary and configuration render correctly on iOS 26.5. No custom blur or visual effect is being applied. Current Configuration let appearance = UITabBarAppearance() appearance.configureWithDefaultBackground() appearance.backgroundColor = nil appearance.backgroundEffect = nil appearance.shadowColor = .clear tabBar.standardAppearance = appearance tabBar.scrollEdgeAppearance = appearance tabBar.isTranslucent = true tabBar.backgroundColor = nil tabBar.barTintColor = nil tabBar.backgroundImage = nil tabBar.shadowImage = nil Runtime Verification Verified at runtime: tabBar.backgroundColor == nil tabBar.barTintColor == nil tabBar.isTranslucent == true standardAppearance.backgroundColor == nil standardAppearance.backgroundEffect == nil scrollEdgeAppearance.backgroundColor == nil scrollEdgeAppearance.backgroundEffect == nil View Hierarchy The runtime hierarchy contains Apple's native Liquid Glass implementation: UITabBar _UIBarItemPlatterView _UILiquidLensView BackdropView ClearGlassView _UIPortalView _UITabSelectionView Therefore UIKit is using the Liquid Glass implementation rather than falling back to a legacy blur. Investigation Performed The following were tested without changing behavior: Removed all custom blur views Removed custom overlays Removed refresh/recomposition code Removed layout invalidation Removed transform hacks Removed PageMenu Replaced entire first tab with a plain UITableViewController Replaced DiscoverVC completely Replaced nested collection views Rebuilt a minimal demo project using identical UITabBarAppearance code The minimal demo renders correctly. The production application renders with a much more opaque gray background. Question Has anything changed in the Liquid Glass compositor or backdrop sampling behavior in iOS 27 Beta 4? Is there any new API or recommended configuration required to achieve the same transparency level as iOS 26.5? If this is expected behavior, is there any supported way to control the opacity of the system Liquid Glass material? Screenshots Attach: iOS 26.5 screenshot iOS 27 Beta 4 screenshot

This was confirmed as a framework gap in an accepted answer from an Apple Vision Pro engineer in June 2024 (https://developer.apple.com/forums/thread/758014?answerId=792769022#792769022): .background fires identically whether the user taps a window's close button or the system backgrounds a window that's been out of the field of view for ~61 seconds, and there's no app-visible signal that distinguishes the two. The recommendation at the time was to use a gesture/affordance to reopen the window, and to file an enhancement request. Two years on, with the window-management APIs that have shipped since, I want to confirm whether the situation has changed as of visionOS 26. My case: VisionBlazer, a native spatial 3D creation tool (TestFlight beta, August 2026 launch). Users routinely work with several SwiftUI WindowGroup tool windows open at once — drawing tools, materials, timeline, properties, lighting — parked spatially around an ImmersiveSpace. Parking a window behind or beside you is core to the workflow. The app should terminate when the user closes the primary window, but must not terminate when a secondary window (or the primary) is simply parked out of view. What I've verified on-device (visionOS 26.5): scenePhase == .background fires identically for a user close tap and for the ~61s out-of-FoV backgrounding (SurfBoard: "…is out of FOV after 60.99 seconds. Backgrounding"). The phase sequence (active → inactive → background) and timing (~0.2–0.4s gap) are indistinguishable between the two cases. scenePhase on visionOS reflects visibility, not focus — a parked window stays .active while the user edits elsewhere, until the out-of-FoV timer fires. The session identifier reachable from the window's view hierarchy (view.window!.windowScene.session.persistentIdentifier) never matches the identifier reported by application(_:didDiscardSceneSessions:) or UIScene.didDisconnectNotification for that same close. The view-visible session stays in UIApplication.shared.openSessions indefinitely after the close. Those disconnect/discard callbacks arrive ~10–15s late and only ever carry foreign session identifiers, so they can't be attributed to a specific window. Stale-session discards from prior launches pollute the signal further. onDisappear does not fire on user close. Five strategies tried, all failed: (1) scene-object identity captured at didMoveToWindow; (2) session.persistentIdentifier matching against openSessions; (3) live re-capture of scene/session from the view hierarchy on every lifecycle change; (4) temporal correlation of didEnterBackground/didDisconnect; (5) a focus-recency heuristic on scenePhase transitions. All fail on the identifier mismatch and the visibility-not-focus semantics above. Questions: As of visionOS 26, is there now any supported way to detect that the user intentionally closed a specific window, distinct from system backgrounding? Is there a SwiftUI or scene-delegate callback tied to a window's own scene that fires only on user close? Is there a dismissalReason (or equivalent) anywhere on the close path? If none of the above exists, is an explicit in-app Quit button still the intended pattern for "quit when the main window is closed"? I have a focused test project reproducing all of this and can link it. Thanks.

I’m developing an app (well, Claude Code is doing the Swift work) that has a need to send SMS messages on a regular basis. It’s an app that sends location information to a third party, via SMS, in case the user goes missing. Claude is telling me that the user has to hit send for every message. Claude also says there’s no way for the app to know if a message was successfully sent. It only knows that it was queued in Messenger but not that it was actually successful in sending. In the Android port we don’t have those restriction, apparently. The Android app can send messages without the users involvement (after granting permission ahead of time). The Android app can also query as to whether the send was successful, and optionally retry the send when it wasn’t. The advantage of not having the user needing to hit send ’Send’ and being able to determine if the queued send was successfully sent is an increase in reliable location information being received by the recipient. My questions are whether Claude Code is correct in what iOS allows, and if there’s an alternate approach. I understand the security concern with sending messages the user didn’t explicitly approve for each message but I’m wondering if Apple is considering an implementation mechanism that approaches Android (ie: approve message sending without per-message authorization) and the ability to check if a queued message was successfully sent. Thanks.

Hi All,I am working on a project to turn my iPhone to silent mode via Code (Swift), Can someone ,plz, help to put on the right direction as I am very new to Xcode and Swift.Regards

I'm observing an interesting behavior on iOS when uploading edited videos from the Photos library. Scenario Device: iPhone Video: 4K, 60 FPS Original video size (Photos app): 660 MB Uploaded original asset: 660 MB After applying a simple edit (e.g., a filter) in the Photos app: Photos app still shows the edited video. When my app uploads the current/edited asset, the uploaded file size becomes 167 MB. So the edited version is approximately 75% smaller than the original (660 MB → 167 MB), even though the duration appears unchanged. Questions Is this expected behavior for edited videos in the Photos library? Does iOS automatically re-encode edited videos using a lower bitrate or a different codec (e.g., HEVC) when generating the current rendition? Does the Photos app continue to display the size of the original asset rather than the size of the edited rendition? I'm aware that PhotoKit allows retrieving both the original and the current (edited) versions of a PHAsset. In this case, I'm intentionally retrieving the current version, and this behavior is observed only for the edited asset.

I'm using PDFKitView: NSViewRepresentable to present the pdf page in SwiftUI. Seems we already have some useful built-in functions in the context menu. However, the highlight manipulation functions are not functional - I can neither delete the highlight annotation nor change the color/type of the current pointed highlight annotation. The "Add Note" and other page display changing functions work well.

We're working on an Endpoint Security extension and using Swift 6 with Concurrency. I've heard there are some subtleties to getting the threading right across those two domains and am hoping that someone can help shed light on it. In particular, ES events can be delivered on a high priority thread and I'd like to be sure that any work done in the Concurrency domain retains that priority to minimize latency between event delivery and response.

In the iOS Photos app there is a caption field the user can write to. How can you write to this value from Swift when creating a photo? I see apps that do this, but there doesn't seem to be any official way to do this using the Photo library through PHAssetCreationRequest or PHAssetResourceCreationOptions or setting EXIF values, I tried settings a bunch of values there including IPTC values but nothing appears in the caption field in the iOS photos app. There must be some way to do it since I see other apps setting that value somehow after capturing a photo.

I am currently developing an app for MacOS that needs to control HomeKit devices like lights. However, it seems like MacOS is supported on the official documentation, but not when I try to create an app ID on developer.apple.com. On the link https://developer.apple.com/apple-home/, MacOS is clearly showed as supported for MacOS. But when I try to create an app ID, it shows that it is only compatible for iOS, VisionOS and WatchOS. Could this be clarified? Best regards, orangeidle25