My problem persists.
I can't start a local Xcode Server from the Xcode Preferences window.
Failure (vanilla startup)
I've tried both a user account created for the purpose and my admin account. The progress text reaches "Confiuring SSL Certificates…", suspends for a few seconds, then displays an alert with the same sort of content others report, apparently a printout of the NSError with human-readable id:
Could not export API server SSL certificate: Error Domain=XCSSecurity Code=-1 "OpenSSL: Error decrypting key,
followed by a stack dump of the source files and lines where the error was thrown. (Colorizing the plain text was not my idea.)
xcscontrol
As suggested on StackOverflow, I tried sudo xcscontrol --reset from the command line. It exited without error. No change.
Another reply to that SO question suggested deleting /Library/Developer/XcodeServer/. After quitting Xcode, I did, then restarted Xcode. Same problem.
Keychain xcsd
I tried xcscontrol --initialize --build-service-user xcodeuser. This resulted in a dialog box asking for the password to a keychain named "xcsd". A user on that stackoverflow exchange reported finding that keychain in Keychain Access, it's not in mine. The System.keychain contains an "Identity Preference" named com.apple.dt.XCSBuilder, which expired in mid-2021. I'm not certain enough to try deleting it. Dead end.
xcsd turns out to be a launch daemon embedded in Xcode.app. It embeds a load of JavaScript, much of it Node.js.
It also embeds a bash script named create_keychains. It does create an xcsd keychain. It's just a few lines, but I'm not eager to fool with it — especially not knowing what's in $XCSSECURITY_PATH.
TEST_PATH=/tmp/XCSTest
mkdir -p $TEST_PATH
echo "repositories" > $TEST_PATH/RepositoryKeychainSharedSecret
"$XCSSECURITY_PATH" keychain-create -k "$TEST_PATH/Repositories.keychain" -m "$TEST_PATH/RepositoryKeychainSharedSecret"
echo "xcsd" > $TEST_PATH/XCSDKeychainSharedSecret
"$XCSSECURITY_PATH" keychain-create -k "$TEST_PATH/xcsd.keychain" -m "$TEST_PATH/XCSDKeychainSharedSecret"
Configuration
Xcode 13.2.1 (13C100)
macOS 12.1 (21C52) Monterey
MacBook Pro M1 (late 2020)
1 TB storage free
memory pressure 50–60%, which seems typical
CPU near-idle with short runs near-saturated
xcode-select is pointed to /Applications/Xcode.app, which is the only instance of Xcode on the machine.
(Gosh, maybe I ought to report this to Feedback.)
Post not yet marked as solved
Oops, sorry: This has manifested on simulators for both iPhone 8 and iPhone 11, both running iOS 13.7.
Post not yet marked as solved
Has anyone been of help to you since you posted? If so, I'd like to know the solution.I have the same problem. Installing the Xcode Integration add-on and activating it for my account didn't help.Taking the error message at its word, I investigated, I found that we're running Bitbucket Server 5.10, released nearly two years ago, and end-of-life in May. The current versions are 6.9 (Server) and 6.10 (Enterprise), released mid-December and mid-January respectively.So… what version of Bitbucket Server were you using? If you updated, did that resolve the problem?
Post not yet marked as solved
I hope the topic isn't stale. I'm using Xcode 10.1 (10B61) and am seeing the same behavior.Given that Xcode 10 is long out of beta, and that nobody seems to be asking about it any more, I'm hoping there's now a solution.I'm adapting a tutorial, "Triassic Loupe" from raywenderlich.com (blessed be its name) to explore AR reference-image techniques. It worked (properly identified the target planes and overlaid them with a video) with my new images. I did further work, meaning only to replace the video overlay with a cgImage. Now when I execute the following code:static let imageGroup = "OIplanar"private func setupImageDetection() {
imageConfiguration = ARImageTrackingConfiguration()
guard let referenceImages = ARReferenceImage
.referenceImages(
inGroupNamed: ImageViewController.imageGroup,
bundle: nil) else {
fatalError(#function)
}
imageConfiguration.trackingImages = referenceImages
}referenceImages at line 9 shows all images correctly identified, but with physicalSize .zero:(lldb) po referenceImages
▿ 6 elements
- 0 :
- 1 :
- 2 :
- 3 :
- 4 :
- 5 :(lldb) po referenceImages
▿ 6 elements
- 0 : <ARReferenceImage: 0x283f78a50 name="Lion" physicalSize=(0.000, 0.000)>
- 1 : <ARReferenceImage: 0x283f79270 name="QST" physicalSize=(0.000, 0.000)>
- 2 : <ARReferenceImage: 0x283f4f570 name="Bull king" physicalSize=(0.000, 0.000)>
- 3 : <ARReferenceImage: 0x283f79450 name="Middle Attendants" physicalSize=(0.000, 0.000)>
- 4 : <ARReferenceImage: 0x283f796d0 name="Extreme priest" physicalSize=(0.000, 0.000)>
- 5 : <ARReferenceImage: 0x283f40460 name="Cuneiform" physicalSize=(0.000, 0.000)>(lldb) po referenceImages
▿ 6 elements
- 0 : {ARReferenceImage: 0x283f78a50 name="Lion" physicalSize=(0.000, 0.000)}
- 1 : {ARReferenceImage: 0x283f79270 name="QST" physicalSize=(0.000, 0.000)}
- 2 : {ARReferenceImage: 0x283f4f570 name="Bull king" physicalSize=(0.000, 0.000)}
- 3 : {ARReferenceImage: 0x283f79450 name="Middle Attendants" physicalSize=(0.000, 0.000)}
- 4 : {ARReferenceImage: 0x283f796d0 name="Extreme priest" physicalSize=(0.000, 0.000)}
- 5 : {ARReferenceImage: 0x283f40460 name="Cuneiform" physicalSize=(0.000, 0.000)}(Sorry for the repeats, the literal-text style gets very confused by angle brackets and I can't fix or delete them in-place. For all I know you'll see all three.)When execution proceeds to sceneView.session.run(imageConfiguration), the same error as elsewhere in this thread reaches session(_:didFailWithError:) -... (same for the other images) ...
2018-12-05 18:48:17.183728-0600 Not OI[25465:9988437] [Technique] Could not add planar object for detection: <ARReferenceImage: 0x283f40460 name="Cuneiform" physicalSize=(0.000, 0.000)> Reason: 4
2018-12-05 18:48:17.184038-0600 Not OI[25465:9988437] [Session] Session (0x104b09bb0): did fail with error: Error Domain=com.apple.arkit.error Code=300 "Invalid reference image." UserInfo={NSLocalizedFailureReason=One or more reference images have an invalid size: Lion, QST, Bull king, Middle Attendants, Extreme priest, Cuneiform, NSLocalizedRecoverySuggestion=Make sure that all reference images are greater than 100 pixels and have a positive physical size in meters., ARErrorItems=(
Lion,
QST,
"Bull king",
"Middle Attendants",
"Extreme priest",
Cuneiform
), NSLocalizedDescription=Invalid reference image.}Following other suggestions I converted to all JPEG (no), then all PNG (no), editing the respective Contents.json files to match. Here is what's in the Contents.json for one of them:{ "images" : [
{ "idiom" : "universal", "filename" : "Cuneiform.jpg" }
],
"info" : { "version" : 1, "author" : "xcode" }, "properties" : { "width" : 0.9144000000000001 }
}The conversions were by way of a script using sips to convert and sed to edit the suffixes in the Contents.jsons. Remember I had this trouble before I did any of that. No change. Cutting the dimensions from ~2800 on a side to 1024 didn't help. (512 got me dimension-too-small runtime warnings, and I lacked the patience to correct those by hand.)I know I should retrace my steps through the tutorial (no, I didn't add SCM until after I crossed the line to un-workland). I'll do that tomorrow after I go home and sleep.In the mean time, I hope someone has figured out what exposes this issue and how I can avoid it.
Solved.The client dribbled UDIDs at me and I reissued the provisioning profile several times. For some reason the new devices never made it into the archiving workflow, so all subsequent devices were ineligible. That's why iTunes didn't highlight for the drop of the .ipa and .mobileprovision. Issuing a fresh profile cleared up the problem.Now all I have to figure out is how to supersede the previous profile. The client is still dribbling device IDs.Many thanks, again, to KMT for his interest and help.
Post not yet marked as solved
Take this as well-intentioned advice, and not some busybody shaking the rulebook in your face.If you intend to use private API, and aren't just curious…It's a violation of the developer license. But I can't see anyone getting excited about it if that's all it is.Apple keeps a framework private when it does not want to make it part of the operating systens' API contract. The preconditions, inputs, side effects, outputs, and existence of private frameworks are subject to change with any point release, or even with changes in hardware, hardware state, time zone shifts, race conditions, internal configuraton, installed applications, or system/user data.If you want to fool around, understand that you are placing a bet on not destroying data or bricking the device. Unlikely? Sure; it's only a slight chance of a high cost.The App Review bots can easily detect when an app hooks directly into private API. At best, the app will be rejected. At the very worst, but unlikely, if there's any whiff of malware, now you have to worry about the license because Apple has you on a legal hook. Again, very unlikely, but our world is full of unreasonable people.It's no skin off my nose if you want to explore, but you should do it with your eyes open.
