Google released 3.7 Flash just yesterday They also slashed prices for 3.7 and 3.6 Flash by 50%! What's relevant to us is they didn't slash prices for 3.5 Flash, so Xcode agentic coding users are stuck with a service that's double the price for less performance (it gets worse if you use 3.1 Pro Preview). The more I look into gemini-cli(which Xcode's native agentic coding is dependent on, as Antigravity doesn't support ACP), the more dire things look for Gemini users who want to stay in Xcode. https://github.com/google-gemini/gemini-cli/discussions/28685 https://github.com/google-gemini/gemini-cli/issues/28625 https://github.com/google-gemini/gemini-cli/issues/28802 There are signs that, despite explicitly committing to supporting Gemini CLI for enterprise users (which ostensibly includes Apple and downstream Xcode users), Google has effectively put Gemini CLI on ice, rolling out support for 3.5 Flash only after 3.6 Flash was released, and immediately before 3.7 Flash. An issue to add 3.6 and 3.7 support was flagged as "Backlog - a good idea but not currently a priority." It feels like they're trying to soft-force everyone into using Antigravity, but for many reasons I'd much rather stick with Xcode. The Coding Intelligence team at Apple should really look into alternative/custom ACP agent solutions, at least for Gemini, or just drop native Gemini agent support altogether. Otherwise a lot of devs might wrongly think it's Apple's fault they're forced to use older, less performant models at double price.

Update: Xcode 27 Beta 5 works with Gemini 3.5 Flash I did some digging around and it turns out the very latest weekly Gemini CLI build doesn't work with 3.6 Flash, weeks after its release^, so Apple can't really be blamed for this. Google is being so slow with everything it makes me want to jump ship to OpenAI/Anthropic even though they're not available where I live. As a side note, Gemini 3.6 Flash (extended) leading me in circles with frequent and persistent hallucinations about various Google products like Antigravity and Gemini CLI doesn't inspire confidence. While I'm here I'd like to request the ability to specify service/pricing tier (standard/flex/batch/priority)--this setting can greatly impact cost ^ I've avoided installing Gemini CLI and using it as an external ACP agent due to security and privacy concerns but used a VM to check it out

Xcode currently uses Gemini CLI v0.42.0 from last year Correction: 0.42.0 was released in May Things move so fast in the AI world, May feels like last year.

The issue seems to have been resolved in iOS 26.1 (tested on simulator) Thank you!

@jwcarr I'm a new developer, and the fact that I stumbled upon this bug in a non-beta release makes me nervous about what other bugs in basic functionality I just haven't noticed yet.

@Claude31 All devices, physical and simulated. The code I provided consistently doesn't work. @Tomato I found a workaround involving measuring the screen aspect ratio to determine whether a device is an iPhone SE or not. Not the most elegant solution, but does the job. Your answer is interesting because I've always assumed that Apple didn't allow developers to access specific information like device name, etc. due to privacy concerns, so it never really occurred to me to just look up the model name and go from there. This is really useful information to me as it will allow me to tweak UI on a per-device basis, and more. Thank you!

To be clear, I tested this with UIDesignRequiresCompatibility=TRUE. I don't know if this is the case for @jwcarr and I haven't tested this with glass Sliders. Also, flattered that I got an Apple Recommended badge, but not sure I deserve it for that post.

Noticed this today; hope something this basic gets fixed ASAP

@DTS Engineer Thank you for your response. I'm trying to magnify a SpriteView within a SwiftUI view where the user's finger is. The SpriteView itself has a pinch gesture for zooming in, but on top of that I need to offer greater gesture precision via a magnifying glass. MagnifyGesture + scaleEffect therefore wouldn't help. I've also tried implementing an UIView magnifying glass within the SKScene but it just shows crosshairs. https://github.com/niczyja/MagnifyingGlass-Swift import UIKit import SwiftUI public class MagnifyingGlassView: UIView { public weak var magnifiedView: UIView? = nil { didSet { removeFromSuperview() magnifiedView?.addSubview(self) } } public var magnifiedPoint: CGPoint = .zero { didSet { center = .init(x: magnifiedPoint.x + offset.x, y: magnifiedPoint.y + offset.y) } } public var offset: CGPoint = .zero public var radius: CGFloat = 50 { didSet { frame = .init(origin: frame.origin, size: .init(width: radius * 2, height: radius * 2)) layer.cornerRadius = radius crosshair.path = crosshairPath(for: radius) } } public var scale: CGFloat = 2 public var borderColor: UIColor = .lightGray { didSet { layer.borderColor = borderColor.cgColor } } public var borderWidth: CGFloat = 3 { didSet { layer.borderWidth = borderWidth } } public var showsCrosshair = true { didSet { crosshair.isHidden = !showsCrosshair } } public var crosshairColor: UIColor = .lightGray { didSet { crosshair.strokeColor = crosshairColor.cgColor } } public var crosshairWidth: CGFloat = 5 { didSet { crosshair.lineWidth = crosshairWidth } } private let crosshair: CAShapeLayer = CAShapeLayer() public convenience init(offset: CGPoint = .zero, radius: CGFloat = 50, scale: CGFloat = 2, borderColor: UIColor = .lightGray, borderWidth: CGFloat = 3, showsCrosshair: Bool = true, crosshairColor: UIColor = .lightGray, crosshairWidth: CGFloat = 0.5) { self.init(frame: .zero) layer.masksToBounds = true layer.addSublayer(crosshair) defer { self.offset = offset self.radius = radius self.scale = scale self.borderColor = borderColor self.borderWidth = borderWidth self.showsCrosshair = showsCrosshair self.crosshairColor = crosshairColor self.crosshairWidth = crosshairWidth } } public func magnify(at point: CGPoint) { guard magnifiedView != nil else { return } magnifiedPoint = point layer.setNeedsDisplay() } private func crosshairPath(for radius: CGFloat) -> CGPath { let path = CGMutablePath() path.move(to: .init(x: radius, y: 0)) path.addLine(to: .init(x: radius, y: bounds.height)) path.move(to: .init(x: 0, y: radius)) path.addLine(to: .init(x: bounds.width, y: radius)) return path } public override func draw(_ rect: CGRect) { guard let context = UIGraphicsGetCurrentContext() else { return } context.translateBy(x: radius, y: radius) context.scaleBy(x: scale, y: scale) context.translateBy(x: -magnifiedPoint.x, y: -magnifiedPoint.y) removeFromSuperview() magnifiedView?.layer.render(in: context) //If above disabled, no change //Possible that nothing's being rendered into context //Could it be that SKScene view has no layer? magnifiedView?.addSubview(self) } }

