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 having a strange issue with NSDateFormatter. I'm using a fixed dateFormat string of yyyyMMdd-HHmmss, but on my iOS device (only; its fine in Simulator or on Mac) I get an extra AM/PM added to the string, and also missing leading zeros for the time portion: dateFormat: "yyyyMMdd-HHmmss" result 20200725-22454 PM where I'd expect (and elsewhere get) dateFormat: "yyyyMMdd-HHmmss" result 20200725-022454 any ideas what I could be missing? Both my Mac and my test phone are set to 12-hour time, but as I understand it local settings should not matter when providing a dateFormat string...

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.

IIRC, WWDC 2014 had a great session (no longer available among the 10 or so videos still left from 2014) about best practices that are relevant again for Big Sur for "automatically" getting the proper transparent sidebar look and for extending toolbars. Is there any documentation (I could not find any) left on this topic, aside from the (sparse) info in this years "adopting macOS 11's new Look" video? In particular, I'm having two issues I need guidance on: 1) even after converting to NSSplitViewController (was using plains NSSplitViews before), the proper Sidebar behavior for the left pane, etc, I'm, not getting the full height sidebar. What's best steps to investigate whats stopping this "magic:" from happening? 2) I have a small strip of controls underneath the toolbar (similar to Xcode's jumpbar, say). IIRC the Yosemite talk had information about how to "extend" the translucent toolbar behavior to such an area — but again, I cant find any official information on howe to do this, anymore. It seems that the HIG only discusses high-level non-code design info, while the AppKit class documentation does not touch on these design considerations at all (in fact eg the NSplitViewController doc us severely lacking, literally just saying "its very complex". duh! Am I missing a third set of docs, aside from (disappearing old WWDC videos) that covers the intersection of these two?

One of my apps, which works fine on Catalina. consistently crashes when I go full screen in Big Sur beta 1, with the following assertion. None of the code omg the stack involved is my own. this happened with my previously built (against Catalina) binary, as well as when I rebuild it against the macOS 11 SDK. Is anyone seeing something similar, or has any idea what could be wrong? Assertion failed: (commonAncestor != nil), function -[NSView _transformFromView:], file /AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/AppKit/AppKit-1997/AppKit.subproj/NSView.m, line 6486. 3:35 Main Thread (1) Queue : com.apple.main-thread (serial) #0 0x00007fff694ef842 in __pthread_kill () #1 0x00007fff695b5671 in pthread_kill () #2 0x00007fff694627c0 in abort () #3 0x00007fff69461a76 in __assert_rtn () #4 0x00007fff26903868 in -[NSView _transformFromView:] () #5 0x00007fff26c92f8b in __27-[_NSPortalView2 drawRect:]_block_invoke_2 () #6 0x00007fff26606f09 in +[NSAppearance _performWithCurrentAppearance:usingBlock:] () #7 0x00007fff26c92f20 in __27-[_NSPortalView2 drawRect:]_block_invoke () #8 0x00007fff26645749 in -[NSFocusStack performWithFocusView:inWindow:usingBlock:] () #9 0x00007fff26c92e7b in -[_NSPortalView2 drawRect:] () #10 0x00007fff2678a38a in _NSViewDrawRect () #11 0x00007fff26e9d13e in -[NSView _recursive:displayRectIgnoringOpacity:inContext:stopAtLayerBackedViews:] () #12 0x00007fff267899b0 in -[NSView(NSLayerKitGlue) _drawViewBackingLayer:inContext:drawingHandler:] () #13 0x00007fff33c47241 in CABackingStoreUpdate_ () #14 0x00007fff33caa719 in invocation function for block in CA::Layer::display_() () #15 0x00007fff33c4678d in -[CALayer _display] () #16 0x00007fff267891d4 in -[_NSBackingLayer display] () #17 0x00007fff266f4d4a in -[_NSViewBackingLayer display] () #18 0x00007fff33c457b2 in CA::Layer::display_if_needed(CA::Transaction*) () #19 0x00007fff33d77379 in CA::Context::commit_transaction(CA::Transaction*, double, double*) () #20 0x00007fff33c2349d in CA::Transaction::commit() () #21 0x00007fff2679e815 in __62+[CATransaction(NSCATransaction) NS_setFlushesWithDisplayLink]_block_invoke () #22 0x00007fff26ed2c25 in ___NSRunLoopObserverCreateWithHandler_block_invoke () #23 0x00007fff296de055 in CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION () #24 0x00007fff296ddf70 in __CFRunLoopDoObservers () #25 0x00007fff296dd5a6 in __CFRunLoopRun () #26 0x00007fff296dcbea in CFRunLoopRunSpecific () #27 0x00007fff280c3dd0 in RunCurrentEventLoopInMode () #28 0x00007fff280c3bc9 in ReceiveNextEventCommon () #29 0x00007fff280c38ec in _BlockUntilNextEventMatchingListInModeWithFilter () #30 0x00007fff26619e2b in _DPSNextEvent () #31 0x00007fff26618659 in -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] () #32 0x00007fff2660ab4b in -[NSApplication run] () #33 0x00007fff265dea58 in NSApplicationMain () #34 0x000000010588c4b7 in +[Program Main::] () #35 0x00007fff69389c71 in start () #36 0x00007fff69389c71 in start ()

Bit of a handful that title, sorry ;) My app has an NSOutlineView as a source list, and win selecting a node in the outline, it will show a new custom NSScrollView based view for the item. As part of showing the view, I restore the scroll position to a previous value, or a reasonable default. Now here's the weird part; this works fine when I *click* the NSOutlineView. I show my view, set the scroll position, and the view shows instantly. However, when I instead use the cursor keys to move up and down between items in the outline view, rather than showing the right position instantly, the view will appear scrolled to one end, and then *visibly* scroll up or down (depending on the key that was pressed in the NSOutlineView) to the correct position. Now, all I am doing is reacting to NSOutlineView's outlineViewSelectionDidChange delegate method, so none of my resulting code that shows the view even has any knowledge of *how* the selection changed (keyboard, mouse click, or whatever), at all. But yet, the NSScrollView behaves visually differently, as if it somehow "remembers" the keypress. Does anyone have any idea what could be going on here, and — more importantly — how to prevent it?

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.