If I understand correctly, you can run the binary from Terminal. The Finder is different. It's going to expect a real app. That's a totally different environment.

Start here: https://developer.apple.com/documentation/technotes/tn3151-choosing-the-right-networking-api I have a really old code base where I think I must have supported 10.6 at one time. I have a class called "CURLRequeset" that was a wrapper for the funky Libcurl API. It was easy to convert this class to use NSURLSession if it was available. I should probably rip out the Curl logic. It hasn't been triggered in years.

Yes, I can run the binary by calling "cargo run" from the Terminal, and then the binary opens as well. Sounds like it's working then. So you are saying that when using Finder, it expects a real app. Yes. A "real app" is just a bundle directory that wraps the executable and includes dynamic libraries and frameworks, helpers, resources, and various metadata files like an Info.plist. Ok, so how do I convert my Rust binary into an Apple app? No clue about anything Rust-related. I can tell you that every "real app" includes a command-line executable. You can usually run that executable on the command-line like any other Unix command. Sometimes this can be handy to easily see certain log messages or to force the app to run in a particular localized language. The downside is that since you aren't running it from the Finder, there may be some unexpected behaviour. But sometimes you can even have apps that run normally in the Finder, but also have a special command-line only mode. Now the mechanism of displaying a graphical user interface via a command-line app is deep, undocumented black magic. It works for most "real apps" built using normal Xcode templates. It also works for legacy architectures like XQuartz and maybe Tcl/tk stuff. If Rust is able to hook into standard Apple APIs and Frameworks, then it should be able to do that too. A further question. Are all binaries that run on MacOS considered "apps"? No. There are all kinds of exotic things that can be executed. If so, that would imply that all binaries compiled with Xcode would be "apps". It is true that Xcode was designed for app building and for building various other app-supporting artifacts. But Xcode is also just an IDE like any other. I build websites in Xcode using XML and XSLT. That being said, Xcode includes too much baggage for simple, educational command-line tools. But since you are poking around with exotic command line things like Rust on a Mac, I should warn you. Modern, open-source projects can sometimes be based on extremely complicated build systems that make Xcode look simplistic by comparison. (Anything that anyone from Google or Meta has ever touched, for example). If you are trying to build any of that stuff on a Mac, you might find it easier to discard those build systems and port it all to Xcode. It sounds like a lot of work, but at the end of the month, you'll have something to show for it where you wouldn't trying to figure out something like Ninja etc.

There are many different communities for various languages and platforms. If you choose an odd combination, then the burden will be on you to figure it out. Rust people may not know anything about Apple platforms and Apple developers may not know anything about Rust. That can be an opportunity for you to become that expert. But generally speaking, the barriers are social and psychological rather than technical.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.