Hello, I'm responsible for several apps within my company. We tried to apply for the user-assigned device name entitlement, but again we didn't get the approval: "Thank you for your interest in the user-assigned device name entitlement. We are unable to approve your request at this time." We use in our app the bluetooth connect and want to show the user in the vehicles the device name. Currently it's just "iPhone". Does somebody know how I can contact Apple to fix this? I chose this answers: Will your app display the user assigned device name to the user? No Will your app use the device name solely for functionality in a way that the user can easily see and understand? Yes Will your app functionality support interaction between multiple devices operated by the same user? Yes Will your app share the device name with any service providers or third parties other than a cloud hosting service provider? No Would be great to get any feedback with this. Thanks a lot.

Hello, I am currently facing an issue with my iOS app and its associated Preview extension. I am trying to save a file to a shared container using App Groups, so that my main app can read the file. The code works perfectly on the iOS simulator, but when I run the app on a physical device I encounter a "You don't have permission to save the file" error. Here's the relevant code snippet: let appGroupIdentifier = "group.com.yourcompany.yourapp" func saveDataToSharedContainer(fileName: String, data: Data) -> Bool { guard let containerURL = FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: appGroupIdentifier) else { print("Error: Unable to access the shared container.") return false } let fileURL = containerURL.appendingPathComponent(fileName) do { try data.write(to: fileURL, options: .atomic) print("Data saved to shared container successfully.") return true } catch { print("Error: Unable to save data to shared container. \(error)") return false } } I have already verified the following: App Groups capability is enabled for both the main app target and the extension target. The App Group identifier is consistent in both the main app target and the extension target, as well as in the Swift code. Provisioning profiles and signing certificates are up-to-date, and the issue persists after cleaning the project and resetting the provisioning profiles. Despite trying these steps, the issue remains unresolved. This error is reproducible in a new project with a Preview extension. I would greatly appreciate any insights or suggestions from the community to help me resolve this issue. Thank you in advance!

We're in the process of updating an app that we released approximately a year ago -- which had no issues with codesigning and notarization in our last release. The current version fails at the initial submission process; stating that the file "must be a zip archive (.zip), flat installer package (.pkg), or UDIF disk image (.dmg)" The process itself we're taking is rather straightforward, and follows much of what I've seen repeated on the forums here. A few additional details: The app itself (a Unity project with a lot of content that needs to be shipped with the app) is quite large, weighing in at around 20GB. Despite this large size, we were able to go through this process in the past with no issues. I was originally running Xcode 13 on Big Sur, but upgraded to Xcode 14 on Ventura to no avail. Our notarization script runs the following: ditto -c -k --keepParent OurAppName.app NotarizationFileName.zip xcrun notarytool submit NotarizationFileName.zip --keychain-profile OUR_CREDENTIAL_PROFILE --wait When we add --verbose to the xcrun command; this is our output: $ Build > xcrun notarytool submit NotarizationFileName.zip --keychain-profile OUR_CREDENTIAL_PROFILE --wait --verbose [23:01:54.643Z] Debug [MAIN] Running notarytool version: 1.0.0 (27), date: 2023-03-25T23:01:54Z, command: /Applications/Xcode.app/Contents/Developer/usr/bin/notarytool submit NotarizationFileName.zip --keychain-profile OUR_CREDENTIAL_PROFILE --wait --verbose Conducting pre-submission checks for NotarizationFileName.zip and initiating connection to the Apple notary service... [23:01:54.717Z] Info [PREFLIGHT] NotarizationFileName.zip is not a zip archive. warning [/Users/michael/.jenkins/workspace/bastion-add-build-tools/Build/NotarizationFileName.zip]: 17179869184 extra bytes at beginning or within zipfile (attempting to process anyway) . Err: 1 [23:01:54.729Z] Debug [PREFLIGHT] NotarizationFileName.zip did not pass the disk image potentiality test. Moving on to other tests. [23:01:54.730Z] Debug [PREFLIGHT] NotarizationFileName.zip is not a flat installer package. [23:01:54.731Z] Debug [PREFLIGHT] Finished completing determination of file type for NotarizationFileName.zip. Operation took 80ms. Error: NotarizationFileName.zip must be a zip archive (.zip), flat installer package (.pkg), or UDIF disk image (.dmg) Usage: notarytool <subcommand> See 'notarytool --help' for more information.

