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

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.

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

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.

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?

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.

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?

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.

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

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.

Was sent here when I asked in the general forums and they pointed out I was running public beta, so had to ask here. That’s bad advice over there. This forum isn’t the right place for troubleshooting app issues, whether on beta or on an official release. According to the beta FAQ, about all you can do is this: When you experience an issue or something does not work as expected, send your feedback directly to Apple with Feedback Assistant.

See here for some background on why you shouldn’t expect to find a simulator for every release. And can you clarify: does your app not crash on 17.4 beta? Have you locally tested your app in Release build (which is what TestFlight users get) in addition to the usual Debug build you use during the edit/debug cycle? Have you tested on a real device running 17.3? Do you have crash reports from TestFlight that shed any light on the cause of the crash?

Do you mean update that key via code while your app is installed on the user’s device? That’s not possible. Two issues with that: Your entire app bundle is read-only so you can’t modify Info.plist or any other file at all. LSApplicationQueriesSchemes is thus also read-only because its whole purpose is to minimize abuse of the canOpenURL API. Previously, apps could use it to scrape a list of other apps that are installed on the device. So their stance is: you aren’t allowed to do that any more. The limit of 50 entries is a simple compromise to allow legitimate use of canOpenURL without letting malicious/advertising apps get away with scraping too much information. What exactly are you trying to accomplish?

Arguably it’s even more confusing: not even considering combining sequences, NSString is indeed basically “UTF-16 code unit string” and doesn’t process surrogate pairs (for code points outside the BMP) for operations such as length. But then NSCharacterSet does actually support surrogate pairs and all the supplementary planes, aside from the bug that @Amiorkov encountered here. BTW, you can actually see the bug in Apple open source in CFCharacterSet.c. In the specific scenario of creating a character set of both BMP and non-BMP characters, you end up in CFCharacterSetAddCharactersInRange() which assumes the range is in BMP and silently truncates the range’s location (starting code point) to 16 bits while appending to the existing string of BMP code points.

trying to understand there is a different results when checking the two strings "a🥀" and "a😀" And those two emoji would produce different results in your letters test because: U+1F940 WILTED FLOWER gets corrupted to U+F940 CJK COMPATIBILITY IDEOGRAPH-F940 which is actually categorized as a letter in Unicode: 1> print("\u{F940}".unicodeScalars.first!.properties.generalCategory) otherLetter U+1F600 GRINNING FACE gets corrupted to U+F600 which is not a valid Unicode character (it’s in a “private use area”) so it’s not a letter: 2> print("\u{F600}".unicodeScalars.first!.properties.generalCategory) privateUse