Will UVC native support come for the Iphone as well? So, using external cameras with the ipad is greatly beneficial, but for the iphone, it can make it a production powerhouse! So, have there been discussions around bringing UVC support for the Iphone as well? and if so, what were your conclusions?

Hi everyone! I've considered this — what if Apple added a native system-wide feature in all of iOS, iPadOS, and macOS called “CrossRun” where you can natively execute non-App Store software like Windows or Linux apps natively on your device? But not in a sluggish emulator—this would use intelligent Apple-signed Just-In-Time (JIT) compilation inside the virtual containers, and the experience would actually perform fast and feel natural. This is my vision for CrossRun: Every developer, student, creative professional, and enterprise user who relies on specialized software—whether it’s legacy Windows tools, Linux-only applications, or vintage DOS and Classic Mac utilities—feels the pain of platform lock‑in. Artists can’t run niche Linux‑based graphics programs on their iPads. Engineers can’t test x64‑only binaries on Apple Silicon without juggling emulators. Retro‑gaming fans miss their favorite DOS titles. Even enterprises struggle to standardize on Apple hardware because critical Windows‑only applications won’t run seamlessly. If we don’t push for CrossRun now, the Apple ecosystem remains siloed: iPads and iPhones will continue limited to App Store apps, Macs will still need multiple third‑party VM tools, and countless workflows stay fragmented across devices. That means slower development cycles, extra licensing costs for virtualization software, and lost opportunities for education, creativity, and business efficiency. Without CrossRun’s universal runtime, we’ll still be rebooting into different environments or paying for separate virtualization apps—year after year. Apple already provides the building blocks: Rosetta 2, Virtualization.framework, Apple Silicon—and QEMU thrives as open‑source, battle‑tested code. With the next wave of Apple Silicon devices on the horizon, demand for cross‑architecture support, legacy‑app compatibility, and enterprise containerization is only growing. Delaying another year will cost developers, businesses, and users real time and money. Let’s show Apple that the community is ready for a truly universal, system‑integrated solution—right now. Key features we should demand in CrossRun: Built‑in Apple‑signed QEMU for all ISAs (x86, ARM, RISC‑V, PowerPC, 68k, MIPS, etc.) Rosetta 2 JIT for seamless macOS and Windows x64 support Metal‑backed 3D GPU passthrough and Vulkan→Metal / Direct3D→Metal translation Downloadable OS and app containers via the App Store or verified repositories (Ubuntu, Windows ARM/x64, Android, Haiku, ReactOS, FreeBSD, retro OSes) Predictive ML pre‑warm cache to speed cold starts Dynamic resource scaling (CPU, GPU, RAM) per container iCloud‑synced snapshots and shareable VM links for cross‑device continuity Customizable on‑screen controls (D‑pad, virtual buttons, trackpad, keyboard) on iPhone, iPad, and macOS Secure sandboxing via Virtualization.framework with VM disk encryption and MDM policy enforcement Virtual LAN and VPN passthrough for container networking Developer tooling (crossrunctl CLI, Xcode debugger integration, CI/CD support) Plugin ecosystem and container SDK for community‑published templates and translation layers Let Apple know it’s time to bake CrossRun into the system and unlock a universal runtime for every app, past and future, across iOS, iPadOS, and macOS.

I'd like to know the install state of my iOS safari extension in the associated swift app. Is there any way to get this? As we have seen it is available for macOS here, is there anyway to know iOS Safari extension is enabled or not? Thanks

