It's best to reply as a new reply. The "comment" functionality only serves to hide activity. I'm not familiar with the Network framework. They don't seem to be all that sensitive. In every reference I can find, people are just using ".main" or ".global()". When Apple engineers respond, they don't seem to be complaining about that. So perhaps you're just thinking too hard. That being said, many apps are little more than demo apps. And I have seen Apple engineers go out of their way to recommend against ".global()" in other places. Many years ago, I tried to write some real-world networking apps and ran into many of the same kinds of detailed questions that you are asking. I was trying to use GCD networking directly, before the Network framework existed. My solution was to switch to a simpler, more well-defined, and proven API - BSD sockets. You do have that same option too. There is always a risk when committing to a new API that depends on some other technology that later falls out of favour and/or use. I think your other question is much more straightforward and specific. Hopefully you'll get a good answer there.

Why do you care? And why are you avoiding the elephant in the room - Swift Concurrency? While GCD isn't deprecated, it does appear to be disavowed. Given that documentation was never its strong suit, and no one ever really knew how to use it, it seems like it would be risky to rely on any of those answers even if you could get them. If Apple breaks and/or changes Swift Concurrency, they'll have to document it. Or, if nothing else, people will figure it out and complain about it online. Either way, with a large user base, the word will get out. But if Apple changes anything at the GCD layer, perhaps to support those upcoming changes to Swift Concurrency, anyone relying on low-level GCD behaviour is going to be in a pickle and no one will be able to help.

Posting your feedback ID in these discussion forum questions does seem to result in more attention from people who can affect change. I would like to know what happens in your case if you turn off all indentation. I would also like to know what your Xcode editing and indentation settings are. You are one of the only people I've seen who has mentioned this problem. Since I can't reproduce your specific experience, if I could reproduce it, I might be able to tell you what causes it. And maybe I could figure out a way to fix my version of the indentation problem.

Xcode 16 unindents lines if I choose a code-completion and I cannot find a way to stop this - does anybody know how to stop it? Here's a link to a gif demonstrating this problem - it's incredibly frustrating. That's strange. I see the exact opposite. I have all indentation turned off, yet any use of code completion adds an unwanted indent. I filed two feedbacks about this in June. Both were closed with nonsensical replies. FB13893391 FB14102219 But I've definitely never seen it unindent the way you describe. But I'm mainly using Swift these days. I just tried with a C++ test project and I can't reproduce what you are seeing when I have all indentation settings turned off. I also tried turning on various settings to trigger what you are seeing, but I couldn't do it. File a feedback. Maybe you'll get better results than I did. Then turn off all indentation. At least for C++, that seems to work. I guess I should have stuck with C++ instead of switching to Swift.

The sidebar is the result of using the Source List style for your navigation table view. You have to add the sidebar toggle button yourself. Set the "isNavigational" property to true so that it appears in a navigation location in the titlebar. I think there is some sort of "toggleSidebar" operation. There is a menu item for it. But the built-in operation isn't animated. For an animated collapse, you'll need to set the "isCollapsed" property of first NSSplitViewItem, using the "animator()" proxy, of course. Rest assured, it is much more complicated than it sounds. There's a reason why SwiftUI is so popular. If you hit the wall on what SwiftUI offers, you have to make some hard choices.

So now I don't know what to think. Either, the useless answer was sent by an actual Apple human who didn't read the question, or it was written by a bot that is sentient enough to acknowledge its mistake! Before they all got laid off, the Community Specialists on the Apple Support Community used to be accused of being bots. I think these first-tier support engineers are only allowed to post canned replies. Maybe they don't even have moderation rights, which is why they reply instead of just delete. I think the more interesting aspect of that other thread is knowing the exact number of words that someone will read from this kind of forum posting. I guess the magic number is 60. You have to state your key points in the first 60 words to avoid being misunderstood or ignored. That's good to know. I always get annoyed when I reply asking 3 specific, important questions and the OP only ever answers one. But it's definitely not a bot. I haven't seen anyone posting bot replies here at all. They do that in the Apple Support Community often enough. You can always tell they are bot reply due to the numbered list. I think the only non-Apple people posting replies in this forum are in this thread!

It would be best to start with Xcode. Create your project from the appropriate template with your best guess for a name and save it somewhere appropriate. When you save the project, you'll have the option of creating it in a git repository. Then, you can create a GitHub repository with the same name. I believe that once you do this, it gives you instructions on how to push a local repository. You can just run those command on the command-line from the directory containing your Xcode project folder. Then refresh your GitHub web browser and you should see all your files. Xcode will automatically detect and use GitHub as the upstream. I recommend against using the Desktop for Xcode projects. The Desktop could be under control of some kind of file sync service like iCloud. You don't want to mix that with git. It won't turn out well for you.

Does anyone else in the forum community have any other information on this topic that they would be willing to share. I'm afraid the community is pretty small. If Apple support engineers don't take an interest in your question, which they probably wouldn't in this case, there are only a handful (as in 3 or 4) of other people who ever answer questions here. Specially, how (code - that will only be used for my personal use) you were able to get Photos to download from the NASA website I reference in my post. Photos is an end-user, consumer app. If you have questions about those kinds of apps, it would be better to ask on the Apple Support community, which is more focused on end users. This forum is intended for code-level developer support for developers on Apple platforms. That's why I'm guessing that Apple engineers wouldn't respond to a question about NASA APIs. In my case, I just downloaded those images using the command-line "curl" app. You haven't said anything about the actual code you are writing, so nobody knows what would be appropriate in your case. Generally speaking, this isn't something that Photos would be support. You might be able to build an Automator script or a Shortcut to download images. I know nothing about those tools. That's definitely a question for the Apple Support community. If I wanted to script something like this, I would do it in Perl. That's what I used when I wrote these kinds of APIs for NASA. 😄

