If your app really does look different due to the changed safe area and the home indicator, then why not do your potential new users a favor and show them accurate screenshots. As to whether the reviewers would actually notice if you cheat... nobody here can answer that. ;-)

The bug is in your format string: DD means day of the year. You want dd which means day of the month. Also, there’s a subtle difference between YYYY and yyyy in some cases; see the Unicode spec linked from here.

There isn’t always a new SDK for every OS release. From the user-facing release notes, it sounds like 16.3 doesn’t have any new APIs that would require a new SDK. And the developer-facing release notes for 16.3 says this: The iOS & iPadOS 16.2 SDK provides support to develop apps for iPhone and iPad running iOS & iPadOS 16.3.

It’s amusing that this guideline: This feature may not be used for dynamic, automatic, or serial changes, such as to reflect up-to-date weather information, calendar notifications, etc. ...basically tells you not to do something that the API doesn’t support anyway. It’s good to be thorough. But be mindful of this part: and the app includes settings to revert to the original icon. So just changing the icon in response to navigation actions within the app may not satisfy the guideline. Since we’re down to trying to parse the exact meaning of the review guidelines, I think you should just submit your app and see how it goes.

Breakage aside, are the new fields also values from 0 to 1 but with a name ending in Pct? Or do they seem to go from 0 to 100? Either way, seems a little sloppy. Hopefully this is just a pre-release thing they are trying out for now.

Just to clarify: did you already request and receive the CarPlay entitlement as described in the first paragraph of that documentation?

You should be able to call setAlternateIconName whenever you like. Is it not working in your case? Make sure to check for success via the completion handler, or by catching any error thrown if using the async version. If it succeeds, the system should present an alert to the user automatically. Is anything not working as expected? With that said, I’d be a little worried about this: Technically it is possible, but it seems to be a problem in the app review process. What does this mean? Did your app get rejected for this? If so, what was the reason? Are you trying to “get around” app review in some way?

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.