Can you share some documentation regarding this path? Here is Apple documentation. - https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPFrameworks/Tasks/InstallingFrameworks.html One concern with this approach is that other installers can overwrite some common library I suppose that is possible, but highly unlikely. There are really no such things as "common" frameworks. (eg libcurl.dylib, assuming we can also place dylibs here).  That path is only for frameworks. If you have stand-alone dylibs, a more appropriate place would be /usr/local/lib. However, in /usr/local, you stand an excellent chance of some other installer overwriting a common library, or of the user deleting it. libcurl, however, is part of the operating system. You don't need to install that. If you did want to install your own build of libcurl (which wouldn't necessarily be a bad idea), the best approach would be to create your own framework and statically link that to your custom build of libcurl.

There are no exact breakdowns available via the Apple Developer Console that provides developers with a full breakdown of who pays what. It isn't in the developer console. It is in the Apple Developer Program License Agreement. - https://developer.apple.com/services-account/agreement/XV2A27GUJ6/content/pdf I have read if you are a developer selling apps in the UK, there is no VAT to pay as Apple handles it. Whereas I am read Google Play don't handle any VAT. You will have to ask Google how their system works. Is anyone able to clarify this point for me? No. This is an anonymous support forum. No one knows where you are located or what your particular tax structure might be. The rules could be different for you than they are for someone else. This is what makes global sales taxes such a challenging issue. Please review the Apple Developer Program License Agreement that I linked to above. If you are not able to figure out what your tax obligations are, then you will need to hire a tax attorney to help.

I guess I will be Etresoft now. I need to use my Developer account to upvote or downvote. And I need 100 points to do that. <sigh> Those 971 points in the other account aren't going to help.

Is there no way to find threads you previously participated in, other than to bookmark them in your web browser or something? Nope. The only reference to my past activity seems to be on my profile... which only mentions the number of posts I made, but doesn't mention what or where they are or provide any way to find them. Yep. On the bright side (?), it is so difficult to find new threads in over 300 separate forums that you are very unlikely to actually participate in multiple forums. So just bookmark your favourite tags and go to those to see if there is any new activity in your threads.

I downloaded your existing apps and all of the XSLT files are 1.0. Can you confirm that you are re-implementing the XSLT operations as 2.0? And can you confirm that you absolutely, desperately need XSLT 2.0 support and no other solution will suffice? XSLT 2.0 is usually only used via Java, in a server context, and only in a handful of very specific, XML-friendly industry domains. This is the best reference that I've seen for XSLT version support: (https://stackoverflow.com/tags/xslt/info/) I don't know what you mean about that external C library that is no longer acceptable in the App Store. The only reason I could think of would be a GPL-licensed project. If that's the case, then the App Store isn't the problem, it's the license. The GPL license is designed to prevent you from using the code with Apple platforms. Releasing such code in the App Store would be a violation of the license. That makes the app illegal and Apple doesn't allow illegal apps in the App Store. From my casual inspection of your app bundles, it seems that XSLT may only be a tiny part of your apps. It doesn't sound like trying to support XSTL 2.0 is worth the effort. If there was something specific you need that XSLT 1.0 doesn't provide, maybe you could implement your own EXSLT function. Anything that Apple provides is going to be XSLT 1.0. There really isn't any WebKit interface per se. I think that just refers to the standard XSLT HTML stylesheets that I think all web browsers support. There's no point in trying to do XSL via Javascript in WebKit. That's just a Rube Goldberg architecture. My software makes very heavy use of XSLT and all of it is XSLT 1.0. You can do pretty much anything in XSLT 1.0. Certain things may be easier to do in XSLT 2.0, but the effort required to support that far exceeds the gain in convenience. And if you are willing to write some EXSLT, then there's virtually nothing that you can't do in XSLT 1.0. Apple has some native XML and XSLT APIs available: (https://developer.apple.com/documentation/foundation/archives_and_serialization/xml_processing_and_modeling/) Personally, I don't use Apple's APIs. The DOM processing APIs, which include the XSLT logic, are macOS-only. It was quite easy to implement my own, more powerful, wrappers around the lower-level APIs provided by libxml2 and libxslt for parsing XML and transforming XSLT. I do all of the XML generation logic on my own. I've only written EXSLT functions in Perl, where they are very easy. They are probably much more difficult to implement in C. I certainly wouldn't consider Apple's Objective-C API, or the lower-level C APIs, to be "unsafe". They are C-based, so you have to be careful. You may get some minor memory leakage in instruments, but not enough to worry about. The biggest problem is that they are Mac-only and essentially forgotten. Apple doesn't pay much attention to them and neither do most app developers. Using the lower-level C APIs provides some insulation against potential deprecation and removal of the Apple wrapper APIs. I'm not sure what you mean about a "clear statement in the reference documentation". XML, and by extension XSL, are not "popular" technologies, in the social sense. While they are widely used in many industries, you won't find much about them on the internet except as fodder for mocking older developers. There is very little overlap between XML and the practice of most app developers for Apple platforms. It is safe to assume that everything is XSLT 1.0 and will always remain so.

