why it works if i set .ascii instead of .utf8? That’s the critical clue here. It turns out that file is not encoded using UTF-8, and contains some bytes that are not a legal UTF-8 encoding. So the file is being downloaded just fine but the string initializer fails because it can’t handle those non-UTF-8 bytes. Note the file actually uses the Windows-1252 encoding, according to this line: <meta http-equiv=Content-Type content="text/html; charset=windows-1252"> Specifically the issue is around line 551 which contains a degree symbol for latitude and longitude. It’s encoded as single byte B0 in the file, but in UTF-8 that would be the byte sequence C2 B0. So the most correct encoding to specify would be .windowsCP1252, though you’ve seen that .ascii also happens to work in this case since they are mostly compatible.

Using an example of code block formatting: is the second line here for real, or just a copy/paste error while redacting your code for the forum? — request.addValue("application/json", forHTTPHeaderField: "Accept") request.setValue("application/json", forHTTPHeaderField: "Authorization") Assuming a bad authorization header isn’t the problem, can you be more clear about what is going wrong? it doesn't record the information What does that mean exactly? Does the upload execute successfully (without hitting any of the error cases) and the data is simply not available on the backend? Or does it execute one of the error handling cases? If so, which one? Also (at least for next time) please try to cut down the code to the smallest amount that demonstrates the problem. That makes people more likely to read it and often helps to figure out the problem directly. In this case, the code for validating input and dispatching results to the UI isn’t relevant to the core problem and is best omitted when posting.

In your bug report, you could also mention the screenshot in the online user guide is even more confused about latitude and longitude:

I use the (navigator bar height + status bar height) to calculate the originY of the content view. That assumes the navigation bar always abuts the status bar with no gap or overlap, but I don’t know if that relationship has ever actually been documented by Apple. If that happened to be true for past models, it seems not to be true for the iPhone 14 Pro models for whatever reason. Maybe they just want the bottom of the nav bar, including the 1-pixel shadow below it, to fall on an integral point boundary. Sounds like you should use the bottom edge of the nav bar’s frame as the top of your content view. The status bar frame isn’t relevant to that calculation.

As you’ve seen in the other thread, there’s no documented support for this. But even worse, note that starting with iOS 16 the whole CTCarrier class is marked as deprecated with no replacement. All properties of CTCarrier will eventually return placeholder values “at some point in the future.” (Your carrierNames array elements will all be "--".) So it’s not too soon to start thinking about how you will handle this loss of functionality.

See also this thread about similar weird behavior for iPhone 14 Pro models with TestFlight.

There’s actually a form to fill out to request the entitlement. It’s linked from the documentation page for the entitlement.

Or does it mean it is yes if the app is built with iOS 15.4 SDK or later? That’s the one. This lets old apps keep working the same based on the default that was current when they were built, but as soon as you build a new app or an update, you’re now responsible for knowing about and handling the new behavior. Note it says linked rather than compiled, which implies that you (building the final app) are are responsible for handling the behavior change even if you use 3rd party libraries that were built before the behavior change and which may contain assumptions about the old behavior.

not sure I'm familiar with the "Standard" and "Zoomed" options you're referring to It’s an end-user feature so you access it within iOS itself: In the simulator, go to Settings → Developer → View On a device, go to Settings → Display & Brightness → View (or Display Zoom on iOS 16)

There are lots of great online resources for learning constraints, but for now the short answer is: the order doesn’t matter. Don’t think of constraints like an assignment operation in a procedural language. Rather, a constraint just expresses the result you want. The layout system then looks at the constraints and figures out a layout that satisfies them. In this case, the safe area is always fixed in position, so the system knows unambiguously exactly where the label should go: 326 points up from the bottom. But if you prefer, you can switch the order of the views to (say) make things more clear in Interface Builder. In the attributes inspector for the constraint, click on either First Item or Second Item and then select Reverse First And Second Item.

I have an engineering background, but very very new to iOS development. Welcome! Unfortunately it’s not good news on this issue... our organization built has a dependency to UIremotekeyboardwindow, which i'm told, will no longer be supported after iOS 16 is released. Actually that was never a supported API and should never have been used by apps in the first place. It’s an internal implementation detail of the OS that people have figured out how to exploit over the years for various purposes. But since it’s not a public API, it could get changed any time and break apps that use it. Apps should use only public, documented APIs. What exactly did the existing code accomplish via this API? There may, or may not, be a way to do it via public APIs. should we expect all apps that use this class to crash once a phone is updated to iOS 16? It depends on each app. If designed to fail gracefully (and simply lose the relevant functionality) then great. Or if never designed to handle the case of it no longer working on future OS versions, then not so great. See this thread for a longer discussion of a similar issue. The solution may even be relevant to your situation.

I battled this too, and lost; see this thread. (Takeaway: it’s a bug.) You could mention my Feedback ID in your own bug report. It may help the  folks to keep track of duplicate reports on this.

Building and running on macOS 12.3.1, base SDK 10.14 It’s because your app is built with an old SDK version. You’re seeing a clever compatibility trick to sidestep bugs in some (or many) older apps that checked the version number in an unsafe way. If you raise your SDK to the current version, then you should get the true version string. Here’s one article that explains it pretty well: https://eclecticlight.co/2020/07/06/why-big-sur-wont-stumble-over-version-numbers/

Here another thread where someone found a solution that worked for them. A quick internet search for "user rejected certificate for github.com” turns up more of the same, and the issue seems to be around something at the client end blocking something it shouldn’t. Are you behind a corporate firewall, or ad blocker, or corporate safe browsing proxy, or something like that? Is your Xcode configured to access GitHub via HTTPS, or via SSH? Are you able to clone the repo from the command line (using git clone) via either of those protocols?

My question: How to return a nullable [pointer] from an Objective-C method which also throws? There’s a function attribute for that: swift_error. It’s hinted at in the documentation here and described fully at https://clang.llvm.org/docs/AttributeReference.html#swift-error. The default behavior, as you have seen, is equivalent to __attribute__((swift_error(null_result))). In your case, you’ll want to use __attribute__((swift_error(nonnull_error))). Then throwing will be controlled by whether you populate the error out-parameter.