Firstly, I realise that Kexts are deprecated. And for my needs, user-space IOKit from an application might be more than I’ll ever need, but I can’t help ensuring I’ve got all my ducks in a row while I’m designing an app. I noticed in the above Kext deprecation notice that it’s more about specific APIs that are deprecated rather than the kext mechanism itself (no mention of IOKit kernel APIs there). Along with the fact that a reboot would be required and various other policy changes. While reading up on System Extensions and the various newer tools, DriverKit, Endpoint Security etc, I’ve noticed there’s no mention of this “IOKit Driver” target/deliverable in the Xcode template chooser. It looks like, from the requirements, that DriverKit is aimed at hardware manufacturers, with a need to request the DriverKit entitlement for development. With respect to Apple’s internal Kext deprecation roadmap, how safe is it to build a product that relies on using an IOKit Driver and are there any requirements similar to DriverKit? Would a developer need to request an entitlement? If I developed an app using user-space IOKit and, for illustration purposes let’s say I also included an IOKit Driver in the app bundle. If I used the IOKit API, including header file constants only (no digging around in the IORegistryExplorer for non-public keys), as Apple intends them to be used, would this fall foul of any App Store rules that anyone is aware of? Put another way, would making use of an IOKit Driver disqualify my app from being distributed via the App Store, similar to an Endpoint Security extension? As an aside, there are a lot of API in the ES Framework that could be used to build apps that have nothing to do with Endpoint Security. File system related apps for example. It’s a shame there isn’t an enhanced middle ground between FSEvents and Endpoint Security framework.

Firstly, I want to keep my GUI app available for download on the Mac App Store, which means I need to provide the Endpoint Security functionality in some other executable, such as a daemon. I'm going to use a User Agent for user-aware background processing. Instead of the typical use of adding an Endpoint Security system extension to a macOS app, could I instead add the sysex to my User Agent bundle? I like the benefits of coupling the sysex to the client that will interact with it, and this would also allow me to not have to worry about managing a daemon. I could simply provide the User Agent in a downloadable installer signed with my Developer ID certificate.

Let's image that someone wants to use a background service to keep track of FSEvents activity, at the file level (a firehose, some might say). I choose this example, to indicate the volume and rate of data transmission in question. I'm not creating a front-end for FSEvents data, but my background service may generate data at a similar pace. The service runs off of user defined document/s that specify the FSEvent background filtering to be applied. Those that match get stored into a database. But filters can match on almost all the data being emitted by FSEvents. The user decides to check on the service's activity and database writes by launching a GUI that sends requests to the background service using XPC. So the GUI can request historic data from a database, but also get a real-time view of what FS events the service is busy filtering. So it's a client-server approach, that's concerned with monitoring an event stream over XPC. I understand XPC is a request/response mechanism, and I might look into using a reverse connection here, but my main concern is one of performance. Is XPC capable of coping with such a high volume of data transmision? Could it cope with 1000s of rows of table data updates per second sent to a GUI frontend? I know there are streaming protocol options that involve a TCP connection, but I really want to stay away from opening sockets.

I'm trying to find out of SF Symbols is the correct tool for job I have in mind. I'm wanting to create custom box drawing symbols, like those in the unicode block. Box drawing requires the lines from one symbol to connect to the lines of an adjacent symbol. Does SF Symbols allow for this connecting of symbols, or does it create some padding restriction around each symbol, preventing lines from connecting to one another?

As an indy developer, it's prohibitive to start developing backend receipt validation services. Is there anything else in Apple's technologies that we can use to verify whether the person who is using my app, has paid for it? The first thing I thought of when Apple rolled out Sign in with Apple ID, was hopefully, it would include some API that would allow me to ask a simply question: did this Apple ID pay for my app? As an indy developer, this is the one feature that would keep my paid app on the Mac App Store. Anyone have any good suggestions for solving this as an indy developer?

