Don't ever put an option to exit your app in an app. It's an extremely poor user experience. Seconding that! Even if your user interface really is just an ”Update me!” message, there’s no need for a force exit feature. The user can just task switch away or return to the home screen like any other app.

You are close. The custom encode(to:) just needs to be the inverse operation of init(from:) (using a single value container) like this: func encode(to encoder: Encoder) throws { var c = encoder.singleValueContainer() try c.encode(asString) } Should I do JSONSerialization instead? Nope! That’s a huge step backwards from the nice Swift Codable API. BTW, would it be feasible to make asDouble be a computed property, derived from asString as needed? Or the other way around? Ideally only one of them would be a stored property to serve as the single source of truth.

You set the copyright text yourself in App Store Connect. See Platform version information for details.

Is this what you are looking for? menu → Xcode → Settings → Behaviors → Running → Generates output → uncheck Show debugger There’s a similar setting under Running → Starts too, though it seems to be unchecked already by default.

Just enter the desired character directly in the xcconfig file. The XML character reference ߒ isn’t needed since an xcconfig file isn’t XML. It’s just a text file encoded in UTF-8 so just about any character should work. Also note that you can enter this directly in the Info.plist file too. The XML character reference syntax is fine of course (and improves readability in this case) but isn’t needed in most cases.

Even worse, interface names such as pdp_ip0 and en0 are not considered API, so you really shouldn’t rely on them at all. (Search the forum for those names for more about this.) And even if each SIM got its own documented BSD interface, the deprecation of CTCarrier means it would be hard to even figure out a name for the SIM currently being used. #include <ususl_caveat_about_specially_entitled_carrier_apps>

is forKey:fileSize considered accessing non-public API? value(forKey:) itself is public API of course, so you likely wouldn’t get rejected by whatever means App Review uses to try to flag more obvious non-public API usage. However, you are relying on undefined behavior, which is still a bad idea for compatibility. The documentation of that class doesn’t mention a property by that name being supported via KVC. In fact, at this very moment, an engineer at Apple may be busy rewriting PHAssetResource in a way that still conforms to the documented API but no longer responds to fetching that particular property via KVC, and your code would stop working in the next OS release. Make sure your app can handle that.

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”.