Summary: Content scripts injected via manifest continue to receive and respond to chrome.tabs.sendMessage() calls even after the user has navigated away from the original page, causing messages intended for the current tab to be handled by zombie contexts from previous pages. Environment: Safari/iOS Version: 18.5 Extension Manifest: Version 3 Expected Behavior: When a user navigates from Page A to Page B: Page A's content script context should be destroyed. chrome.tabs.sendMessage(currentTabId, message) should only reach Page B's content script Only Page B should be able to respond to action button clicks (or other background to content messages). Actual Behavior: When navigating from Page A to Page B: Page A's content script context persists as a "zombie". chrome.tabs.sendMessage(currentTabId, message) reaches zombie context instead of the Page B's one. Hence, it looks like the extension is broken because the content script does not respond to the background messages. Details: Tab ids are properly recognized by both background and content script The problem does not always occur; it occurs on random occasions. It's quite easy to have it reproduced. It can be reproduced easier if user clicks ext icon during site loading (before it fully loaded), triggering ActionClick (ext icon click) event and then sending a msg upon it to the content script Regardless of whether the content script is injected into the tab using manifest.json, registerContentScripts, or executeScript, the problem is still there Once the problem occurs, e.g. user is on macys.com but zombie injected content script believes it's google.com (a previous page), even refreshing the tab doesnt change anything - zombie context is still there (thinking it's still google.com) . Changing a domain to something completely different one could help though. Then going back to macys.com could still lead to the described issue. A zombie content script does not have access to the page's console function and others. Example communication Sending following message from the background to the content script using chrome.tabs.sendMessage() { "tab": { "id": 155, "active": true, "url": "https://www.macys.com/", "title": "Macys.com" } } Results in the content-script zombie context response (the url is taken from the window.location.href) "message": { "type": "ActionClicked", "data": {} }, "response": { "data": { "windowUrl": "https://www.google.com/", "contentReached": true, "timestamp": "1,753,138,945,272", } } }

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.

