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 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.

I believe you can do that using MDM. However, macOS is a consumer operating system. That is what it is designed to do. It may be possible to turn off various parts via SIP, but I don't know. If you wanted to use it for this kind of work, you will likely have to find some other way.

It would be the same.

Hey, were you able to figure out why this is happening? We are facing a similar issue here. Would be helpful if you could share how you dealt with the problem You should probably open a DTS ticket for help with this problem from Apple. This question is a year old and these forums are one of the quietest places on the internet.

That's the way it works. Dynamic libraries can't "depend" on static libraries. They have to be self-contained. You can link the static libraries with with dynamic libraries and then omit the static ones from the rest of the project, because they will already be available in the dynamic library. But if you have cross, or multiple, dependencies, then you may need to run everything as dynamic libraries.

You can assign a background quality-of-service to these tasks. That should keep them on the high-efficiency cores. See the documentation. - https://developer.apple.com/documentation/os/workgroups/tuning_your_code_s_performance_for_apple_silicon?language=objc

I understand, eventually most of the software providers are going to release ARM based version, but how long I have to wait? Those are all 3rd party products. You will have to ask the developers. Is Rosetta 2 good enough to handle most of the software written for x86 architecture to run in M1 ? Yes. However, there are some additional security requirements for the new Apple Silicon chips. In the past, those open-source projects have treated those as merely "suggestions". And by "past", I mean "for years". In some cases, they now have only a few months to learn a lot of basic Mac development techniques.

There are a number of methods to load from a URL or data and supply a specific base URL for relatively-referenced resources on the page.

Perhaps HEIC is lossless after all. What is happening is that when an HEIC destination writes the image to disk, it resizes the image by one pixel. It actually crops one pixel on the bottom and left. You would only know it if you had added a noticeable, 1 pixel border, which I had done to debug. Obviously, a one-pixel resize is going to remove any losslessness. One thing you can do is manually shrink the image by one pixel width, and two pixels high, shifting the image up by one pixel. Then it won't crop any of the image. Of course, now you've done two one-pixel resizes, but at the least the geometry will now be correct. Apparently someone at Apple already knew that because Preview seems to do that double-resize too. But at least HEIC is still useable for reading and for low-resolution previews.

Apparently, this is a known bug: https://developer.apple.com/forums/thread/668919

I'm seeing the same problem. I had been using Catalina to do all of my official builds, but for various reasons I wanted to try it with Big Sur this time. I had noticed problems when exporting Developer ID builds. Every other export would fail on my quick look plug in. I guess I have to re-write my quicklook plugins, eh?

Yes, I mean trusted by Apple. What I have seen with experimentation is that when I sign with some TSA other than that of Apple's then Authority=(unavailable) is shown in signature, that’s the reason I'm not sure it will work. Basically, I'm exploring the option of signing artifacts with other TSA in case Apple's TSA is down. I doubt that Apple, or any reasonable company or organization, would trust anyone other than themselves. I have seen people try to justify a custom timestamp based on the fear that Apple's server goes down. But Apple is one of the biggest companies in the world, would you be able to find some other service that is more reliable? And what is the risk of a failure on Apple's part? And what is the cost of failure on Apple's part? By this I mean, how likely is Apple's server to go down and how long would it stay down? Also, can there be any unforeseen issues after signing? This is exactly what I am worried about, the unforeseen issues. Basically if there is slight possibility of any of the above issues then it becomes no-go for me but then it makes me wonder why is there an option to specify TSA in codesign command.  There is always a possibility of failure. In fact, there is always an absolute guarantee of failure. It is only a question of when. Are you going to find some other service that has a lower possibility of failure than Apple? And what additional risks or costs are you willing to spend for that (false) guarantee? As I understand it, the reason for this option is to allow signed software in an environment that does not have internet access. Such facilities typically have other, often physical, security mechanisms in place. In theory, you might be able to use a local timeserver in such an environment. But in any environment that has internet access, I can't think of any rational reason not to use Apple's servers. Think of it this way. If you do something funky and it breaks, that's on you. You bear sole responsibility for any and all damages. No one will remember or notice if your software was functional during some Apple outage. If there were a widespread Apple outage, some other cascading failure would likely prevent your software from working anyway. But if you accept the Apple defaults and it breaks, that's on Apple. No one will blame your company or software. A few haters might say that you shouldn't have trusted Apple, but haters should be ignored. You will never be able to satisfy them no matter what you do.

You should probably open a DTS ticket for this. It looks like you have some low-level kernel operations that are not working. Those are very difficult to do correctly.

You have installed some 3rd party software called "sentinel" that is interfering with the operating system at a very low level. I don't know if this is malware or, even worse, anti-malware. But that is definitely the cause.