Thank you that fixed the problem. Any idea how the problem was caused in the first place?

same as for positioning windows on ceiling (which is already possible) just in reverse — for when you're lying face down. I already understand this can be done in your own app if it's an immersive experience. I'm looking for a way to do this just with any old window — like Safari for example. The dragging angle limit seems somewhat arbitrary anyways — like the developers had to go through extra effort just to restrict the movement of the windows to within specific angles around head. Why?

No, no mouse resizing icon unfortunately. Tried both hovering over trailing edge at header portion of view and in the body where the values are; also slowly moved past them both to see if there was somewhere invisible that might trigger the resizing icon — nothing.

Is it in the documentation that an application service listener is specific to DeviceDiscoveryUI? I would of thought that DeviceDiscoveryUI is semantically separate from the type of listener and that you could use either one with it. Thank you for clarificationa and the confirmation on the listener/connection semantics.

please ignore — was supposed to be a reply. replied the same above

Also CMIIW, but it seems like the messages aren't received through the NWListeners, but through the NWConnections even for the runtime that establishes the 'bonjour' NWListener. I would've thought that the bojour listener communicates through that and the client the NWConnection but it seems like the listener is just used for setting up the connection, at which point they both use the connection objects.

Thanks for the reply. One confusion I have is in the TicTacToe sample app. In the PeerListenerViewController whenever the user opts to host a game they create a 'bonjour' type NWListener. Which makes enough sense to me. But in viewDidLoad() they always create an 'application service' NWListener which appears to be never used. Just trying to figure out the significance of this and if it's something I should be doing.

it's been a while, but i don't think i did. i ended up compromising on image quality and not using .photo for preset. IIRC, that reduced the overal resolution, didn't result in complaints by the system about the size of the watermark, and was good enough.

The size of the image and the watermark UIView is the same as the resolution of the exported image: 3024 x 4032. I have no idea where the 9072 x 12096 comes from in the error. It's obviously the size/resolution times three, but I have no idea why it's doing that. If I remove the watermark logic, then my code does no multiplication at all — the multiplication takes place in the watermark to ensure the text is scaled properly with the size of the image (doesn't appear super small).

I don't get it, why not just use the height that I give you explicitly. There's no need for estimation when I've given you the exact height for each and every index path. I just spent a day fixing a bug that was the result of this estimation logic. If all the cells are the same height — which isn't uncommon — then the estimation should just be the item count times the height. The estimation it was calculating for my table view was nearly twice the actual content size???