I've done some more testing, and it looks like: - The prompt stopped animating in iOS 11.0. - The main bug here with nav bar buttons breaking started in iOS 11.2. - The only thing I mentioned that's new in iOS 12 beta is the constraint errors.

If anyone needs a quick and dirty workaround: Hiding and unhiding as in the example below the bar fixes the issue with the buttons freezing. Putting it all in an animate block produces the expected animation.

UIView.animate(withDuration: 0.3) { self.navigationController?.setNavigationBarHidden(true, animated: false) self.navigationItem.prompt = "Here's a prompt in the navigation bar." self.navigationController?.setNavigationBarHidden(false, animated: false) }

There are no current plans to build a feature of this type. We are closing this bug report. If you have questions regarding the resolution of this issue, please update your bug report with that information. Please be sure to regularly check new Apple releases for any updates that might affect this issue.

I still didn’t get an answer for this: If you set allowsExternalPlayback to false, you should be getting buffered audio (not real-time audio). This should work pretty well. Why do you want to have allowsExternalPlayback set to true and have audio playback? allowsExternalPlayback controls URL flinging, and we think using URL flinging for audio only assets doesn’t give any benefit to developers, especially now that we have buffered audio. Please provide your response or results by updating your bug report. If uploading files, please compress first.

Assuming that Apple is trying to push GPU intensive developers to migrate to the macOS ecosystem, it would be hard to imagine Apple adding support for this. However, I would love to see official bootcamp eGPU support as well!

Apple Developer Relations response on 10/9/2017:

APIs need to run in a properly entitled process, i.e. "hosted" in the terminology used.

Seems to work now in Xcode 9.4.1

While the insets aren't respected for me, too, there are better solutions for 3 of the 4 Buttons/Views:

MapKit defines MKCompassButton, MKScaleView, MKUserTrackingButton that can be placed freely inside and outside the mapView and are fully functional. See the WWDC 2017 MapKit video for details how to use them.

The only button Apple has forgotten is the legal button so the problem remains.

Seems update is delayed and rendering is wrong.

In tick, caretRect(for: endOfDocument) becomes correct, but not in immediately after toggling isSecureTextEntry. Rendering must be updated in "not previous value" manner.

Temporary solution before native fix:

    // update caret position
    DispatchQueue.main.asyncAfter(deadline: .now() + 0.01) {
        let (beginning, end) = (self.beginningOfDocument, self.endOfDocument)

        self.selectedTextRange = self.textRange(from: beginning, to: end)
        self.selectedTextRange = self.textRange(from: end, to: end)
    }

Thanks you! Indeed, my mistake. I missed that new entitlement. Could you please tell if there are any special considerations when using this entitlement? For instance, maybe only a certain type of apps is allowed to use it?

Engineering has determined that this issue behaves as intended based on the following information: To use CNCopyCurrentNetworkInfo() function in iOS 12 and later, enable the Access WiFi Information capability for your app in Xcode. When you enable this capability, Xcode automatically adds the Access WiFi Information entitlement to your entitlements file and App ID. Have you added the required entitlement in your application? Please see https://developer.apple.com/documentation/systemconfiguration/1614126-cncopycurrentnetworkinfo for more details.

The original report on your issue has been closed recently. Please note that you will not be able to directly view the original report in order to keep its information confidential. If you have further questions about this issue, please update your report using the Apple Bug Reporter http://bugreport.apple.com.

Has been fixed in the latest Mojave beta

0 swift 0x00000001128a037a PrintStackTraceSignalHandler(void*) + 42 1 swift 0x000000011289fb2e SignalHandler(int) + 302 2 libsystem_platform.dylib 0x00007fff5d5e7f5a sigtramp + 26 3 libsystemplatform.dylib 0x00007ffee1125b50 _sigtramp + 2209602576 4 swift 0x000000010f924d76 swift::TypeVisitor<(anonymous namespace)::ObjCPrinter, void, llvm::Optional >::visit(swift::Type, llvm::Optional) + 230 5 swift 0x000000010f91f7b5 (anonymous namespace)::ObjCPrinter::print(swift::Type, llvm::Optional, swift::Identifier, (anonymous namespace)::IsFunctionParam_t) + 629 6 swift 0x000000010f9220e9 (anonymous namespace)::ObjCPrinter::visitVarDecl(swift::VarDecl*) + 4617 7 swift 0x000000010f920e8d void (anonymous namespace)::ObjCPrinter::printMembers<false, swift::IteratorRange >(swift::IteratorRange&&) + 461 8 swift 0x000000010f91d845 swift::ASTVisitor<(anonymous namespace)::ObjCPrinter, void, void, void, void, void, void>::visit(swift::Decl) + 4133 9 swift 0x000000010eb6cb94 printAsObjCIfNeeded(llvm::StringRef, swift::ModuleDecl, llvm::StringRef, bool) + 6132 10 swift 0x000000010eb63f72 performCompile(swift::CompilerInstance&, swift::CompilerInvocation&, llvm::ArrayRef, int&, swift::FrontendObserver, swift::UnifiedStatsReporter) + 39522 11 swift 0x000000010eb57015 swift::performFrontend(llvm::ArrayRef, char const*, void, swift::FrontendObserver) + 7717 12 swift 0x000000010eafcc95 main + 1349 13 libdyld.dylib 0x00007fff5d2d9015 start + 1 14 libdyld.dylib 0x0000000000000042 start + 2731700270

I'm not an expert, but I believe the issue is caused by the SSL provider (DigiCert), which was acquired by Symantec. By switching to another SSL certificate provider, the issue would be fixed

Engineering has determined that this issue behaves as intended based on the following information: We support this functionality if you select Search Library instead of Apple Music, then hit return.

Apple Comment. 'Please know that our engineering team has determined that this issue behaves as intended based on the information provided.'

Set inputAccessoryView again when the inputTextView has changed. This works as expected on step5.

March 7 2017, 3:49 PM Please know that our engineering team has determined that this issue behaves as intended based on the information provided.

Marked as a dup of 43295148

Marked as a dup of 43295148