My goal is to implement a moving background in a virtual camera, implemented as a Camera Extension, on macOS 13 and later. The moving background is available to the extension as a H.264 file in its bundle. I thought i could create an AVAsset from the movie's URL, make an AVPlayerItem from the asset, attach an AVQueuePlayer to the item, then attach an AVPlayerLooper to the queue player. I make an AVPlayerVideoOutput and add it to each of the looper's items, and set a delegate on the video output. This works in a normal app, which I use as a convenient environment to debug my extension code. In my camera video rendering loop, I check self.videoOutput.hasNewPixelBuffer , it returns true at regular intervals, I can fetch video frames with the video output's copyPixelBuffer and composite those frames with the camera frames. However, it doesn't work in an extension - hasNewPixelBuffer is never true. The looping player returns 'failed', with an error which simply says "the operation could not be completed". I've tried simplifying things by removing the AVPlayerLooper and using an AVPlayer instead of an AVQueuePlayer, so the movie would only play once through. But still, I never get any frames in the extension. Could this be a sandbox thing, because an AVPlayer usually renders to a user interface, and camera extensions don't have UIs? My fallback solution is to use an AVAssetImageGenerator which I attempt to drive by firing off a Task for each frame each time I want to render one, I ask for another frame to keep the pipeline full. Unfortunately the Tasks don't finish in the same order they are started so I have to build frame-reordering logic into the frame buffer (something which a player would fix for me). I'm also not sure whether the AVAssetImageGenerator is taking advantage of any hardware acceleration, and it seems inefficient because each Task is for one frame only, and cannot maintain any state from previous frames. Perhaps there's a much simpler way to do this and I'm just missing it? Anyone?

Hi, I'm building an app for iPhone, iPad and Mac (Mac Catalyst). Unfortunately when I'm adding Family Controls capability to project I'm unable to run Mac Catalyst version of app. Everything is compiling, it fails when run and shows "Could not launch App" Launch Service error IDELaunchErrorDomain: code 20 RBSRequestErrorDomain: code 5 NSPOSIXErrorDomain: code 153 iOS version work without any problems and Screen Time releated Api too. My minimum deployment target is iOS 15. Our permission for Family Controls to distribute in AppStore is currently processing but I guess it shouldn't has influence as I'm running debug. Best, Marcin

Hi all, I got the entiltlements for the DriverKit PCI (primary match). so I added it to my driver app ID. so, I can show the ~~transport.pci entitlement item on my provision profile. However, macOS system still block the my driver, and log show the " Unsatisfied entitlements: com.apple.developer.driverkit.transport.pci"

Developing a ios app in Unreal Engine 5. Everything was alright. Until it wasn’t. Build to iOS device. Click. Cooking. Building… “ERROR: CodeSign Failed” D4mn it! hahaha Here’s the log: UATHelper: Packaging (IOS): Command CodeSign failed with a nonzero exit code UATHelper: Packaging (IOS): ** BUILD FAILED ** UATHelper: Packaging (IOS): The following build commands failed: UATHelper: Packaging (IOS): CodeSign /Users/jordansktorres/My\ Drive/PROJECTS/CRUZEIRO-DO-SUL/ValenteGO/ValenteGO_V1/Binaries/IOS/Payload/ValenteGO_V1.app (in target ‘ValenteGO_V1’ from project ‘ValenteGO_V1’) UATHelper: Packaging (IOS): (1 failure) UATHelper: Packaging (IOS): Took 12,659139s to run env, ExitCode=65 UATHelper: Packaging (IOS): ERROR: CodeSign Failed UATHelper: Packaging (IOS): (see /Users/jordansktorres/Library/Logs/Unreal Engine/LocalBuildLogs/Log.txt for full exception trace) UATHelper: Packaging (IOS): AutomationTool executed for 0h 1m 51s UATHelper: Packaging (IOS): AutomationTool exiting with ExitCode=32 (Error_FailedToCodeSign) UATHelper: Packaging (IOS): RunUAT ERROR: AutomationTool was unable to run successfully. Exited with code: 32 PackagingResults: Error: Failed to Code Sign I have deleted the binaries, build, intermediate, and saved folders. I have generated and created new certificates. I have deleted UE5 and re-install it again. I have thrown the project into the garbage can and created a whole new project file with the same content folder. It all led to the same result. “ERROR: CodeSign Failed” Please, someone, anyone, give me a light here. hahaha

