I have been asked the above question by a long-time developer, and I don't know the answer. To find out I fired up Xcode (11.0beta6), added my non-developer AppleID to the account preferences, flipped the signing team from my developer account to the new "Gavin Eadie (Personal Team)," hardened the app, archived it and tried to send it for notification with "Developer ID" selected as the distribution method.My non-dev account was happily given an "Apple Development Certificate" via Xcode (visible in account prefs) but notarizing was refused by: Team "Gavin Eadie (Personal Team)" is not enrolled in the Apple Developer Program.Is "enrolled in the Apple Developer Program" the same as "hasn't paid $99 this year"? And how did I get a Apple Development Certificate if I'm not enrolled? The documentation around this feature is astonishly confusing. Is the "Apple Development Certificate" that Xcode got me not a "Developer ID certificate" as referenced in the following Xcode help text?"In some cases, you may want to distribute an app outside of the Mac App Store. Because the app won’t be distributed by Apple, assure users that you are a trusted developer by signing your app with a Developer ID certificate. Users gain additional assurance if your Developer ID-signed app is also notarized by Apple.""A notarized app is a macOS app that was uploaded to Apple for processing before it was distributed. When you upload a macOS app to be notarized by Apple, you’ll select Developer ID as the distribution method and it’ll be code signed with a Developer ID Application certificate."

Building a large science software package on macOS11.6 with only the Command Line Tools (CLT) installed (Xcode is not installed). All was working while MacOSX11.sdk was the newest SDK (which was true when the project started last year), but a recent re-install of CLT advanced support to MacOSX12.sdk which adds one new method to NSBundle.h (localizedAttributedStringForKey) that is tripping up clang. Isolated testing shows compiling against MacOSX11.sdk does still work correctly. Since CLT's default is to use the most recent SDK, builds now fail with a compilation error when Foundation's NSBundle.h is reached. Installing CLT creates SDK directories for the range of versions of macOS that are supported by the equivalent Xcode for example (from a Monterey Mac): √ ~ % ls -l /Library/Developer/CommandLineTools/SDKs total 0 lrwxr-xr-x 1 root wheel 14 Mar 15 10:23 MacOSX.sdk -> MacOSX12.3.sdk drwxr-xr-x 7 root wheel 224 Nov 30 2020 MacOSX11.1.sdk drwxr-xr-x 7 root wheel 224 Mar 15 10:24 MacOSX11.3.sdk lrwxr-xr-x 1 root wheel 14 Mar 15 10:23 MacOSX11.sdk -> MacOSX11.3.sdk drwxr-xr-x 7 root wheel 224 Feb 23 11:14 MacOSX12.3.sdk lrwxr-xr-x 1 root wheel 14 Mar 15 10:23 MacOSX12.sdk -> MacOSX12.3.sdk √ ~ % I believe there is no way to set the global environment to select the SDK that CLT should use for headers, libraries, etc. Two low-level options are to (1) change to xcrun —sdk *** clang or (2) use -isysroot to select the MacOSX11.sdk includes, but changing the many, many makefiles to do either is unacceptable (and would need conditionals for Linux). Is there a way to coerce CLT to not use the most recent SDK? xcode-select -s .. has been mentioned in other forums but is irrelevant because there is no Xcode on the Mac. And, since this package will be distributed to people for whom make is the tool of choice, Xcode is not an option. PS: my theory is that the new localizedAttributedStringForKey method needs a Monterey version of clang with a new feature related to concurrency support and Big Sur gives you an older clang without that feature, hence compiler barfing .. Gavin Eadie, Ann Arbor MI

I just wasted quite a lot of time on this .. so in case somebody else checks in here, beware that the following: formatted(dateTime.hour(.defaultDigits(amPM: .omitted))) does, indeed omit AM/PM, but it doesn't change to using a 24 hour clock. Instead, hours cycle through 1...12 twice a day.

I've read the definitive "Recording Private Data in the System Log" by @eskimo and the words at man 5 os_log and written code to, specifically, turn on "Enable-Private-Data" in my app. My application is a command line and I've configured Xcode to insert what I believe to be the appropriate incantations in an Info.plist file into the unstructured executable binary. When I run the app with Terminal, I see <private> output in the Console app where I expect values to be displayed in a public manner. Nothing I've read says that <key>Enable-Private-Data</key><true/> doesn't apply to command line apps, and my own understanding of the value of of the logging mechanism rejects that notion because logging is performed all over macOS, not just in a xxx.app environment. A this point, I'm firmly convinced this unexpected behavior is of my own doing, but I have paused the search for my (probably embarrassing) mistake, to write this note because of a 1% doubt I'm wrong. I'd be very happy to receive the, expected, assurance that logging configuration via an embedded Info.plist in a command line app does influence logging behavior. With that assurance, I'll know it's my problem and I'll search/find/fix. On there way there, I'll create the simplest command line app that exhibits this anomaly -- which will likely reveal my error and, if not, it'll be fodder for a bug report. Embedding an Info.plist into a command line app is a tad out of the ordinary but I've done it before (using Xcode or SPM) to carry knowledge into a CLI via a mainBundle.infoDictionary .. and in the particular case described above, I've printed that infoDictionary to show the successful embedding, viz: . . . . "OSLogPreferences": { "com.ramsaycons" = { "DEFAULT-OPTIONS" = { "Enable-Private-Data" = 1; }; }; }, . . . . Sonoma 14.5 / Xcode 15.4 / MBP (Apple M1 Max)

