If you run "codesign" on your executable, it tells you exactly what the problem is: /tmp $ codesign -vv -R="anchor apple generic" renderrob.app renderrob.app: unsealed contents present in the root directory of an embedded framework In subcomponent: /private/tmp/renderrob.app/Contents/Frameworks/Python.framework If you explore that framework using Terminal, you'll see what it's complaining about: /tmp $ find /private/tmp/renderrob.app/Contents/Frameworks/Python.framework ... /private/tmp/renderrob.app/Contents/Frameworks/Python.framework/Versions/._Current /private/tmp/renderrob.app/Contents/Frameworks/Python.framework/._Resources /private/tmp/renderrob.app/Contents/Frameworks/Python.framework/._Python Remove those files and try again: /tmp $ rm /private/tmp/renderrob.app/Contents/Frameworks/Python.framework/Versions/._Current /tmp $ rm /private/tmp/renderrob.app/Contents/Frameworks/Python.framework/._Resources /tmp $ rm /private/tmp/renderrob.app/Contents/Frameworks/Python.framework/._Python /tmp $ codesign -vv -R="anchor apple generic" renderrob.app renderrob.app: a sealed resource is missing or invalid file added: /private/tmp/renderrob.app/Contents/Resources/lib/python3.11/._site.pyc file added: /private/tmp/renderrob.app/Contents/Frameworks/._libmpdec.4.dylib Almost there. Keep removing those dot files... /tmp $ rm /private/tmp/renderrob.app/Contents/Resources/lib/python3.11/._site.pyc /tmp $ rm /private/tmp/renderrob.app/Contents/Frameworks/._libmpdec.4.dylib /tmp $ codesign -vv -R="anchor apple generic" renderrob.app renderrob.app: valid on disk renderrob.app: satisfies its Designated Requirement renderrob.app: explicit requirement satisfied Now you're good to go. Or at least, ready to notarize. Something in your toolchain is trying to create resource forks inside a zip file incorrectly. Are you building some of this on a non-Mac platform? I made a point to double-click your zip file to unzip using the expected procedure. I think you can use "ditto" on the command line to achieve the same result, but not "unzip". When using Finder, I shouldn't ever get those kind of dot files. (And for the record, they aren't even correctly structured dot files.) I understand a lot of internet folks don't like Xcode. I've got a long list of Xcode complaints myself. But I still use it because, even at its worst, it's better than anything else. I have a very complex project under development that was designed to use some of the most gnarly Linux/open-source build platforms ever known. It's bit the bullet and took the time to port it all to Xcode. It just insane how much better Xcode is at this. Those poor Linux masochists have no idea.

I swapped out my old deprecated code for the new WKWebView code similar to what you're using. It was surprisingly easy. It does require macOS 11. And I lose my custom headers and footers. But otherwise, it works fine. In my code, I'm using fit pagination for both horizontal and vertical. I think that may fix your ridiculously tall pages. Safari also generates such pages when exporting to PDF, so perhaps "automatic" is what's doing that. Otherwise, I have a document-based app and I don't call runModal on the print operation. As I said above, I'm using NSDocument's "printDocumentWithSettings:..." after the web view has completely loaded.

My code is much more elaborate than that. To start with, I create my own print operation via "printOperationWithSettings:error:" (still Objective-C). I don't call "runModal" at all. WebView is really tricky with printing, at least for me. I create a new view just for printing, then load it, and print in my load completion using NSDocument's "printDocumentWithSettings:...". And of course, all this still uses the long-deprecated WebView class. I don't know if Apple ever added print support WKWebView. Still works in Tahoe. You seem to be trying to use the new logic. I don't plan on using WKWebView in the future anyway. So if Apple eventually removes the old WebView I won't be affected.

While you can't control when people review or what they say, you can control when they're prompted to post a review. Make sure to only prompt them when your code detects that they are getting real value from your app. Don't just pop it up at launch time. Wait until they're (done) using a key feature. Also monitor the reviews closely. For a real, non-scam app, 3.5 is pretty good. You're always going to get 1-star junk reviews saying, "the app works great but costs too much", or worse. While you can't stop those, you can turn them into your favour. Reply to those reviews and turn them into an advertisement for your app. Show how responsive you are. Point out valuable key features. Etc. If the haters see that you can effectively turn their 1-star reviews into useful advertisements, they won't bother.

First of all, never use comments for replies. Apparently they don't trigger notifications, for people who use them. But they also don't get noticed at all. WGS 84 is a large and complex standard, among many similar large and complex standards designed for dealing with coordinates on the earth. However, because WGS 84 is such a broad standard, it isn't going to have much practical meaning in more specific contexts like a map display. When it does have a specific meaning, it will typically have some kind of qualifier. It is usually better to refer to EPGS identifiers. Apple Maps is a good example. The Apple Maps display uses EPGS:3857, AKA "WGS 84 / Pseudo-Mercator". But most government and professional mapping systems like ArcGIS use EPGS:4326, AKA "WGS 84". You can easily see the difference between these two systems in an image or map. The above references to CLLocationCoordinate2d using WGS 84 is also true, but the significance there is related more to where a particular lat/long coordinate is on the earth, rather than the overall map display. However, I don't know which interpretation is relevant for this question regarding China. China itself doesn't use WGS 84 or the EPGS system. They have their own, proprietary system that purposefully obfuscates locations on the map. China is very strict about mapping. They don't allow foreign companies, like Apple, to display maps in China. That's why Apple has to use Amap. Why does any of this matter? What is the OP trying to determine with question #1? Is question #2 even legal? I can't answer either and I recommend just ignoring these literal "edge" cases. If someone has a more specific need that seems like it would be 1) worth digging into and 2) legal, then maybe add a new reply instead of a comment.

