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.

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?

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.

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”? 😉

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

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.

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.

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.

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.

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.

That link from @Claude31 is very, very well worth reading. Then some further thoughts on this: completionHandler: @escaping (Double) -> Void It’s better to use type CLLocationDegrees rather than Double. They are actually the same (via typealias) but using CLLocationDegrees is much more clear to someone reading the code. But with that said, I’d suggest you change to result type to CLLocationCoordinate2D (lat + long) or even CLLocation (coordinates plus other information). Why? Because... Your other post mentions you have an equivalent getLongFromAddress method. That’s not a good idea if you actually need both coordinates, since both call geocodeAddressFromString which is async and relatively slow. Instead you should have a single (say) getLocationFromAddress to get both the latitude and longitude together. If in any any specific call you need only one of them, then that’s fine. So if you changed the completion handler to this... completionHandler: @escaping (CLLocationCoordinate2D) -> Void ...there’s still a problem: this doesn’t handle any error from the underlying geocodeAddressFromString call. The early return means the caller of your method never finds out if there was an error and can’t do anything about it. Any completion handler like this should report both success (with a result) and failure (with an error). If you follow the style used by geocodeAddressFromString then your completion handler would look like this: completionHandler: @escaping (CLLocationCoordinate2D?, Error?) -> Void That’s fine, though there is a newer convention for implementing this sort of “either result or error” completion handler, using the Result type: completionHandler: @escaping (Result<CLLocationCoordinate2D, Error>) -> Void And going further, as Claude said you can convert all of this to the modern async / await pattern, but I think that’s a topic for a bit later.

If you declare a function as async then it should not use a completion handler. That’s the whole point of Swift concurrency: it takes over control of delivering results asynchronously so you don’t have to explicitly. So the proper declaration (with the result type adjusted) would be like this: func getLatLongFromAddress(_ address: String) async throws -> CLLocationCoordinate2D { As an async function there’s no completion handler. Instead, the task simply pauses until the function returns a result. And throws is needed because that’s how you report any error from the underlying geocoding operation, which may throw an error. Then to implement this, it’s easiest to use the async (no completion handler) version of the geocode API. That works like this: let geocoder = CLGeocoder() let placemarks = try await geocoder.geocodeAddressString(address) let location = placemarks[0].location // for now we’ll assume [0] always exists return location!.coordinate // for now we’ll assume the coordinate always exists Then to call this function from a button handler, you need to call it from a Task block (because it’s async) and you should also put it in a do / catch block so you can handle any errors that get thrown during the geocoding.

If an app requires iOS 13 as a minimum, then it can’t run on an iPhone 6.

In your verif() function, the async geocoding is inside a Task block, but below that block you have code that depends on the result of the geocoding. That won’t work. The code after the task block executes immediately after the task is started, which is before the geocoding inside the task completes. To make this work, your code that needs the geocoding result (specifically the checkAddress() call) needs to be inside the task block. Then it will run after the geocoding instead of before it. So basically your entire verif() function needs to be async. And since you call verif() from within a Task block, you don’t need another Task block inside verif(). Try removing that and changing the declaration like this: func verif() async -> Bool { ...and then call it like this: Task { @MainActor in if await verif() { // ...handle success... } else { // ...handle failure... } } Also, note you can optimize the logic a bit. It appears you don’t even need the geocoding result unless the checkCP() test returns false. So it may be helpful to not do the geocoding until you actually need it.

That looks correct. All those timestamps are in UTC (note the “Z” at the end, which means UTC) so they should be 11 hours behind your local time. If presenting them in your user interface, you’ll need to use a date formatter with the time zone set correctly. You did specify your local time zone in the request URL, but the API doc says that’s for determining day boundaries for daily forecasts. Looks like all timestamps in responses will still be in UTC.