I would like the MKMapItem returned from MKLocalSearch to contain an "altitude" property. In order to achieve this, I've decided to create a subclass for MKMapItem. class MapItemGeoSpatial: MKMapItem { var altitude: Measurement<UnitLength> public init(placemark: MKPlacemark, altitude: Measurement<UnitLength>) { self.altitude = altitude super.init(placemark: placemark) } required init?(coder: NSCoder) { fatalError("init(coder:) has not been implemented") } } While the above implementation compiles, it results in a fatal error when attempting to initialise MapItemGeoSpatial. Fatal error: Use of unimplemented initializer 'init()' for class 'MapItemGeoSpatial' The above error occurs during the super.init(placemark:) call. The altitude property is set by me (the source of this value is not relevant to this discussion, but it is determined by extracting the coordinates from MKMapItem) via the designated initialiser. I understand that MKLocalSearch has nothing to do with altitude, but I, as the client, found it desirable to contain this information when it is passed to other areas of my project. This is the primary reason why I chose to subclass MKMapItem, in an attempt to "inherit" all it's functionality and introduce my own functionality. The flow diagram for this process is- MKLocalSearch -> MKMapItem  -> Determine altitude using coordinates from MKMapItem -> Initialise MapItemGeoSpatial. I can create an override init() for the above class, but this will require me to initialise the altitude property, which is not specified for this initialiser. Initialising altitude by specifying a dummy variable (eg. 0) overcomes this issue, but appears to be a poor workaround. Making altitude optional is another workaround, but this is not a direction I wish to take. I'm aware that MKMapItem inherits from NSObject and I'm curious if this relation has an influence on the above observation. I would like to- Understand the root cause behind this issue and Determine if subclassing MKMapItem is a viable solution to the problem mentioned at the start of this post

Background I have generated some content using Reality Composer and imported the resulting .rcproject file into my iOS application in Xcode. Xcode creates a .reality file that is then loaded onto the App bundle while also auto-generating code to streamline the interface with this file. load<scene name>() type method is an example of a useful method from the generated code, which returns the specified scene from the .reality file. Observations Invoking the above method synchronously results in the App crashing (and only signalling Thread <thread>: EXC_BREAKPOINT). The crash occurs at loadAnchor(contentsOf:withName:) within the load<scene name>() method. The documentation for this does state that the method "Blocks your app while loading an anchor entity from a file URL", but I don't see why this should result in a crash (I would anticipate unresponsive UI, and this is only if it's being run on the main thread to begin with). Scheduling this operation on the main queue (via DispatchQueue or MainActor) overcomes the above issue. Placing the method within an unstructured Task does not result in a crash either, but scheduling it on a global queue results in a crash. The above behaviour is observed during unit tests as well, but the use of an unstructured Tasks also results in a crash here. Versions While I've listed the respective versions below, I've also experienced this behaviour in prior versions. Xcode 13.4.1 iOS 15.6