Sorry. I only looked at the other app. I missed that file. However, I looked at the file and, other than the version number, it looks like XSLT 1.0. I changed the version from "2.0" to "1.0" and ran it against some sample data posted by acmuller and it seems to work fine. I admit that I'm not familiar with XSLT 2.0. There may be some differences in behaviour even if the syntax is identical, but it seems like you can just change the version number back to "1.0". Unfortunately, after looking more closely at this project, it seems much more problematic than I originally assumed. I thought this would be a straightforward code-level question involving one of my favourite technologies. I was wrong. So, I don't know what to tell you. Symbol conflicts between your code and any private frameworks are easy to fix. Apple only officially supports the public APIs as documented on the Apple developer site. Internally, Apple may implement those APIs with various other 3rd party frameworks, but you can't use those. It's always possible to have a symbol conflict between Apple's private frameworks and your own code, but you can just rename the symbols in your code. Going beyond code-level issues, I see a couple of potential problems getting the app published in the App Store for iOS. But I'm not Apple, so all I can do is speculate and that gets messy in a hurry.

I can reproduce what you are seeing. Try adding the following to the map view delegate: func mapView( _ mapView: MKMapView, regionDidChangeAnimated animated: Bool) { addScale() } I tried your code, making PISimpleMapView its own delegate, and it seems to fix the problem.

This issue was mentioned in this WWDC video. It refers you to this older video from WWDC 2020. You already mentioned two of the other links I was going to refer to you. I tried your app and it said it ran to completion with no error. It doesn't seem like it should work at all since you don't seem to have the proper entitlement and usage string. I thought I had changed the destination IP to be a local IP address. But I was testing in a VM, so maybe the networking is too funky and it was treating it as an internet connection. You don't need to be administrator to approve local network access. Obviously, for issues like this, Apple does not provide any way for an app to bypass user consent. That would defeat the purpose. Apple does usually provide some MDM key to preset the value for managed devices. If this is library code, I don't see how it would be a problem. It's the app developer's responsibility to manage this.

I assume the mere act of copying the license (a file called devel.lic which is a small text file) is causing this. Yes. Any change to the application bundle after signing could trigger this. I think there are ways to validate a signature while accepting a certain level of irregularity. But you don't have any control over how the OS on an end user's system is going to perform the validation. And those validation strategies will likely change as the OS evolves. The best course of action is to always assume the bundle never changes. There are many alternative places to store licensing information. I recommend keeping it in the user's home directory so you don't have to ask the user for admin privileges to create it. Why does it say it “does not seem to be an app”? Most likely the bundle structure diverges too far from what is expected. Remember that the purpose of all of this is to detect and block malware, which often uses novel ways to structure bundles and executables. The idea is to exploit edge cases that Apple never anticipated in order to confuse the system and gain more privileges. The more unusual your app is structured, the more likely you are to be impacted. This can happen during development or at an unexpected time later on. This self-modification of the files in the Contents/Resources directory is a huge feature. We allow downloading of patches, which add features and fix bugs in the product. Is this going to be a problem, going forward? Yes. In theory, it's possible to modify parts of the application bundle and then supply an updated signature that matches the new bundle. But I'm not sure if anyone has ever managed to do that successfully. It's a high-risk, high-effort solution when storage and bandwidth are cheap. Furthermore, you shouldn't be putting patches or executable code in the Resources directory. That is a special location for non-executable resource data. Using it for any kind of executable code is an excellent way to give yourself signing and/or notarization problems.

