Here’s why: Supported URL Schemes. Especially note this statement: Other Apple URL schemes are not officially documented. Their use is unsupported. If you rely on such implementation details, things might work, or they might not, and that state might change over time.

Here’s the latest word: Supported URL Schemes.

While preparing for your one-on-one App Review consultation, just note that lots of IoT companion apps do exactly what you describe, ranging from (just looking around my own house) security cameras to dog trackers. Also note that Wi-Fi scanning directly within apps is “limited or restricted” by simply having no supported API for doing so. There is no such restriction on receiving blobs of data from a connected device and displaying them to the user.

That’s correct, for the same object. The original description didn’t clarify if you were doing this, with a single dictionary: let object = Test() object.test() object.test() ...or doing this, with a new dictionary each time: Test().test() Test().test() If would be unexpected to get the varying results if doing the first case.

on my colleague's computer [...] within the same session, we get the same order in print(i) Are these different computers running different versions of macOS (if testing a Mac app) or iOS device / simulator (if testing a target device)? There was a cutover point in the OS where this behavior changed. Before they rewrote Dictionary in Swift, the old Objective-C implementation produced stable orderings for the same set of keys across all dictionaries in a given process. But after, the orderings are unstable between individual dictionary instances. See this thread for some more discussion of this effect.

I’m wondering about the purpose of those weird offset values, since they represent the offset in mean solar time at the longitude of those cities rather than official time zones. It’s not inconceivable that some bug exists somewhere in handling nonstandard time zone offsets like that.

See this recent thread for a good discussion of the topic. You don’t give a specific example of the condition that may trigger that specific crash, but the answer is basically that Swift doesn’t support handling low-level exceptions like that.

figure.stand and figure.stand.dress Doh! I tried searching various terms such as “man”, “male”, “female”... didn’t think of “figure”.

There are a few with “toilet” in the name, available starting in iOS versions 16.0 and 16.1. They look like what they sound like. There don’t seem to be any for the pants-wearing person and skirt-wearing person icons commonly found on restroom doors. To request something new, probably just file a regular suggestion via Feedback Assistant.

When posting code examples, please use the Code Block formatting style, like this: func getCellularConnectionType() -> String { return "This is readable now." }

Emoji are governed by the Unicode Consortium, not Apple. Start here: Guidelines for Submitting Unicode® Emoji Proposals https://unicode.org/emoji/proposals.html

This is a popular topic lately. See the  Recommended reply and link in this thread.

Here’s one recent thread on the topic that includes a link you may find useful. We have a client that want us to add such button Gotta wonder what their next example of unfamiliarity with this platform will be.

Is your project configured (by someone) to run a linter as a build step? If so, is that linter performing auto corrections? (Yikes!) And if so, is that linter triggering on your structs that contain no instance properties? (I’m familiar with SwiftLint which has a rule that suggests changing struct to enum when there are only static properties, but it doesn’t trigger on your Padding struct. Maybe a different linter does something similar but goes wrong in your case.)

Having an app abruptly vanish and dump back to the home screen is also known as “crashing.” Why do you want that user experience in your app? The user can always go directly to the home screen or task switch to another app using the standard interactions for doing so. Here’s an old but apparently still valid document on the subject: How do I programmatically quit my iOS application?