Thank you glow! Indeed. This would explain the problems I'm seeing. I redesigned the screen to only have one Paste control on it and it is placed in the dedicated cell with only a help label below it. Even when sizing that dedicated UIPasteControl - until it stopped "touching" the neighbour controls, it was asking for the permission. I can see the point in avoiding obscuring its parts. How can we define the UIPasteControl sizing requirements properly to be sure to give it enough space? I'm trying its intrinsic size and it always returns as zero rect. I'm trying to achieve its size predictability via minimumContentSizeCategory and maximumContentSizeCategory, so it has a predictable size for the different accessibility text sizes. What's the correct way of placing/sizing this control in a storyboard with auto layout? The example here: https://developer.apple.com/documentation/uikit/uipastecontrol?changes=_5 Suggests: pasteButton.frame = CGRect(x: view.bounds.width/2.0, y: view.bounds.height/2.0, width: 150, height: 60) Is it something considered the safe dimensions for the UIPasteControl for all of the accessibility text sizes? Width of 150 doesn't seem to be "safe" - the whole UIPasteControl may not be even shown or it might be raising the permission alert, if the control itself shows. Is it something that needs to be embedded into SwiftUI? Or would it work well in some sort of a container like UIStackView, would this one size it properly for all of the accessibility text sizes? Some pointers would be appreciated so we can build future-proof designs that would not break easily.

Same here.

These 4 years of not fixing this issue is probably a silent statement from Apple that it works as designed.

My payment with the same due date was delayed until Jan 3rd 2022. Company payment came at Dec 31rd, as expected, so I know it is hardly Apple who caused the delay. Looks like "usual" New Year (and any other holiday) bank mess here, in Czech Republic. And then banks have the nerves to back date these in the statements, as if nothing happened. Fingers crossed for your payment to appear soon.

Same here. Says 8 days to me. Was sending yesterday without any warning.

Only brainstorming here: Lock can be hold by the serialization iterator and then on other thread some other code might have tried to change the array? Iterator might have panicked. Or vice versa. Only my speculative speculation. And this is on the main thread, iOS might have considered that is not a "resolvable" lock and killed you at once. If you do read-write access to this array, try to serialize it via, e.g. the queue?

Same here (Czech Republic). My address contains diacritics and after the error message on that input field, removing diacritics > submitting, I see that Apple changes the chars, e.g. from "s" to "sh" where š would normally be. Submitting the corrected by them variant leads to the same error. I wrote to finance with the error flow description and referring to this thread. [Update] Reply from the Finance came instantly with the following solution that worked: Hello, Please attempt to make this update from the Agreements tab, and not the banking tab.  From the AGREEMENTS tab, click on the paid agreement’s name that requires a banking update. Examples are “Paid Apps”, “Paid Books”, “Music”, “Video”, etc. You have to click the words (agreement name) even though they do not have a blue hyperlink. You must be on the AGREEMENTS tab, not the Banking Tab Under Bank Accounts on the AGREEMENTS tab, scroll to the right and click Edit From the Edit drop down menu select from: Edit Current Account Update your bank account holder address  If the message asks you to verify your banking, click SAVE again. If the message persists, please click save 3 times. Please be sure to let the page refresh before you click it again.  This should resolve the issue.

I have the same problem and I wonder if this started to happen the moment when one of the internal testers tried using the public link. Have you come to any resolution on this?

Seems to be working again. I tested just a moment ago and purchase/restore is working again for me in the sandbox.

Also can't test anything related to in-app in the sandbox. Everything ends up in the error. Hopefully something to be fixed by Apple soon.

Not happening to any of my apps (not new ones and last updates were ~2 weeks ago), but I can confirm that I see your icon tiled in Chrome as well. Can be something then that came out of the processing error on the Apple's side. Be sure to report a problem via "contact us".

I'm from Czech republic, EU citizen, myself and from what I've studied: Part I, points 5, 6, 7 Is for US citizens. I don't have to fill it. I have Czech VAT and Tax ID, but I believe these are for US citizens who would live abroad, pay taxes elsewhere and then would need to reconcile it. Part II. Point 9 - check if you are. I believe this should avoid having any taxes being withhold from US sales? And plus this is just a confirmation of what residence/tax domicile we are. Point 10, nothing. There are no special rates and conditions in my case. By no means I'm an expert, but I've read the tax treaty between Czech Republic and US and I also read the instructions for filling the form, which these input fields are taken from. By no means you should trust me though. Please make your own judgement.

Same problem here + "Spotlight crashed" almost each time I open an iOS 14 simulator. Logged as FB8753877 with a link to this thread.

Try removing the transparency or changing the alpha of the line color to 1.0. That seemed to be a work around for now, but it appears to be a bug for me too. Thank you for this suggestion @dmorneault, it certainly works! As I didn't want to lose the transparency in my polylines I moved to drawing lines myself in the subclass of a MKPolylineRenderer and providing this subclass as a renderer where I was using pure MKPolylineRenderer before.

Looks like it works again.