iOS 18.0 (public) Same here; all ScrollViews containing elements with DragGesture() don't scroll properly and this is causing major headaches. I've switched some from .highPriorityGesture() to .simultaneousGesture() as a stopgap measure.

The issue has been resolved. For posterity, Xcode must have access to both wifi and bluetooth to detect the watch and make the Settings > Privacy & Security > Developer Mode list item appear. If there's no bluetooth, the list item never appears, but the Settings > Developer menu item will appear on its own despite the user never having toggled or even seen the Developer Mode list item. This should be considered a bug, but is an edge case. The documentation should make it clear that Bluetooth must be enabled on macOS in its "Enabling Developer Mode on a device" article. Since Bluetooth availability was the key, tethering and other wifi-based workarounds were ineffective.

I came up with a convoluted method to sidestep this issue entirely, but this is extremely specific to my app's use-case, so I'm not going to post it here. If anyone feels like answering this question for posterity, please feel free to do so and I'll be sure to give you your checkmark.

Always good to know what's empirically true. The following statements in the article tripped me up: Even better, if [MainActor.run] was already running on the main actor then the code is executed immediately – it won’t wait until the next run loop in the same way that DispatchQueue.main.async() would have done. and Important: If your function is already running on the main actor, using await MainActor.run() will run your code immediately without waiting for the next run loop, but using Task as shown above will wait for the next run loop. Some more results based on variations of your code: Task { @MainActor in print("\(delta()) main actor will run") ... t+0.0 start t+1.0 main thread will sleep t+2.1 task will start t+2.1 task did start t+3.0 main thread did sleep t+3.0 main actor will run t+3.0 main actor running t+3.0 main actor did run Task { @MainActor in print("\(delta()) main actor running") ... t+0.0 start t+1.0 main thread will sleep t+2.1 task will start t+2.1 main actor will run t+2.1 main actor did run t+2.1 task did start t+3.0 main thread did sleep t+3.0 main actor running Both waited for the run loop @MainActor func main() async { print("\(delta()) start") Timer.scheduledTimer(withTimeInterval: 0.0, repeats: false) { _ in print("\(delta()) main thread will sleep") sleep(2) print("\(delta()) main thread did sleep") } await MainActor.run { print("\(delta()) main actor running") } } t+0.1 start t+0.1 main thread will sleep t+2.1 main thread did sleep t+2.1 main actor running This shows that the statements in the article don't reflect what's empirically true. await MainActor.run() in a function that's already on the main actor will not cause the code to run immediately without waiting for the next run loop.

@TonECCT I found an article about this: https://www.hackingwithswift.com/quick-start/concurrency/how-to-use-mainactor-to-run-code-on-the-main-queue The reason I failed to come across this before was that I was searching for variations of "DispatchQueue.main.async concurrency replacements" instead of looking for @MainActor directly. It does a good job going into the nuances between the two and is easily digestible. What's important to me is that Task { @MainActor in behaves exactly like DispatchQueue.main.async because it waits for the next run-loop, which means it can be replaced 1:1 in most situations. Using await MainActor.run { } causes the closure to run immediately, without waiting for the next run loop. Another important difference is the Task version can be run straight from a regular context while MainActor.run needs to be in an async context.

This is perfect! All I'll have to do is to find and replace all instances of DispatchQueue.main.async { with Task { @MainActor in in my project. I would've never figured this out in a million years since using @MainActor inside the closure is just plain counterintuitive; doing it without some constant (e.g. list.filter { thing in thing.isTrue }) doubly so. I would've tried sacrificing gerbils when compiling before trying that. I'll look into Observable, Combine, and async streams if the need arises, but for now getting rid of all GCD calls and making my app pure async-await is enough. Thank you very much