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?

Hi everyone and Apple support, I’ve built an app that continuously runs and receives temperature data from a sensor. When a threshold is reached, I use Live Activities with the push notification flow to display alerts on the Dynamic Island. The Live Activity and push notification flow work fine in foreground and background states. However, I’m trying to support push-triggered Live Activities when the app is in the terminated state. Since my app rarely terminates, I can’t confirm if the Live Activity push token is generated in that state. It seems like it isn’t, which blocks the Live Activity from starting via push. I tried with both pushtostarttoken and pushtostarttokenupdates. None of them worked. Has anyone dealt with this or found a workaround to ensure the push token is available even when the app is terminated?

When shooting with an iPhone 15 or later, it’s possible to capture HEIC or JPEG images that include gain map information conforming to the ISO 21496-1 standard. However, during image format transcoding, the HEIC codec is able to preserve the ISO 21496-1 gain map. But when converting from HEIC to JPEG, the gain map is transformed into the Apple Gain Map format instead. Is there any solution to this issue?