Use the bundle ID.

Sorry, I'm not going to learn and then install CocoaPods, Alamofire, Zip, Swifter?, etc. If you had a stand-alone project, I might have downloaded that. I can give you some speculations.1) Your example project seems to be trying at least 3 different things, including the one, super-difficult thing I told you not to try (and embedded server), and commenting out the one, super-easy thing that eskimo and I told you to do (loadFileURL). 2) When you start down a path of maximum complexity, you are going to have to deal with those complexities and figure them out before you can ever get to that really simple thing you are trying to accomplish. You seem to have a really complex chicken-and-egg problem there. I don't know if it is worth dealing with.

It is 2019. Don't worry about "MBs".

Why do you want to use an XPC at all? Never assume that you will be able to accomplish the same things as Apple. You don't have access to the source code and private APIs.

I've already addressed the UIScene issue. The app runs on iOS 11. It appears to run fine, but it is just a placeholder for running unit tests at this point. It is those unit tests that don't work. On iOS 13, it runs fine and the unit tests work fine. But I still get that error message on iOS 13, even though the tests work. I don't know if the error message is even related to the failure to run tests. It seems to match the stack trace though.Currently, the "app" is just a single view with a quit button. It only exists in this form to run unit tests. What I'm trying to test is a monster open source framework (GDAL) that has taken me about 3 weeks just to get building on iOS. These unit tests are very important for me. For one, there is an awful lot of functionality to verify on an OS where this code has never run before. For another, some components are GPL and I'll be swapping them out with my own versions, but I want to use unit tests to compare my code against the "standard" GPL libraries.The framework is large (65 MB) but relatively simple in structure. I've gotten all of the components to link statically so that is not an issue. But given the scale of the iOS market, I'm concerned about any one-in-a-million failure as those scale up too. I'm not too familiar with iOS development either. I see many recommendations to delete derived data, clean, delete apps, reboot devices, etc. For example, I did have trouble with a resources directory named "Resources". I had forgotten about that. So is this failure just an after-effect of that earlier configuration problem because I'm using the same device that I had tried to use with a "Resources" resources directory? Is that why the other device works fine?

I was able to answer one question. I am a creature of habit and I do have another iOS 11 device. I get the same failure on this device too. Here is the backtrace:* thread #1, stop reason = signal SIGABRT * frame #0: 0x000000010152e2f8 dyld`__abort_with_payload + 8 frame #1: 0x000000010152dad0 dyld`abort_with_payload_wrapper_internal + 100 frame #2: 0x000000010152dafc dyld`abort_with_payload + 12 frame #3: 0x0000000101504314 dyld`dyld::halt(char const*) + 312 frame #4: 0x00000001015073c4 dyld`dyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**, unsigned long*) + 6888 frame #5: 0x000000010150121c dyld`_dyld_start + 68And error message: dyld: could not load inserted library '__PLATFORMS__/iPhoneOS.platform/Developer/usr/lib/libXCTestBundleInject.dylib' because image not foundI don't always get the error message, but it does always fail with the same backtrace.It is not a critical issue. It just makes me a little nervous. I have an iPhone 6 on the way so I can test with iOS 12. I'm aware of rates of iOS adoption. It is just that I see random, unexplainable failures even on my Mac app. I don't want to just blame these issues on random failures or buggy Xcode. If it fails, I'm the one who has to deal with it.

Yes. A game template generates the same problem. It runs the app fine. It is the unit tests that fail to load.I filed a bug report (FB7488431). I guess it my own fault for not planning ahead and having an iOS 12 device handy. I guess I'll just drop iOS 11.

Yes. I just noticed that.

A "file" can be read in as an NSData object. XML could have different encodings. It is just a sequence of bytes. It is possible that attempting to convert into into a String or Data could alter those bytes. I say it is "possible" because you are probably testing is simple data. There are many cases where this would be virtually guaranteed. So, forget the String stuff. This is a byte sequence.There seems to be a large number of resources available for signing XML files. I can't imagine there are many Mac or iOS users doing that. But it should be fairly easy to use those existing projects and techniques for verification if nothing else. Some of them might be open source with liberal licenses that you can just re-compile. Once you figure out the basics, you may be able to convert it into Swift if you really want.

The description of AEXML says "This is not a robust full featured XML parser, but rather simple, lightweight and easy to use utility for casual XML handling." And it doesn't say anything about adding signatures. XML can be tricky. You'll find lots of these "basic" tools. But an organization that requires signed XML is probably using XML in a more professional fashion. Those quick-n-dirty projects aren't going to cut it. There are plenty of resources, including online validators, that you can use to check your signatures. But that is going to be a waste of time until you start with a known, valid signed XML document and you are able to reproduce the signature. You are going to have to step out of the Swift comfort zone for this. Maybe you could write Swift wrappers around existing libraries. But it would be a waste of time to try to reimplement this from scratch.

Have you looked at Dash instead? I find Dash invaluable for those times when Xcode's documentation viewer refuses to respond to keystrokes.

I can't reproduce your crash. It works fine here.However, hard coding text is problematic. Trying to hard code attributed text is even worse. You can't localize that stuff easily. Xcode's IB text editor is difficult, and that's being kind.What I do is just put placeholder text in text views. All of my actual attributed text is in RTF resource files. I just load them on demand and store them into the text view.The only problem is layout. I have a hack where I try to estimate how tall a field would be based on my dynamic, styled text. There are system methods for that. Then I update a constraint with the height. It is a little flaky, but it works.

You would have to re-code all of that yourself - and I mean all of it. You would essentially have to have your own storage for autofill data, passwords, sites, etc. You can't have access to system data or user data.What you can do instead is use SFSafariViewController. That puts Safari inside your app. You won't have access to any of the autofill data, but it should give you a genuine, Safari view inside your app.

Have you tried the UNUserNotification class instead? It is available on 10.14 too.Could there be a bug where some cached data remains after a process has been killed? Of course. Bug or not, it exhibits the behaviour that it has and you aren't going to get that changed for 10.14 or even 10.15 at this point. That's the way it works.Here are some things you could try:1) If you have to restart procA, since a "prime the pump" notification to get things going again. If it isn't displayed, all the better. 2) Schedule the notification for a couple of seconds in the future. 3) Just wait a couple of seconds before sending the notification.4) Use your workaround. If you have a workaround, what's the big deal? You want an API without bugs? You're on the wrong platform!

So what is your plan when Apple Script and Finder are no more?