Don't use the comments. They hide your replies. I didn't test your app. It's SwiftUI. I had looked at this recently and wanted to see if there was different behaviour in AppKit. I did not test it incorrectly. I wrote a menubar app with LSUIElement set. It behaves as you describe. But if I temporarily set the activation policy to be regular, before displaying the window, then the window appears normally. When closing the window, I could set the activation policy back to accessory. That would definitively fix the problem, at the cost of having the app temporarily appear in the dock.

Another vote for darkpaw's suggestion. I recognize that it's very fashionable in certain internet circles to trash App Review. But they may be the closest thing to real-world users that many individual developers ever encounter. Get rid of the select buttons. Get rid of the send button. Get rid of the message field. When the user taps a question, show the message field. When the user starts typing, show the send button.

Maybe use the sshfs MacFuse FS, as the example, porting it to FSkit, and then document the process and what needed to be done. It looks like Apple finally added a little bit extra to FSKit in macOS 26. They now support URL resources. Before, FSKit was restricted to system devices. I've got some older apps I could re-deploy using FSKit now. I wouldn't touch anything FUSE related, and especially sshfs, due to GPL licensing issues.

I just tried this in an AppKit app and it works using just "activate()" after I change the activation policy to ".regular". The icon does appear in the dock while the activation policy is regular. But it's interesting behaviour. It doesn't really seem to be "activation policy" anymore but app state. If I use a 5 second delay and set it back to accessory, the window jumps to the background. But if you're OK with having a dock icon while the window is displayed, you can do that.

There appears to be a set of sign writing modifiers in Unicode to display rotated text. But I can't get it to work. I think it requires a custom font. And I'm no expert with Unicode combining character/modifier sequences. The only really practical option would be attributed text with attachments.

I'd genuinely appreciate clarification on how App Review distinguishes a points-based football competition from gambling under the current guidelines. You can certainly appeal the rejection, or request a Meet with Apple App Review appointment. App Review has already tried to clarify this. I've tried too. You've rejected both attempts at clarification. However, App Review does have the final word.

I'm simply trying to determine whether this is an isolated review decision What if it is? whether other developers of football prediction or fantasy league apps have recently received similar feedback. What if they have, or haven't? These are not rhetorical questions. Please explain what you plan to do about it, in material terms. App Review specifically asked us to answer "Yes" for "Gambling", not "Simulated Gambling". That's part of my confusion. The App Store Connect definition of Gambling refers to betting or wagering using real money (or currency exchangeable for real money), while our app has no betting, wagers, entry fees, cash prizes, payouts, odds, or exchangeable virtual currency. In your original post: App Review says that because the app includes "tips, tools, predictions or other information related to real money gambling" Perhaps random people on the internet aren't that reliable. In hindsight, I think my assessment was wrong. Instead, perhaps "Simulated gambling" would be restricted to a virtual casino or virtual card game environment. In that kind of app, there is no virtual outcome that would have any relation to any actual, real money gambling scenario. Such a simulated gambling app might help people learn individual card games, or make a realization that Orlando might be a better vacation choice than Vegas. But the app would be useless if the user were actually gambling in Vegas. Your app is actually modelling a real-world, real-money gambling scenario. It could help people make predictions in current, real-life gaming events. Ergo, it's a gambling app.

What confuses me is that the App Store Connect age rating describes Gambling as betting or wagering using real money or in-game currency that can be exchanged for real money, which does not apply to our app. And it also has a category for "Simulated Gambling" which precisely describes the core functionality of your app. Has anyone else recently experienced this with a football pool, fantasy league or sports prediction app? How would that be useful? I've never understood the point of a comparison to some other app from some other developer. Do they think that App Review is going to come back with, "Doh! You got us on that one! App approved!" Wouldn't it be just as easy for App Review to say, "OK. Fair enough. App rejected under 4.3 (b)." This clause also includes: "Repeated submissions of this kind may lead to removal from the Apple Developer Program." Kinda seems like the 18+ age limit is the better deal there.

I am being told by developer support that betas are phased rollouts and not every developer gets access to the betas at the same time. Totally not true. As I said, it's just buggy. And the bugs are in the current version, which isn't being updated anymore. Rebooted, signed in and out etc. You may need to try that multiple times. I've done literally everything You can always download a restore image from the developer site and use Apple Configurator. Granted, it's not as easy as an over-the-air update, and you'll lose all your existing data, but it will have the beta afterwards.

Where are you looking? The beta auto-update feature in the OS itself is buggy. If that's where you're looking, try restarting. And try turning betas on and off and then restarting. If all else fails, you can download the restore images on the developer site.