I am trying to sign a DriverKit extension for distribution using a Developer ID provisioning profile, but when I try to import the profile to sign the dext I get the error "Platform: MacOS doesn't match platform DriverKit". We requested the entitlement from Apple a few months ago and according to Apple Support it was approved (though we did not get any email directly from the DriverKit approval process). The App ID we are using appears to have the DriverKit capabilities that we need under "Additional Capabillities". Our process right now is this: Go to Certificates, Identifiers, and Profiles Create a new Provisioning Profile and select Developer ID Distribution Select the correct App ID After creating and downloading the profile, import it into Xcode Receive the error "Platform: MacOS does not match DriverKit" According to https://developer.apple.com/documentation/driverkit/requesting_entitlements_for_driverkit_development#3557213, there should perhaps be a prompt adding DriverKit to the provisioning profile and not just the identifier, but we do not see this. Has anybody else run into a similar issue and resolved it? I see a similar thread at https://developer.apple.com/forums/thread/710713, but that one is eight months old and doesn't appear to have a solution.

I got an email from Apple, "Your Developer ID Installer Certificate will no longer be valid in 30 days". So I went to my certificates page on developer.apple.com, and I see the attached photo. Basically, yes, I have a Developer ID Installer Certificate that expires 2023/07/01; but I also have one that expires 2025/12/08, and one that expires 2026/01/09, and one that expires 2026/12/15, and another that expires 2026/12/16! Why do I have all these certificates? I have no idea. There is a "+" button to add a new one; but given that I already seem to have ones that won't expire for several more years, do I need to? There does not seem to be a "-" button, or any way to clear out this cruft. I then recalled that perhaps I have managed my certificates in Xcode in the past, not on this page (or maybe I have done both, at different times?). So I went to Xcode, and things seem to be rather a mess there too, but in a different way (second image attached). Here, I seem to have lots of stale certificates that are in gray and say "Not in Keychain" – how do I clear those out? Again there does not seem to be a "-" button. And the newer ones that I saw on developer.apple.com do not seem to be listed here, maybe – it's hard to compare, though, because on developer.apple.com it shows the expiration date but not creation date, whereas in Xcode it shows creation date but not expiration date. What should I do? Note that I am not a member of multiple different teams, or anything like that; I'm a solo developer. This stuff is really confusing and does not seem to be well-documented anywhere that I have found. Am I just being dense?

My app has the App Sandbox enabled and the File Access to Downloads folder is set to Read / Write in XCode. Upon clicking on a button the app should open the Finder displaying the Downloads folder. The following code snippet is used to launch the Finder if let inspirationsDirectory = FileManager.default.urls(for: .downloadsDirectory, in: .userDomainMask).first{ NSWorkspace.shared.open(inspirationsDirectory) } On my MacOS it works well. After releasing the app to the AppStore and installing it on another Mac the following message is received upon clicking the button: The application does not have permission to open "Downloads" Which would be the solution to launch the Finder successfully ? Is it possible to launch the Finder showing the Downloads folder sorted by the Date Added column descending ?

