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.

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.

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.

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.

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.

There are several lower-level libraries like libcurl that are not present on iOS. I strongly recommend the built-in alternatives instead. There are many to choose from.

First of all, don't use the comments in the forums. They effectively hide your reply. When searching for new or updated questions, your question still shows up with only one reply. Your comment isn't listed. If you already have it working on macOS with an outline view, I strongly recommend you just resolve those few remaining issues. Trying to use a diffable data source is the path of greatest resistance. Even on iOS, the only reason to use it is because there's no other option. It's much more difficult. It would require a significant rearchiteture effort. On iOS, what you see as an outline view is just a collection view where the cells are simply full-width. That hierarchical display that makes it look like an outline view is implemented with both NSDiffableDataSourceSnapshot and NSDiffableDataSourceSectionSnapshot classes. It's really tricky. For example, because it's a collection view, there are no rows. You can only insert before another identifier, after another identifier, or append to a parent. The entire concept of a hierarchical list was something that was clearly thrown in at the last minute, without much documentation.

In theory, anything's possible. There's a GitHub project trying to implement an "OutlineViewDiffableDataSource" but it hasn't been touched for years. I've also seen various attempts to reimplement outline views or to implement them on iOS prior to diffable data sources. So that can be done too. What are you hoping to get that's better than the current NSTableView/NSOutlineView? It's certainly difficult to use, but then so are diffable data sources. My outline views on iOS with undo/redo support were much more difficult to achieve than any equivalent on macOS.

You should probably request one of those "one-on-one App Review consultations", as described here: https://developer.apple.com/events/view/upcoming-events

Try sysctlbyname with "machdep.cpu.brand_string"

The reason is the need to support older macOS Version and the newer ones. We have a bunch of build agents and want to keep the total amount of them as small as possible. And on the other hand use the current version of macOS on them when ever possible. I'm not sure what you mean by "build agent". You can use the current version of Xcode to build code that runs on anything from macOS 10.13 "High Sierra" or later. If you do need to support deployment to 10.12 or earlier, then you will need an earlier version of Xcode. But the cut-off here is Xcode 13.4, not 12.4. See this page for more details. But otherwise, you are correct. There is a "maximum macOS version requirement" for Xcode, which isn't documented anywhere. If for some reason you did need an older version of Xcode, then you'll have to run an older, matching version of macOS on either an old computer or a VM.

Xcode versions are usually closely tied to a particular macOS version. Sometimes there is a little leeway where the next major release of Xcode will run on an older version of the OS. But with Xcode, Apple will sometimes introduce an incompatibility in a minor version. For example, my production system is Ventura and I'm limited to Xcode 15.2 (I think. I'm not there right now.) In most cases, upgrading Xcode doesn't cause any problems. There are a couple of significant issues with Xcode 16, so it is always important to pay attention to what's next. But I don't see any reason why you would need Xcode 12.4. And if you did (maybe for < 10.13 support), I don't see any reason why you would need Sonoma.

Building a notarized Perl app on a Mac using the command line? You're kind of fighting the whole world at once there, eh? 😄 In addition to the hardened runtime, you'll need some entitlements to relax said hardened runtime. Put those in an XML file and use the "--entitlements" flag with "codesign". Make sure to completely test your installation with all kinds of funky edge cases. In addition to all the up-front notarization checks, there are certain checks that happen only at runtime, or only at runtime when you try to trigger something like dynamic loading or JIT execution. That is the part that trips up most people in your situation who get that far. I don't know which entitlements Perl will require - most likely all of them.

That is a read-only properly. Just remove the "set" and it should be fine.