User Profile

In the past I submit TSI without any issue. With the latest changes the documentation here is useless: https://developer.apple.com/support/technical/ It simply says: Apple Developer Program and Apple Developer Enterprise Program members can submit a TSI in the Code-Level Support section in their account. When I go there and submit a form after many exchanges a) the TSI is not debited from account and b) the people responding tell me This number you are referring, it is our case number. This is not a TSI case. The only form I can submit via in my account is here: https://developer.apple.com/contact/technical/#!/request/form What is the correct URL to submit the TSI now?

I have a mac where I am signed in with my own iCloud account. One of my projects is on a team to which I was granted access via a DIFFERENT apple id. I sign in to Xcode with that second account and everything works fine, I can see the apps in Organizer windows, upload archives, get distribution profiles and signing certificates etc. just fine. Now I need to generate a CoreML encryption key (.mlmodelkey) file. This is failing with the following error: Failed to Generate Encryption Key Sign in with you Apple ID in the Apple ID pane in System Preferences and retry. Now I don't actually want to do that because my mac is setup with my iCloud account. Is there a way to generate mlmodelkey without signing out of my other iCloud account on macOS?

Since iOS 15.5 I am receiving a large number of crash logs from my app with no app specific code. My app is written in Swift. The error says SIGABRT: Cannot expell bindable from a binder which doesn't own it The symbolicated crash log is as follows CoreFoundation __exceptionPreprocess + 220 libobjc.A.dylib objc_exception_throw + 56 Foundation -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 200 UIKitCore -[_UIContextBinder expellBindable:] + 384 UIKitCore -[UIWindowScene _detachWindow:] + 264 UIKitCore -[_UIScreenBasedWindowScene _detachWindow:] + 48 UIKitCore -[UIWindowScene _attachWindow:] + 116 UIKitCore -[UIWindow _setWindowHostingScene:] + 252 UIKitCore -[UIWindow setWindowScene:] + 216 UIKitCore _UIApplicationSceneConnectionHandler_block_invoke + 980 UIKitCore +[UIScene _sceneForFBSScene:create:withSession:connectionOptions:] + 1060 UIKitCore -[UIApplication _connectUISceneFromFBSScene:transitionContext:] + 1252 UIKitCore -[UIApplication workspace:didCreateScene:withTransitionContext:completion:] + 340 UIKitCore -[UIApplicationSceneClientAgent scene:didInitializeWithEvent:completion:] + 384 FrontBoardServices -[FBSScene _callOutQueue_agent_didCreateWithTransitionContext:completion:] + 436 FrontBoardServices __94-[FBSWorkspaceScenesClient createWithSceneID:groupID:parameters:transitionContext:completion:]_block_invoke.215 + 124 FrontBoardServices -[FBSWorkspace _calloutQueue_executeCalloutFromSource:withBlock:] + 236 FrontBoardServices __94-[FBSWorkspaceScenesClient createWithSceneID:groupID:parameters:transitionContext:completion:]_block_invoke + 368 libdispatch.dylib _dispatch_client_callout + 16 libdispatch.dylib _dispatch_block_invoke_direct + 260 FrontBoardServices __FBSSERIALQUEUE_IS_CALLING_OUT_TO_A_BLOCK__ + 44 FrontBoardServices -[FBSSerialQueue _targetQueue_performNextIfPossible] + 216 FrontBoardServices -[FBSSerialQueue _performNextFromRunLoopSource] + 24 CoreFoundation __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 24 CoreFoundation __CFRunLoopDoSource0 + 204 CoreFoundation __CFRunLoopDoSources0 + 264 CoreFoundation __CFRunLoopRun + 824 CoreFoundation CFRunLoopRunSpecific + 596 GraphicsServices GSEventRunModal + 160 UIKitCore -[UIApplication _run] + 1096 UIKitCore UIApplicationMain + 360 MyAppModule main (MyEnum.swift:16) undefined 0x0000000105841ce4 Unfortunately there is no specific behaviour that I can see that leads to this, and it seems to be from looking at the stack during the app launch/resume or transition to background. How do I begin figuring out what is going on? This only started in iOS 15.5, and continues on iOS 15.6 and iOS 15.6.1 One way that we sometimes can trigger it is by bringing up list of tasks and swiping up to kill our app, but this doesn't happen everytime.