I regularly see folks run into problems with their Developer ID signing identities. Historically I pointed them to my posts on this thread, but I’ve decided to collect these ideas together in one place. If you have questions or comments, start a new thread here on DevForums and tag it with Developer ID so that I see it. IMPORTANT Nothing I write here on DevForums is considered official documentation. It’s just my personal ramblings based on hard-won experience. There is a bunch of official documentation that covers the topics I touch on here, including: Xcode documentation Xcode Help Developer Account Help Developer > Support > Certificates For a lot more information about code signing, see the Code Signing Resources pinned post. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" The Care and Feeding of Developer ID Most Apple signing assets are replaceable. For example, if you accidentally lose access to your Apple Development signing identity, it’s a minor inconvenience. Just use the Developer website to revoke your previous certificate and create a replacement. Or have Xcode do that for you. IMPORTANT If you don’t understand the difference between a certificate and a digital identity, and hence signing identity, read Certificate Signing Requests Explained before reading this post. Some signing assets are precious. Losing access to such assets has significant consequences. Foremost amongst those are Developer ID signing identities. These allow you to sign Mac products that ship independently. Anyone with access to your Developer ID signing identity can sign code as you. This has a number of consequences, both for you and for your relationship with Apple. Identify a Developer ID Signing Identity A Developer ID signing identity consists of two parts: the certificate and the private key. There are two different flavours, identifiable by the subject name in the certificate: Developer ID Application — This is named Developer ID Application: TTT, where TTT identifies your team. Use this to sign code and disk images. Developer ID Installer — This is named Developer ID Installer: TTT, where TTT identifies your team. Use this to sign installer packages. Note If you do KEXT development, there’s a third flavour, namely a KEXT-enabled Developer ID Application signing identity. For more details, see KEXT Code Signing Problems. This post focuses on traditional signing identities, where you manage the private key. Xcode Cloud introduced cloud signing, where signing identities are “stored securely in the cloud”. These identities have the Managed suffix in Certificates, Identifiers, and Profiles. For example, Developer ID Application Managed is the cloud signing equivalent of Developer ID Application. To learn more about cloud signing, watch WWDC 2021 Session 10204 Distribute apps in Xcode with cloud signing. To identify these certificates ‘in the wild’, see Identifying a Cloud Managed Signing Certificate. Limit Access to Developer ID Anyone with your Developer ID signing identity can sign code as you. Given that, be careful to limit access to these signing identities. This is true both for large organisations and small developers. In a large organisation, ensure that only folks authorised to ship code on behalf of your organisation have access to your Developer ID signing identities. Most organisations have some sort of release process that they use to build, test, and authorise a release. This often involves a continuous integration (CI) system. Restrict CI access to only those folks involved in the release process. Even if you’re a small developer with no formal release process, you can still take steps to restrict access to Developer ID signing identities. See Don’t Leak Your Private Key, below. In all cases, don’t use your Developer ID signing identities for day-to-day development. That’s what Apple Development signing identities are for. Create Developer ID Signing Identities as the Account Holder Because Developer ID signing identities are precious, the Developer website will only let the Account Holder create them. For instructions on how to do this, see Developer Account Help > Create certificates > Create Developer ID certificates. For more information about programme roles, see Developer > Support > Program Roles. IMPORTANT In an Organization team it’s common for the Account Holder to be non-technical. They may need help getting this done. For hints and tips on how to avoid problems while doing this, see Don’t Lose Your Private Key and Don’t Leak Your Private Key, both below. Limit the Number of Developer ID Signing Identities You Create Don’t create Developer ID signing identities unnecessarily. Most folks only need to create one. Well, one Developer ID Application and maybe one Developer ID Installer. A large organisation might need more, perhaps one for each sub-unit, but that’s it. There are two reasons why this is important: The more you have, the more likely it is for one to get into the wrong hands. Remember that anyone with your Developer ID signing identity can sign code as you. The Developer website limits you to 5 Developer ID certificates. Note I can never remember where this limit is actually documented, so here’s the exact quote from this page: You can create up to five Developer ID Application certificates and up to five Developer ID Installer certificates using either your developer account or Xcode. Don’t Lose Your Private Key There are two standard processes for creating a Developer ID signing identity: Developer website — See Developer Account Help > Create certificates > Create Developer ID certificates. Xcode — See Xcode Help > Maintaining signing assets > Manage signing certificates. Both processes implicitly create a private key in your login keychain. This makes it easy to lose your private key. For example: If you do this on one Mac and then get a new Mac, you might forget to move the private key to the new Mac. If you’re helping your Organization team’s Account Holder to create a Developer ID signing identity, you might forget to export the private key from their login keychain. It also makes it easy to accidentally leave a copy of the private key on a machine that doesn’t need it; see Don’t Leak Your Private Key, below, for specific advice on that front. Every time you create a Developer ID signing identity, it’s a good idea to make an independent backup of it. For advice on how to do that, see Back Up Your Signing Identities, below. That technique is also useful if you need to copy the signing identity to a continuous integration system. If you think you’ve lost the private key for a Developer ID signing identity, do a proper search for it. Finding it will save you a bunch of grief. You might be able to find it on your old Mac, in a backup, in a backup for your old Mac, and so on. For instructions on how to extract your private key from a general backup, see Recover a Signing Identity from a Mac Backup. If you’re absolutely sure that you previous private key is lost, use the Developer website to create a replacement signing identity. If the Developer website won’t let you create any more because you’ve hit the limit discussed above, talk to Developer Programs Support. Go to Apple > Developer > Contact Us and follow the path Development and Technical > Certificates, Identifiers, and Provisioning Profiles. Don’t Leak Your Private Key Anyone with your Developer ID signing identity can sign code as you. Thus, it’s important to take steps to prevent its private key from leaking. A critical first step is to limit access to your Developer ID signing identities. For advice on that front, see Limit Access to Developer ID, above. In an Organization team, only the Account Holder can create Developer ID signing identities. When they do this, a copy of the identity’s private key will most likely end up in their login keychain. Once you’ve exported the signing identity, and confirmed that everything is working, make sure to delete that copy of the private key. Some organisations have specific rules for managing Developer ID signing identities. For example, an organisation might require that the private key be stored in a hardware token, which prevents it from being exported. Setting that up is a bit tricky, but it offers important security benefits. Even without a hardware token, there are steps you can take to protect your Developer ID signing identity. For example, you might put it in a separate keychain, one with a different password and locking policy than your login keychain. That way signing code for distribution will prompt you to unlock the keychain, which reminds you that this is a significant event and ensures that you don’t do it accidentally. If you believe that your private key has been compromised, follow the instructions in the Compromised Certificates section of Developer > Support > Certificates. Back Up Your Signing Identities Given that Developer ID signing identities are precious, consider making an independent backup of them. To back up a signing identity to a PKCS#12 (.p12) file: Launch Keychain Access. At the top, select My Certificates. On the left, select the keychain you use for signing identities. For most folks this is the login keychain. Select the identity. Choose File > Export Items. In the file dialog, select Personal Information Exchange (.p12) in the File Format popup. Enter a name, navigate to your preferred location, and click Save. You might be prompted to enter the keychain password. If so, do that and click OK. You will be prompted to enter a password to protect the identity. Use a strong password and save this securely in a password manager, corporate password store, on a piece of paper in a safe, or whatever. You might be prompted to enter the keychain password again. If so, do that and click Allow. The end result is a .p12 file holding your signing identity. Save that file in a secure location, and make sure that you have a way to connect it to the password you saved in step 9. Remember to backup all your Developer ID signing identities, including the Developer ID Installer one if you created it. To restore a signing identity from a backup: Launch Keychain Access. Choose File > Import Items. In the open sheet, click Show Options. Use the Destination Keychain popup to select the target keychain. Navigate to and select the .p12 file, and then click Open. Enter the .p12 file’s password and click OK. If prompted, enter the destination keychain password and click OK. Alternatively, Xcode has a feature to export and import your developer account, including your Developer ID signing identities. Do this using the action menu in Xcode > Settings > Accounts. For the details, see Xcode Help > Maintaining signing assets > Export signing certificates and provisioning profiles. Recover a Signing Identity from a Mac Backup If you didn’t independently backup your Developer ID signing identity, you may still be able to recover it from a general backup of your Mac. To start, work out roughly when you created your Developer ID signing identity: Download your Developer ID certificate from the Developer website. In the Finder, Quick Look it. The Not Valid Before field is the date you’re looking for. Now it’s time to look in your backups. The exact details depend on the backup software you’re using, but the basic process runs something like this: Look for a backup taken shortly after the date you determined above. In that backup, look for the file ~/Library/Keychains/login.keychain. Recover that to a convenient location, like your desktop. Don’t put it in ~/Library/Keychains because that’ll just confuse things. Rename it to something unique, like login-YYYY-MM-DD.keychain, where YYYY-MM-DD is the date of the backup. In Keychain Access, choose File > Add Keychain and, in the resulting standard file panel, choose that .keychain file. On the left, select login-YYYY-MM-DD. Chose File > Unlock Keychain “login-YYYY-MM-DD“. In the resulting password dialog, enter your login password at the date of the backup. At the top, select My Certificates. Look through the list of digital identities to find the Developer ID identity you want. If you don’t see the one you’re looking for, see Further Recovery Tips below. Export it using the process described at the start of Back Up Your Signing Identities. Once you’re done, remove the keychain from Keychain Access: On the left, select the login-YYYY-MM-DD keychain. Choose File > Delete Keychain “login-YYYY-MM-DD”. In the confirmation alert, click Remove Reference. The login-YYYY-MM-DD.keychain is now just a file. You can trash it, keep it, whatever, at your discretion. This process creates a .p12 file. To work with that, import it into your keychain using the process described at the end of Back Up Your Signing Identities. IMPORTANT Keep that .p12 file as your own independent backup of your signing identity. Further Recovery Tips If, in the previous section, you can’t find the Developer ID identity you want, there are a few things you might do: Look in a different backup. If your account has more than one keychain, look in your other keychains. If you have more than one login account, look at the keychains for your other accounts. If you have more than one Mac, look at the backups for your other Macs. The login-YYYY-MM-DD keychain might have the private key but not the certificate. Add your Developer ID certificate to that keychain to see if it pairs with a private key. Revision History 2023-10-05 Added the Recover a Signing Identity from a Mac Backup and Further Recovery Tips sections. 2023-06-23 Added a link to Identifying a Cloud Managed Signing Certificate. 2023-06-21 First posted.

