Is it possible to call a specific screen What does this mean? It doesn’t seem to correspond to the title of your post. without user consent That’s usually a red flag here in Apple-land. What exactly are you trying to accomplish? Note that setAlternateIconName always presents an alert after the change, so you can’t quietly change the icon without the user noticing. And while there doesn’t seem to be any specific discussion of this in the HIG or API documentation, the intent of this API is pretty clear: to let the user pick an app icon they like, such as a sports team logo or a more pleasing color scheme. It doesn’t support using the icon to display useful information like the built-in calendar and clock apps do.

That banner is added by Flutter, not by Xcode or by the simulator. Knowing that, a quick web search on “flutter debug banner” may be all you need. In a more general mode - how do people create screenshots for iOS without owning a bunch of physical Apple devices? Just the good old iOS simulator.

That condition always needs to hold, or else the type wouldn’t work correctly in hashed collections such as dictionaries and sets. Those work on the assumption that equal values being compared (such as a dictionary keys or set members) will first have equal hashes, and then have equal values. If you need (for example) 1 meter and 100 centimeters to be considered different for displaying as separate items in a list or something, then you can make a wrapper type that implements equality and hashing appropriately. But note this would require them to be considered not equal, and then it’s not obvious what the other comparison operations (greater-than and less-than) actually mean.

It’s a field called associatedStoreIdentifiers which seems to be buried quite deep in the pass documentation. See also this post.

Start here: TN3111 - iOS Wi-Fi API overview

That usage of async is actually a function (see here) which returns a Task instance. It’s arguably confusing to have both a function and a keyword with the same name, and just initializing a Task directly seems cleaner. Seems like the kind of API refinement that is normal when developing something new with everyone watching.

Even if the performance is the same, you may find the multiline literal style easier to read: let description = """ title - \(myItem.title) \ subtitle - \(myItem.subtitle) \ text - \(myItem.text) \ price - \(myItem.price) """

Note that the full signature for URLSession.download(for:) is actually this: func download(for request: URLRequest, delegate: URLSessionTaskDelegate? = nil) async throws -> (URL, URLResponse) So I’m thinking this means the async version ignores the session’s delegate and only uses the optional delegate you can pass in here. Why ignore the session delegate? Just a guess, but the session delegate is documented as running on a specific OperationQueue that you specify when creating the session. But the async version doesn’t say what queue the delegate may run on. So this API design allows it to run on a different queue than OperationQueue used for the old-style tasks.

Short answer: this is considerably harder on iOS than on the other platform. Search online for “iOS crack prevention” to get started reading on the topic. Then you’ll be better able to decide whether this is worth the trouble.

Glad it’s working, but this still seems vulnerable to the original problem. The completion handler still captures and updates the cell you are setting up (hCell) but if the handler actually runs after any appreciable time delay, then the captured hCell may not refer to the cell you want. Also, what’s up with the members.isEmpty check? Sounds like members is your data model, so if it’s empty, then why are there any cells being displayed at all? Or if members being empty means you are displaying a placeholder cell (e.g. “Sorry, you have no friends.”) then maybe you want to check earlier and dequeue a cell with a different identifier that is specially designed for this case.

overrideUserInterfaceStyle (link) may be the droid you’re looking for.

What would such a delegate do? Your onlineViewStatus view (btw, would the name be more clear as onlineStatusView?) seems to be just an “output” via its background color, and doesn’t seem to have any actual behavior that would need to be reported via a delegate back to the view controller. Is this correct? Try to make the cell behavior as simple as possible: you have an image, a name, and a view that shows online status. You already get the image and name from the Member object which is passed to the cell during configuration. Similarly, now you’ll want to pass the online status to the cell when you receive it, and then the cell just sets the color. Then the cell class becomes extremely simple. The fun starts at “pass the online status to the cell when you receive it.” So the view controller would launch async operation(s) to fetch everyone’s online status, and then updates the cell for each member when that member’s online status is received. The best way to do this is to build your table using a diffable data source. (If you’re not already using this, I strongly recommend it. It makes things much easier.) Then you use the diffable data source snapshot to tell the table to redraw the cells that need updating.

I suspect a race condition due to using async operations to set up the cell. If getDocuments() is async, then the completion handler may be called after the cell has already appeared on screen, scrolled away, and even been reused for a different member that has scrolled onscreen. If that happens, the completion handler’s capture of self refers to the reused cell, which no longer represents the original member. (And the snapshot listener could cause an extreme case of this, if a snapshot update could happen a long time after you create it.) You could try to work around this by saving the Member or its documentId in each cell and checking it in the completion handler to make sure it matches, but it’s still not a great solution. This cell setup code will get called a lot as you scroll and it’s best to keep it fast and avoid redundant work. Can you do all this async work in your view controller or view model before you show the table? And then update the table when you receive changes.

The bug report you filed is the source of truth. Keep an eye on it for status changes or clarifying questions.

What issues are you having? In theory the forum site should work with any modern browser on any platform. It’s not that fancy. Here’s one thread with some troubleshooting ideas for people using Chrome. If you’ve definitely found a compatibility bug when using your platform and browser, please file a feedback report.