Using Instruments, I see that the view seems to recreate the subviews three times per keyboard event, so I'm clearly doing something wrong. Not necessarily Most SwiftUI stuff on the web is iOS-oriented, and typically has a focus on fairly simple apps, so the whole topic of dealing with menu commands doesn't get a lot of coverage Correct What I've been able to find is not particularly helpful for a full-fledged application like mine, so I'm looking for advice on how to structure the app. You don't have to use SwiftUI.

What kind of information are you looking for that you can't access? You tagged this post with AppKit. And you also mentioned Alfred and Raycast, which appear to be macOS apps. That means you're talking about macOS, where all this information is readily available. From what I understand, you can even get this information on iOS, but it's more difficult there. But on macOS, (almost) anything you want is right there.

All you need to do is take some existing icon image as use it as a background template. You can even use your existing, post icon-jail image on Tahoe. Make sure that your content doesn't extend beyond the edge of the squircle. You'll probably want to add a thin shadow border so the icon looks decent on older versions of macOS. On Tahoe, if your squircle is good enough, then it will only its own border - kind of an icon ankle-monitor rather than icon-jail. But it looks fine. You could even Liquid Glass your icon to the max in Icon Composer, then export it as PNG images and use them on old Xcode/OS versions. The only thing you really lose with this approach is the dynamic dark version. Even the clear and tinted versions looks decent.

Obviously the developers felt they needed it. You'd have to ask them for details. Obviously you haven't included it in your project. Freetype is a 3rd party framework. It's commonly used with open source tools, but relatively rare on macOS.

Don't use comments to reply. They get lost and no one ever sees them. Freetype is a commonly used library for certain open-source projects. In that context, it could be used as a static library. However, if your case, the dynamic library libsfml-graphics.2.6.2.dylib is trying to load it as a dynamic library.

The operating system is ready It is not. Xcode barely runs on macOS as it is. Xcode is the single most crash-happy app I have. It crashes on me at least 3-4 times per day, every day. Xcode on iPad would not be a pleasant experience.

That doesn't have anything to do with static libraries. It just can't find an appropriate dynamic library.

Looks fine here.

I can't tell you any more than I already have.

GDAL is for much more than just extracting coordinates. You would use GDAL to actually warp the image into a new 2D representation, based on your selected projection. And GDAL will do that out of the box (not true), much more accurately than any perspective transform. Any geospatial data is likely going to be much larger than anything Apple supports, especially on iOS. Apple APIs are designed to handle an image generated by the on-board camera. Even the latest iPhones released today are still touting 48 MP images. Your moderate-sized geospatial PDF is over 10 times larger than that. And you're using iOS, which has very limited RAM. Even on macOS, where you can open these large images, it will lock up the UI for any operation. And I'm curious about something. One thing that GDAL doesn't support out of the box is geospatial PDF. It requires one of a few different PDF libraries, each of which is problematic in its own way. Which one are you using?