I'm busy designing my app's functionality and really would like to provide some features that rely on background processing after the user has logged in. A Login Item seems ideal for this use case. I appreciate the lengths Apple go to, to communicate the complex technologies involved in app development, including the planning of macOS apps. I haven't found any information in the planning and design (admittedly under HIGs) documentation on whether it's possible to provide some background processing element along with an app destined for the Mac App Store. Perhaps it's not mentioned for a reason? However, it would be really useful to background processing dealt with up-front, especially under planning, because it has a huge impact on how one moves forward with product design. Especially when you're an indy developer with limited time and resources. I can't, for the life of me, find where I previously read that daemons and agents weren't allowed to be shipped with a Mac App Store app, because of the Sandbox requirements. It was probably a reply by Eskimo somewhere in the forums. Does the same apply to Login Items? The bulk of the Login Item documentation is in the documentation archive, most of which was written before the existence of the app stores, so I couldn't find any answers there. I previously believed that an app destined for the Mac App Store could only include a single binary, that of the main app itself. Although I've seen the recent article on including a command line utility binary in the distribution too. Also, if my understanding of code signing is correct, apps distributed via an app store are signed by Apple, and thus can't communicate via XPC with a binary signed and distributed via a Developer ID. Or is there some workaround there that might get me closer to my goal?

There are a few things about how Core Data 4 Cloud Kit initializes that I'm stuggling to understand. I've spent most of the day finally getting a schema initialized on the server, and learnt a few things along the way.Firstly, even though I have a Default configuration in my managed object model, and it has been there from day one with the option "Used with CloudKit" checked for true, if I create an `NSPersistentStoreDescription` and set the configuration property to "Default", when I try to load the stores, it will fail, saying "Unable to find a configuration named 'Default' in the specified managed object model.". If I inpsect the debug description for my ManagedObjectModel instance, it does indeed not have any reference to the string "Default" in it (I'm not sure if debugDescription is actually printing out the configuration names however). Why does this fail? I can only get my store loaded and the schema initialized if I remove the code that sets the configuration name to "Default".The next thing that tripped me up was the NSPersistentCloudKitContainerOptions property on the store description. Considering that the only property on that class is now gone, so you no longer need to perform `options.shouldInitializeSchema = true`, I incorrectly assumed that I'd no longer need to even create and set a NSPersistentCloudKitContainerOptions instance on my store description, because all it really holds is the containerIdentifier. Why would I need to specify a container identifier if the system is going to fetch the first iCloud Container Identifier out of the entitlements file and associate it with the Default configuration which I'd (clearly incorrectly) assumed would be automatically associated with CloudKit and my "Default" entitlement container identifier.Below is the code I was using. It's mild playground refactor of my real code, but it's quite straightforward.// Instantiate the Managed Object Model let modelName = "CloudModel" let url = Bundle.main.url(forResource: modelName, withExtension: "momd") let mom: NSManagedObjectModel = NSManagedObjectModel(contentsOf: url!)! // Define the Cloud Store Description let storeURL = URL(fileURLWithPath: "Cloud.sqlite", isDirectory: false, relativeTo: NSPersistentContainer.defaultDirectoryURL()) let cloudStoreDescription = NSPersistentStoreDescription(url: storeURL) cloudStoreDescription.shouldAddStoreAsynchronously = true cloudStoreDescription.configuration = "Default" // this will cause loading to fail with an "Unable to find // a configuration named 'Default' in the specified managed object model." error // Add a container options instance to the description, because without it, loading will fail with // "Couldn't initialize CloudKit schema because no stores in the coordinator are configured to use CloudKit" var cloudKitOptions = NSPersistentCloudKitContainerOptions(containerIdentifier: "com.example.container.identifier") cloudStoreDescription.cloudKitContainerOptions = cloudKitOptions // Create the Container for the Cloud Store let container: NSPersistentCloudKitContainer = NSPersistentCloudKitContainer(name: modelName, managedObjectModel: mom) container.persistentStoreDescriptions = [cloudStoreDescription]