it is the only way to get it without having to use private API's. Actually that code does use a bit of private or undocumented API: the interface name prefixes it looks for ("pdp_ip" and "en") aren’t official API. They probably won’t change any time soon, but there’s no actual guarantee they won’t. provide documentation on the interfaces used on the code It’s using the old BSD function getifaddrs(3). In a command prompt, enter the command man getifaddrs to get started. take the total Wi-Fi and cellular usage and compare it with the new one every 15 minutes Here’s a big gotcha with that API: the returned byte count values are unsigned 32-bit integers, not 64 bits as the wrapper code suggests. So they can wrap around zero fairly often depending on data usage, and I don’t see that your code or the wrapper code handles this. With a sampling interval of 15 minutes there’s a risk of wrapping more than once between samples, which would make it impossible to track accurately. You can make this work if your sampling interval is guaranteed to be less than the time required for a single wraparound (that is, the minimum time needed to transfer 4GB of data). But if (for example) your app is waking from the background to take a sample while other apps run, then you may have trouble meeting this timing requirement.

All my replies are still there. But note one of them quotes from a previous reply to me by @endecotp, and that reply I quoted from is what disappeared.

Here is mine: https://developer.apple.com/forums/thread/719597

Based on your description, this would be extremely unexpected. I’m chiming in just to add that I just noticed that (in another thread) a reply that I had replied to yesterday also mysteriously disappeared, leaving the message thread sounding a little confusing. Maybe Apple has recently implemented an almost-perfect filter to block the occasional spam storms... emphasis on “almost”? 😉

Are you saying the app is literally crashing, or just that this is a “normal” termination by the OS while in the background? (Saying “normal” in quotes because you are reporting that it seems abnormally frequent and unexpected, even if the OS does have its own reasons for the termination.) Is this happening only on iOS 16.0.1 and 16.0.2? Did it not happen in older versions? Does it no longer happen in newer versions? If it stopped happening, then great. Or if it’s still happening, then consider it an opportunity to add or improve your app’s state restoration logic, to preserve the illusion of seamless background execution across termination events regardless of the cause. That’s a nice feature in any app.

Not clear what you mean. Does the equivalent app on Android receive valid JSON when accessing the same URL (running the same PHP code)? Or is something else different? Or does the Android app also not receive valid JSON? Can you access that URL via a web browser or a simple utility such as curl? What is the result?

You are perhaps too new to iOS development Actually I’ve been at this about 12 years but still haven’t read any version of the developer agreement in full. 😉 The clause was removed from the agreement Sounds like the rare example of the people with relevant technical expertise within a large organization actually winning an argument.

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.

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);

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. ;-)