To debug this we would need to see the data received from the server before you try to parse it via JSONSerialization. Is the line 1 bytes the output from calling print(data)? That would definitely not be the valid JSON you are looking for. Now admittedly I have no experience with PHP, but I must wonder if this line does what the comment says it does: // Finally, encode the array to JSON and output the results echo utf8_encode($resultArray);

I would actually find it hard to believe that source language will ever matter in validating an app upload. Even with Swift, the iOS platform API (for the most part) uses the venerable Objective-C ABI, so any toolchain that can produce binaries compatible with that ABI should be valid. With sufficient patience and skill and tool support, you could write an app in assembly or Fortran or even generate the object code by flipping switches on an Altair-style front panel complete with blinkenlights. As long as the resulting packaging is valid and the code can call the needed APIs, it should work.

That’s not the right API. You want the one that goes the other direction: JSONSerialization.jsonObject(with:options:). The term “JSON object” in this API means data structures in your app that can be converted to/from JSON: arrays, dictionaries, strings, numbers, etc. Having said that, I’d strongly recommend you consider the modern Swift API for JSON: JSONDecoder (link) and the Codable protocol. The very old JSONSerialization is fine for Objective-C but isn’t a good choice when writing new code in Swift.

That means that we should never modify NSLayoutConstraint.constant in the code... or else save the values and restore them in viewDidLayoutSubviews. My solution would be to create the troublesome constraint in code and convert the existing storyboard constraint to a design-time placeholder. Then no further workaround is needed. @IBOutlet var myView: UIView! // btw, ‘weak’ is not usually needed var heightConstraint: NSLayoutConstraint! // no longer an outlet override func viewDidLoad() { super.viewDidLoad() let h = traitCollection.horizontalSizeClass == .regular ? 350 : 300 heightConstraint = myView.heightAnchor.constraint(equalToConstant: h) heightConstraint.isActive = true }

Here’s what’s happening. When you go to background, UIKit temporarily changes your traitCollection.userInterfaceStyle to the opposite (from light to dark, or from dark to light) in order to capture an app switcher screenshot in that style, and then changes it back. You can override traitCollectionDidChange: and see that it gets called twice. Unfortunately, this trait collection change triggers a reload from the storyboard of any constraints that have size class variations, even though the size class didn’t actually change. I don’t know if this is a bug or a feature but it’s been like this for a long time. You can observe this effect without even backgrounding: just change the device’s light/dark mode while your app is running. When you change it, the constraint will revert back to the storyboard definition.

Next time, please make sure to use code block formatting like this: CTTelephonyNetworkInfo *netinfo = [[CTTelephonyNetworkInfo alloc] init]; CTCarrier *carrier = netinfo.serviceSubscriberCellularProviders; The error message should lead you to checking the documentation for serviceSubscriberCellularProviders which is indeed a dictionary containing CTCarrier objects rather than a single CTCarrier object. This supports phones with multiple SIMs. There’s an older (and deprecated) subscriberCellularProvider property that hold a single CTCarrier object but the documentation doesn’t define its behavior when there are multiple SIMs, so it’s best to use only serviceSubscriberCellularProviders. Please see this recent thread for a detailed discussion of how to use this API, and especially note that the information in CTCarrier itself is now marked as deprecated and may become unavailable in the future. What exactly are you trying to achieve by accessing CTCarrier?

But note the existing CTCarrier functionality is critical to certain regular apps, specifically the kind that let you test your network speed. In return for giving you a speed result, often they collect your MCC/MNC and location, and use this data (aggregated and anonymized) on the back end to drive analytics, maps, reports, maybe sell it to interested parties such as carriers or cell tower companies. Often there’s an Android counterpart that can collect even more telephony data such as signal strength. (I used to work on such an app, but I don’t any more.) Developers of such apps should submit feedback to plead for keeping the CTCarrier information available in some way. Here some are solutions I can think of: Make it available via a hard-to-get entitlement, as is now the case with the user-assigned device name. Tie it to the existing location authorization, as is now required to access Wi-Fi network information. Add a new authorization API (with system-provided alert, app-supplied purpose string, etc.) as in various other privacy-sensitive areas. Don’t actually remove the deprecated CTCarrier functionality.

Steve Jobs addressed this issue years ago: “You’re holding it wrong.” (Sorry, couldn’t resist. ;-)

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?