Search results for

Visual Studio Maui IOS

105,652 results found

Post

Replies

Boosts

Views

Activity

App Intent Parameter (AppEntity) not registering
I'm currently testing this on a physical device (12 Pro Max, iOS 26). Through shortcuts, I know for a fact that I am able to successfully trigger the perform code to do what's needed. In addition, if I just tell siri the phrase without my unit parameter, and it asks me which unit, I am able to, once again, successfully call my perform. The problem is any of my phrases that I include my unit, it either just opens my application, or says I can't understand Here is my sample code: My Entity: import Foundation import AppIntents struct Unit: Codable, Identifiable { let nickname: String let ipAddress: String let id: String } struct UnitEntity: AppEntity { static var typeDisplayRepresentation: TypeDisplayRepresentation { TypeDisplayRepresentation( name: LocalizedStringResource(Unit, table: AppIntents) ) } static let defaultQuery = UnitEntityQuery() // Unique Identifer var id: Unit.ID // @Property allows this data to be available to Shortcuts, Siri, Etc. @Property var name: String // By not including @Proper
1
0
51
2w
Reply to Background GPU access in iOS 26 for iPhones
When we tried using this feature, we were not able to get it to work on iOS 26. We stumbled upon this ticket (https://developer.apple.com/forums/thread/797538?answerId=854825022#854825022) in the Apple Developer forum, in which possibly an Apple engineer claims it is supported ONLY for iPadOS 26. That engineer would be me, and yes, what I said there is correct. Background GPU access is currently only available on iPads. 96% of the users are on iPhone (compared to iPad), and if we refer to the official documentation above, it claims that this feature should work on iOS 26. What the documentation says is that the APIs themselves are available on iOS and iPadOS and that background GPU access is not available on all devices, both of which are true. This both simplifies the implementation on both platforms and allows for future API evolution without requiring major API revision. This is the same basic pattern most of our APIs use when functionality is only available on some hardware. __
2w
Reply to File Provider UI extension unsupported on Vision OS
my current File Provider UI code is based on UIKit (coming from iOS) so that is why I started with visionOS. Which is not really encouraging yet :-) Does your current iOS file provier adopt NSFileProviderReplicatedExtension yet? If not, you might consider doing that. With NSFileProviderReplicatedExtension, you can create a file provider that supports both iOS and macOS, as shown in the mentioned sample code, and hence don't need to concern macCatalyst. Best, —— Ziqiao Chen  Worldwide Developer Relations.
2w
watchOS app with @Published properties fails to compile in Xcode 26.0.1 - "missing import of defining module 'Combine'
I'm developing a watchOS companion app for my iOS app in Xcode 26.0.1 on macOS Sequoia. The watch app uses a simple ObservableObject class with @Published properties for state management, which compiles fine for iOS but fails for the watchOS target. Error: Initializer 'init(wrappedValue:)' is not available due to missing import of defining module 'Combine' Code: swiftimport SwiftUI import WatchConnectivity import Combine // Added explicitly class WatchConnectivityProvider: NSObject, ObservableObject { @Published var distance: Double = 0 @Published var isActive: Bool = false // Additional @Published properties... } Environment: Xcode 26.0.1 (17A400) macOS Sequoia watchOS deployment target: 11.0 Apple Watch Series 11 running watchOS 11.6.1 What I've tried: Adding import Combine explicitly Cleaning build folder Verifying target membership This same code pattern works in the iOS target Is @Published / Combine supported differently in watchOS under Xcode 26? This code worked in previous
0
0
56
2w
Some SF Symbol effects cause SF Symbol to not draw.
I seem to be having an issue where certain symbol effect animations are not working. Using symbol effect .appear, .drawOn .drawOff seems to cause the symbol to not display at all. Am I using this code correctly if I want to have a simple animate repeatedly on display? Specifically, modifying the Multiplatform app template in xcode: Image(systemName: ellipsis) .font(.title) .foregroundColor(.blue) .symbolEffect(.drawOn.byLayer, options: .repeat(.continuous)) I'm currently on the latest release on Xcode/macOS and iOS/macOS on client. Both iOS and macOS seem affected. The project is multiplatform and only support macOS/iOS 26.
4
0
149
2w
Reply to File Provider UI extension unsupported on Vision OS
Do you mean that uploading to TestFlight a macOS app with an NSFileProviderReplicatedExtension + a file provider UI extension triggers the same error? That will be an issue in the app submission process, because these extensions are supported on macOS, as discussed here. I haven't tested this with macOS (yet). What I meant is that the two documents I listed before have the same contradiction for macOS as for visionOS. I am not sure if the availability of the sample code makes it more official. I mean, that page lists Mac Catalyst as supported while FPUIActionExtensionViewController.h states FPUI_AVAILABLE(ios(11.0), macos(10.15)) API_UNAVAILABLE(macCatalyst) I'll probably try this for macOS at some point in the future as the app is also available on macOS (with NSFileProviderReplicatedExtension), but my current File Provider UI code is based on UIKit (coming from iOS) so that is why I started with visionOS. Which is not really encouraging yet :-) From a developer's viewpoint the issue is pre
2w
Reply to AppIntents don't show up in Shortcuts app when in SPM package
Figured it out. For anyone who was following the instructions at the end of the WWDC 2025 video on App Intents: It appears AppIntentsPackage definitions are only required when you have an AppEntity conformances to define across package boundaries. AppIntents themselves are automatically discovered in any package or target, and defining AppIntentsPackage could result in duplicate metadata for AppIntents in the bundle, resulting in the OS being unable to resolve the AppIntent to use at runtime. So if all you have is AppIntents to share across the app bundle and a widget extension for example, you do not need to define AppIntentsPackage at all. This is a Xcode 26 compiler feature and is retroactive to at least iOS 18.
2w
Reply to How to detect or opt out of iOS app prewarming?
So, let me start by sorting out prewarming: We are running into issues with iOS app prewarming, where the system launches our app before the user has entered their passcode. Prewarming is not why your app is waking up. This forum post goes into this in more detail, however, quoting myself for the most relevant detail: Since late iOS 15, the Prewarm process suspends your app very early in the dyld load process, specifically before ANY 3rd party library (and most of our libraries) can be loaded. By design, your application cannot have ANY effect on that process. Indeed, it's entirely possible for prewarm to have created your process minutes or even hours before ANY of your app’s code actually executed. Prewarming is only what created your app’s process, NOT the reason why your app is actually executing code. That leads to here: On iOS 16+, the ActivePrewarm environment variable doesn’t seem to exist anymore (though older docs and SDKs such as Sentry reference it). Are you sure ModuleI
2w
iOS Safari - Input element is unresponsive when modifying DOM via a touch event (touchstart, touchmove, touchend, etc)
This is a really strange issue on iOS Safari. Under certain conditions a basic input element will not be focusable or show the on screen keyboard. I can reproduce the issue with a very simple HTML file by dynamically adding an anchor element with an href during a touch event. If you add a different element or an anchor without an href, there is no issue. Similarly, if you apply the same listener to a click event there is no issue. Reproducible in iOS Simulator 17.2 and 18.1 This HTML/JS showcases the problem: InputIssue
Topic: Safari & Web SubTopic: General
0
0
147
2w
How to safely switch between mic configurations on iOS?
I have an iPadOS M-processor application with two different running configurations. In config1, the shared AVAudioSession is configured for .videoChat mode using the built-in microphone. The input/output nodes of the AVAudioEngine are configured with voice processing enabled. The built-in mic is formatted for 1 channel at 48KHz. In config2, the shared AVAudioSession is configured for .measurement mode using an external USB microphone. The input/output nodes of the AVAudioEngine are configured with voice processing disabled. The external mic is formatted for 2 channels at 44.1KHz I've written a configuration manager designed to safely switch between these two configurations. It works by stopping AVAudioEngine and detaching all but the input and output nodes, updating the shared audio session for the desired mic and sample-rates, and setting the appropriate state for voice processing to either true or false as required by the configuration. Finally the new audio graph is constructed by attaching appropriate nod
0
0
60
2w
Present confirmationDialog from swipeActions in List
Hello, We use the .confirmationDialog() view modifier to present an alert when deleting an item in a list. Prior to iOS 26, this dialog appeared as an action sheet on iPhone. Following WWDC 25, my understanding is that on iOS 26 the dialog should appear as an action sheet over the originating view on iPhone. This is the behavior we observe in the built-in Messages and Mail apps when deleting an item (see the screenshot below). However, when using .confirmationDialog() on iOS 26, the dialog is displayed as a standard popover on iPhone. I haven’t been able to reproduce the new expected behavior. Here's a sample code: struct ContentView: View { @State var data: [String] = [A, B, C] @State var confirmationPresented: Bool = false var body: some View { List { ForEach(data, id: .self) { item in Text(item) .confirmationDialog(Title, isPresented: $confirmationPresented, actions: { Button(action: { }, label: { Text(OK) }) }) .swipeActions { Button(Delete, systemImage: trash, action: { confirm
2
0
144
2w
How to handle CoreNFC session timeout when APDU exchange exceeds 20 seconds?
I’m developing an iOS application using CoreNFC and working with ISO7816 tags. My use case involves exchanging APDU commands with a hardware device, but some operations can take more than 20 seconds. From my testing, I see that: The NFC reader session itself lasts about 60 seconds. But once a tag is connected, the connection seems to drop after ~20 seconds, and I receive a “connection lost” / session invalidated error. My questions are: Is this ~20-second connection window a hard limit enforced by iOS? Is there any way to extend this timeout for long-running APDU operations? If not, what’s the recommended design pattern for handling these scenarios? For example, should I split the process into smaller APDU commands and prompt the user to re-tap when the session times out? Any guidance or best practices for handling long NFC exchanges on iOS would be greatly appreciated.
1
0
66
2w