Visual Studio Maui IOS

Hey Dawich, I'm following a similar implementation and using capacitor with stripe subscriptions in my ios application. I came across the capgo plugin and tried that approach but based on apple guidelines, it seems like we must use the in app purchase natively with Storekit. Were you able to find a solution to this?

@KT_ You can see answer Here https://developer.apple.com/forums/thread/801977?login=true&page=1#860804022 But I'm interested to know if Is there any plan to fix this bug in an upcoming iOS release?

Thank you for your previous response to my question which directed me to the Extra-ordinary Networking documentation. We have thoroughly reviewed this documentation and related articles, but have yet to find a direct solution to the specific problem we are facing. Our VoIP application is currently being operated in a customer environment utilizing an sXGP-SIM (local LTE-SIM). A specific requirement from our customer is to always use the data communication network, rather than the voice call-specific VoLTE network, for establishing SIP and RTP traffic. What we know from our investigations so far: In the customer's sXGP environment, we have confirmed that the VoIP application (client) can successfully connect to the SIP server (server) and conduct VoIP calls (RTP), regardless of whether the connection routes through what might be conceived as a VoLTE network or a general data communication network. Following general best practices, we considered an approach where we do not explicitly call bind() when creating s

The file shown in your screenshot is part of the iOS SDK, so it does not normally have compile errors like this. That indicates that the problem is elsewhere in your build configuration, and this file is an innocent victim of a problem elsewhere. I see a build error that says failed to emit precompiled module, so maybe start there and work backwards. Since your project involves Cocoapods, it's possible that tool's configuration is also adding to this issue, so you should work to determine if their configuration set up by their tool is part of the source here, and if that turns out to be the case, you'll want to get in contact with their support resources. — Ed Ford,  DTS Engineer

Depending on your minimum deployment version, isn't it just the matter of a elimination game with UIDevice.current.name? import SwiftUI struct ContentView: View { var body: some View { VStack { ... } .onAppear(perform: { let device = UIDevice.current print(1 (device.name)) // iPhone 16 Pro print(2 (device.systemName)) // iOS print(3 (device.model)) // iPhone print(4 (NSUserName())) // mobile print(5 (device.description)) // //print(6 (device.model)) // iPhone }) .padding() } }

The brother app went through the review process two days ago. The new app in question went through the review process successfully an hour ago. So why the toolbar item images from Assets.xcassets were miniaturized into 4-by-by tiny images possibly under iOS 26? I have no clue. As a possible remedy, I have created 3 scale versions for each toolbarItem image at the exact sizes (84 px, 56 px, 28 px) as opposed to just one image having the app resize it. I was pretty much prepared to abandon this new app. I'm kind of surprised that it has gone through the review process without a hitch

macOS: 15.6 XCode 26 iOS 26 Steps to Reproduce: Click on Simulator -> Devices-> iPhone 16 (or any other iPhone version). It just crashes

Hi - thanks for the quick response. I'll try to answer as best as I can. Could you tell me more about these watchOS targets? My primary curiosity is how they are able to build successfully even during a normal build, if their dependencies do not support watchOS. I mentioned at the bottom of my original post that our app is [a mixture of] SPM packages and traditional target structure. This is mostly because SPM was introduced after our app was already published and created. We've slowly been migrating old features to SPM, and new features get added to SPM. The reason we love SPM is it introduces modularity for us, and enables greater code sharing. The way we decided to structure SPM within the context of all of our targets is one shared Package.swift file. This is because so many of our targets share the same code, it seemed easier at the time to keep all our various libraries within one SPM package (I hope that makes sense). So our one Package.swift declares all platforms like this: platforms: [ .iOS