I am receiving an error message trying to upload an update for my macOS app to App Store Connect that I do not understand: "Cannot be used with TestFlight because the signature for the bundle at “YourApp.app” is missing an application identifier but has an application identifier in the provisioning profile for the bundle. Bundles with application identifiers in the provisioning profile are expected to have the same identifier signed into the bundle in order to be eligible for TestFlight". I have double-checked, and the nbunde identifier in the profile matches that in the Info.plist, and I have, in addition, now passed it via "--identifier" to code sign for the app bundle as well, but the error remains. Where else would the identifier be needed, and has this changed recently? (I last uploaded this app a year ago, w/o issues, and made no relevant changes). I am using a custom toolchain and not Xcode to build the app bundle and installer. codesign -dvvv also reports the correct the bundle identifier back as expected. any suggestions?

Is there any documentation about the Objective-C ABI changes that cause the above warning warning: mixed ObjC ABI, libSomeLib.a compiled without category class properties ? what are "category class properties"

Hi. it's been a while since i used APS, and I'm trying to set up a new iOS app fort push notifications (for now just a dummy app). I have Push enabled for the profile, got the certificate, and everything. in my app i call registerForRemoteNotifications and get the expected callback to didRegisterForRemoteNotificationsWithDeviceToken with a device token that looks good. I've got the server set up to send a test notification using the new HTTPS/2 APIs, and that all seems to work well (after some hurdles), the server sends back a "200" status code for my push. I'm running my app in developer mode on a real iOS device; I'm using the sandbox push server URL. however (a) no notification shows on the Phone and more curiously (b) despite getting a token, my App does not show in Settings under Notifications, and in the apps now settings view, there's no Notifications item either. Again this is even though registerForRemoteNotifications succeeds What step could i be missing? thanx, marc

Hi, i'm trying to follow the steps from the Virtualization WWDC22 session. The sample app provided works ok "as is", but if I use the same APIs in my own app (i.e. a project I started from scratch), I get errors such as Internal Virtualization error. Installation service returned an unexpected error. when downloading the "best supported" image via VZMacOSRestoreImage.fetchLatestSupportedWithCompletionHandler, and Internal Virtualization error. Unable to connect to installation service. if I try and install one I downloaded myself. I did add the <key>com.apple.security.virtualization</key> <true/> entitlement to my own app and (since this is arm), it is codesigned (with -) . But could it be that there is some other application-level flag or setup needed to enable virtualization use? Since I'm calling the exact same APIs, and neither seem to depend on much prior setup I could get wrong, it seems weird that they work in the sample app but not when called from my own app... Ideas? thanx!

I have the following code: &#9;var codeFont := NSFont.fontWithName("SF Mono Regular") size(11); &#9;var attributes := new NSMutableDictionary<NSAttributedStringKey,id>(); &#9;attributes[NSFontAttributeName] := codeFont; &#9;attributes[NSForegroundColorAttributeName] := NSColor.blackColor;; &#9;var charSize := new NSAttributedString withString("Q") attributes(attributes).size; &#9;writeLn("attributes {0}", attributes); &#9;writeLn("codeFont {0}", codeFont); &#9;writeLn("charSize.height {0}", charSize.height); on Catalina, it prints attributes { &#9;&#9;NSColor = "NSCalibratedWhiteColorSpace 0 1"; &#9;&#9;NSFont = "\"SFMono-Regular 11.00 pt. P [] (0x14f73aa80) fobj=0x14f728120, spc=6.80\""; } codeFont "SFMono-Regular 11.00 pt. P [] (0x14f73aa80) fobj=0x14f728120, spc=6.80" charSize.height 17 When I build and run it on a Big Sur/Intel machine, it prints the same. When I build and run it on an Big Sur/M1 machine *without a deloyment target set, is also prints the same. but: if I build with a deployment target of 10.15 (*), I suddenly get: attributes { &#9;&#9;NSColor = "Generic Gray Gamma 2.2 Profile colorspace 0 1"; &#9;&#9;NSFont = "\"SFMono-Regular 11.00 pt. P [] (0x142f26dc0) fobj=0x142f1fad0, spc=6.80\""; } codeFont "SFMono-Regular 11.00 pt. P [] (0x142f27500) fobj=0x142f1fad0, spc=6.80" charSize.height 13 Note that the height of the string is reported at 4 display points smaller than it should (also, the font name is shown as "gray" instead of black, but ok...) If I actually draw, the font draws the same size (and proper black) — but all my metrics that calculate where and what to draw based on what size gives me are of course off, so everything goes wrong (e.g. I end up drawing lines too tight together) What could going on here? is this "as designed" or am I missing something? (* actually, it might be a bit more complicated than that. The above is with our own compiler, Elements, and repros consistently, when I switch the deployment target back and forth. Compiling the equivalent ObjC with Xcode 12.2 or 12.3 Beta, I always get the wrong value of 13, even if I drop the deployment target. And to make things more complicated, I have an Intel-only build of my app, migrated from my Catalina/Intel machine, that has the proper behavior even when run on Big Sur/M3, but the same app from our build system, also Catalina, shows the same wrong behavior. it's all very weird)