navigator.permissions.query -> permissionStatus.onchange is Supposed to listen to the event of a change in permissions in the browser settings. This works for all browsers, but in Safari for iOS and MacOS this seems to be broken in the currently recent versions 17.x Example: navigator.permissions.query({ name: 'notifications' }).then((permissionStatus) => { permissions = permissionStatus.state; // this value gets set correctly permissionStatus.onchange = () => { // This will not get executed when permissions have been changed // within the safari settings app, or iOS Settings for PWA or Safari }; }); Can someone from Apple's Webkit Team please comment on this? Thank you. T.

I'm developing a web extension for Safari on iOS using MV3. The extension is working fine in Chrome, but in Safari I experience some seemingly random issues. I would like to debug it, but here is my problem. I have my iPhone connected via cable to Mac, and it works fine with XCode, so I assume this part is OK. I open Safari or Safari Tech Preview (doesn't matter) on my Mac, developers options are enabled, and in the Develop menu, under my iPhone section, there are things I can debug. There is an entry "[Ext name] - Extension Service Worker" but when I click it, it's empty. Web inspector pops up, but there are no network requests, no logs, nothing. I know the extension is working, because I can stream log to my HTTP server, but I don't see them here at all. I can use console to trigger commands like chrome.storage.local.get(null, console.log) and it shows my local store, so why I don't see any logs? Also, the background script is not visible in the Sources tab, just one weird request: navigator.serviceWorker.register('safari-web-extension://E3449EA7-EC25-4696-8E6C-[ID HERE]/background.js'); </script> Any ideas what went wrong? The entire team of 4 people has the same issue and we can't move forward because of that. Also, the Develop => Service workers or any other menu section doesn't show my service worker. Logs for websites running on my phone are visible and in general web inspector for them works fine.

Hello Apple Developer Community, I'm experiencing an issue with PDF link interaction in WKWebView that appears to be specific to iOS 26. Problem Description: I'm loading a PDF in WKWebView.The links may vary widely and are not necessarily DPF, so I need to load them using WKWebView. On iOS versions prior to 26, links within the PDF are clickable and work correctly. On iOS 26, the same links are not clickable (no response when tapped). Expected Behavior: PDF links should remain clickable and functional across all iOS versions. What I've Tried: Tested opening the PDF directly in Safari on iOS 26 - links still not clickable This suggests the issue might be related to changes in the system's PDF rendering engine Reproduction Steps: Load the PDF URL in WKWebView Navigate to page 12 Attempt to tap the link Environment: Test Devices: iPhone 15(26.0 ) / iPhone 16 Pro Max(18.0.1 ) Xcode: 16.2 Questions: Is this an intentional change in iOS 26's PDF handling or WKWebView? If so, is there a new API or configuration to restore link interactivity? Any guidance or suggestions would be greatly appreciated!

Hey Guys My PWA video playback and even youtube videos stopped working after updating iOS to 26.0.1. The video thumnails appear fine and if i try to play the video, it remains stuck. If i restart the phone, the video plays for a second in the PWA and then stops again and entire app gets stuck. Request apple team to fix this issue at the earliest. This is hampering all my iOS users who install the PWA on their device homescreen and use it as app. FYI strangely EVERYTHING WORKS FINE ON iOS SAFARI browser including videos playback If i open it as a web app. so this seems like a specific PWA issue on latest ios 26.0.1

Hi all, Chrome has it already - animation-timeline aka scroll-animations. I can nowhere find any informations on what's the status in Safari/Webkit. Seems like they do not have it on the agenda at all? Does anyone know anything - I wanted to push a feature request for that - but also seem there is no feature request list anymore for webkit. See: https://www.w3.org/TR/scroll-animations/ Cheers and kind regards!

I’m observing an intermittent issue with a Safari Web Extension on macOS 15.7 (Safari 26.0.1). After installing the Safari extension from the App Store, it appears under Settings → Extensions, but the enable checkbox is often missing. Sometimes, after restarting Safari multiple times, the checkbox becomes visible. However, even when I manage to enable the extension, reopening Safari often hides the checkbox again. However, I don't see this issue in safari 26 with macOS 26 I’d like to know if this behavior is a known issue with Safari 26 or macOS 15.7? Any workaround available?

I'm a web developer of WebRTC based web app for video and audio calls. After updating to iOS 26.1 beta I noticed, that my app can't use microphone anymore. When I'm calling to getUserMedia with audio set to true, Safari returns error "No AVAudioSessionCaptureDevice device". Other WebRTC demo apps also can't access microphone on this firmware. And maybe it's connected somehow, but safari can't detect connected AirPods Pro 2 as an input device. So, this bug brakes any WebRTC app, that uses microphones.

hi Testing on OS26 Public Beta 6. In Safari, if you enter x homepage and scroll, the tab bar sticks to the bottom and moves. Make the keyboard appear in the search window When scrolling down on the Safari homepage again, the issue of not being able to stick to the bottom appears. Is it because the liquid glass UI was applied this time? and safari bug? Please let me know if I'm missing anything

Adding Stack Trace for your reference: thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BREAKPOINT (code=1, subcode=0x1a6efe5b8) frame #0: 0x00000001a6efe5b8 WebCoreWebCore::BaseAudioSharedUnit::BaseAudioSharedUnit() + 668 frame #1: 0x00000001a6efe044 WebCoreWebCore::CoreAudioSharedUnit::singleton() + 80 frame #2: 0x00000001a9521fe4 WebCoreWebCore::CoreAudioCaptureSource::create(WebCore::CaptureDevice const&, WebCore::MediaDeviceHashSalts&&, WebCore::MediaConstraints const*, std::__1::optional<WTF::ObjectIdentifierGeneric<WebCore::PageIdentifierType, WTF::ObjectIdentifierMainThreadAccessTraits<unsigned long long>, unsigned long long>>) + 360 frame #3: 0x00000001a94f180c WebCoreWebCore::RealtimeMediaSourceCenter::getUserMediaDevices(WebCore::MediaStreamRequest const&, WebCore::MediaDeviceHashSalts&&, WTF::Vector<WebCore::RealtimeMediaSourceCenter::DeviceInfo, 0ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc>&, WTF::Vector<WebCore::RealtimeMediaSourceCenter::DeviceInfo, 0ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc>&, WebCore::MediaConstraintType&) + 356 frame #4: 0x00000001a94f22cc WebCoreWebCore::RealtimeMediaSourceCenter::validateRequestConstraintsAfterEnumeration(WTF::Function<void (WTF::Vector<WebCore::CaptureDevice, 0ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc>&&, WTF::Vector<WebCore::CaptureDevice, 0ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc>&&)>&&, WTF::Function<void (WebCore::MediaConstraintType)>&&, WebCore::MediaStreamRequest const&, WebCore::MediaDeviceHashSalts&&) + 356 frame #5: 0x00000001a94fb394 WebCoreWTF::Detail::CallableWrapper<WebCore::RealtimeMediaSourceCenter::enumerateDevices(bool, bool, bool, bool, WTF::CompletionHandler<void ()>&&)::$_0, void>::~CallableWrapper() + 164 frame #6: 0x00000001a814bbe8 WebCoreWTF::Detail::CallableWrapper<WebCore::AVCaptureDeviceManager::refreshCaptureDevicesInternal(WTF::CompletionHandler<void ()>&&, WebCore::AVCaptureDeviceManager::ShouldSetUserPreferredCamera)::$_0::operator()()::'lambda'(), void>::call() + 520 frame #7: 0x00000001ab7f1aac JavaScriptCoreWTF::RunLoop::performWork() + 524 frame #8: 0x00000001ab7f1880 JavaScriptCoreWTF::RunLoop::performWork(void*) + 36 frame #9: 0x00000001935e7d0c CoreFoundationCFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION + 28 frame #10: 0x00000001935e7ca0 CoreFoundation__CFRunLoopDoSource0 + 172 frame #11: 0x00000001935e6a24 CoreFoundation__CFRunLoopDoSources0 + 232 frame #12: 0x00000001935e5c64 CoreFoundation__CFRunLoopRun + 840 frame #13: 0x000000019360a730 CoreFoundationCFRunLoopRunSpecific + 572 frame #14: 0x00000001e0fb5190 GraphicsServicesGSEventRunModal + 168 frame #15: 0x0000000196239f34 UIKitCore-[UIApplication _run] + 816 frame #16: 0x0000000196238164 UIKitCore`UIApplicationMain + 336 frame #17: 0x000000010811bec4 AppName.debug.dylibmain at AppDelegate.swift:25:13 frame #18: 0x00000001bae06a58 dyldstart + 5964

Is ServiceWorker supported on WKWebView? As per Mozilla Developer Network(MDN Web) docs[1] its not supported, but our research shows that ServiceWorker becomes available for a domain in WKWebView 1) if the domain is allowlisted in app-bound domains[2] or 2) if app is registered as default browser(this can not be considered for our app as its not a browser). How to enable ServiceWorker on WKWebView? Is adding domain as app-bound domain the right/only way to enable ServiceWorker on WKWebView? We didn't find any official documentation about this. Can WebView get ServiceWorker support by default without enabling app bound domains since that is not an option for our app? Our app needs to support more than 10 domains. Powerful APIs such as JavaScript injection, cookie manipulation, event handlers are by default available to all domains/WebView instances even if App doesn't enable app-bound domains. Is it possible to do same for ServiceWorker? If ServiceWorker can not be supported by default then can Apple provide a feature by which ServiceWorker will be enabled in App for all the domains? Apple enforces maximum of 10 app-bound domains. Is it possible to remove this limit and provide a way to dynamically add to this list at the time of a request? [1] https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorker#browser_compatibility [2] https://webkit.org/blog/10882/app-bound-domains/

