smb big sur

I’m not sure what happened here. Generally, when there’s a new agreement pending, the Developer website makes it very obvious as soon as you enter Developer > Account. There’s a big banner at the top and the act of agreeing to the update is quite explicit. Unfortunately this stuff is hard to test because you can’t undo your agreement. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

“Submitting a Rejection Appeal” I have already submitted this, but I doubt the team will fully understand the situation and that my account will be reopened, because I am currently being unfairly labeled with a “Pending Termination Notice” and “Evidence of Dishonest or Fraudulent Activity.” Please look at the screenshots. I am already trying to contact the App Store Connect team, but they suspend my account without even giving a warning. There is a big problem here, the account cannot be suspended that easily. There are people who abuse their position.

Started happening on Xcode 26.0.1 or were you successful with that version of Xcode? To clarify, it works properly with an iOS app upload. It is only for MacCatalyst app. So Xcode 26.0.1 works for ios and not for MacCatalyst. Have you tried today to submit one to TestFlight? I have, twice, still been getting the same issue. I will try again later today. Do you have all the logs? I have the build logs. But it is too big to attach to this reply. I will add it to the bug report.

What I don't understand from the reviewer's response is what receipts validation are they talking about? When a user makes a purchase, it creates a receipt in the app bundle. Your app should check the validity of that receipt. If it is valid, then you make the premium features available. If you don't validate the receipt, then hackers will re-distribute your app with a fake receipt so that anyone can use it for free. They might even charge a fee, making money off your app instead of you. Don't assume you're too small to be targeted. I assure you that you're not. I have no payment servers (the whole concept of using Apple's in-app-purchases service is to not have to deal with my own payment implementation) That's something totally different. Most apps are subscription based or have some service provided over the internet. For these use cases, Apple provides a quick-and-easy way to validate receipts. In your case, since you're entirely on-device, you'll need to validate the receipt on-device. That's tricky beca

I tried .otherNavigation and .other Also, it is not snapping to roads, at all. It is just that when the ship moves slowly, it does not really update the reported position, insteads it stays around the current position for a while and later makes a big jump to a new area where it resides then. The behaviour seems to occur less often if the ship is travelling faster (e.g. downstream). I parsed the internal locationd logs for GNSS NMEA messages and resolved positions and related them. The NMEA reported raw positions are plotted in blue, the resolved positions are plotted as green circles with their radius being the reported accuracy, and there are faint orange arrows pointing from NMEA positions to the afterwards resolved positions which are then reported to the apps.

This sounds related to my feedbacks FB16246168 (Text in Lock screen accessory rectangular widget does not wrap to another line when it should fit) FB16246023 (Lock screen accessory rectangular widget does not appear as expected on iPhone 16 Pro because text is too big and truncated) But both of those were filed before iOS 26

I’m not going to be able to help you with this. We don’t support folks killing arbitrary system processes. This is problematic for a variety of reasons, but the big issue here is that the name, location, and behaviour of system processes are all implementation details. If you build a product that relies on such implementation details, you are likely to run into compatibility problems down the line. Which is exactly what’s happened in this case )-: My advice is that you find an alternative way to achieve your ultimate goal. If you’re unable to do so, I recommend that you file an enhancement request for a supported path forward, making sure to explain your requirements and the reasons why the current mechanism don’t work for you. If you do file an ER, please post your bug number, just for the record. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

You can't. Tokens are created per app per device when the app calls registerForRemoteNotifications() I don't understand why writing a program to do so is a big deal, as you say you already have an app to send notifications to. So, you need to implement push notifications in your app as shown in the sample project.

Dear Apple, with regards to the above - can you please shed light on the connection between: CXProvider delegate method providerDidReset This is called when the XPC connection between CXProvider and callservicesd is interrupted. invalidate() method in CXProvider Among other things, this breaks the XPC connection between CXProvider and callservicesd. If you call invalidate(), then the delegate will receive providerDidReset. Is it 100% always true? When it comes to software engineering, I am violently allergic to the word always. The system is big, complicated, and constantly evolving, which means there's a pretty big difference between: This is what the system normally does VS The system behaves this way under all circumstances today, in previous versions, and in all future versions Yes, I suspect providerDidReset generally does get called when you invalidate, both now and in the past. That's the strongest promise I'll make. My current Xcode has a line like: The provider must be invalidated b

Kevin and ssmith_c for your assistance. I fortunately managed to file in the bug: FB20677188 Thank you! Looking over the bug, there was one point I wanted to comment on: For the Matter Media Device Basic Video Player Type Apple Home does support the commissioning (adding the device to the list of accessories displayed in Home App), but no controls are displayed. Not even the mandatory required controls: ... This type of Matter Device, which is part of the standard, should at least expose the mandatory controls and commands. The idea that Apple (and general ecosystem vendors more broadly) should try and support the full range of the Matter specification is, IMHO, one of those ideas which sounds reasonable on the surface but is, in fact, a very bad idea. First off, quoting myself: The Matter specification itself is sufficiently broad and complex that, in practice, I'm not sure it will ever really be possible to create a high-quality controller app* that actually supports EVERY possible accessory configuration i