xcode github

Thanks for your post. This is an intriguing question, as I am not an expert in this field. However, there are several engineers here that can assist you and I encourage them to write into this thread, however before I recommend reviewing the comprehensive list of requirements to be considered as the default browser by the system, if you haven’t already. Have you requested the entitlement using the form and have you received an answer? Upon examining the list, you will find numerous requirements: https://developer.apple.com/documentation/Xcode/preparing-your-app-to-be-the-default-browser Additionally, there are restrictions to be adhered to: https://developer.apple.com/documentation/Xcode/preparing-your-app-to-be-the-default-browser#Adhere-to-browser-restrictions Hopefully if you fulfill all requirements, you should be able to see your app listed. Albert Pascual
  Worldwide Developer Relations.

One thing that may be happening here is that your app is launching without the debugger attached, which is where Quinn's points about the system log come in. You can use the macOS Console app to look for your logs once you're using OSLog. Something I like to do in addition to that is configure LLDB to wait to attach until your process is launched. That way, when you use Siri to launch the app, the logs you're expecting will be picked up in the LLDB console. You can configure this in your Xcode scheme, under the Run options. With that configuration set, if you press the Run button in Xcode, the system starts LLDB, but not your app like usual when you press the Run button. You can then launch your app through Shortcuts or Siri, LLDB will now attach automatically, and record all of your OSLog statements inside of Xcode for that launch sequence. — Ed Ford,  DTS Engineer

What version of Xcode do you have? Make sure you are running the latest release so Xcode can provision your devices I would recommend to read the where section of TN3125 Inside Code Signing: Provisioning Profiles, Hope this helps, Albert Pascual
  Worldwide Developer Relations.

Your GitLab instance needs to be accessible to the Xcode Cloud servers without VPN. The network configuration information for the traffic that Xcode Cloud sends to your server is documented in Use a remote source control repository so that you can work with your network or IT teams to configure your firewall with that information. — Ed Ford,  DTS Engineer

Thank you for your post. And thanks for the 2 images showing the behavior for the confirmation dialog: https://developer.apple.com/documentation/swiftui/view/confirmationdialog(_:ispresented:titlevisibility:presenting:actions:)-9ibgk A comprehensive documentation exists regarding Liquid Glass, which may explain certain changes. However, it is noteworthy that controls now exhibit subtle variations in default behavior to align with the updated UI. While you can still anchor or modify controls to achieve your desired outcomes, I personally recommend retaining the new iOS behavior. https://developer.apple.com/documentation/technologyoverviews/adopting-liquid-glass However, if the default behavior of any control does not align with your requirements, I recommend customizing it instead of requesting an enhancement. I see you are using iOS 26.1 simulator, have you downloaded the new Xcode in beta and try the new beta iOS simulators? Albert Pascual
  Worldwide Developer Relations.

You get lost when you try what ? If that may be useful, my advice is to get focused. You have learned the basics (of Swift, SwiftUI, Xcode…). Even if you are not yet an expert, that is good enough for second step. Focus: Imagine a simple app that you would be pleased to use for yourself (think of some pain points you have in your daily life that an app could help solve). Then go and develop the app. Going through all the development steps will let you put in practice what you have learned and then better understand how all this works. For sure you will face issues you cannot manage: ask for help on the forum. Once you app is completed, you will see you have learned a lot. And be ready to think of an app for the AppStore. Good luck.

Hi Apple team, Thanks for the follow up. Here are the details you requested: Platform: iOS (running on iPhone hardware; built with Xcode 15, iOS 17 SDK). Extension type: Network Extension provider packaged as an app extension (appex) within the main app target. Keychain configuration: The main app and the extension both have the Keychain Sharing capability enabled with the same access group (for example, ABCD1234.com.example.shared). We also tried the common app group and specifying the access group via kSecAttrAccessGroup, including variations such as $AppIdentifier.KeyChainSharingGroup. Error observed: When the extension attempts to access the shared keychain, SecItemCopyMatching returns status 25291 (errSecNotAvailable), which Xcode reports as No keychain is available. The same code and access group work from the containing app. Could you advise whether additional entitlements are needed for Network Extension providers on iOS, or if there are specific packaging or provisioning steps we sh

[quote='867992022, pepipox, /thread/808699?answerId=867992022#867992022, /profile/pepipox'] The whole concept already works if launched from Xcode as root. [/quote] Running code as root from Xcode is very tricky. It puts you in a mixed execution context, where you’re running as user ID 0 but your non-BSD execution context is that of the GUI login session. Weird things happen in that case. In this case those weird things seem to be beneficial, but in reality they’re just misleading )-: [quote='867992022, pepipox, /thread/808699?answerId=867992022#867992022, /profile/pepipox'] My idea is that the user launches some app [/quote] If you have a GUI app and you’re using Personal VPN, why not call NEVPNManager directly from it. Why do you need these extra running-as-root bits? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='868011022, chrismuench, /thread/769472?answerId=868011022#868011022, /profile/chrismuench'] it is clearly still a bug in Xcode 26 [/quote] Absolutely. There’s no argument about that. [quote='868011022, chrismuench, /thread/769472?answerId=868011022#868011022, /profile/chrismuench'] which leads to deployment failure from my Visual Studio on my PC. [/quote] With Xcode, you don’t need to explicitly install the profile because the system picks it up from the embedded.mobileprovision file embedded within the built app. I don’t know enough about how Visual Studio builds and installs apps to offer any insight into why that’s not working for it. My advice is that you escalate this via the support channel for that tooling. ps It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I wanted to wade in to the logging side of this. You wrote: print(…) When debugging code that might run in the background, I recommend that you use the system log rather than print(…). The print(…) routine prints to stdout, which you’ll only see if you ran your app from Xcode. OTOH, the system log lets you monitor your logging regardless of how your app was launched. I have a lot more info about the system log in Your Friend the System Log. I also have general info about debugging code that runs in the background in Testing and Debugging Code Running in the Background. Not all of that applies to your case, but it’s a good place to start. os_log(.debug, perform boot: (item)) Is there a reason you’re not using the new Logger API? It’s much nicer. [quote='868100022, Eloo, /thread/809001?answerId=868100022#868100022, /profile/Eloo'] the logs appear to be uneven [/quote] Right. The system log is a limited resource. If you log to it too quickly, you will run into problems. In your specific example, logging