I recommend you just create the project in Xcode itself and stop using CMake altogether. I have a similar project I've been working on for a while. Getting rid of 3rd party build tools solves so many problems. One trick that I used was to try Xcode cloud. Your project has to be absolutely perfect for Xcode cloud to work. So once I could get the build running there, I could run it anywhere. And then I stopped using Xcode cloud because it's so, so slow.

Are you sure you really need a paid app? Realistically, you probably aren't going to make much money on your first app. The costs will almost certainly be more than any profits. in App Store Connect, whose SSN should be entered — my mom's or mine? Or would it make more sense to obtain a free EIN (Employer Identification Number) from the IRS to use instead of either personal SSN? If this is your mother's account, then all of the information would have to be hers. Furthermore, you should consider how much of this information is going to be posted on the internet. If you want to distribute any paid apps in the EU, then you will have to be setup as a "trader" according to EU law. I'm pretty sure that means your mom's name, home address, phone number, and e-mail address will all be publicly visible in the EU. Don't do that. a minor developer with a parent's account? Just to clarify something here. Your mom will be the developer, with special authorization allowing you to share her developer account. How did you handle the tax reporting correctly? That depends on the tax laws where you live. I strongly recommend talking to an accountant just to get an idea of how this will impact tax requirements. I have already spoken with a SCORE tax mentor who confirmed my mom will not be taxed I guarantee that's wrong. All income is taxable pretty much everywhere in the world. There are certain special tax allowances for people running home businesses like this. But those allowances are strictly to reduce your compliance responsibilities to less-than-normal for a business. Tax always has to be paid. Plus, there's more to worry about than just the tax. There's the compliance. You (your mom, actually) will have to fill out the correct tax forms. Depending on your family's situations, that could be cheap and easy, or exceptionally difficult, stressful, and cost thousands of dollars. It depends on your family. That's what an accountant can help you with. Or, you can bypass all of that and stick to free apps for two years until you turn 18.

Can i revert to the previous version? Why not? The only thing you really have to be concerned about is Apple's requirements for submission to the App Store. As of April 28, 2026, you must use Xcode 26 to submit apps. It seems likely that there will be a similar updated requirement next year. If you're stressed for time, then don't install beta software. You'll still have six months or so to get used to the new versions when everything gets released. Hopefully they will be working better by then. Also, there is a beta version of Reality Composer Pro available too. There is a case to be made for getting familiar with the betas and submitting bug reports if you encounter serious problems. Ideally, you can continue development with stable versions on production device while also testing beta versions on test devices. In this case, that may mean a dedicated Mac and dedicated test devices.

If anyone from the App Review team sees this Contrary to what you might think by reading 90% of the posts in this forum, App Review does not participate. There are only a handful of Apple engineers who ever post replies, and they only do that for strictly technical questions. But Apple always has App Review appointments available on the event schedule.

I won't expose the exact binary I am talking about, but would you say ffmpeg is something people write themselves? Sorry. I've been on the internet too long. If you ask for advice, I'm going to give you guaranteed, risk-free, correct advice. I don't want your lawyers showing up at my house with a lawsuit. I'm not making a joke here. There are people who will do this. I've already been targeted. If you want to take a risk and import some multi-million line project made by thousands of anonymous people, that's on you. Apple includes a substantial number of media APIs in its system SDKs. Use those instead of ffmpeg and there's nothing to worry about. As an added bonus, instead of notarizing, you can distribute on the App Store. And since Apple SDKs are cross-platform, you can target iOS too. That's my official advice. So we can use ffmpeg as an example. How do I defend against embedding ffmpeg in my installer, getting supply chain attacked, and afterwards signing and notarizing some malware under my name? ffmpeg isn't a great example. It's grey market, certainly. It's big enough to be ubiquitous, which makes it high risk. Obviously crypto or AI would be even higher risk. But it's still high risk. You can't defend against it because you can't review all the code. All you can do is assume the risk and hope nothing bad happens. There are ways to increase your risk. As I said earlier, you can follow industry-standard practices and keep your dependencies updated. That will ensure you always incorporate the newest, highest-risk code. Of course, that puts your code at higher risk for security exploits on the other end. The older your dependencies, the more likely any malicious code would have already been discovered. The risk is never zero because "sleeper cell" malware is always possible. It isn't commonly used because leveraging those high-risk, industry-standard practices is so much easier and efficient. I can't say anything that I didn't say before. It's a risk/value trade-off. But when I say value, I mean that in a material way. What are you going to gain from this project - financially? What's the point of even doing the math on the risk/value tradeoff when one of the variables is zero?