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

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.

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() } }

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.

You'll probably need to subclass NSDocumentController.

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.

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!

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.

Alright, thanks! So I can’t move the Developer folder to an external SSD, right? To be honest, I've never tried doing anything like replacing the Developer folder with a symbolic link. In many cases, when there is something special about a folder, like special system protections, or it's being managed by a system daemon, you can't do that. But I don't know about the Developer folder. I had forgotten about the Locations setting. In my case, I could use that to move 17 GB on this machine. But the iOSRuntime is the big problem. At one point during the summer, this folder went crazy and completely filled my SSD with 300 GB of data. I had to hack it via SIP. A later build fixed that. This is just one of those problems that can be easily solved with money. A problem solvable with money isn't a real problem.

What's the "Repository Up Arrow"? I don't see any arrows. The closest thing I can find suggests it may be part of GitHub Desktop, which I don't use. .gitignore is part of git. You'll have to take that up with Linus. However, this is a good use of AI. Forget "vibe coding", use AI to explain how to do things in Git. This is probably causing your issue #1. You probably have some IDE data files managed by Git. You don't want that. Try this for a .gitignore file: .DS_Store xcschememanagement.plist **/xcuserdata/ **/xcshareddata/ That's another Git issue. Use Fetch Changes to do things like detect new branched added elsewhere. I forget what Refresh is good for. I have used a couple of times, but only a couple of times. It sounds like most of your complaints are just about Git. Source control system were much easier and straightforward 20 years ago.

Is it safe and supported to move Xcode to an external hard drive (SSD), use it from there, and simply connect the drive whenever I need to work with Xcode? Yes. Absolutely. Are there known issues with performance, stability, or updates? Nope. Apps can run from any visible location. Are there components that must remain on the internal disk to avoid unexpected behavior? Nope. Xcode is self-contained. Is this a reasonable long-term setup, or just a temporary workaround? Neither. It can't possibly work. The Xcode app itself is quite small. Moving it will do absolutely nothing to solve any storage problems. The problem with Xcode is the "Developer" folder. On my computer that's 34 GB for "Developer" in my home folder. There's another one in "Library" that's 80 GB. And in the System "Library" folder, there's an iOS Runtime folder for another 211 GB. And this isn't even my primary development machine. This is my backup and test rig. You need a minimum 1 TB boot drive for Xcode. Sorry.

My Mac app, an application launcher, has been rejected under Guideline 5.2.5 for being "too similar to LaunchPad, which creates a misleading association with Apple." After requesting specific feedback on what needs to change, I received only a generic response directing me to read the guidelines without any actionable details about which features or design elements are problematic. App Review has seen your screenshots and actually run your app. How would we be better able to judge it than those people who've actually run it? I've observed several other app launchers on the Mac App Store that appear to share more similarities with LaunchPad than mine does (e.g., identical pagination, similar grid layouts, similar visual design). I know! I just bought a new one recently published by the developers of one of my other favourite apps. Has anyone else faced this type of rejection for app launchers or similar utility apps? While I haven't personally experienced this, I've seen many, many posts virtually identical to yours from almost the first day these forums opened. What specific changes did you make that satisfied App Review? In the past, I've found App Review to be a good final check from a fresh set of eyes. People often complain that App Review doesn't understand how their app works. But I think that's what makes App Review valuable. They act much more like end users than the person who developed the app itself. If App Review is confused, then end users would likely be confused too. Are there particular visual elements or features that App Review considers "off limits" for this category? No one here in the forums knows the internal guidelines of App Review. Should I consider filing a formal appeal, or is there a better path forward? I think there's a better path forward. Since Tahoe, the market's flooded with LaunchPad clones. And that's the Mac market, which was minuscule and unprofitable in the first place. Just release your app for free on your own web site. Take what you learned from building it and make something new and unique. Are there any Apple engineers who might be able to provide insight into how to differentiate from built-in macOS apps while still solving the same user problem? Are there? Certainly such people exist. But they don't answer questions in these forums. The few Apple engineers who participate in these forums only answer technical questions. When the topic is App Review, they always qualify their answers that they don't work for App Review and restrict themselves to technical issues. I'm not trying to clone LaunchPad Oh, come on! Some people saw the writing on the wall and started developing their LaunchPad clones in June. Now you're finally ready to release but some manager in App Review has decided that they have enough LaunchPad clones now. It's a pretty brutal industry, eh? That's why I recommended you publish your app for free on your own website. If you attempt to charge money outside of the App Store, you'll get a really good lesson in how brutal the industry is. App Store developers are totally coddled by Apple. Don't throw good time and money after bad. Sometimes the best return on investment is a valuable lesson for next time.

What is everyone using to create awesome "Previews and Screenshots" images for your app? The app itself? I tried Gemini AI and the art was great, but it's so stupid it just ignores the dimensions I tell it to use. That's the point of screenshots. In addition to being the exact dimensions required, they are also an accurate representation of the displays of your app. I don't see how AI would qualify for this.

So this is the actual purpose of my app. But the access you are attempting to obtain would also give you unrestricted ability to read and modify bookmarks, browsing history, image caches, cookies, extension data, etc. That's very valuable information. And having that access would, in turn, make your app valuable. Even if you only checked for invalid links, you could sell your app, and its Full Disk Access, to some other, less-scrupulous company. do you still think this would be considered too risky or difficult to get approved? I'm sorry, but wasn't clear enough before. I don't work for Apple or for App Review. My opinions have no part in their review. I've already described Full Disk Access as "a suspicious Big Red Flag" and "a horrible user experience". You asked for advice and experiences. I've provided both.

Full Disk Access is a user privacy setting. App Review can't give that to your app. Only your users can give your app Full Disk Access. Furthermore, Mac App Store apps are sandboxed. That's a separate layer of privacy protection. You have to ask the user to give your app access to a given folder (or root) and then the user would also have to give your app Full Disk Access. Technically, it is possible. A few years ago, I had an app that did all that in the Mac App Store. I don't remember the relevant App Review communications at the time, but I remember thinking that I was not allowed to ask for Full Disk Access or direct users to it. I had an option in app settings to provide it, but users had to find that on their own. I could give them instructions on the web site, but not inside the app itself. I can't say what App Review's current policies are. All I can do is relate my own experience. I would also suggest that you're entering into a dangerous area. What kind of data from third party web browsers are you looking for? That's a suspicious Big Red Flag. Merely asking for such access can trigger a closer look at your app. You might ask, "What's the worst that App Review can do? Reject my request?" No. The worst that App Review can do is kick your app out of the store and you out of the developer program. Apple has over 51 million developers. They don't lose any sleep over terminating 100-400k developers per year. And the #1 category for app removals is "utility". You're talking about a Mac app. How much money are you really going to make from it? Even if you succeed, it's a horrible user experience.