I distribute an application in a zip file from my website. the application needs access to some files next to it to run properly. The application is correctly signed and notarized and stapled.Of course if I download it from my website, it gets the quarantine attribute. When I try to open it for the first time, a gatekeeper warning saying that the application comes from the internet, but has been checked by apple and no malware has been detected is displayed. My impression is that the application has been correctly signed and notarized. but If confirm that I wan to open it, the quarantine attribute is not deleted. spctl -a -v /path/to/Myapp.app path/to/Myapp.app: accepted source=Notarized Developer ID

I need an OV certificate to code sign an Electron application. I was used to build in Jenkins the application oth for Windows and macOS using Electron-Forge (https://www.electronforge.io/guides/code-signing/code-signing-macos). To be more specific use XCode and Keychain to store the certificate. Sadly, new certificate industry requirements will force me to use Azure Key Vaults (or other cloud HSM alternatives) to store the certificate. I need to find a way to code-sign it for macOS from Azure Key Vaults or equivalent solutions. Thank you

Hi, I am running into a strange issue where my universal links work fine on devices when using USB, simulators and TestFlight, it works with no problem on all test environments But once I submit it for App Review, they don't work. And I have no way to replicate it. At some point they get it working somehow but every resubmission the process repeats where I go back and forth for days until they finally get it working. Anyone run into this strange issue or has a clue what might be going on?

Guys I'm the account holder of my company and we are working on a new EPP solution. Approx two months go I requested an Endoint Security entitlement so we can develop our product and then requested it again about a month ago. Is there a way to see what is the status of the request and whether this time frame is indeed the one we should expect? Thanks a lot!

Dear iOS Developers, I have a question about In-House distribution for iOS 17, currently I am using Xcode 14.x for distribute my application (for iOS 16.x and below). In the future, Apple will release the new iOS version that is iOS 17. So, my question is 1./ "Do I need to build and distribute the mobile application with Xcode 15 for supporting iOS 17? 2./ or iOS 17 can run In-house mobile application fine with building and distribution with Xcode 14.x?" Anybody have knowledge about it? Thanks, Lam

I'm porting my VPN app to tvOS 17. Here's some code which works just fine in iOS but doesn't in tvOS 17: func toggleVPN() { let vpnManager = NEVPNManager.shared() vpnManager.loadFromPreferences { (error) in if let error = error { print("Could not load VPN Configurations: \(error.localizedDescription)") return } if vpnManager.connection.status == .connected || vpnManager.connection.status == .connecting { vpnManager.connection.stopVPNTunnel() } else { vpnManager.isEnabled = true vpnManager.isOnDemandEnabled = true vpnManager.localizedDescription = "tvpn" let p = NEVPNProtocolIPSec() p.authenticationMethod = .sharedSecret // or .certificate p.serverAddress = <REDACTED> p.username = "client" p.useExtendedAuthentication = true // Retrieve password and shared secret references from the keychain let secretData = <REDACTED>.data(using: .utf8)! let passData = <REDACTED>.data(using: .utf8)! p.sharedSecretReference = try! VPNKeychain.persistentReferenceFor(service: "vpn", account: "SharedSecret", password: secretData) // I took this part from Apple dev forums, it's tested in iOS p.passwordReference = try! VPNKeychain.persistentReferenceFor(service: "vpn", account: "Password", password: passData) vpnManager.protocolConfiguration = p vpnManager.saveToPreferences { (error) in if let error = error { print("Could not save VPN Configurations: \(error.localizedDescription)") return } do { try vpnManager.connection.startVPNTunnel() } catch { print("Could not start VPN Connection: \(error.localizedDescription)") } } } } } in iOS the VPN connects successfully, however in tvOS saveToPreferences returns error Code 1: Could not save VPN Configurations: Missing protocol or protocol has invalid type Another thing I noticed, that there's no com.apple.developer.networking.vpn.api entitlement for tvOS, but NEVPNManager is available there according to documentation. Could you advise what's the problem with my code?

