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".