We are experiencing a crash in our application that only occurs on devices running iOS beta 26. It looks like a Beta problem. The crash appears to be caused by an excessive number of open File Descriptors. We identified this after noticing a series of crashes in different parts of the code each time the app was launched. Sometimes it would crash right at the beginning, when trying to load the Firebase plist file. That’s when we noticed a log message saying “too many open files,” and upon further investigation, we found that an excessive number of File Descriptors were open in our app, right after the didFinishLaunching method of the AppDelegate. We used the native Darwin library to log information about the FDs and collected the following: func logFDs() { var rlim = rlimit() if getrlimit(RLIMIT_NOFILE, &rlim) == 0 { print("FD LIMIT: soft: \(rlim.rlim_cur), hard: \(rlim.rlim_max)") } // Count open FDs before Firebase let openFDsBefore = countOpenFileDescriptors() print("Open file descriptors BEFORE Firebase.configure(): \(openFDsBefore)") } private func countOpenFileDescriptors() -> Int { var count = 0 let maxFD = getdtablesize() for fd in 0..<maxFD { if fcntl(fd, F_GETFD) != -1 { count += 1 } } return count } With this code, we obtained the following data: On a device with iOS 26 Beta 1, 2, or 3: FD LIMIT: soft: 256, hard: 9223372036854775807 Open file descriptors BEFORE Firebase.configure(): 256 On a device with iOS 18: FD LIMIT: soft: 256, hard: 9223372036854775807 Open file descriptors BEFORE Firebase.configure(): 57 In the case of the device running iOS 26 beta, the app crashes when executing Firebase.configure() because it cannot open the plist file, even though it can be found at the correct path — meaning the OS locates it. To confirm this was indeed the issue, we used the following code to close FDs before proceeding with Firebase configuration. By placing a breakpoint just before Firebase.configure() and running the following LLDB command: expr -l c -- for (int fd = 180; fd < 256; fd++) { (int)close(fd); } This released the FDs, allowing Firebase to proceed with its configuration as expected. However, the app would later crash again after hitting the soft limit of file descriptors once more. Digging deeper, we used this code to try to identify which FDs were being opened and causing the soft limit to be exceeded: func checkFDPath() { var r = rlimit() if getrlimit(RLIMIT_NOFILE, &r) == 0 { print("FD LIMIT: soft: \(r.rlim_cur), hard: \(r.rlim_max)") for fd in 0..<Int32(r.rlim_cur) { var path = [CChar](repeating: 0, count: Int(PATH_MAX)) if fcntl(fd, F_GETPATH, &path) != -1 { print(String(cString: path)) } } } } We ran this command at the very beginning of the didFinishLaunching method in the AppDelegate. On iOS 26, the log repeatedly showed Cryptexes creating a massive number of FDs, such as: /dev/null /dev/ttys000 /dev/ttys000 /private/var/mobile/Containers/Data/Application/AEE414F2-7D6F-44DF-A6D9-92EDD1D2B014/Library/Application Support/DTX_8.191.1.1003.sqlite /private/var/mobile/Containers/Data/Application/AEE414F2-7D6F-44DF-A6D9-92EDD1D2B014/Library/Caches/KSCrash/MyAppScheme/Data/ConsoleLog.txt /private/var/mobile/Containers/Data/Application/AEE414F2-7D6F-44DF-A6D9-92EDD1D2B014/Library/HTTPStorages/mybundleId/httpstorages.sqlite /private/var/mobile/Containers/Data/Application/AEE414F2-7D6F-44DF-A6D9-92EDD1D2B014/Library/HTTPStorages/mybundleId/httpstorages.sqlite-wal /private/var/mobile/Containers/Data/Application/AEE414F2-7D6F-44DF-A6D9-92EDD1D2B014/Library/HTTPStorages/mybundleId/httpstorages.sqlite-shm /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.01 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.11 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.12 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.13 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.14 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.15 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.16 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.17 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.18 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.19 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.20 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.21 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.22 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.23 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.24 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.25 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.26 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.29 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.30 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.31 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.32 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.36 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.37 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.38 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.39 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.40 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e … This repeats itself a lot of times. … /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.36 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.37 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.38 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.39 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.40

Hi everyone, I’m encountering a critical reliability issue with message passing in my Safari Web Extension on iOS 18.4.1 and iOS 18.5. In my extension, I’m using the standard messaging API. The background script sends a message to the content script using browser.tabs.sendMessage(...), and the content script registers a listener via: browser.runtime.onMessage.addListener(handler); This setup has been working reliably in all prior versions of iOS. However, after updating to iOS 18.4.1 and 18.5, I’ve noticed the following behavior: ✅ The content script is successfully injected, and onMessage.addListener is registered (I see logging confirming this). ✅ The background script sends the message using the correct tabId (also confirmed via logs). ❌ The content script’s onMessage listener is not consistently triggered. ⚠️ This issue is intermittent, sometimes the message is received, sometimes it is silently dropped. ❌ No exceptions or errors are thrown in either script, the message appears to be sent, but not picked up from the content script message listener.

Hello! I have a quirky situation that I am looking for a solution to. The iOS app I am working on needs to be able to communicate with systems that do not have valid root certs. Furthermore, these systems addresses will be sent to the user at run time. The use case is that administrators will provide a self signed certificate (.pem) for the iPhones to download which will then be used to pass the authentication challenge. I am fairly new to customizing trust and my understanding is that it is very easy to do it incorrectly and expose the app unintentionally. Here is our users expected workflow: An administrator creates a public ip server. The ip server is then configured with dns. A .pem file that includes a self signed certificate is created for the new dns domain. The pem file is distributed to iOS devices to download and enable trust for. When they run the app and attempt to establish connection with the server, it will not error with an SSL error. When I run the app without modification to the URLSessionDelegate method(s) I do get an SSL error. Curiously, attempting to hit the same address in Safari will not show the insecure warning and proceed without incident. What is the best way to parity the Safari use case for our app? Do I need to modify the urlSession(_ session: URLSession, didReceive challenge: URLAuthenticationChallenge, completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void) method to examine the NSURLAuthenticationMethodServerTrust? Maybe there is a way to have the delegate look through all the certs in keychain or something to find a match? What would you advise here? Sincerely thank you for taking the time to help me, ~Puzzled iOS Dev

With the new ios 26 beta 3 helps some stabillty and performance issues but most of the liquid glass has been removed or made very frosty look; and it defeats the whole purpose of a big redesign, and even thought the changes are because of readability and contrast complaints it should not take away liquid glass design. I think apple should consider adding a toggle or choice to choose if they would want a more frosted look or a more liquid glass look the the original plan.

With the new ios 26 beta 3 helps some stabillty and performance issues but most of the liquid glass has been removed or made very frosty look; and it defeats the whole purpose of a big redesign, and even thought the changes are because of readability and contrast complaints it should not take away liquid glass design. I think apple should consider adding a toggle or choice to choose if they would want a more frosted look or a more liquid glass look the the original plan.

In iOS26, when using a standalone UITabBar without UITabBarController, the liquid glass blur effect is not applied when scrollable content moves behind the tab bar. However, the blur effect appears correctly when using UITabBarController. Sample Screenshots: When using UITababr When using UITababrController Sample Code: class SimpleTabBarController: UIViewController, UITabBarDelegate { let tabBar = UITabBar() let redItem = UITabBarItem(title: "Red", image: .add, tag: 0) let blueItem = UITabBarItem(title: "Blue", image: .checkmark, tag: 1) override func viewDidLoad() { super.viewDidLoad() view.backgroundColor = .white tabBar.items = [redItem, blueItem] tabBar.selectedItem = redItem tabBar.delegate = self tabBar.translatesAutoresizingMaskIntoConstraints = false let tableContainerView = TableContainerView() view.addSubview(tableContainerView) tableContainerView.translatesAutoresizingMaskIntoConstraints = false NSLayoutConstraint.activate([ tableContainerView.topAnchor.constraint(equalTo: view.topAnchor), tableContainerView.leadingAnchor.constraint(equalTo: view.leadingAnchor), tableContainerView.trailingAnchor.constraint(equalTo: view.trailingAnchor), tableContainerView.bottomAnchor.constraint(equalTo: view.bottomAnchor) ]) view.addSubview(tabBar) NSLayoutConstraint.activate([ tabBar.leadingAnchor.constraint(equalTo: view.leadingAnchor), tabBar.trailingAnchor.constraint(equalTo: view.trailingAnchor), tabBar.bottomAnchor.constraint(equalTo: view.bottomAnchor) ]) }

I'm attempting to distribute a proprietary application (not released to the app store), and everytime I confirm the either validate or distribute in anyway Xcode crashes with no error message. I've seen a few posts regarding the agreements, but I have the free app agreement signed so that can't be it. I haven't had a problem previously with not having the paid agreement signed, but now i'm running into this issue. I've confirmed my ad-hoc profile and cert are all good and valid, so I'm unsure what else could be causing this issue. Not even getting prompted to submit a crash report.

Hello, I am testing an existing app on iOS 26. It hast an UITableViewController that shows a custom context menu preview using previewForHighlightingContextMenuWithConfiguration and providing an UITargetedPreview. Something along the lines like this (shortened): public override func tableView(_ tableView: UITableView, previewForHighlightingContextMenuWithConfiguration configuration: UIContextMenuConfiguration) -> UITargetedPreview? { guard let indexPath = configuration.identifier as? NSIndexPath else { return nil } let previewTableViewCell = self.getCell(for: indexPath) var cellHeight = self.getCellHeight(for: indexPath, with: maxTextWidth) // Use the contentView of the UITableViewCell as a preview view let previewMessageView = previewTableViewCell.contentView previewMessageView.frame = CGRect(x: 0, y: 0, width: maxPreviewWidth, height: cellHeight) previewMessageView.layer.masksToBounds = true let accessoryView = ... let totalAccessoryFrameHeight = accessoryView.frame.maxY - cellHeight var containerView = UIView(frame: .init(x: 0, y: 0, width: Int(maxPreviewWidth), height: Int(cellHeight + totalAccessoryFrameHeight))) containerView.backgroundColor = .clear containerView.addSubview(previewMessageView) containerView.addSubview(accessoryView) // Create a preview target which allows us to have a transparent background let previewTarget = UIPreviewTarget(container: tableView, center: ...) let previewParameter = UIPreviewParameters() // Remove the background and the drop shadow from our custom preview view previewParameter.backgroundColor = .clear previewParameter.shadowPath = UIBezierPath() return UITargetedPreview(view: containerView, parameters: previewParameter, target: previewTarget) } On iOS 18 and below this works fine and buttons that are included in the accessoryView are tapable by the user. Now on iOS 26 the preview is shown correct (although it has a bit weird shadow animation), but tapping a button of the accessoryView now closes the context menu, without triggering the touchUpInside event anymore. For me it feels like an unintended change in behavior, but maybe I am missing something? Filed FB18644353

In e-sim after before some time not richeble the internet it was the big issue for me

Immediately after installing iOS 26 on my iPhone 14 Pro, my phone display stopped working. It's not responding to touch, but I can see it charging. It also wakes the screen whenever I pick it up, but it's not touching at all. What do I do, or do I have to downgrade?

Hi, In my apps, the recent iOS 16.0 beta 7 (20A5356a) broke the .timer DateStyle property of the Text view, in a SwiftUI widget. In previous OS and beta, Text(Date(), style: .timer) was correctly displaying an increasing counter. In iOS 6.0 beta 7, Text(Date(), style: .timer) does not update anymore, (and is offset to the left). The other DateStyle (like .offset, .relative, ...) seems to update correctly. Anyone noticed that (very specific) problem ?

I'm trying to update an old iOS app to use the UIScene architecture, and I've run into a problem I'm hoping somebody can help me fix. When I try to share a file with my app by AirDrop from another device, the URL that I'm getting from the urlContexts argument does not exist on the device. Here's the code I'm using in my SceneDelegate class to get things going: func scene(_ scene: UIScene, openURLContexts URLContexts: Set<UIOpenURLContext>) { guard let url = URLContexts.first?.url else { os_log("URL in %@ is nil", #function) return } // check that it's the proper file type guard url.pathExtension == fileExtension.replacingOccurrences(of: ".", with: "") else { return } ... } When I set a breakpoint after populating the url property, checking its existence in the Xcode Console reveals the enclosing folder does not exist: (lldb) po url.path /private/var/mobile/Library/Mobile Documents/com~apple~CloudDocs/Downloads/Seattle Times 2025-04-30 10.dbsud (lldb) po FileManager.default.fileExists(atPath: URL(filePath: "/private/var/mobile/Library/Mobile Documents").path) true (lldb) po FileManager.default.fileExists(atPath: URL(filePath: "/private/var/mobile/Library/Mobile Documents/com-apple-CloudDocs/Downloads").path) false (lldb) po FileManager.default.fileExists(atPath: URL(filePath: "/private/var/mobile/Library/Mobile Documents/com-apple-CloudDocs/").path) false So when I try to process the file at the provided URL, it fails of course. Any ideas on how I can fix this? This is happening while running the code on an iPad with iOS 18.5 from Xcode 16.4. If it makes a difference, the AirDrop is originated from an iPhone 16 Pro also running iOS 18.5.

As the title states, and it’s extremely frustrating. The floating bar that now appears above the keyboard is cool compared to the built in bar, though it seems to only work when it feels like it. Also the screen seems to have a haze around it, sometimes I cannot read whats needed because of it being blurred and it won’t allow me to navigate to certain things due to the haze being there too. Any way of rolling back my update and going back to my previous iOS?

I am developing a VoIP application that uses NetworkExtension (Local PUSH function) And VoIP(APNs) PUSH. Since iPhone X, iPhones have supported eSIM, allowing for the simultaneous use of a physical SIM and an eSIM. Consequently, users of our VoIP app have requested the ability to lock the network used by the VoIP app to either the eSIM or the physical SIM. Our VoIP app utilizes the network through the socket API. Is there an API in the iOS SDK to lock the network used via sockets to either the eSIM or the physical SIM? In other words, we would like to be able to retrieve the IP address assigned to the eSIM or the physical SIM in advance, and know which IP address is assigned to which SIM. Are there any such APIs available (that are not "Deprecated")

Apple's Wi-Fi Aware demo shows that pairing is required before establishing a connection. Is this pairing mandatory? Can Android devices pair with Apple devices? My Android device strictly supports Wi-Fi Aware 4.0 and I want to achieve interoperability with Apple devices.

I recently upgraded my device from IOS 18.4 to IOS 26. My web extension has disapeared from safari. I can see it in Settings > Apps > Safari > Extensions and when I turn it on and re-open safari. I just get a mesasge that says "{extension name} is no longer avaiable". I have tried Manifest V2 and Manifest V3 both yield the same results. The current production extension bundled with the IOS app has the same problem. I can no longer use or test my own extension !? Help please !

I'm currently finding it impossible to get a text filtering extension to be invoked when there's an incoming text message. There isn't a problem with the app/extension because this is the same app and code that is already developed, tested, and unchanged since I last observed it working. I know if there's any history of the incoming number being "known" then the extension won't get invoked, and I used to find this no hindrance to testing previously provided that: the incoming number isn't in contacts there's no outgoing messages to that number there's no outgoing phone calls to the number. This always used to work in the past, but not anymore. However, I've ensured the incoming text's number isn't in contacts, in fact I've deleted all the contacts. I've deleted the entire phone history, incoming and outgoing, and I've also searched in messages and made sure there's no interactions with that number. There's logging in the extension so I can see its being invoked when turned on from the settings app, but its not getting invoked when there's a message. The one difference between now and when I used to have no problem with this - the phone now has iOS 18.5 on it. Its as if in iOS 18.5 there ever was any past association with a text number, its not impossible to remove that association. Has there been some known change in 18.5 that would affect this call filtering behavior and not being able to rid of the incoming message caller as being "known" to the phone? Update I completely reset the phone and then I was able to see the the message filter extension being invoked. That's not an ideal situation though. What else needs to be done beyond what I mentioned above in order to get a phone to forget about a message's number and thus get an message filtering extension to be invoked when there's a message from that number?