Confirm fixed in Xcode 13 Beta 4 thanks

Please verify this issue with the Xcode 13 Beta 4 and update your bug report with your results by logging into https://feedbackassistant.apple.com/ or by using the Feedback Assistant app.

Xcode 13 Beta 4 (13A5201i) https://developer.apple.com/download/

Apple believe this may be fixed in 11.5

This is expected; you must either annotate methods using unavailable app extension APIs as @available(iOSApplicationExtension, unavailable), or in this specific case, use view controller based solutions instead, such as changing:

guard let orientation = UIApplication.shared.windows.first?.windowScene?.interfaceOrientation else { return }

To:

guard let orientation = view.window?.windowScene?.interfaceOrientation else { return }

https://developer.apple.com/forums/thread/668050

we had similar issue and were rejected from MacAppStore with temporary exception. To solve we used IOKit to detect USB device, then we were able to access that device using '/dev/cu.usbmodem.../' path.

Thanks, where are the specs for Exchange and absolute date alarms not being supported? Would be nice if it was part of API docs of EKAlarm.

1.IOS 14.6 and free Outlook account (https://outlook.live.com/owa/). I'm unable to check Exchange version in OWA. This issue was first reported half a year ago. So, it's unlikely related to latest IOS and Exchange versions. 2.Changing in code. The absolute date alarm is not present in event (new or existing). Pls check attached CalendarTester.zip for actual code. 3.Pls find sysdiagnose attached.

Thanks for contacting us. We need additional information.

Our understanding is that Exchange does not support absolute date alarms; it only supports relative alarms. The behavior you are observing when you create the event is expected.

We would like more information about the subsequent syncing failures that you are observing: 1. What versions of Exchange and iOS are you observing this on? 2. How, exactly, are you attempting to further update the event? Are you changing it in the Calendar app, or are you changing it in your code? If you are changing it in your code, is the absolute date alarm still present on your version of the event? 3. Could you please provide us with logs from when the syncing fails? Please provide a sysdiagnose.

Please update your feedback report to provide the additional information. Thank you.

Directions for all sysdiagnose logging, screen recording and profiles: https://developer.apple.com/bug-reporting/profiles-and-logs/

I hit enter prematurely. The description of the bug: I have a workspace and project with two app targets, MyApp and MyAppLite, when I choose Product > Xcode Cloud > Create Workflow… it only shows the MyAppLite target. Apple has gotten back to me and I have provided more information for them.

Beware: macOS Finder “Connect to Server” accepts FTPS URLs (FTP in a SSL/TLS tunnel) but actually connects via plain FTP! https://apple.stackexchange.com/questions/423367

Many thanks for addressing this!

I confirm that a few (around 5-7) cases that I had with complex SwiftUI code or complex arithmetic expressions have been fixed. However, the following case still doesn't compile in Xcode 13 beta 2: https://gist.github.com/alex-swiftify/6166e0abda7472ebba35bbd05faab281

Let me know if you rather want a separate radar report for this case.

In case anyone is looking, this is still an issue as of Safari on Mac 14.1.1

All iOS versions below iOS 15 beta 1 (including iOS 14.7 beta) still have the issue. iOS 15 beta 1 have no issues with AirDropping DNGs.

Found workaround solution: Need to reset "from" frame to .zero at UIViewControllerAnimatedTransitioning.interruptibleAnimator on dismiss event

Example here: - https://github.com/ivan-gaydamakin/uikit-swiftui-transition-ios14-bug/blob/6454146ff146ba19dc139ff6f4df39848b711a25/FluidTransition/Transition/Animations/DismissAnimation.swift#L26

Same problem

Also I prepared example to reproduce it: https://github.com/ivan-gaydamakin/uikit-swiftui-transition-ios14-bug

Thank you so much for getting back to me. I’ve tried this approach in Xcode 13 beta 2 without any success. I’ve included an updated Sample project. Am I still doing this wrong?

The options I am passing in are this:

AttributedString.MarkdownParsingOptions(interpretedSyntax: .inlineOnlyPreservingWhitespace)

Thank you! Ryan

The difference in behavior you are experiencing is expected. The AttributedString(markdown:) initializer applies semantic attributes to ranges of text, it does not insert any additional characters to “render” the text. According to the CommonMark specification that we are following here, the AttributedString created with the markdown initializer does not contain newline characters and instead contains separate paragraph attributes denoting the start and end of paragraphs. On the contrary, SwiftUI’s Text view uses the MarkdownParsingOptions.InterpretedSyntax.inlineOnlyPreservingWhitespace option when parsing text input as markdown, causing all whitespace characters (including newlines) to be preserved in the output. If you were to use the .inlineOnlyPreservingWhitespace option, the whitespace in their AttributedString would be preserved in the same way that Text preserves whitespace.

I agree with this. I work in a retail store where we share store computers at the registers and utilize apples website for various things. Having it ask for the local password only to offer logging in with the wrong account is very annoying and wastes time.

In 2021 I am still battling this problem on a daily basis. Sometimes it works, sometimes like today I have to troubleshoot for literally 3 hours before it starts working again https://openradar.appspot.com/FB9053529

Probably not a bug on Apple's side since they refuse to admit it, it's most likely a feature.

Thank you for your reply. It is possible we were unaware of the workaround when the release notes were posted. Via Feedback Assistant, we kindly ask that you file a separate feedback against the documentation, asking that the workaround be properly documented.