you won't get through since so many things have changed Here (link) is just one of those many things: Starting April 25, 2022, iOS, iPadOS, and watchOS apps submitted to the App Store must be built with Xcode 13, which includes the SDKs for iOS 15, iPadOS 15, and watchOS 8.

But first, a sanity check: are you sure you don’t want the new app to be an update of the old app in the store? That way, users of the old app can update easily, or even automatically.

If this is an open-source framework, then you should example the code to determine exactly why this is happening. If it’s not (and you have only a binary) then I would be concerned about why the framework wants location authorization when your app hasn’t requested it.

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.

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.