Good day. We are moving our CI to Github Actions and we have met a problem whereby even though we have 1/1 codesigning identities that are valid, trying to sign MyTrue as per guides posted in the forum still results in this error. SSH is fine. Would appreciate to have some light shed on this. Thanks in advance!

I regularly come across Mac developers who have an app in the Mac App Store but are unable to submit it to TestFlight. This post explains a common cause of that problem. If you have any questions or comments about this, start a new thread and tag it with Provisioning Profiles and TestFlight so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" TestFlight, Provisioning Profiles, and the Mac App Store A provisioning profile authorises a device to run your app. For historical reasons, not all Mac apps need a provisioning profile. A Mac app only needs a profile if it uses a restricted entitlement, that is, an entitlement that must be authorised by a profile. For more background on this, see TN3125 Inside Code Signing: Provisioning Profiles and, specifically, its Entitlements on macOS section. IMPORTANT Your Mac App Store apps must be signed with the App Sandbox Entitlement, but that entitlement is unrestricted. This means that many Mac App Store apps ship without a provisioning profile, and that’s absolutely fine. However, these apps run into problems with TestFlight. To submit an app to TestFlight, it must have a provisioning profile. If you attempt to submit an app without a profile to TestFlight, it’ll fail with an error like this: ITMS-90889: Cannot be used with TestFlight because the bundle at 'MyApp.app' is missing a provisioning profile. Main bundles are expected to have provisioning profiles in order to be eligible for TestFlight. The fix is to give your app a profile. How you do this depends on how you build your app. Fix an app built with Xcode If you build your app with Xcode, the fix is relatively straightforward: Sign your app with a restricted entitlement. This causes Xcode’s code signing machinery to kick in. If you have automatic code signing enable, Xcode will sort this all out for you. If you use manual signing, Xcode will highlight the problems you need to solve. A good restricted entitlement to use is the Keychain Access Groups Entitlement. Enable this by adding Keychain Sharing to the Signing & Capabilities editor for your app. You have two options here: Leave the Keychain Groups list empty. This will fix this problem while having no effect on any keychain code in your app. Use this as an opportunity to switch to the data protection keychain. In this case you might want to add one or more keychain access groups. For an explanation as to why you might want to switch to using the data protection keychain, see TN3137 On Mac keychain APIs and implementations. For more information about keychain access groups, see Sharing Access to Keychain Items Among a Collection of Apps Fix an app built outside of Xcode If you don’t use Xcode to build your app: Use Developer > Account > Identifiers to create an App ID for your app. Remember that your App ID is the combination of an App ID prefix and your app’s bundle ID. For new App IDs, use your Team ID as the App ID prefix. Use Developer > Account > Profiles to create a macOS App Development provisioning profile for that App ID. Use Developer > Account > Profiles to create a Mac App Store distribution provisioning profile for that App ID. Update your build system to embed a provisioning profile into your app. Use the profile from step 2 for development-signed builds and the one from step 3 for distribution-signed builds. For information about where to place the profile, see Placing Content in a Bundle. Add the following to your .entitlements: A com.apple.application-identifier property whose value is your App ID A com.apple.developer.team-identifier property whose value is your Team ID Build your app and check your work by dumping the entitlements claimed by your app and the entitlements authorised by your provisioning profile. For the specific commands to use, see TN3125 Inside Code Signing: Provisioning Profiles. WARNING In step 1, if your team has any unique App ID prefixes registered, the Developer website might default to using one of those legacy values rather than your Team ID (r. 70571514). If the App ID Prefix value is a popup, select your Team ID from the list. If the App ID value is a read-only copy of your Team ID, your team has no unique App ID prefixes, and so the Developer website always uses your Team ID as the App ID prefix. IMPORTANT In step 5, make sure that your .entitlements file is only applied to the app itself, not to any nested code. For more on this, see the Entitlements and Nested Code section below. Historically you might have been able to get away with using single .entitlements file for all your code. Once you start adding restricted entitlements, like com.apple.application-identifier, this bad practice will cause problems. For general information about how to sign and package apps outside of Xcode, see Creating Distribution-Signed Code for Mac and Packaging Mac Software for Distribution. Entitlements and Nested Code An App Store app might contain the following code; The app itself Nested libraries, like a framework or a dynamic library Nested executables, like a helper tool or an app extension Step 5 in the previous section specifically refers to the entitlements of the main app. When it comes to nested code, the first case is easy: Never add entitlements to nested libraries. It doesn’t do anything useful and can prevent your code from running. The story with nested executables is more nuanced. To start, every nested executable must be signed with at least one entitlement because: All App Store executables must be sandboxed. You enable the App Sandbox with the com.apple.security.app-sandbox entitlement. In many cases a nested executable only needs unrestricted entitlements, like com.apple.security.app-sandbox and com.apple.security.inherit. In that case the nested code doesn’t need a provisioning profile. If a nested executable uses restricted entitlements, it needs a provisioning profile to authorise the use of those entitlements, and its own unique App ID to tie the executable to the profile. Place this profile in the nested executable’s bundle, according to the rules in Placing Content in a Bundle. IMPORTANT The nested code can’t ‘piggyback’ off the app’s provisioning profile. It needs its own profile with its own unique App ID. Revision History 2023-08-17 Added the Entitlements and Nested Code section. Made other minor editorial changes. 2023-07-17 First posted.

I implemented "com.apple.developer.device-information.user-assigned-device-name" on app, it's don't work.