I ran into this too and figured it out. The issue is that the to_chars functions’ availability attributes use the “strict” modifier, which means it isn’t possible to check for them at runtime. From the Clang docs: The flag strict disallows using API when deploying back to a platform version prior to when the declaration was introduced. An attempt to use such API before its introduction causes a hard error. So unfortunately, to use these functions in an app that supports older OSs, you have to use compile-time checks with ifdefs.

Yes, I filed FB10015555 and FB10015541.

If you need a lot of shared memory, use a memory-mapped file instead. Create a file, then call mmap on it with permissions PROT_READ | PROT_WRITE and attributes MAP_FILE | MAP_SHARED. If you don't want the file to hang around in the filesystem, you can delete (unlink) it as soon as your process(es) have mapped it; the memory remains valid until the memory map is removed or all the processes exit.

It doesn't answer the question about when to use Lazy Stacks and when not to.  I think it did. First consider the "rule of thumb" while coding; then profile the app and if there are performance issues involving a particular Stack, try changing its laziness and see if that helps. Why not make all stacks Lazy stacks, and implement the above rule of thumb in the compiler?  Presumably because the decision about whether a Stack should be lazy is not one that can be made by an algorithm. If that rule of thumb were hardcoded, there would probably be cases where it turned out to be wrong, and the app developer wouldn't be able to do anything about it. Programming is full of situations where there are multiple ways to do something, with different performance characteristics. Should I implement this property as a precomputed value, or lazily evaluate it when it's accessed? Should I use a search tree or a hash table here? Etc.

I'm pretty new to CloudKit, but I know that everything iOS sends to/from servers is encrypted, mostly with TLS/SSL. (Apple has been trying hard for years to get developers to stop using unencrypted HTTP connections; that's what the App Transport Security mechanism is for.)

As often happens, soon after posting a question I discovered a solution. Specifically, mbedTLS does have a function that enables callback-based root cert lookup. It's called `mbedtls_ssl_conf_ca_cb()` — with a name like that I don't know why it didn't leap out at me earlier 🙄So yes, using that function I can evaluate a cert passed to me by mbedTLS during the handshake, using the SecTrust API, and find and return the appropriate root cert. Problem solved!