It seems that when suing NSTask to launch an executable from a process running under Rosetta 2, the new process will always run under Rosetta as well, even if the target executable has an arm64 slice. Is there a way to override/prevent this? In my concrete case, I have a x86_64 process that is launching debugserver (from inside Xcode 12, which is a fat binary with both x86_64 and arm64 slices) to debug another (arm64) process. In my testing, the exact same command line for debugserver works fine when run from Terminal, but when my process launches it via NSTask, debugserver thinks its target binary is/should be x86_64, and thus fails... Thoughts?

Hi, i'm looking for a way to detect, from an x86_64 executable (ostensibly running in Rosetta), whether the architecture of the current system is arm64. Unfortunately, it seems even calling out to "/usr/bin/uname -m" via TSTask does not work, as uname seems to return "x86_64" the called from a x86_64 process, even on Apple Silicon (it returns arm64 as expected, when the calling process is arm64 too). Is this as designed, or a bug? And does anyone have an alternative suggestion to safely detect the system architecture?

I'm using "Sign in with Apple" in my iOS app. I'm pretty much following the boilerplate code from https://developer.apple.com/documentation/authenticationservices/implementing_user_authentication_with_sign_in_with_apple, and all seems to be working fine for logging in: I get a guid-looking identifier in appleIDCredential.user which I store persistently, as well as the user's name and email (if provided). the problem, is when I kill and restart my my "production" app (a "app store ready" release build, from test flight, but with extra logging), i reload the user identifier and I can confirm in Console.app that it's the same as was stored in the previous run, *but* getCredentialState always returns 2, "not found". if I manually log in again, I get then same identifier as before, but on next relaunch, I still get "not found" and have to log in again. what could be going on, what could I be missing? I'm testing on iOS 13.0 thru 13.6, also 14.0 beta, same everywhere, since day one.

I cannot see thios documented anywhere — has anyine figured our how to use xcodebuild to build a propject for UIKIt for Mac (ie Catalyst)?You can specify "-sdk iphoneos" vs "-sdk iphonesimulator" top toggle bertween those two targets, but "-sdk uikitformac" does not seem to work ("SDK not found"), despite Xcode itself using that nomenclature (e.g., it builds to a "Debug-uikitformac" folder, etc). i also tried different SDK values that might have made sense (such as "-ssk macabi"), but no avail.Suggestions?

I'm wondering if anyone else is seeing that calling codesign (manually from Terminal) just hangs (and niot showing a popuop dialofg asking for permission, either).for example, i'm running/usr/bin/codesign -v --deep --force --sign "Developer ID Application: MyCompany" "./MyApp.app"and it just never returns.