This is also spelling out in our end user agreement as well Unfortunately, sounds like maybe your license and app requirements got developed without considering App Store policies up front. If so, there’s no good solution aside from just making the changes needed to pass review. It also seems you ask for gender. Why do you need ? Indeed, be very careful there. I can’t even imagine what a “peer to peer sharing app” needs with gender. If it’s just for cosmetic purposes, such as choosing pronouns for addressing users in messages that you generate... well, be very, very careful. Or just don’t go there.

Are you asking for their specific birth date? It may be acceptable to just ask: Are you at least 18 years old?

They finally (a few years ago) put it all in GitHub, so you can forget about that terrible old web page: https://opensource.apple.com https://opensource.apple.com/releases/ Libm doesn’t seem to be listed under any of the OS release repos, but has its own repo: https://github.com/apple-oss-distributions/Libm

Take a look at this helpful tech talk: Write clear purpose strings.

How to sort this? Pretty much what it says: for your next update after April 29th, you need to build it with Xcode 15 or later. But nothing bad will happen to the version of the app already in the store.

Nothing says you have to use Sign in with Apple specifically, though it’s quite convenient that Sign in with Apple just so happens to already satisfy those requirements. But any third party would be free to develop a new sign in option that also satisfies those requirements. Maybe one or more such options already, or will eventually, exist. (Of course this is actually just a clever response to meddlesome governments forcing Apple to offer a more “open" platform. Now you aren’t forced to use Sign in with Apple but users still have an option for enhanced privacy.)

Has your connection changed from HTTP/2 to HTTP/1.1 for some reason? Headers are required to be lowercase in HTTP/2, but can be any case in HTTP/1.1.

How can I remove and add more devices please wihtout having to wait until new membership year? As the message says, you can’t. I imagine this is intended to prevent using it as a sneaky (if rather labor-intensive) method of app distribution. Do you really have 100 iPhone devices across your team at one time?

Try removing the decoder.keyDecodingStrategy = .convertFromSnakeCase line. You are already supplying an explicit key mapping via enum CodingKeys, so you don’t want the decoder to attempt to perform additional conversion on top of your mapping. Can't the enum be named something other than CodingKeys? CodingKeys is a special name recognized by the compiler to indicate that you have taken charge of defining the key mapping. So enum CodingKeyss will be ignored and the compiler will synthesize its own version of CodingKeys based on your property names. That, combined with the convertFromSnakeCase strategy, ends up performing the same name mapping that your explicit enum CodingKeys performs.

Do I need to do something to ensure bytes is released, since it doesn't seem to be happening on its own? Definitely! See this note in the documentation for UnsafeMutablePointer.allocate(capacity:): When you allocate memory, always remember to deallocate once you’re finished. The Unsafe in the name is a reminder you’re in old-school C land now, where you need to free() at some point after every malloc().

(Before anyone advises just reposting this in the user support forum...) This is actually not up to Apple to implement, nor any other vendor. Emoji flags, defined by Unicode, essentially support only countries and regions that have a two-letter ISO 3166-1 country code, and currently Kurdistan does not have such a country code. (For those of us previously unfamiliar, Wikipedia says it’s a roughly defined geo-cultural region covering parts of Iran, Iraq, Syria, and Turkey.) Here’s a great post with full details of how emoji flags work, including discussion of the lack of support for regions like this: https://blog.emojipedia.org/emoji-flags-explained/

WebKit should be adding be using a prefix as well. I’d appreciate you filing a bug against it. Please post your bug number, just for the record. It looks like the culprit is something called libSESShared.dylib, according to this helpful bit of information someone has put together: https://github.com/MTACS/iOS-17-Runtime-Headers/blob/main/Frameworks/CoreFoundation.framework/NSData.h#L1503

Have you tried Core Location’s isSimulatedBySoftware (link) property?

Note that according to https://useyourloaf.com/blog/iphone-15-screen-sizes/, the iPhone 15 Pro (not Pro Max) is Compact both ways. Do you get the desired layout if you try the iPhone 15 Pro Max simulator?

In order to get more accurate compass data it seems that iOS devices with a simcard installed can provide better results. What leads you to believe this is the case? Is it documented by Apple somewhere? All recommendations are pointing to the deprecated CoreTelephony functions which are obsolete since I am working with iOS17 devices. And note that various functions are annotated with something like "Deprecated with no replacement".