Search results for

Visual Studio Maui IOS

105,630 results found

Post

Replies

Boosts

Views

Activity

Illegible navigation title when presenting Map view
When building with the iOS 26 SDK (currently beta 4), the navigation title is often illegible when rendering a Map view. For example, note how the title Choose Location is obscured by the map's text (South America) in the screenshot below: This screenshot is the result of the following view code: import MapKit import SwiftUI struct Demo: View { var body: some View { NavigationStack { Map() .navigationTitle(Text(Choose Location)) .navigationBarTitleDisplayMode(.inline) } } } I tried using the scrollEdgeEffectStyle(_:for:) modifier to apply a scroll edge effect to the top of the screen, in hopes of making the title legible, but that doesn't seem to have any effect. Specifically, the following code seems to produce the exact same result shown in the screenshot above. import MapKit import SwiftUI struct Demo: View { var body: some View { NavigationStack { Map() .scrollEdgeEffectStyle(.hard, for: .top) // ⬅️ no apparent effect .navigationTitle(Text(Choose Location)) .navigationBarTitleDisplayMode(.inline)
7
0
234
1w
Reply to Illegible navigation title when presenting Map view
@T.P: Apple has not responded to my ticket. For iOS 26.0, I've worked around the issue as follows: Original Code import MapKit import SwiftUI struct Demo: View { var body: some View { NavigationStack { Map() .navigationTitle(Text(Choose Location)) .navigationBarTitleDisplayMode(.inline) } } } Updated Code import MapKit import SwiftUI struct Demo: View { var body: some View { NavigationStack { Map() .navigationTitle(Text(Choose Location)) .navigationBarTitleDisplayMode(.inline) .preserveNavigationBarViaSafeAreaInset() } } } private extension View { // HACK: Work around https://developer.apple.com/forums//thread/794351 func preserveNavigationBarViaSafeAreaInset() -> some View { Color.clear .safeAreaInset(edge: .bottom) { self } } } Before After
Topic: UI Frameworks SubTopic: SwiftUI Tags:
1w
Mac Catalyst: Toolbar still appears below title bar, leaving empty safe area
Hi everyone, I’m testing my Catalyst SwiftUI project on iOS 26 / iPadOS 26 / macOS 26. I started with a NavigationSplitView (triple-column) inside a WindowGroup. On iPad it looks great: the toolbar items merge into the navigation bar, with the three traffic lights. But on Mac Catalyst, the app always reserves a blank safe area below the traffic lights, and places the toolbar on a separate line beneath the title bar. That leaves wasted vertical space I don’t want. What I expect (based on Apple’s WWDC session “Elevate the design of your iPad app”): The toolbar should merge into the title bar with the traffic lights, no separate row. Content should extend into the full height of the window. What I get on Mac Catalyst: Title bar + traffic lights at the top. Then a completely separate toolbar row below it. Safe area inset prevents my content from reaching the top of the window. What I’ve tried: .toolbarRole(.automatic), .editor, .browser → no effect. Hiding the title bar via titlebar?.titleVisibility = .h
1
0
201
1w
Torch Freezes Ultra-Wide Camera When Switching Between Wide & Ultra-Wide Lenses (AVFoundation Bug?)
I'm developing an iOS app using AVFoundation for real-time video capture and object detection. While implementing torch functionality with camera switching (between Wide and Ultra-Wide lenses), I encountered a critical issue where the camera freezes when toggling the torch while the Ultra-Wide camera is active. Issue If the torch is ON and I switch from Wide to Ultra-Wide, the camera freezes If the Ultra-Wide camera is active and I try to turn the torch ON, the camera freezes The iPhone Camera app allows using the torch while recording video with the Ultra-Wide lens, so this should be possible via AVFoundation as well. Code snippet DispatchQueue.global(qos: .userInitiated).async { [weak self] in guard let self = self else { return } let isSwitchingToUltraWide = !self.isUsingFisheyeCamera let cameraType: AVCaptureDevice.DeviceType = isSwitchingToUltraWide ? .builtInUltraWideCamera : .builtInWideAngleCamera let cameraName = isSwitchingToUltraWide ? Ultra Wide : Wide guard let selectedCamera = AVCapture
2
0
626
1w
DeclaredAgeRange import error in Mac Catalyst app
Hello, I’m developing an app for both iOS and macOS using Mac Catalyst. On the iOS target, the DeclaredAgeRange framework works fine: I enabled the capability, set the entitlement, and can call the APIs successfully. However, when I build the Mac Catalyst target, I get compile-time errors because DeclaredAgeRange cannot be imported. Environment Xcode 26.0.1 Deployment Target (iOS): 13.0 Mac Catalyst target enabled (same bundle ID, same source code base as iOS version) iOS build works well with DeclaredAgeRange What I tried Added the Declared Age Range capability in Signing & Capabilities for iOS target → works fine. Tried setting Mac Catalyst Deployment Target to macOS 15.0+ and rebuilding → still failed to import. Because it didn’t help, I reverted and removed the separate macOS target setting. On Catalyst, the module simply isn’t available (import DeclaredAgeRange fails). From Apple’s documentation, my understanding is that DeclaredAgeRange should al
5
0
185
1w
RealityKit and USDZ: Winding Order Issue with Negatively Scaled Meshes
Hi all, I've encountered a potential issue with how the winding order of geometry is handled when their transformations involve negative scaling. I created a simple test asset, a single triangle, to demonstrate this. The triangle's vertices are defined in a counter-clockwise (right-handed) winding order, and its transform has a negative scale on the X-axis. According to the OpenUSD specification, this negative determinant in the transformation matrix should effectively reverse the winding order of the geometry: However, any given gprim's local-to-world transformation can flip its effective orientation, when it contains an odd number of negative scales. This condition can be reliably detected using the (Jacobian) determinant of the local-to-world transform: if the determinant is less than zero, then the gprim's orientation has been flipped, and therefore one must apply the opposite handedness rule when computing its surface normals (or just flip the computed normals) for the purposes of hidden surface detectio
3
0
500
1w
Reply to RealityKit and USDZ: Winding Order Issue with Negatively Scaled Meshes
Thanks for following up, and apologies for the delay-- this slipped past me. Here’s a repro asset I wrote that you can test directly: https://github.com/alexchuber/Assets/raw/refs/heads/main/Repros/triangleNegScale.usdz For additional reference, here's the USDA content of the asset (material omitted for clarity): #usda 1.0 ( defaultPrim = Root metersPerUnit = 1 upAxis = Y ) def Xform Root { def Mesh Triangle { matrix4d xformOp:transform = ( (-1, 0, 0, 0), (0, 1, 0, 0), (0, 0, 1, 0), (0, 0, 0, 1) ) uniform token[] xformOpOrder = [xformOp:transform] int[] faceVertexCounts = [3] int[] faceVertexIndices = [0, 1, 2] normal3f[] normals = [(0, 0, 1), (0, 0, 1), (0, 0, 1)] ( interpolation = vertex ) point3f[] points = [(0, 0, 0), (1, 0, 0), (0, 1, 0)] uniform token subdivisionScheme = none } } The steps to reproduce are just: Add the asset to a new Reality Composer Pro scene. Open the same asset in QuickLook on iOS/macOS. Compare the facing direction in both views. You should see that the triangles appear to
Topic: Graphics & Games SubTopic: RealityKit Tags:
1w
Reply to Xcode26 build app with iOS26, UISplitViewController UI issue
Issue still in iOS 26.0.1 Reproduce with the sample app 'DiffableDataSourceSample' from https://developer.apple.com/documentation/uikit/updating-collection-views-using-diffable-data-sources. It runs with UISplitViewController columns populated when compiled for target iOS 18.2. It comes up empty when target is changed to iOS 26. Both builds run on iPad at iOS 26.0.1 My app was patterned on this sample app and is failing to show content in the same way. FB20611981 submitted
Topic: UI Frameworks SubTopic: UIKit Tags:
1w
scenekit is deprecated but realitykit is for special computing what should i use ?
hello i am new to apple ecosystem and development i have some coding experience with c# now i like to develop my game for iphone 16 and up(due to ability to run ai models) but i am having hard time figuring out what to use there is a lot of resources for scene-kit but on its doc page it says its deprecated so i look at the reality-kit docs and tutorials and its strictly tells how to develop for visionos and i am really confused about this since there is no tutorials that shows how to develop a game for ios with reality-kit that does not focus visionos. i just want to develop for iphone 16 and up but i cant find resources focuses at that.
1
0
148
1w
Reply to PCIDriverKit entitlements during development
I was asked to follow up on FB19449747 after this was supposedly fixed, so I did. I can't see a DriverKit PCI Transport (development) entitlement in the list of available Capabilities. Huh. Can you double-check on the portal just to be sure? I've checked on three different teams I have access to, and all of them are showing it. A few things to note: It's actually called DriverKit PCI (development), simply to keep the name length a bit more manageable. I just noticed that it doesn't currently include the extra Development only. Learn more Provisioning support required. label on the portal (I'm working on fixing that). I also noticed that it's offering iOS as a platform, which turned out to be one example of a much broader bug (r.162380702). It turns out that several DriverKit entitlements also include extra platforms, which means they can be included in targets they should not be included with. I don't think including them will actually cause any problems (macOS will just ignore them), but it's defini
Topic: Code Signing SubTopic: Entitlements Tags:
1w