you seem to be under the impression I'm trying to sell it? Well, yeah. I have to work for a living. I assume many other people do too. If not, why bother? you're suggesting that the app reviewers have decided there are enough Launchpad clones? Sorry, I didn't make my self clear. I'm a not an employee of Apple, Inc. Nor am I affiliated with Apple in any way other than through the Developer program. I do not claim to speak for Apple in any way. I have zero knowledge of internal App Review processes beyond my own experience several years ago, and a then a few weeks ago. I'm just a dude spouting off his opinions on the internet. When I say I'm not trying to clone Launchpad, I mean to say I'm trying to offer the same functionality but with additional features. Not just a cut and paste version of Apples. But you posted a link to your website right there. It looks identical to Apple's LaunchPad. App Review is doing you favour here. Apple's LaunchPad was never very good. Had a 3rd party developer submitted that design to the App Store before Apple included it in the operating system, it probably would've been rejected for both bugs and lack of functionality. Tahoe's new version is even worse. It breaks both LaunchPad and the Spotlight interface. Apple benefits from platform control and end user inertia. 3rd party developer have neither. We have to do better than Apple to succeed. Yes, there are 1000s of duplicate apps in the App Store. What's the point in being duplicate # 1001? Build something unique instead.

the lengthy lecture about what App Review is "doing me a favour" with a bit strange After your initial greeting, you said, and I quote, "I'm seeking advice". And then, at closing, you doubled-down on that with, "Any advice, experiences, or suggestions would be greatly appreciated." You've also managed to argue both that Launchpad is terrible (and Tahoe's version is even worse), and that I shouldn't bother building something better. You're mischaracterizing my statement. I suggested that you shouldn't build something that looks like LaunchPad, and apparently App Review agrees with me. That's what an app launcher looks like. As I said in my first reply, I recently purchased a nice app launcher from one of my favourite developers. It looks nothing like LaunchPad. That fact was part of the appeal. My original question was a straightforward one: have people encountered IP issues during review for apps that improve on native functionality? You posted a numbered list of 5 specific questions, followed by an explicit request for "advice, experiences, or suggestions". I answered each of those questions and provided advice and suggestions based on my own experiences. Good luck with your app launcher!

That isn't a standard operation. You'll have to invent it. It should work similarly to the "openDocument" method. If you dig into the "openDocument" method, it has a pretty good description of how the architecture opens a new document from URL and displays it. You'll just have to replicate that with a data object or pasteboard item. Once you get to the NSDocument level, there is a read method that accepts data.

You'll probably need to subclass NSDocumentController.

You definitely wouldn't want to change the highlight style in "viewFor". Maybe do that in viewDidLoad or something. Your terminology isn't quite right. You're getting a row view and setting the layer colour on it. There's nothing wrong with that, and it would be a correct solution. But it's not "cellView". It looks like your actual cellView is drawing its own background. That's what you would want to disable. (Unless you wanted to do the selection drawing at the cell view level). There's more than one way to do this. TableViews are just really complicated if you try to do anything fancy with them.

What's the issue ? That's a method that creates and returns a cell view. It gets called frequently and not by you. It's not an appropriate place to set a tableview property that you only need to set once, when you want it set. I change my mind to stay consistent with system behaviour and will change the color of the text (to white) when selected, to make it more readable. What if the user's in dark mode? I checked some code where I was doing this. What I'm doing is subclassing the row view and overriding this method: // Customize selection. override func drawSelection(in dirtyRect: NSRect) { if self.selectionHighlightStyle != .none { let frameColor = NSColor.selectedContentBackgroundColor NSGraphicsContext.current?.saveGraphicsState() frameColor.setStroke() let rect = CGRect( x: box.frame.minX + 5, y: box.frame.minY + 4, width: box.frame.width - 10, height: box.frame.height - 10) let roundRect = NSBezierPath(roundedRect: rect, xRadius: 4, yRadius: 4) roundRect.lineWidth = 4 roundRect.stroke() NSGraphicsContext.current?.restoreGraphicsState() } }

When it comes to anything related to nibs or storyboards, init is playing with fire. In fact, the entire setup sequence is quite delicate and depends on your point of view. For example, if you're starting with a standard NSViewController, you don't touch any @IBOutlet until viewDidLoad(). But even there, there's not much you can do with those objects beyond basic setup. There's no geometry or windows at that point. For that, you have to wait until "viewWillAppear" or "viewDidAppear". Then you'll have a window and know its size. But if you're using Auto Layout, you don't know the sizes of any views until after Auto Layout has settled down, whenever that happens. Hopefully you've done your layout properly and it's a finite process. From an NSWindowController perspective, I have no idea. That class is required for certain very specific operations, but not what you're talking about. That's why one class is a "Window" controller and the other is a "View" controller.

How are you opening these files? Do they have attributes that are different than other files?

You probably started both apps from the templates. Interface Builder is just XML, so classes are just class names. It doesn't know the difference between two different classes that are both named "ViewController". I had this problem in a project I'm currently developing. My main app showed objects from my UI tester app. I closed the main app and opened just the subproject with the UI tester app. From there, I could safely refactor "ViewController" to "TestViewController" to fix the problem.

My first thought was some kind of cross-platform PDF code that wasn't doing file coordination properly. But what you're showing is basic NSDocument file reading. However, NSDocument can get very complicated when writing. You said you're writing a viewer app. Are you sure you've specified the role for PDF as "Viewer"? There would have to be some other kind of change, possibly to attributes or permissions, in order for Time Machine to balk. Reading a file should be a no-op in that respect.

Closing the app and running TM fixes the error. So you're saying there is no error? Because that's how Time Machine works. It doesn't back up open files. There is some uncertainty as to what constitutes an "open file" on macOS. Obviously an open SQLite file or a package being actively modified will qualify. But an NSDocument file, even though it opens a file only briefly, could replace the original at some later date. I'm happy to let the Apple folks debate those finer points. If the problem goes away when your app quits, then there is no problem. You still haven't answered my question about your NSDocument Viewer/Editor role. Perhaps that is an improvement you can make.

I set the PDFDocument to nil when I close it. Maybe review how you're doing that. The NSDocument teardown process is not straightforward. As the documentation says, the "close()" method doesn't always get called. This is a general problem throughout the UI APIs. The init, setup, layout, display, hide, teardown, dealloc process can be quite delicate. This is most apparent with NSDocument, where everything either happens at an inconvenient time, or simply not at all. It's better to rely on major events like NSWindowDelegate "windowWillClose" to perform your teardown. Make sure your teardown logic can be safely called repeatedly, and then call it again in places like close() and dealloc. The "Debug Memory Graph" tool is very useful. Just run your app normally. Open a couple of documents and close them. Then hit Debug Memory Graph. You may be surprised at what objects still exist at that point.

This all makes me think that "sleep" on macOS in the past few years is now defined differently -- perhaps an Apple Silicon change? But I can't find documentation that covers this. Buried in a WWDC video, maybe? I think it was before that. It sounds like you're encountering "Dark Wake". It's only hinted at in a couple of places in the documentation. The "Power Nap" feature is closely related and seems to be more openly acknowledged. But I don't know of any way (for an app) to detect or control when they get triggered. Apple engineers say there's no way to detect it.