Thank you for your attention Using a self-signed leaf certificate puts you far off the well-trodden path, and it’s something I actively recommend against This is a private network. AFAIK it is not possible to use an established authority to sign a certificate for an internal network. It is not connected to the public Internet. It must be secure as it is transmitting sensitive data over a shop floor We could enable HTTP for the APP NSAllowsArbitraryLoads but that causes other problems. (We could use a VPN to secure the data, but it would limit how we install the app on the device.)

I can only see two ways out of this. The first is for the customer to get on board with running their own CA. This is standard practice for enterprises that run private networks. It offers a world of benefits, not least of which is that they don’t have to request that every software vendor jump through hoops to run on their network. This is good. We have a conclusion. Our customer has themselves confused running their own CA, but they do it. They literally lost track of which root certificate is for what This is a large corporation for where it is in a modern Western (albeit small) country, so they should pull their socks up! But that is not a business like approach for me to take. I will find a way. But I can see the way this must be done: Network manager creates a CA using OpenSSL Network manager issues certificate for the server using that authority Network manager installs certificate on server they need to connect to Network manager uses MDM to install the root certificate for their CA on all the appropriate iPads. Problem solved. The root certificates will be visible in Settings -> About -> Certificate Trust Settings This is what I thought, but I am not a specialist in this (TLS and OpenSSL) so we talked past each other a bit. Thank you for your help, it was invaluable! Be pleased!!

Your goal is different from the original poster, who was building a test tool to deploy internally. Yes, and no. Awareness of available resources is very important to maintain for serious computing that stretches the capabilities of the underlying hardware. This I am doing. We cannot do everything we want because the hardware of the iPad is not infinitely capable (have to wait for M3 for infinity mode, I guess) We can do less than what the iPad is capable of because we cannot approach the limits, we have to keep well clear of them in case we hit them. I come from a much more pure Unix programming environment where this sort of thing is easy. It is terribly difficult in iOS. I am very interested in knowing how much memory the next allocation is going to use (sizeof(..)), and how much memory is left (not really a fixed target, and impossible to really know but most platforms have a way to estimate: get_avphys_pages (3) or GlobalMemoryStatusEx. This bit me when loading and processing images on an iPad. Not a core activity, but it mattered. It turned out not to be limitations of the iPad that caused the problem, but some other (non apple) system. So I dropped it. But this sort of thing comes at you, as an applications programmer, out of the blue. It would be very helpful if Apple would address this directly, rather than the oblique fashion that you do. It is not needed often, but when it is needed it is a life saver and makes for much better user experience in the end.

Helpful. It is sad that Swift inherited ARC as a memory management tool.

Answering my own question, with another: I added the following to the info.plist file: <key>CFBundleDocumentTypes</key> <array> <dict> <key>CFBundleTypeName</key> <string>Draft Layouts</string> <key>LSHandlerRank</key> <string>Owner</string> <key>LSItemContentTypes</key> <array> <string>public.comma-separated-values-text</string> </array> </dict> </array> and <key>LSApplicationCategoryType</key> <string></string> and <key>LSSupportsOpeningDocumentsInPlace</key> <true/> Now when I use AirDrop to drop a CSV file on the iPad my app is listed as a recipient. Inspecting the bundle I see it is placed in: AppData/Documents/Inbox/MyFile.csv I am unsure what changes I made to info.plist are necessary, or quite what they are for. Have I set a trap for myself? I do not know.....

Or you can send with AirDrop and save in Files. From there you will be able to access from the app. It depends on the settings in Info.plist Where are they documented? I am especially concerned that I cannot find public.comma-separated-values-text documented anywhere. I have this working, with that above and below, for CSV, but I also need JSON. Without any documentation of these settings it is very difficult. Currently the relevant parts are <key>CFBundleDisplayName</key> <string>My App Name</string> <key>CFBundleDocumentTypes</key> <array> <dict> <key>CFBundleTypeName</key> <string>My App Files</string> <key>LSHandlerRank</key> <string>Owner</string> <key>LSItemContentTypes</key> <array> <string>public.comma-separated-values-text</string> </array> </dict> </array> There must be documentation some place. Can I just add JSON support with: <array> <string>public.comma-separated-values-text</string> <string>public.json</string> </array>

Same here Xcode: Version 14.1 MacOS: 13.3.1 iPadOS: 16.4.1 No further updates available. And when I try to debug iPad App in Xcode: " The run destination iPad is not valid for Running the scheme '....'. Failed to prepare the device for development. This operation can fail if the version of the OS on the device is incompatible with the installed version of Xcode. You may also need to restart your Mac and device in order to correctly detect compatibility. " Been a few reboots....

And to make me doubly mad, Wikipedia reports that the latest Xcode is 14.3. Why can I not see that?

So if there are any poor folks who like me relied on the update notifications from Apple it looks like the App Store will upgrade my Xcode. I spent hours doing upgrades ahead of time so I would not be in this situation. I am grumpy about this.