https://developer.apple.com/system-status/ Ha! I get "The system status is temporarily unavailable. Please try again later."

I believe that you need to set . activityType to “fitness” if you want to avoid the snap-to-road misfeature. Please try this and let me know if it works for you. I went through this years ago; it would be useful to know if that’s still the best fix.

Is there a way we could make all the accounts active so that we receive the funds in the acquired currencies? No.

Don't read the reviews or look at the ratings, it will only make you miserable. Just concentrate on making the best app you can.

Is this actually Mac OS, with the app running in "made for iPad" mode? Edited to add: What fallback policy do you recommend I recommend not using App Attest, precisely because for some small 0.xy% of users it doesn't work, and those are not all hackers.

Yes, I see this too - don't panic, no doubt it will resolve itself.

It wouldn't surprise me if you're using a newer version of Swift than was current when the book was written. It is an evolving language, and not always backwards-compatible.

I have this note in my implementation: req->SetContentLength(std::to_string(receipt.size())); // Apple return 400 Bad Request if we don't send this, // and it's not added automatically.

Your experience with previous review times may have been better than average - wait patiently for a week (or more?) before worrying.

Who owns the IP address block? Have you considered using something like Amazon SES? Fundamentally, email is unreliable due to spam filtering. Don't depend on it. Have some alternative mechanism for whatever it is that you're trying to achieve.

No

Can we bundle our app with our own version of SQLite with extensions that we want. Yes, and you should do that. The version that Apple includes depends on the iOS version (see https://github.com/yapstudios/YapDatabase/wiki/SQLite-version-(bundled-with-OS) for a table). If you use the Apple version, there's a danger that your app will break after an iOS update, or will not function on an older iOS version that you are still trying to support but don't test on as well as you should. I was caught out by the latter issue because the sqlite in iOS 14 doesn't support "on conflict" without a column list.

Sure, you can integrate acceleration to get velocity and integrate velocity to get distance. But the problem is that you integrate all the errors in the sensor values too, and they quickly dominate. This is a well-known problem that has been studied in the context of submarine, aircraft and spacecraft navigation (pre-GPS) for decades. The solutions tend to be either ever-more precise sensors (which is not something you can change on a phone) and "sensor fusion", where you blend your integrated value with a value from another sensor. One example of sensor fusion is the Kalman Filter - look it up. Do be aware that the sensor values that you get on iOS have probably already been processed in some way by the system before you receive them.

Now, returning to the Objective-C doc, I see this: What you're seeing now is the fixed version. Until yesterday, the * was missing. AgentFriday and I both understand the differences between classes and structs in C, objC and Swift and neither of us was misreading anything. There was no confusion; it was a bug in the documentation generator which has now finally been fixed. user-level bug Huh? There's a difference between "user-level bugs" and "developer-level bugs"? I guess I'd better go and look at all my completely ignored bug reports from the last decades and check if any of them accidentally got in a "user-level" category.