Thanks to those who have commented in support of this idea. Please file a bug report at bugreport.apple.com requesting the same change to let Apple know.

Here's a post on Apple's developer forums: https://forums.developer.apple.com/thread/84996 There are various suggested workarounds here. I could not get any of them to work. For example calling sizeToFit on the search bar will correct the search bar's layout, but not the navigation bar that it's a part of. It looks just as bad, and tapping on the scope buttons in that state just sends the tap to whatever is below it.

Here's a Stack Overflow post with no answers currently: https://stackoverflow.com/questions/46735159/scopebuttontitles-in-uisearchcontroller-with-uinavigation-ios-11

Here's a UISearchController tutorial that includes discussion of this problem in the comments, but no suggested fixes: https://www.raywenderlich.com/157864/uisearchcontroller-tutorial-getting-started

I'm not sure what's going on with this bug. It's very simple to reproduce—all you have to do is set scopeButtonTitles and use the new navigationItem.searchController property, and your app will have this bug. My bug was marked as a duplicate of 33709776, which is marked as closed. It's been marked as closed for the past few 11.1 betas, but the bug remains.

I have not been able to find a workaround—even trying to dismiss the search controller on rotation just introduces new visual bugs. As far as I can tell the only current solution is to not use scopeButtonTitles when you're using the navigationItem.searchController property. For example, you could add your scope buttons to the table view header instead.

Screenshot of CPU trace: https://twitter.com/lieven/status/922486399483424768

Jon, mine was also closed as a dupe of the same ticket. There is now an Option withFractionalSeconds in the docs. But it has no comments against it.

I wonder how you can select the number of decimal places?

Just wanted to add an additional note. The docs for withInternetDateTime say "The format used for internet date times, according to the RFC 3339 standard.". This is also not true. The RFC 3339 standard section 5.1 mentions the use of fractional second digits and so allows the use of the ISO8601 fractional digits mentioned earlier.

+1 Also just ran into this issue.

Perhaps this is the cause for https://openradar.appspot.com/35116174

The problem started yesterday for me. Deleting all files and subfolders in Derived (including ModuleCache) data did not solve the problem.

Still an issue for me on Xcode 9.1 beta 2 on a Mid 2011 Mac Mini

I fully agree with James for the removal of blame. The only useful information is date and commit. Also Intelij uses "annotate" which looks much more for constructive informational purpose than pointing a finger at someone.

When I think about when I use “blame” in Xcode, I am usually more interested in the date and commit message than the actual author. Therefore “blame” is completely the wrong meaning.

Main bug still happening on Xcode 9.1 beta 2.

My last comment that says "ALSO, when using navigationController?.navigationBar.isTranslucent = false, the additionalSafeAreaInsets are ignored completely." was fixed on Xcode 9.0.1 / iOS 11.0.1.

Main bug still happening on Xcode 9.0.1 / iOS 11.0.1.

Good definitions make for clear ideas. I fully support James's request to remove blame.

Actually the problem turns out to run even deeper than you suggest here. I have file a bug report radar 35057087 showing that MPMusicPlayerMediaItemQueueDescriptor(itemCollection:) always fails, even for basic things like setting the queue. If, instead of play, you call prepareToPlay with the completion handler, which provides an error parameter, you can see there's a completely spurious error every time claiming that the storefront is wrong, as if we were using a totally different queue descriptor having to do with Apple Music.

Only happens on iPads running iOS 11

Our team made some research on the issue.

Here is summary of the findings:

• UITextView and UITextField seem to use NSBigMutableString as their internal buffer (i.e. when you invoke .text on them, that’s what gets returned)

• When an NSBigMutableString that contains less or 256 UTF-16 units gets bridged to a Swift String, it works correctly

• When an NSBigMutableString that contains more than 256 UTF-16 units gets bridged to a Swift String, grapheme clustering is not performed correctly — i.e. each code point gets converted to a Character, even ones that should be clustered together with previous code points (like variation selectors)

I should also mention that another big reason for having Guides available in the documentation browser is so that they're available offline