is there any order of serviceSubscriberCellularProviders dictionary values?  Dictionaries have no concept of order. You can enumerate the entries in a dictionary, but the actual order in which they get enumerated is meaningless. Our real-time experience is 1st value of physical SIM and 2nd value of eSIM. but on the internet, we saw many developers say they got eSIM value as 1st value and physical SIM as 2nd one. This is expected behavior. When enumerating dictionary entries, the order is not only meaningless but it’s actually random across separate runs of the program. And (noting this for completeness) there’s no significance to the actual strings used as keys in the serviceSubscriberCellularProviders dictionary. The next release could change them to "Jobs" and "Wozniak" and still be perfectly compliant with the published documentation. So there’s truly nothing in the documented API that can tell you the difference between an eSIM and a nano-SIM.

Your example names look like a getter and setter for a “property” (within the scope of an enclosing type not shown) which, if it were defined via normal property syntax, would be named simply number. If possible and if it makes sense, consider using actual properties in cases like this, instead of separate getter and setter methods. Then callers can both read and write the property using very clean dot syntax like this: myObject.number = 42 print(myObject.number) Or if you are asking about naming free (global) functions, then it probably would be more common to name the getter like a property (with no prefix) and use the set prefix on the setter, like this: setMaximumNumberOfGameLevels(42) print(maximumNumberOfGameLevels()) You can find a number of good Swift coding convention guides online that cover this sort of thing in detail. Definitely worth checking out for anyone new to Swift.

Fun fact: you can also refer to nil by its more formal name as an enum Optional case: if var1 == .none { } Of course normally you would say nil but this form might be helpful for clarity in rare cases. And it’s fun to remember what’s really going on under the covers.

There’s a subtle API design issue that’s helpful to be aware of here... as they explain, if you insertSegment beyond the number of segments in topCaptionSegmentedControl, it is simply added as the last segment: First segment 0, then segment 1, etc… UISegmentedControl is a little unusual among array-like data structures as it happily accepts an out-of-bounds index. You could even do this: topCaptionSegmentedControl.insertSegment(withTitle: choice.emoji, at: 9999999, animated: false) In fact most of the segmented control methods that accept an index are documented that way: An index number identifying a segment in the control. It must be a number between 0 and the number of segments (numberOfSegments) minus 1; the segmented control pins values exceeding this upper range to the last segment. But data structures like NSMutableArray or Swift Array will fail if you pass an out-of-bounds index like that. IMHO, this was a poor choice in the UISegmentedControl API design. It’s trying to be helpfully forgiving, but this can just mask bugs in the calling code, and is inconsistent with other array-like APIs you use every day. It’s even internally inconsistent: it helpfully clamps indexes that exceed the upper bound, but not the lower bound. Passing +999 works but -1 fails.

how can I identify whether internet mobile data is connected through [one ]SIM or [the other] SIM? Is dataServiceIdentifier (link) what you need? It’s a key into the serviceSubscriberCellularProviders dictionary (and also serviceCurrentRadioAccessTechnology) for the one providing data.

The documentation is wrong on this point. That’s disconcerting. Shouldn’t the published documentation be considered as part of the contract for using this API? We now know of at least two apps that are relying on the “you can […] override this [navigationItem] property” behavior. The OP’s problem may be due to overriding leftBarButtonItems which isn’t mentioned in the docs one way or the other[1], but for the case of navigationItem it would be much appreciated if the documented behavior remained supported going forward. [1] But in various cases, classes or method that don’t support subclassing or overriding are explicitly called out as such.

What I'm saying is your overrides are not supported. UIViewController.navigationItem is expected to be used as is. Hi @Rincewind, this seems to contradict the documentation, which says: To ensure the navigation item is configured, you can either override this property and add code to create the bar button items when first accessed or create the items in your view controller's initialization code. In my app, we load (once) a pre-built UINavigationItem from a nib via an outlet and then return it in an override of navigationItem. As of iOS 16 this is working fine and seems to be in compliance with the documentation. Should we worry that this will break at some point?

Hold on, don’t run outside to play in the sleet just yet. The documentation for Precipitation.sleet (link) says: A form of precipitation consisting of ice pellets. That’s American sleet, and remember that Apple APIs and documentation generally are written in American English.

What OS/version is this happening on? I just tried it on iOS 16 simulator and the REPL in Monterey, and the URL gets created successfully. However, while unencoded apostrophe works (at least on these versions) indeed it’s a best practice to encode it. But that still won’t work in your specific example, because the URL of your actual page uses a curly quote (U+2019 RIGHT SINGLE QUOTATION MARK in Unicode-speak). That character also works unencoded, or is more properly encoded as %E2%80%99. Probably an even better practice would be to manually remove this character from the URL (which is obviously derived from the page title) if you have control over that.

That alert didn't come from iOS. You should double check your third party libraries. Maybe this is a stealth feature of one of them for some reason. (Maybe such a library secretly harvests user data and has determined that it’s out of date itself, and hopes your next app release includes a newer version that can secretly harvest even more user data. It’s explained more clearly using colored string on my conspiracy board.) Clues that this isn’t an Apple-authored alert: iOS doesn’t even have a feature to prompt users to update apps like this. The title yells at the user with an exclamation point. Apple doesn’t yell. The apostrophe is vertical rather than curly. Apple knows a thing or two about typography.

Sounds like an annoying change, but was the old behavior (the relative order of the notification and delegate call) actually documented? If not, then I wouldn’t be surprised to hear back from Apple that this isn’t a bug.

Well, does the “MAC” in “SQUADMAC” refer to Mac computers, like you’re a squad of experts on that particular platform? Or is it totally unrelated? If the former, then you’re probably out of luck. If the latter, then you can try to write up and submit a detailed explanation of what the name means and why it shouldn’t be considered a trademark conflict. Good luck.

In your bug report, you could also mention the screenshot in the online user guide is even more confused about latitude and longitude:

I use the (navigator bar height + status bar height) to calculate the originY of the content view. That assumes the navigation bar always abuts the status bar with no gap or overlap, but I don’t know if that relationship has ever actually been documented by Apple. If that happened to be true for past models, it seems not to be true for the iPhone 14 Pro models for whatever reason. Maybe they just want the bottom of the nav bar, including the 1-pixel shadow below it, to fall on an integral point boundary. Sounds like you should use the bottom edge of the nav bar’s frame as the top of your content view. The status bar frame isn’t relevant to that calculation.

As you’ve seen in the other thread, there’s no documented support for this. But even worse, note that starting with iOS 16 the whole CTCarrier class is marked as deprecated with no replacement. All properties of CTCarrier will eventually return placeholder values “at some point in the future.” (Your carrierNames array elements will all be "--".) So it’s not too soon to start thinking about how you will handle this loss of functionality.