@himaratsu thanks so much for this PR! I've switched to your branch until PureLayout guys do smth.

@himaratsu Good job on starting the initiative on supporting the safe area insets which are now relevant on the iPhone X but noticed a couple of things with your PR:

1. Your insets aren't correctly set for .trailing, .bottom and .right because those inset values are supposed to be negative, you forgot this so for those three conditions they're working as offsets instead.

2. For consistency with the already implemented API, would be nice to have the other convenience methods as in the ones that include the relation (which the inequalities have to be reversed for the above conditions as well), the superview margins, and the excluding edges as well.

Looking forward to this getting merged in soon. 👍🏾

Decided to implement my own changes (lol) so made a PR to your fork which you can take in and hopefully get these merged in. I added iPhone X support and updated one of the demos accordingly as well.

To follow up, @mickeyreiss this question I'll direct over to you, noticed that tests are failing when checking the availability of the APIs that depend upon being iOS 11+ (the safeAreaLayoutGuide of a UIView). Do you have any suggestions for this? I would ideally like for the tests to pass and not fail due to the error that Travis is throwing below while trying to figure out why the @ sign is there :/

/Users/travis/build/PureLayout/PureLayout/PureLayout/PureLayout/ALView+PureLayout.m:171:9: error: unexpected '@' in program if (@available(iOS 11.0, tvOS 11.0, *)) {

would be nice if this PR can get merged soon, we are using this branch now

Sadly, this project looks like it's abandoned :(

@mickeyreiss I'd be interested in it as I use this library extensively throughout my iOS projects. Feel free to reach out if there's anything else needed.

I could help too, as I'm actively using it in a project and replacing it is not something I would want to do.

I'd love to help if its needed too. I use this library a lot and I'd love to see it up to date.

Just for reference, I have a PR that will take care of the above issues that I noted that can be merged into @himaratsu branch for this PR. Feel free to let me know your thoughts on the changes.

himaratsu#1

Any luck ? :(

Updating the Travis CI build environment to Xcode version 9.0 or later should solve the issues with the build failure.

Currently, the build environment is:

• OS X version: OS X 10.11
• Xcode version: Xcode 8gm

Any progress on getting this included? Great library btw keen to see it maintained.

@mickeyreiss Any updates in regards to the status of this PR and the library in general would be great

Can we get a new branch for this in the PureLayout repo while we wait for the master update? I feel like it makes zero sense to point to a third party's fork of this.

Opinions on this?

@himaratsu I merged a PR that (unfortunately) will generate some warnings inside of the -autoPinEdgeToSuperviewSafeArea: withInset: relation:] method as the project will now warn about APIs that are used outside of the deployment target. To resolve this issue you should append an API_AVAILABLE() on the method signatures. The PL__PureLayout_MinBaseSDK_iOS_8_0 can be left as this will make sure that these methods aren't accessible on MacOS. I have attached a screenshot that should help in resolving the warnings

@aravasio The reason being for the fork living so long is that the author recently received write access to the repo after creating the PR hence why it is on a fork. I think the discussion here is valuable to keep from closing this PR to create a new one. This of course won't occur going forward since the author now has write access to the repo.

@himaratsu any updates for this PR? There are quite a few people that would like to have these additional APIs to more easily support safeAreaLayoutGuide

@himaratsu Do you mind if we take your changes and @toohotz's change and make a new pull request? I'm happy to do the work.

@toohotz Can you have a look? Looks like @himaratsu merged in your changes. I'll poke around on the Travis build issue.

@lwdupont so taking a look at the changes, I see two different possible directions that the new APIs could go forward in.

The current way that @jjksam had done so in which the safeArea methods would be backwards compatible with previous versions with NSLayoutAnchor and regular constraints when targeting below iOS 9. With the current changes for example, where the layout anchor constraints are being defined on line 179 would need to be wrapped inside of an if (@available(iOS 9.0, *)) {} to suppress the @available warnings that Xcode is throwing.

So that brings me to the second point in saying when a user pins using these safe area inset methods, should we restrict the usage for (using -[autoPinEdgeToSuperviewSafeArea] for example) by postfixing the method signature with API_AVAILABLE(ios(9.0), tvos(9.0)) to not only suppress the warnings without having to wrap the anchor constraints inside of the @available check and by doing so, the consumer of the API would then have to handle the previous versions of their OS accordingly with the proper constraint setup.

Both setups would be valid though the latter option aligns more with what Apple does by restricting API usage based on iOS version or should we assume the intention on behalf of the consumer of the API?

I believe we should do as Apple does, and restrict the usage of the new apis to where they make sense.

How do we want to go about it?

If we decide to restrict the usage to where it would make sense then via Apple's way of doing things, we'd force the user to do #available checks in their own code as opposed to doing it in ours.
Example:

if #available(iOS 11.0, *) {
            UIView().autoPinEdgesToSuperviewSafeArea()
        } else {
            UIView().autoPinEdgesToSuperviewEdges()
        }

So the points I would like to make here (at least in my opinion) is that here, for versions that are below iOS 11, there are no devices that are affected by the safeAreaInsets property which in itself is restricted to iOS / tvOS 11 and above therefore why should we conditionally check within this method that deals with the safe area for an OS that does not support it?

Weird things may begin to happen as the consumer of the API could be under the assumption that because it worked without having to version check within their code, that the superview that the view is pinning to has a safeaAreaLayoutGuide property which is iOS / tvOS 11+. We would be obfuscating this as in our API we're performing the checks on the consumer's behalf and assuring them that if it can pin to the safeaAreaLayoutGuide then it will, if not we will pin to the edges via NSLayoutAnchor if iOS 9 and 10 and if iOS 8 and under, we would utilize NSLayoutAttribute.

I suppose the point that I'm making here is that I would rather the user be aware of the API that they're using and version dependencies that comes with it how Apple does it on their end as well. If in a future version does Apple decide to change how safe area layouts work, for our backwards compatible code that is within this single function, we would have to might have to make changes on our end as well. By explicitly having the consumer be aware of the version specifics, when they wrap the code above in its #available checks, they will be aware in the code block the version restrictions (and also the compiler will be there to help you).

If we choose to implement the APIs with us handling the version specific APIs then we would have to make aware to the user if the OS that they're are targeting is below that of the APIs which we are using that we will be handling it ourselves which I'm not exactly a fan of. I would much prefer the APIs that are set in place to function as intended and any newer ones to do the job of what it's function signature describes it to be doing.

I've also been using PureLayout and I'm just now catching up on the current situation here - first of all big thanks to @himaratsu and @toohotz and the others for your help with the recent PRs and changes. I saw PR #203 and the other branches that have been made and would also like to see these get rolled in.

Looks like @toohotz, @revolter, and @tomidelucca are all now members of the PureLayout organization so it looks like @mickeyreiss has added you as maintainers (thanks Mickey!). Maybe it's possible to get these changes pulled into the master branch for a release sometime soon? I'm willing to help but I feel like I have the least amount of context on the code changes - however if there's anything I can do to support please let me know!

I'm going to work on releasing this on the weekend. FYI.

@lwdupont Thank you so much for your help with this! It's greatly appreciated!! 😀