I am curious if ANY level of obfuscation is allowed? Yes, any level of obfuscation is allowed... because it’s totally irrelevant to App Review. They review only your final binary and never see your source code. You can write code with clear symbol names or incomprehensible symbol names and it makes no difference. But I don't really want to make it easy for someone to pull the strings from the binaries and try and copy my work. You can search around the web for much more discussion of this, but basically that’s a pretty difficult thing to do on the iOS platform. And if someone did extract your binary, they won’t see your symbol names. Those disappear during the build process for your final binary. In fact that’s why you’ll see references to needing to “symbolicate” crash reports obtained from user devices: the crash report doesn’t contain any function names because they aren’t on the device at all. Try this: take your .app bundle built from a Release (not Debug) configuration, and search through all the files in it for the kind of strings you are worried about. You shouldn’t find them. If you are coming from a platform where obfuscation is a more normal thing to do, that really doesn’t apply on iOS.

What you want is a “localized standard compare.” Here’s an example of using it via the SortComparator protocol in the Swift REPL: 1> import Foundation 2> print(["1H", "10Ne", "11Na"].sorted()) ["10Ne", "11Na", "1H"] 3> print(["1H", "10Ne", "11Na"].sorted(using: .localizedStandard)) ["1H", "10Ne", "11Na"]

Definitely (probably) a bug let you do Same here when not logged in. I’d expect it to prompt you to log in, as when you hit Reply or Add a Comment when not logged in. I think the icon represents raising your hand for attention, like the Raise Hand reaction you can do in a Zoom call.

Are you specifying the angle in radians (correct) or degrees (not correct)? If that’s not the problem, can you post a small sample of code that produces the unexpected result?

Can you post a small sample of code that demonstrates the problem? Asking folks to examine a full project, hosted externally, isn’t really how the forum works. But having said that, the countries.json file you linked is not valid JSON.

That’s weird. I tried your code in an otherwise empty class and got no warning. Can you show how the class itself is declared: the superclass, other protocols implemented, any attributes like @MainActor, etc.? Do you get the same warning if you implement this protocol method in an otherwise empty class in your project?

Pro tip 1: Don’t use legacy Objective-C functions CGRectGetMinX() and CGRectGetMaxX() in Swift code; use gameArea.minX and gameArea.maxX which are equivalent but modern and Swifty. Pro tip 2: Always start variable names with a lowercase letter, so dino instead of Dino. Breaking this naming convention can really confuse experienced Swift programmers trying to read the code. btw im just following a video so please dumb it down for me Pro tip 3: Be wary of any tutorial or video (on any programming topic) that’s more than a few years old. They often don’t age well. Yours appears to be one that is almost 8 years old. It looks pretty good overall (after just glancing over a couple of the episodes) but as you can see the actual APIs have evolved since then. BTW, another forum user was working off the same video and already performed some of this modernization. See this thread. And to answer the actual original question: arc4random() indeed doesn’t take any arguments. Why is that there? The video uses a function called random() which is defined elsewhere in the code. And (no surprise) the API for generating pseudo-random numbers has evolved since then anyway.

Take a look at this gosh-darn bleepin’ thread: link.

This gets asked a lot, and the answer always amounts to: this is an unrealistic requirement and it’s impossible to implement a perfect solution. Search the forum to find lots of old discussions. Here’s a thread with an especially clear and logical argument: link.

Snoop here: TN3111: iOS Wi-Fi API overview.

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".

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?

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

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

(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/