Don't put too much time into it. I just double-checked and I don't see any changes. It still seems fundamentally broken. The biggest problem I encountered was that the "anchor" functionality doesn't work anymore. I can't confirm this because I'm not using a true help book anymore. But it still seems broken. I can use the hiutil tool to create a help index file, but the same tool can't read a help index file. That ultimately seemed to be the reason that caused anchors to be broken. While Skim is using a true help book, it looks like they haven't updated it in years. For example, it doesn't support dark mode. Apple did eventually update the help UI to support dark mode, so I know this works. Also, debugging is difficult. The system will cache the first help book it finds for your app and won't ever look again. You'll need to manually kill the "helpd" process to get it to load a new help book. It might also only look for help books in /Applications. It was just way too many hassles for me. I implemented my own help UI and that works great. It works very similarly to Apple's UI and solves all the problems I mentioned above. I used to publish it on GitHub, but nobody cares about Mac help. And finally, one thing that Apple has changed recently is not a good change. Before, the help UI was a floating window in your app. Now, the help is run by the new "Tips" app. So when users want help, it takes them out of your app. Plus, the built-in help search functionality will search all apps, potentially showing your users some great features in competing apps. My solution was a fixed UI with a real help book underneath. My app's help would still be incorporated into the system help, but without all the downsides. Unfortunately, because help apps are so rare, a certain developer of a popular app checker app started to flag my app as being suspicious because my help bundle didn't have a separate signature from the rest of the app. Obviously that's wrong, but what can you do? There are lots of reasons to build your own help, and many reasons to avoid Apple's help architecture.

From everything I’ve read, it seems that Apple’s intent is Library/Application Support. Have you read About the iOS File System? I'm not sure what you mean about storing "the app". Which is the correct location? And hopefully, a few compelling justifications. It depends on the data. See the above link. If you want the user to access it, use Documents. If you want to keep the user out, use Application Support. On one of our iPads, the app stopped displaying what was two years of data in SQLite. I haven’t yet tested for index corruption, however one of the programmers believes this resulted from an iOS update that needed space and cleared data in the cache (but that makes no sense to myself). That is the behaviour of the Caches folder. You probably shouldn't save databases in the caches folder. That is reserved for cache files that can be easily re-created, if necessary.

You'll have to specify the path to the file. When you are running in the Xcode debugger, you may be able to specify that in the scheme settings somewhere. Normally these kinds of simple apps are designed to be compiled and run from the command line. In this case "watch.txt" would be located in the current working directory of wherever your Terminal shell happened to be using at that time.

First of all, be careful with any code you download. This particular "API" looks a little suspicious. The GitHub project for the API says it is GPL licensed. That means NASA can run it on NASA's servers, but you better not even look at the source code. Use only those REST endpoint URLs and try to reverse-engineer them as best you can. If you are doing this strictly for your own personal knowledge, then you can do whatever you want, as long as it is within the terms of whatever license or terms of use apply. Years ago, by law, any official, published US government products had to be public domain, giving everyone unrestricted use. I don't know if that is still true. The source for that API is GPL, and the NASA API web site itself has a Google Terms of Use. If you ever want to develop a real app, be very, very careful with licensing, both in terms of the content itself (the photos), and the API (terms of use). All that being said, everything works as expected. I'm not familiar with the structure of the results. It concerns me a "page=2" query works because I can't find the total number of pages. And the query without pagination works, but returns different content. But I've only looked at it for a couple of minutes. The direct imagery URLs seem to work. The one I tried returned a 301 result. You'll have to inspect the HTTP headers to find the target URL. When using a higher-level API on a device, or just somewhere on the client side, you'll want to handle this kind of result. A REST server like this, especially one from NASA, may employ more unusual HTTP response codes than you may have seen elsewhere. Those direct URLs come from a different server. You don't need to add your API key and probably shouldn't try.

That is not the correct constructor for UIImage. It is actually "init?(named name: String)". That "?" means the method returns an optional. You app is expected to gracefully handle a nil result in this case. It could fail for many different reasons. But the UIButton constructor does not return an optional. You can assume that it doesn't fail. There is no guarantee, of course. But if the system can't create a UIButton for whatever reason, chances are that the device and app will have long since died for some other reason. Some APIs will throw an exception instead of returning a nil. The documentation and compiler will clearly identify those cases and you'll be expected to handle them.

Make sure to test your app using any combination of settings that Apple permits, such as iCloud Private Relay, Lockdown Mode, etc.

You can only use system libraries for which you have a header file in the SDK. If the SDK headers don't expose the functions, then you should consider them private and avoid them. You can work around this problem by including your own copy of the lzma library. That won't change any of the automatic detection. You'll still have to configure the project so those symbols aren't exposed. In most cases, all you need to do is link with a static archive.