“Visual Studio Maui IOS”

We're developing a service that requires webtransport support in the browser. Currently, the only browser that doesn't provide support is the IOS version of Safari. Our current way forward for client use is to flag iphone and ipad as non compliant and recommend either desktop use or android. Is there any ballpark date as to when WebTransport will be included in IOS Safari (- webkit supports webtransport)?

I've been rejected a couple of times for Guidelines 5.1.1(i) and 5.1.2(i) regarding third-party AI data sharing consent. Each time, the reviewer states they cannot see the consent prompt, even though it is the first screen displayed on every app launch. My app (GymFusion) uses Anthropic's Claude AI for features like meal scanning, body composition analysis, and workout coaching. Here is exactly what I've implemented: IN-APP CONSENT (embedded in view hierarchy, not a sheet/popup): In my RootView.swift, the consent is a conditional view that blocks the entire app: } else if !consentManager.hasConsented && !consentManager.hasSeenConsent { AIConsentView() } else if auth.isAuthenticated { MainTabView() } The hasSeenConsent flag is reset to false on every app launch in the App's init(), so the consent screen appears on every launch until the user accepts: init() { UserDefaults.standard.set(false, forKey: user_ai_consent_seen) AIConsentManager.shared.hasSeenConsent = false FirebaseApp.configure() } THE CONSE

I encountered an error when trying to rollback context after deleting some model with multiple one-to-many relationships when encountered a problem later in a deleting method and before saving the changes. Something like this: do { // Fetch model modelContext.delete(model) // Do some async work that potentially throws try modelContext.save() } catch { modelContext.rollback() } When relationship is empty - the parent has no children - I can safely delete and rollback with no issues. However, when there is even one child when I call even this code: modelContext.delete(someModel) modelContext.rollback() I'm getting a fatal error: SwiftData/ModelSnapshot.swift:46: Fatal error: Unexpected backing data for snapshot creation: SwiftData._FullFutureBackingData I use ModelContext from within the ModelActor but using mainContext changes nothing. My ModelContainer is quite simple and problem occurs on both in-memory and persistent storage, with or without CloudKit database being enabled. I can isolate the issue in test e

I'm building a Capacitor iOS app with a plain element playing an MP4 file inline. I want Picture-in-Picture to activate automatically when the user goes home — swipe up from the bottom edge of the screen (on an iPhone with Face ID) or press the Home button (on an iPhone with a Home button). Fullscreen → background works perfectly — iOS automatically enters Picture-in-Picture. But I need this to work from inline playback without requiring the user to enter fullscreen first. Setup // AppDelegate.swift let audioSession = AVAudioSession.sharedInstance() try? audioSession.setCategory(.playback, mode: .moviePlayback) try? audioSession.setActive(true) UIBackgroundModes: audio in Info.plist allowsPictureInPictureMediaPlayback is true (Apple default) iOS 26.3.1, WKWebView via Capacitor What I've tried 1. autopictureinpicture attribute WKWebView doesn't honor this attribute from inline playback. It only works when transitioning from fullscreen. 2. requestPictureInPicture() on visibilitych

I’m seeing a visual glitch with toolbar buttons when building with Xcode 26 for iOS 26. During transitions (both pushing in a NavigationStack and presenting a .sheet with its own NavigationStack), the toolbar button briefly flashes the wrong background colour (black in dark mode, white in light mode) before animating to the correct Liquid Glass appearance. This happens even in a minimal example and only seems to affect system toolbar buttons. A custom view with .glassEffect() doesn’t have the issue. I’ve tried: .tint(...), UINavigationBarAppearance/UIToolbarAppearance, and setting backgrounds on hosting/nav/window but none of those made any difference. Here’s a minimal reproducible example: import SwiftUI struct ContentView: View { @State private var showingSheet = false var body: some View { NavigationStack { List { NavigationLink(Push (same stack — morphs)) { DetailView() } Button(Sheet (separate stack — flashes)) { showingSheet = true } } .navigationTitle(Root) .scrollContentBackground(.h

Hi Apple Developer Support, We are reaching out to request guidance on a testing constraint we have encountered related to iOS Universal Links and Associated Domains entitlements. As part of aligning with updated recommendations from our authentication provider, we have transitioned our mobile apps to use HTTPS redirect callbacks (Universal Links) instead of custom URI schemes. This works as expected in production and on real physical devices. However, we are encountering a significant issue in our cloud-based device testing environment. When our testing platform re-signs the app to run it on their infrastructure, the re-signing process strips the Associated Domains entitlement from the app bundle. As a result, iOS no longer honors our Universal Links, which breaks the authentication redirect flow — the callback cannot route back into the app after the user authenticates. We have identified a potential workaround that would involve disabling app re-signing in the testing platform, but this r

My team is evaluating an iOS companion app for our own network-connected device, and we want to understand whether the planned architecture would likely create an App Review problem under Guideline 2.5.17. Our situation is: We are building our own device and our own companion app. We do not intend to market the device as a Matter-certified device initially. We do not intend to support Apple Home or broad third-party Matter ecosystem interoperability in the first release. We are under a tight schedule and are considering reusing Matter/CSA-derived libraries, data models, and protocol concepts internally to reduce engineering effort and move faster toward eventual certification. Our current understanding is that there are already many iOS apps that communicate with LAN-connected devices using proprietary protocols, so our initial assumption is that a vendor-specific local-network device workflow should generally be acceptable. The point we are trying to clarify is whether that changes if the i