Hi Ken, is it also possible to use a CALayer instead of a bitmap context to repeatedly draw over that same original CGImage? will it be faster? how does one that?

Did you finally find a decent way to draw a line over your CGImage (in your scenario and context) ? I'd LOVE to see how. I have similar task, but I'm on the Mac, and my "line"(s) aren't coming from user touches, but rather from some image analysis that finds shapes in the image, and I don't need to ever draw the thing onscreen - just process the image and produce another image. Still - I'd like to be efficient and not copy the whole (huge! in my case) image every time I need to draw a line!!!. Have you found the optimized way to work with this? BTW -- I think if you have a CALayer with a CGImage, you should be able to continuously draw over the layer itself, and the final "merging" of the layer with its image will only be done when you "draw" (or otherwise "output") an image from that. I don't know how to do any of this (or I wouldn't be writing this) but I think that might work? In anyway, be kind to add your own answer hopefully with little helpful code sample. Thanks

Sir, what does Hack.hackPath(dofFile.path) mean or do? can't see any such class/object/function definition. Is it at all necessary? And why would you need that long dance of building a file url in the user's Documents' folder, when you could (in theory) just supply a simple absolute path as string? (pun unintended)

In my case, a shell script is unavoidable (post-install script in an Mac Installer .pkg). However, copying the .app bundle completely (using cp -R) seems to work fine --- only if USER then double-clicks the app to open it. If however, another app will use NSWorkspace API to try and launch it, I get an error dialog saying the app is corrupt - and the NSError says it couldn't find a binary to run!!! `                NSWorkspace *ws = [NSWorkspace sharedWorkspace];                 NSWorkspaceOpenConfiguration *conf = [NSWorkspaceOpenConfiguration configuration];                 conf.addsToRecentItems = NO;                  conf.activates = NO;                 conf.hides = NO;                  conf.appleEvent = appleEvent;                 NSURL *appURL = [ws URLForApplicationWithBundleIdentifier:appBundleID];                 [ws openApplicationAtURL:appURL configuration:conf completionHandler:^(NSRunningApplication * _Nullable app, NSError * _Nullable error) {                     if (error!= nil)                         NSLog(@"Failed to launch app UI %@, error:%@", appBundleID, error);                     else                         NSLog(@"Launched app %@ in the background.", appBundleID);                 }]; ` Maybe an AppleScript will "install" it better? the app isn't installed in /Applications, but rather in a private place, and is a menu-bar "status item" app

Thanks. Should have suspected this... Living too many decades in the realm of C (errr and older...) I no longer see unsafeness there. Only freedom, responsibility and performance... But I fail to see how this is less safe Than the swift code - after all you kept all the conditionals in place. The only missing? point is freeing the addrList if exception occurs somewhere? but where should such exception come from? and if it comes, would freeing that memory save you from the situation? just wondering.

Any chance for an ObjC variant? I believe the underlying getifaddrs freeifaddrs getnameinfo APIs should be the same, but some of the swift trickery here worries me... if I back-translated this to C or Obj-C I might introduce issues... I would believe Mr. Eskimo (whose OpenTransport lines of code I still keep somewhere...) had this code running long before swift existed :) So... it would be much appreciated if you pasted something here.

However, by "avoid breaking wrongly coded software" they break our properly-coded software (some security tool with agent) that reports MacOS version to server - now we get both 10.16 and 11.0 in our servers, and there's not a single coherent API that will tell you even the "marketing" version of MacOS. we're actually bound to hard-wire translation table (10.16 -> 11.0 10.17? -> 11.1 etc.) Into our code for that. It's quite amazing, if you ask me, that MavOS 11.5.2 (some 5 major updates after 11.0) still reports that stupid 10.x on older SDK.

Hi, I experience a similar problem. I received a logo as .SVG image file from our graphic designer. The logo is actually text (black on clear). Now I want to display it in my Window (MacOS Cocoa) but I want it to adjust to dark-theme/light-theme automatically. I opened it in Safari and exported as .pdf (to preserve vector graphics and quality) renamed the PDF to "company-logo Template.pdf) as explained in Quincy's answer, added the image file to my target and resources, and made sure it's in the built bundle, and available by name from the main bundle. placed it in an NSImageView by name. and now it appears as gray square in Interface-Builder, and in runtime - as nothing-at-all. It is embedded in a vertical NSStackView, and the logo item is rendered at zero size. If I remove the word "Template" from the name - the logo looks OK on light-theme, but becomes black-on-dark-gray - almost invisible - in dark theme. Could you please explain a bit more about how to add the "Opacity" thing, and why do I need it? What's the meaning of "Opacity" with vercor graphics, and can a vector PDF have an "Alpha channel" ??? what would it contain? vector graphics too?

Can you spare a note on HOW you found the solution? I have the same exact error, but in totally different scenario - anonymous XPC service listener I create programmatically, suddenly goes astray with this error --- and I can't figure why. Now I got the idea that some remote call had wrong parameter values, or was null where null is forbidden, or something of that sort - and I'll review - but maybe you got more information to help you solve the issue?