I have an Avalonia application I want to distribute in-house. (Avalonia is a crossplatform GUI based on dotnet) I followed the guide here: (https://docs.avaloniaui.net/docs/distribution-publishing/macos) My notarization succeeds and I can get the notarization info using xcrun altool --notarization-info UUID -u myappleid No errors getting notarization info. Date: 2021-08-18 07:29:13 +0000 Hash: d1e8825c6571fff0bbcd11c5496b2a84ac1ad8b8a62b77771cde7a0eca286de9 LogFileURL: <Log URL> RequestUUID: <UUID> Status: success Status Code: 0 Status Message: Package Approved If I run codesign -dvvv "/Path/to/my app.app" I can see Executable=/Path/to/my app.app/Contents/MacOS/my app Identifier=com.my.app Format=app bundle with Mach-O thin (x86_64) CodeDirectory v=20500 size=1126 flags=0x10000(runtime) hashes=24+7 location=embedded Hash type=sha256 size=32 CandidateCDHash sha256=3e5d21fdc6948b0d6cff4c94cd89fa441197182c CandidateCDHashFull sha256=3e5d21fdc6948b0d6cff4c94cd89fa441197182c72119f76a8407aa2c2ce2f0e Hash choices=sha256 CMSDigest=3e5d21fdc6948b0d6cff4c94cd89fa441197182c72119f76a8407aa2c2ce2f0e CMSDigestType=2 CDHash=3e5d21fdc6948b0d6cff4c94cd89fa441197182c Signature size=8980 Authority=Developer ID Application: company name (<TEAM ID>) Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=18 Aug 2021 at 5:26:47 pm Info.plist entries=11 TeamIdentifier=<TEAM ID> Runtime Version=10.15.0 Sealed Resources version=2 rules=13 files=413 Internal requirements count=1 size=188 The cdhash 3e5d21fdc6948b0d6cff4c94cd89fa441197182c is present in the developer log of notarization twice: { "path": "my_app.zip/my app.app/Contents/MacOS/my app", "digestAlgorithm": "SHA-256", "cdhash": "3e5d21fdc6948b0d6cff4c94cd89fa441197182c", "arch": "x86_64" }, { "path": "my_app.zip/my app.app", "digestAlgorithm": "SHA-256", "cdhash": "3e5d21fdc6948b0d6cff4c94cd89fa441197182c", "arch": "x86_64" } When I run the spctl /usr/sbin/spctl --assess --type exec -vv "/Path/to/my app.app" I get /Path/to/my app.app: accepted source=Notarized Developer ID origin=Developer ID Application: company name (<TEAM ID>) My codesign was run using Avalonia's bash script with added --deep #!/bin/bash APP_NAME="/Path/to/my app.app" ENTITLEMENTS="/Path/to/entitlements/my_app.entitlements" SIGNING_IDENTITY="Developer ID Application: company name (<TEAM ID>)" find "$APP_NAME/Contents/MacOS/"|while read fname; do if [[ -f $fname ]]; then echo "[INFO] Signing $fname" codesign --deep --force --timestamp --options=runtime --entitlements "$ENTITLEMENTS" --sign "$SIGNING_IDENTITY" "$fname" fi done echo "[INFO] Signing app file" codesign --deep --force --timestamp --options=runtime --entitlements "$ENTITLEMENTS" --sign "$SIGNING_IDENTITY" "$APP_NAME" After notarization I receive an e-mail from Apple that my software was 'successfully notarized'. However, when I run xcrun stapler staple "/Path/to/my app.app" I get Processing: /Path/to/my app.app Could not validate ticket for /Path/to/my app.app The staple and validate action failed! Error 65. If I run stapler with -v I can see that the ticket is successfully downloaded.