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.

Is the provided folder structure valid for creating a localised help books I doubt it. Is there anything that is missing from across Info.plist files or is in the wrong places? It's hard to say. Many of these values are app-specific. They are correct only if they correspond to your app's specific files. Why the MyApp -> Help opens the main help menu, not the app help I don't understand your question. Generally speaking, building an official help bundle is very difficult. There were some major functionality bugs for many years. I don't know if they ever got fixed. Very few developers bother with help bundles. Most just configure the help operation to open a page on their web site. And yes, as you might expect, those help pages are regularly broken. Your diagram is showing the organization of your Xcode project. As far as the help project goes, all of that is irrelevant. What matters is the final output. I can't say for sure if your project will work or not. You'll have to test it yourself. You will probably only be able to test it when it is installed in /Applications. That was true at one time at least. Help books are very delicate. The best course of action is to find one of those rare 3rd party apps that has one that works and copy what they've done. You can't copy Apple apps because they do really wild things with help that you can't replicate.

NASA has many web sites. You'll have to specify exactly which site you are talking about, ideally with the URL. Any individual mission can have many different data providers. Unfortunately, without knowing more information about what you are trying to do, there isn't much more I can tell you. I think you may have touched on the problem with the reference to APOD. Generally speaking, NASA (and any similar/connected organization) is going to have two sides. One side is dedicated to regular folks on the internet, schoolchildren, etc. That's the APOD the side. The other side is meant for professionals and researchers. This is the real data. It may be in some unusual and very difficult-to-use formats. There may be some unusual access practices. For example, when you download data, you might have to wait for some robot to go fetch the data from tape and load it on disk. Or you might have to just put in a request and wait, perhaps days. Plus, because NASA et al. are such huge organizations, there is no commonality between data sources. Different access points can have wildly different practices. Some may be old-school tape systems. Some may have migrated to AWS or similar. No way to tell without a URL.

I've started getting dozens of crashes related to the NSOutlineView implementation, with many different types of crash report signatures, which all seem internal to Swift and/or NSOutlineView. Thanks for the heads up. I haven't deployed my code at all yet. I think I've seen some comments that Apple is replacing lower-level Objective-C code with Swift. Your crash logs look like that. I made a thread about this here and filed a feedback, but haven't received any response: https://developer.apple.com/forums/thread/767447 Not surprising. I basically need the sidebar to show what on iOS would be done with a sectioned UITableView (which doesn't exist on macOS). You should be able to do that easily enough. macOS uses header rows instead of sections. But you can float and style them and they'll look nice. As far as that goes, if you want to be clever with styling, you could probably draw the row backgrounds so that it looks identical to iOS. I use a dictionary to drive the NSOutlineView. That sounds very bad. Table and outline views should be driven from an array. In outline views, the root is an array. Each element has an array of children. It loads fine, but if something changes, I have to update the 'count' of the item (by updating the count property of the item in the dictionary) and call outlineView.reloadItem, which ends up causing the crash in 1% of the cases. Both of your crashes involve parent/child relationships. I saw another post recently here in the forum that suggested dictionaries on Swift aren't entirely stable. It sounds like your data model is changing underneath the UI. In my opinion, the only time you would ever call reloadItem is to update an item. Never use it to update children. Update children in some other fashion where it can be animated. I think this may be the problem. Table and outline views are really old. They still support old usage methods that don't require animation. That may be hiding bugs that you would have seen if you had done the extra work to make sure everything is animated. That can be a whole lot of extra work and could even require a change of architecture. I have a similar implementation on iOS so it would improve consistency as well. But it doesn't seem to be possible with NSOutlineView, only NSTableView (or collection view) When I did that on iOS, it seemed like the hierarchical representation was the flakiest part of it. I seem to have gotten it to work, but I don't have much confidence in it. You can certainly try it if you want to, but it would still be a Mac implementation. You've already seen how much anyone cares about Mac issues. replace it with a SwiftUI view I started my project in SwiftUI. But after a certain level of hacks, I realized that it just wasn't going to work. When considering the amount of work this will take, also consider the amount of work it will take to reimplement it later without SwiftUI. Plus, these kinds of Split View displays have changed significantly in SwiftUI and could change again. It sounds like trying to use a dictionary as a data source is the problem here. NSOutlineView is more primitive than UICollectionView. If an item isn't expanded, then you don't need to update the UI for changes to children. But if an item is expanded, then you'll need to manually add rows to accommodate what has already been changed in the data model. The way I did it, I have a "data source" wrapper around the various diffable data source snapshots on iOS. I have a similar "data source" wrapper on the Mac side with a very similar interface. But the Mac "data source" actually does some UI manipulation just due to the ancient, kludgy nature of outline views. From from a higher level, view controller perspective, both platforms are virtually identical. That's really the way it works anyway. On iOS, you have your data model and then the diffable data source is just an opaque structure of identifiers that has to match the data source. On the Mac, the outline view itself plays that role in maintaining a structure for the underlying items.

When you create a project, you'll be prompted for a location to save it. I don't recommend the Desktop or any other folder that may be controlled by any kind of file sync system. Any build products like app files or debug/release objects will be located in your "DerivedData" folder at ~/Library/Developer/Xcode/DerivedData. You normally should never need to dig into this folder. When you run your project in Xcode, it will run from an app wrapper in a folder deep within DerivedData. When you're ready to distribute, you'll perform an archive build and you'll have to specify what you want to do with the build product. You can choose to submit it to the App Store, distribute it using a different method, or just save it to disk.