*because it's non-optional, which I imagine nil would be returned if the parameters were invalid, I wonder what gets returned being that it can't be nil.

@DTS Engineer 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.

@DTS Engineer 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. 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.

The reason I've taken the the approach I have for the watermark is because the watermark isn't just an image or simple string, but somewhat complex. It's basically two black translucent bars — one on the top and one on the bottom. In the bar on the top there is a description entered by the user, and beneath the description is a separate, non-constant string; both one line max. In the bottom bar, it's pretty much the same except the top string are GPS coordinates and the bottom one is a timestamp. Furthermore, the watermark contains the app's logo. Using the approach I have makes scaling convenient as I can use AutoLayout to ensure that things are sized appropriately for the resolution of the captured photo.

Did you ever figure this out? Experiencing the same problem myself.

I did: “Specifies if the view is focusable.”. Where in the documentation did you read that it’s for “input-oriented” controls?

I've looked into this myself. And after researching for hours, decided to go the subscription approach. This is because I'm not only almost positive this is something that's not supported by Apple, but also that if you try to implement yourself via logic within the app, if you lock the app up once the free trial is over then your app may be in violation of the Apple developer agreement and taken down. At least that's what I gleaned from the research.

Is this still not possible?

Update Okay, so I know exactly what that threshold amount is equal to. It is equal to the content offset when the bottom of the content is resting at the bottom of the scrollview. In other words, the content offset that results in the content being scrolled all the way to the bottom. It appears that this threshold is used because what is an acceptable content offset when the keyboard is up (smaller scrollview bounds) is not an acceptable offset when the scrollview's bounds increase (keyboard goes down, scrollview gets bigger). For example, if the content is 100 points high and the bounds are 50 high, then it makes sense to have an offset that is 50, because you can only view 50 points of the content at any given time. However, if the bounds were to increase to 100, then a 50 point offset is somewhat erroneous because at that height all of the content is visible at 0 offset, so increasing the offset at all — assuming no insets — just pushes content needlessly out of view. This makes sense, but I think the problem here is that I wasn't expecting this content offset change to occur in the current run loop. In my experience with layout changes that are the result of AutoLayout, they only seem to take effect in the next run loop. But here they are happening immediately — as soon as UITextField.resignFirstResponder() is called. This prevents me from being able to make decisions based on the content offset of the scrollview at the time of the keyboard being dismissed because the will hide keyboard notifications occur after those effects take place. The solution I'm moving towards here is just not using the keyboard layout guide altogether, and instead just changing the bounds manually as I did before using the keyboard notifications; at least then I'll have access to the content offset representative in the UI at the time the notification is published.

Agreed. It shouldn't be this difficult to see an up-to-date list of the pricing tiers. Why does it seem like everyone but Apple is trying to provide this information?

Ever find an answer to this?

I received the same email, and after addressing it with support they claimed there was no record of the email being sent by them; and advised me to forward the email to the address "reportphishing" at "apple.com".