I've a SwiftUI-based app that draws into a Canvas for a complicated, dynamic rendering. Since that rendering is based on a map of the world, I transform the provided context to (±180°×±90°) longitude / latitude coordinates before stroking paths etc. Note that the necessary scaling flips the Y-axis because latitude increases up the screen. All is well until I add words to the picture. Because of the inversion of the Y-axis, the text is rendered inverted. mercatorContext.draw(Text(satellite.commonName) .font(Font(.init(.userFixedPitch, size: 4.0))) .foregroundColor(.white), at: satPoint) My solution was to draw the text via a another (un-inverted) context which corrects the words, but requires the satPoint to be flipped to place the words at the right place on the (inverted) map .. With that preamble, someone suggested I apply scaleEffect(y: -1) to the Text and avoid messing with more than one GraphicsContext. This seemed an excellent solution but it doesn't work .. context.draw(Text(.. draws a Text view but applying scaleEffect turns it into a View which context.draw can't accept. Once it's a View, I suppose I could convert it to an Image and context.draw(Image(.. instead which seems messy. I wondered about the scaleEffect function .. is it the case that it would ever actually return a view type that was different from the type it was given? Leaving my curiosity aside, what would a better way than using a second context to keep my text upright?

In my Swift macOS app, I use OSLog logging via the line: logger.log("••• channel \(channel, format: .octal(minDigits: 3))") .. and the Xcode console shows: ••• channel 29 .. the formatting to octal and minDigits are ignored. I've searched high and low for why this is happening (another app with the same line results in correct Xcode console output). The Console.app does show the correct output: ••• channel 035 Any suggestions regarding what I'm not understanding? Thanks.

The answer to my question is probably very simple but I've spent twelve hours trying to find it myself and I am at my wit's end. Searching the web shows multiple sufferers from, and multiple answers to, this same problem from at least ten years ago. I've a SwiftUI macOS/iOS app that is not finished but at a stage where I want to get it ready for TestFlight. I set it up on App State Connect and set Xcode Cloud to build it on GitHub commits. The first build revealed some obvious omissions, easily fixed, then I hit this one, for macOS: Missing required icon. The application bundle does not contain an icon in ICNS format, containing both a 512x512 and a 512x512@2x image. [In passing, I'll note the app, passes muster for the iOS platform] I make a 1024x1024 PNG .. convert it to ICNS with GraphicConverter .. convert it again with iconutil to a iconset and add it to my app. I do a regular build in Xcode and, there it is, my .icns file in the app bundle. I commit to fire off another Xcode Cloud build, but get the same error. Especially frustrating because I can see the ".. application bundle does contain an icon in ICNS format, containing both a 512x512 and a 512x512@2x image". It's hard to debug from an abundantly obvious incorrect diagnostic, but I do have to get past this and start fiddling with assorted settings .. ten builds later, still no joy. I did notice that my Info.plist file (autogenerated) doesn't contain the string "icon" and that, for example, Mail.app has: <key>CFBundleIconFile</key> <string>ApplicationIcon</string> <key>CFBundleIconName</key> <string>ApplicationIcon</string> If the build process checks for an icon based on the Info.plist contents then the reported error could be more correct, ".. application bundle's Info.plist file makes no reference to an icon in ICNS format .." One possible complication is that my app includes embedded custom fonts and so it need a Fonts.plist file for them. I set that file as my INFOPLIST_FILE <key>UIAppFonts</key> <array> <string>Zerlina.otf</string> <string>Gorton-Condensed.otf</string> <string>Gorton-Normal-180.otf</string> <string>Gorton-Normal-120.otf</string> </array> <key>ATSApplicationFontsPath</key> <string>.</string> The contents of Fonts.plist are copied to the final Info.plist. Maybe that defeated some of the Info autogeneration? I see no setting for CFBundleIconFile so can't add it myself. I'm confident pressing "Submit" on this will suddenly clear my mental murk but, for now, I need help .. thanks for any ..

Having written a SwiftUI based app on macOS 15.2 with Xcode 16.2 I built a version for Monterey (which required backing off some modern uses, like #Preview and others). But the SwiftUI layout, positioning and dimensions, didn't use anything new so, I was surprised that the app did not look exactly the same on Monterey. It was not wildly different, but enough that I had to modify several to frame, padding and font parameters in order to restore my desired appearance. I'm assuming that over the course of generations of SwiftUI, things change -- that's life, but this was a frustrating process for at least two reasons: view modifiers can't be conditionally compiled so something like this, for example, isn't possible RoundedRectangle(cornerRadius: 1) <if Monterey> .padding(.horizontal, -2.0) <else> .padding(.horizontal, -4.0) <endif> .frame(height: 4.0) previewing views is a challenge. Previewing on Sequoia doesn't show what the views will look like on Monterey. I can build the app on Monterey and use the non-macro #preview mechanism, but in order to do that, and the above, I'm pushed to maintain two versions of my app because the following doesn't compile: #if swift(>=5.9) #Preview("Monitor") { MonitorView() } #else struct MonitorView_Previews: PreviewProvider { static var previews: some View { MonitorView() } } #endif These are not show-stoppers but I do wonder if I'm missing some mechanism(s) to ease the pain, or if SwiftUI functional changes are documented.

I've just watched Scott Herschel's WWDC 25 session "Use structured concurrency with Network framework" and I am more than overjoyed to see said framework offer these new features. However, the documentation has not yet been updated (or it's not where I expect to find it) .. Is there more that I can read about the enhancements to the framework? One specific question is whether the structured concurrency portion of the framework's enhancement is backward compatible to before "26"?