This is my first post, so please forgive me if it is to the wrong area. I've been using Tahoe for a few days and, overall, it's very stable. But the one thing that has bothered me to no end is Safari's new behavior with respect to its header (Address bar, Favorite bookmarks bar, tab bar) background color. The web content of the active tab seems to affect everything - and oftentimes makes things completely unreadable - at least in "Dark" mode. For instance, if a web page uses a white background, the Favorites bookmark labels are the same color as the bookmark background, so reading the labels is simply impossible. At other times, they're just very difficult to read. Similarly, it is almost always impossible to tell which tab is the active one - my only workaround is to try 100% brightness....or to just guess. When Apple previously experimented with letting content bleed through to the top, there was a setting for stopping it - but I don't see such a setting anymore. Do you you know of any way to stop this effect?

Our app encountered a new crash since beta5(23A5308g) released last week,and it seems the crash is not solved yet in beta6(23A5318c).The crash stack below `-[UIView _backing_setPosition:] -[UIView setCenter:] -[_UIEditMenuContentPresentation _displayPreparedMenu:titleView:reason:didDismissMenu:configuration:] ___54-[_UIEditMenuContentPresentation _displayMenu:reason:]_block_invoke -[UIEditMenuInteraction _editMenuPresentation:preparedMenuForDisplay:completion:] -[_UIEditMenuContentPresentation _displayMenu:reason:] -[_UIEditMenuContentPresentation displayMenu:configuration:] ___58-[UIEditMenuInteraction presentEditMenuWithConfiguration:]_block_invoke ___80-[UIEditMenuInteraction _prepareMenuAtLocation:configuration:completionHandler:]_block_invoke ___109-[UITextContextMenuInteraction _editMenuInteraction:menuForConfiguration:suggestedActions:completionHandler:]_block_invoke ___107-[UITextContextMenuInteraction _querySelectionCommandsForConfiguration:suggestedActions:completionHandler:]_block_invoke WTF::CompletionHandler<void (WebKit::DocumentEditingContext&&)>::operator()(WebKit::DocumentEditingContext&&) WTF::Detail::CallableWrapper<IPC::Connection::makeAsyncReplyCompletionHandler<Messages::WebPage::RequestDocumentEditingContext, WTF::CompletionHandler<void (WebKit::DocumentEditingContext&&)> >(WTF::CompletionHandler<void (WebKit::DocumentEditingContext&&)>&&, WTF::ThreadLikeAssertion)::{lambda(IPC::Connection*, IPC::Decoder*)#1}, void, IPC::Connection*, IPC::Decoder*>::call(IPC::Connection*, IPC::Decoder*) WTF::Detail::CallableWrapper<WebKit::AuxiliaryProcessProxy::sendMessage(WTF::UniqueRefIPC::Encoder&&, WTF::OptionSetIPC::SendOption, std::__1::optionalIPC::ConnectionAsyncReplyHandler, WebKit::AuxiliaryProcessProxy::ShouldStartProcessThrottlerActivity)::$_1, void, IPC::Connection*, IPC::Decoder*>::call(IPC::Connection*, IPC::Decoder*) IPC::Connection::dispatchMessage(WTF::UniqueRefIPC::Decoder) IPC::Connection::dispatchIncomingMessages() WTF::RunLoop::performWork() WTF::RunLoop::performWork(void*) _CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION ___CFRunLoopDoSource0 ___CFRunLoopDoSources0 ___CFRunLoopRun __CFRunLoopRunSpecificWithOptions _GSEventRunModal -[UIApplication _run] _UIApplicationMain main main.m start

Hello, After upgrading to macOS 26.2, I’ve noticed a significant performance regression when calling evaluateJavaScript in an iOS App running on Mac (WKWebView, Swift project). Observed behavior On macOS 26.2, the callback of evaluateJavaScript takes around 3 seconds to return. This happens not only for: evaluateJavaScript("navigator.userAgent") but also for simple or even empty scripts, for example: evaluateJavaScript("") On previous macOS versions, the same calls typically returned in ~200 ms. Additional testing I created a new, empty Objective-C project with a WKWebView and tested the same evaluateJavaScript calls. In the Objective-C project, the callback still returns in ~200 ms, even on macOS 26.2. Question Is this a known issue or regression related to: iOS Apps on Mac, Swift + WKWebView, or behavioral changes in evaluateJavaScript on macOS 26.2? Any information about known issues, internal changes, or recommended workarounds would be greatly appreciated. Thank you. Test Code Swift class ViewController: UIViewController { private var tmpWebView: WKWebView? override func viewDidLoad() { super.viewDidLoad() // Do any additional setup after loading the view. setupUserAgent() } func setupUserAgent() { let t1 = CACurrentMediaTime() tmpWebView = WKWebView(frame: .zero) tmpWebView?.isInspectable = true tmpWebView?.evaluateJavaScript("navigator.userAgent") { [weak self] result, error in let t2 = CACurrentMediaTime() print("[getUserAgent] \(t2 - t1)s") self?.tmpWebView = nil } } } Test Code Objective-C - (void)scene:(UIScene *)scene willConnectToSession:(UISceneSession *)session options:(UISceneConnectionOptions *)connectionOptions { NSTimeInterval startTime = [[NSDate date] timeIntervalSince1970]; WKWebView *webView = [[WKWebView alloc] init]; dispatch_async(dispatch_get_main_queue(), ^{ [webView evaluateJavaScript:@"navigator.userAgent" completionHandler:^(id result, NSError *error) { NSTimeInterval endTime = [[NSDate date] timeIntervalSince1970]; NSLog(@"[getUserAgent]: %.2f s", (endTime - startTime)); }]; }); }

Hi Apple engineers! We are making an iOS browser and are planing to deliver a feature that allows enterprise customers to use a MAM key to set a PAC file for proxy. It's designed to support unmanaged device so the MDM based solutions like 'Global HTTP Proxy MDM payload' or 'Per-App VPN' simply don't work. After doing some research we found that with WKWebView, the only framework allowed on iOS for web browsing, there's no API for programmatically setting proxy. The closes API is the WKURLSchemeHandler, but it's for data management not network request interception, in other word it can not be used to handle HTTP/HTTPS request well. When we go from the web-view level to the app level, it seems there's no API to let an app set proxy for itself at an app-level, the closest API is Per-App VPN but as mentioned above, Per-App VPN is only available for managed device so we can't use that as well. Eventually we go to the system level, and try to use Network Extension, but there's still obstacles. It seems Network Extension doesn't directly provide a way to write system proxy. In order to archive that, we may have to use Packet Tunnel Provider in destination IP mode and create a local VPN server to loop back the network traffic and do the proxy stuff in that server. In other word, the custom VPN protocol is 'forward directly without encryption'. This approach looks viable as we see some of the network analysis tools use this approach, but still I'd like to ask is this against App Store Review Guidelines? If the above approach with Network Extension is not against App Store Review Guidelines, I have a further question that, what is the NEProxySettings of NETunnelNetworkSettings for? Is it the proxy which proxies the VPN traffic (in order to hide source IP from VPN provider) or it is the proxy to use after network traffic goes into the virtual private network? If none of the above is considered recommended, what is the recommended way to programmatically set proxy on WKWebView on an unmanaged device (regardless of where the proxy runs, web-view/app/system)?

I want to print the content of a WKWebView. I've done some searching, and many people have struggled with this over the years. Some claimed success, but their solutions don't work for me. One person created images for each pages and printed that, but then if you were to print to PDF, you'd get a PDF containing images rather than text. If I just call the printView(_:)) method of the view, I get blank pages. With the following more elaborate code, I get a partial printout, 11 out of what should be about 13 pages. let info = NSPrintInfo.shared info.topMargin = 72.0; info.bottomMargin = 72.0; info.leftMargin = 72.0; info.rightMargin = 72.0; info.isVerticallyCentered = false; info.isHorizontallyCentered = false; info.horizontalPagination = .fit; info.verticalPagination = .automatic; let printOp = webView!.printOperation( with: info ) printOp.canSpawnSeparateThread = true printOp.view?.frame = NSMakeRect( 0, 0, info.paperSize.width, info.paperSize.height ) printOp.runModal(for: webView.window!, delegate: self, didRun: nil, contextInfo: nil ) When I run the above under the debugger, I see console messages saying CGContextClipToRect: invalid context 0x0. Once the print dialog appears, if I touch (but not change) the selected printer, then the page count changes to the correct value.

We are using WebKit in our app and recently started noticing a crash occurring on iOS 17 and earlier versions. The crash log shows the following error: Thread 0 Crashed: 0 WebKit 0x00000001a38593cc WebKit::WebPageProxy::updateActivityState(WTF::OptionSet<WebCore::ActivityState>) + 220 (WebPageProxy.cpp:2544) 1 WebKit 0x00000001a39cb1e0 WebKit::WebPageProxy::dispatchActivityStateChange() + 132 (WebPageProxy.cpp:2653) 2 WebKit 0x00000001a3f541f8 WTF::Detail::CallableWrapper<WebKit::WebPageProxy::scheduleActivityStateUpdate()::$_5::operator()() const::'lambda'(), void>::call() + 52 (Function.h:53) 3 JavaScriptCore 0x00000001a48317ec void WTF::dispatchWorkItem<WTF::(anonymous namespace)::DispatchWorkItem>(void*) + 60 (WorkQueueCocoa.cpp:48) 4 libdispatch.dylib 0x00000001964f5dd4 _dispatch_client_callout + 20 (object.m:576) 5 libdispatch.dylib 0x00000001965045a4 _dispatch_main_queue_drain + 988 (queue.c:7898) 6 libdispatch.dylib 0x00000001965041b8 _dispatch_main_queue_callback_4CF + 44 (queue.c:8058) 7 CoreFoundation 0x000000018e623710 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 16 (CFRunLoop.c:1780) 8 CoreFoundation 0x000000018e620914 __CFRunLoopRun + 1996 (CFRunLoop.c:3149) 9 CoreFoundation 0x000000018e61fcd8 CFRunLoopRunSpecific + 608 (CFRunLoop.c:3420) 10 GraphicsServices 0x00000001d34d01a8 GSEventRunModal + 164 (GSEvent.c:2196) 11 UIKitCore 0x0000000190c5890c -[UIApplication _run] + 888 (UIApplication.m:3713) 12 UIKitCore 0x0000000190d0c9d0 UIApplicationMain + 340 (UIApplication.m:5303) After investigating, we found that this crash was addressed in this https://github.com/WebKit/WebKit/pull/24778 WebKit PR. However, our app is still crashing for users on older iOS versions where this fix is not available. Is there a known workaround to prevent this crash on affected iOS versions? Any guidance would be greatly appreciated.

I'm testing web extension to safari on iOS. I've built and added extension application to simulator, but on safari settings shows no extensions. I'm using Xcode 16.3 beta 2 with Simulator iOS 18.4 (22E5216h), tested on iPhone 16. https://app.screencast.com/oUq4EMonmfT7u https://app.screencast.com/MCquvHzmZi8QS

This is my first time to post on this forum. If there are something we didn't notice, please tell me. Thanks. Background We're using canvas to provide a web component to marketing. https://demo.mescius.jp/spreadjs/BenchmarkSample/ Problem Recently we have met an issue from customer. He is using iPad 10th to access the web component but when he tries to scroll it and it's very slow on iPad 10th. His iPad OS version is 17.7 and this issue also can be reproduced on our iPad 10th with iPad OS 18.0.1. But if we use iPad 9th with iPad OS 17.7 and 18.0.1, things are fine and there isn't any performance issue. We developer took some time investigating and found it's because of iPad 10th's safari takes longer time to paint each frame. On iPad 9th, it needs nearly 10ms to paint each frame. But on iPad 10, it needs nearly 70ms to paint each frame. Also we can provide simple code for you to check the different. We tried to simulate the repaint when user is scrolling. You can see on iPad 9th, it will be 2~3ms but on iPad 10th, it will be more than 10ms for each frame. test-ipad10.html It has been happening on iPad 10th only with iPad OS 17.6/17.7/18.0. This will be a big problem for us because it means on the iPad 10th (the latest iPad, non Pro or Air), it can't be used. Question Is there anyone knowing similar issue with this one? And do you know how to solve it on iPad 10?