How do applications patch themselves and still not run afoul of Gatekeeper, then? Are they just complete reinstalls? I can't speak for all applications. For me personally, life is complicated enough as it is. You can definitely patch your application bundle, but one of the files you replace should be the signature. And that signature will have to be valid for the application bundle as it is on (the user's) disk. Apple is saying we must throw that away, because the patches do include binary executables (shared libraries), though they are code signed. I'm not making any statements about Apple. My position is that it's better to maintain a valid, signed, notarized bundle on disk. I'm confident that this will result in an easier, more trouble free experience for both the user and the developer. I've definitely seen developers use different methods. I just can't recommend those other approaches. Patching the app bundle is not any kind of violation or anything. It's just tricky, prone to failure, and creates the potential for a significant problem later on, when you are least prepared to deal with it. From what I've learned with my own app, I can tell you that Apple has, so far, been very conservative with respect to signature validation. Lots of developers find it challenging to get past Gatekeeper. But once they get installed, they can pretty much do whatever they want. It might not always be that way. Moving everything that changes outside of Contents/Resources will mean either it's user specific, or we'll need to use /Library/Application Support/, which will require admin privs. Also, it's quite a lot of redesign for us to move everything out. That's not what I said. I said that the Resources directory should be for non-executable data - images, text files, translations, data files, whatever. But it's not the place for executable binaries or libraries. Ideally, nothing should be changing. But if you do want to make changes, you can change anything. It's just that the signature should match. There is a version of "Library/Application Support" available in the user's home directory. If you need a place for dynamic source code, plug-ins, libraries, etc., that would be the place for it. I'm not familiar with your code. And I'm not familiar with apps that scatter components around. There might be better locations than "Application Support". There is also a "Frameworks" directory, for example. Apple notarized our app and didn't complain then. Seems like I should have gotten errors or warnings for that. Notarization is used for more than just apps. One mistake I see a lot in this forum is assuming that a successful result from the command-line notarization tools means that notarization was successful. It's not successful until it runs in a pristine environment like a VM.

Can you explain more about this? It seems we might have to go that route, otherwise, it's the redesign of a 40 year old application. I was talking about the same process that Quinn described. I've never done it. Perhaps you should use a DTS ticket for more details.

That's a debug build. It will only be built with your native architecture. Do an archive build and it will contain all architectures.

when i build a archive it's fail "Roxane.1 no such file or directory" Something in your project is not configured correctly. I recommend creating a new project, using the same name, but in a different location, from the template. Don't make any changes. Just build and test an archive build. Then you can just copy your existing code over to the new project.

we can load the OpenSSL libraries fine. They work fine in macOS < 15. They do not work in macOS 15. lldb hangs in macOS 15. It does not hang in < 15. You are talking about loading the dynamic library at runtime. That is always going to be more challenging than embedding a framework into a static app. The only advice I can give is to stick with one, canonical approach. That means forget about Homebrew and focus on the official version that you've built yourself. Much of what you've posted is only relevant to the Homebrew build. I realize your project is very complicated already. You don't need additional complications.

Signal handling is a Unix functionality that pre-dates Linux. Technically, it's more accurate to say that Linux signal handling came from macOS (via BSD), not the other way around. But this mechanism is not related to language runtime exceptions. Apple has its own perspective about exception handling that is likely different than what you are expecting. I can't speak for Apple regarding what their specific philosophy might be. I would suggest that you not worry too much, or at all, about signal handling. If you did need support for some specific signals, then you can add that support as appropriate. I'm not sure what you are saying about the relationship between C++ exceptions and signal handling. I recommend that you handle all C++ exceptions before they could be exposed to any higher levels or Apple APIs such as Objective-C, Swift, or especially SwiftUI. If there are any Swift APIs that depend on Swift exceptions, then you will need to handle those. But I wouldn't recommend building too much of your own exception-based architecture beyond what is required for Apple APIs. Your expectations about how exceptions should behave and interact with the system might not be the same as what Apple intends.