SwiftUI List performance

I believe you are correct that it is working this way, but I don't think it should be. My expectation was that whoever was currently the Agent for our Enterpirse Developer Program would have access to the current push certificates list in the portal. I'm glad I discovered this is not the case before I removed the previous Agent's account. Since allowing a certificate to expire requires re-enrolling after replacing it with a new certificate, this is just a remarkable way to hurt yourself. Especially since there aren't any warnings about this on the portal or member center.

I believe it is the date on which you can delete devices from the list of iOS device UDIDs associated with your account. It should be the date of your original iOS developer program expiry. Now that they have added a variable number of days to people's memberships, that date doesn't necessarily coincide with the membership renewal date any more. So they list it separately.You can delete devices before that date, but if you are at the 100 device limit then you still wouldn't be able to add new ones until after it.

Has anyone made any progress sorting this issue out? I'm still getting non-responsive trackpad and keyboard on wake. I suppose it may be related to the USB known issue listed in the release notes.

Rich, you wrote:1) You might have seen the alert when a purchase attempt occurs - 'You've already purchased this. Tap OK to download it again for free'...... This alert will occur whenever a user with a new device requests to 'buy' an IAP rather than to 'restore' it. At this point in the dialog (i.e. the user is already at the App Store with a purchaseRequest) the user will have added the transaction observer whether they do it your way or mine so any unfinished transaction will already have come through to updatedTransactions.2) Something else to consider. If there is an incomplete transaction and the restoreCompletedTransactions method is called to restore previous transactions, the incomplete transaction will not appear in the array of prodict identifiers to restore. Using my approach of adding the transaction observer only when necessary the code will addTransactionObserver when it executes a restoreCompletedTransaction. 3) As to the recommendation to calling addTransactionObserver in the didFinishLaunchi

the only thing mine has from your list is: Universal app.

Honestly, if you want a notification-style model to work properly, the objects observing probably should be classes.The observers need to have a stable identity, so that there is a valid target for the callback.The observers need to allow the notification center object to keep a reference to them rather than a copy of them, so that the observer is the original object.The observers need a way to deregister themselves when they go out of scope, so that the notification center doesn't try to access a deallocated observer.There are things that structs are great at... the qualities listed above are not any of those things.Using classes for types that need to listen for notifications, and using the existing NSNotification system is just simpler in most cases.You can use a unique-per-instance generated String as the sender for the notifications, if the property you are observing belongs to something that ought to be a struct, in order to match notifications originating from a particular struct instance.But

This isn't about runtime type information. If Swift properly performed generic specialization it could make the correct call with static type information. This is essential to a sane generics implementation IMO. It should be guaranteed by the semantics of the language so we can rely on it. I have to wonder if this code would behave differently when compiled under optimization if the optimizer chose to specialize the calls to baz on lines 22 and 23. If it does we have optimizer-dependent behavior which seems really bad. If it doesn't we have generic specialization that is really crippled.While I am really excited about Swift, love to see Apple doing it, and know the team is working really hard to improve it rapidly, I have to say this kind of issue seems to pop up in many corners of the language and really drive me nuts!

Yes, T with no constraint will behave exactly like Any!Swift can do generic specialization (like shown in wwdc) but only for performance goal when optimize the code. But the final behavior is the same.It's not like C++, which generates a specialized version of every single call.Just to complement: The main problem is the two levels of generic abstraction.When the compile the baz function, there's no constraint to make the compiler create a specialized version of foo function, so compile will decide call the Any version.bar and foo don't have this problem.