AFAIK the only way to get the environment in which the app is running is by parsing the embedded provisioning profile inside the app and retrieve the value for aps-environment, but its format is proprietary and subject to change. It is my understanding that the proper way to do is to try and send the notification on the production environment by default and fallback on the development environment if that fails. I have yet to find a confirmation for this but if we take a successful notification service like firebase that does not ask for an environment value, I don’t see how else they’d do it.

I did reproduce the issue in iOS 16.0 (simulator); the bug looks fixed in iOS 16.1 as the bug could not be reproduced in a simulator w/ this version and above. It’s probably related to the shaders having their y axis inverted on iOS 16.0 too…

I have a workaround, but it clearly is a bug on Apple’s end. I also filed a Feedback (FB13453227).

Bug filed: FB9733892

Tell me if there’s a better way, in the mean time, here’s a screen of the backtrace (nothing’s happening in thread 2). The code is dead simple: do { logger.debug("Treating path \(p)") var url = URL(fileURLWithPath: p) let rv = try url.resourceValues(forKeys: [.ubiquitousItemIsExcludedFromSyncKey]) logger.info("Excluding \(p)") var newRv = rv newRv.ubiquitousItemIsExcludedFromSync = true try url.setResourceValues(newRv) /* <- Hangs here */ } catch { logger.error("Error treating path \(p): \(error)") } A possibly interesting note: it seems the ubiquitousItemIsExcludedFromSync value is never filled (it is nil after the resourceValues call)

Of course, never do that in prod. The code will break unexpectedly as soon as you start adding exotic locale…(For starter, the unit won’t pass the [A-Za-z/] regex.)