I found this hack solution in Stack Overflow which seems to solve the issue. Edit the Scheme, go to the Info tab and turn off Debug Executable. It would be great to know why this works.

Apple has confirmed this issue is a bug. I have filed a bug report.

This is an old post but maybe someone is still looking for a solution. I found that you can just override the fullStateForDocument property and just archive your settings using a Dictionary. No need to play with parameter trees if you don't need your settings to be modified by the Host. // Save an NSString named setting. - (NSDictionary<NSString *,id> *)fullStateForDocument {     NSMutableDictionary *state = [[NSMutableDictionary alloc] initWithDictionary: super.fullStateForDocument];     NSDictionary<NSString*, id> *settingsToSave = @{@"setting": setting,};     state[@"savedSettings"] = [NSKeyedArchiver archivedDataWithRootObject:settingsToSave requiringSecureCoding:NO error:nil];     return state; } // Retrieve settings - (void)setFullStateForDocument:(NSDictionary<NSString *,id> *)fullStateForDocument {     NSData *data = (NSData *)fullStateForDocument[@"savedSettings"];     NSDictionary *savedSettings = [NSKeyedUnarchiver unarchivedObjectOfClass:[NSDictionary class] fromData:data error:nil];     setting = (NSString *)savedSettings[@"setting"]; }

Hi @JHostetler2, did you find a way to solve this? I have exactly the same issue. Did you have to transform everything you wanted to save into parameters in a parameter tree and then use the fullStateForDocument to be able to save everything? If so, how is the fullStateForDocument used? I really can't find good documentation of how to use this. Thanks.

I am having hte same issue. I talked to a representative and sent them all the information they requested but haven't received any response. I need to send these promo codes on the next day or two.

@Claude31, thanks for taking the time to comment and come up with a workaround. In my example, both buttons are children of the default view of a view controller. This view is the Superview for both buttons, and the Safe Area is the one defined for that view. In my example I expected to see a result like you got in your second screen shot. It seems like you have come up with a workaround for this issue by creating an extra view that matches the Safe Area and placing the button there. I think there is a problem in Interface Builder. Height and width constraints with respect to the Safe Area (without a need for an extra view) work (I have tested those and they work), but horizontal and vertical alignment constraints don't. I guess I will have to implement your workaround. It is very unfortunate that something as simple as this doesn't work correctly.

My first entry on this question has a lot of errors and misconceptions but I can't edit it anymore. First, the MIDIOutputEventBlock is a property of the Audio Unit plug-in. According to the header on this property: "The host can set this block and the plug-in can call it in its renderBlock to provide to the host the MIDI data associated with the current render cycle." Second, in the example code that I referenced, the class that calls the allocateRenderResourcesAndReturnError and the internalRenderBlock methods is the actual AudioUnit class. In the template currently being generated by Xcode, these methods are part of the xxxDSPKernelAdapter so, of course, using self will generate a compile error. Any insight anybody could provide on how to obtain and then cache the MIDIOutputEventBlock property, would be greatly appreciated.