It's a beta?

Don't put anything other than ASCII in your app name, Xcode project, or any other file. If you want localized names for things, use the appropriate Info.plist keys or other localization tools.

I think you misunderstood what I meant by local solution: I mean stuff like annotations, polylines, polygons (which in would be the user's data) are rendered locally on the map view. Most JS-based mapping frameworks can display local data. In most cases, that's the only way to display local data as mapping services typically only serve tiles. There are services like Google Maps and ArcGIS where you could upload local data for display on a map, but that would only be required for other people to see the (no longer) local data. However, I don't know if MapKit JS can support this. Maybe it does, I've never looked into it. MapKit has poor performance and extremely restrictive licensing so I've never really considered it. There must be dozens of these kinds of JS map frameworks to choose from. If using WebKit really does allow you to bypass the network block in QuickLook, that really is a great solution. You might be surprised by how well it works.

Don't use the comments feature in the forums. Your replies can get missed that way. Ironically, this solution would become a security concern for the end-user as their file data would be sent to some random website for display, unlike the local solution where data is overlayed on top of MapKit. There is no local solution. All map data is served from the web. MapKit is also available on the web via MapKit JS. MapKit is free to use in macOS/iOS apps. Yes and no. There is currently no charge for displaying map tiles in a map view. There are usage limits, but those limits aren't documented. Some MapKit APIs, including MapKit JS, do have documented limits. Because the system has limits, there must be accounting. And if there's accounting, the developer has to account for what happens when those limits are reached. I don't actually know that native MapKit tracks usage. It seems like a logical assumption, but you never know. Also, it seems as if MapKit is communicating via some local XPC service. MapKit runs just fine in an app that doesn't have internet capability at all. If this is true, then there's absolutely no reason why QuickLook shouldn't run as the connection is merely a local XPC. But again, that's just speculation on my part. There could be all kinds of system complexities that I don't know about.

Maybe review the recently posted Tips for an efficient app review.

Maybe review the recently posted Tips for an efficient app review.

If the team is understaffed please hire more people to take their load off. I am not sure how much of an initial apps submission can be automated but; this is not a hard problem to solve, you are Apple for crying out loud. It's no secret that Apple has ramped up automation. But I think the most important aspect might be the idea that perhaps Apple actually has solved the problem. I thought it was just me going thru this but seems like a lot of devs are facing this prevalently since June. People keep dumping on App Review saying they aren't reading their submissions. I feel their pain. I've posted relevant information several times in this thread and it's just being ignored. "a lot of devs"? How many devs? Please be specific. How many forum posts are we talking about? dozens? hundreds? thousands? Apple itself has admitted to rejecting millions of apps each year. Developers should be able to do math. Considering the number of people complaining about app rejections, or account terminations, and comparing that with the actual numbers, it looks like Apple is doing an exceptionally good job. If it’s spammers/scammers; increase the membership price, double or triple it $300? Do you really think that would be barrier? For the big-time scammers, fees in the millions of dollars are simply the cost of doing business. $300 isn't even a business lunch.

Will we see the day where reviews are billed, as a way to limit the flow of AI app submissions. I wish they would do something. I don't think just raising the price alone is enough to stop the scammers and AI slop. It's a real mess.

those do not have any issues The App Store ecosystem is too big to make any kind of general assessments like that. Apple processed 9.1 million App Store submissions last year. That's 25,000 every day. 2 million of those were rejected, including 1.2 million new submissions and 800,000 updates. So every day, Apple rejects over 2000 updates alone. And most of that was before the AI slop really got cooking. PS: It looks like I was wrong about the transparency reports. The official report was just delayed and didn't exist when I saw the press release version.

WebKit (WKWebView) is(!) working in Quicklook extensions just fine. But unlike MapKit, WebKit is able to do random and uncontrolled network requests, therefore could be a security issue. Wouldn't that be a solution then? You can display your map data in a web view. the user is already forced to enable each Quicklook extension manually in the settings. There's a notification but I think Quicklook extensions are allowed by default. Users can turn them off if they want. Honestly, what is the point in blocking network access of a Quicklook extension, if the Host-App of this extension still has full network access. Perhaps it isn't a security issue at all. Perhaps the fact that it's a system component is the key issue. MapKit is a data service. Those bytes are billed to your account. But if the system is making the call, then your app gets free map tiles. So, if you use a web view, then you can use your API key and have the data properly accounted for.

May I ask how many new apps you have released in the last month, and what your actual App Review timelines looked like? My last app release was six months ago - to the day. But I'm only working on Mac apps right now, so my experience isn't going to be applicable to most other developers. We are talking about more complex products that involve licensing, registrations, data protection, compliance disclosures, financial partners, and other serious requirements. Every app and every developer is unique. Please also take a look at the rest of this forum. Oh don't worry. I've seen it. We structured our post based not only on our own experience, but also on what many other developers are reporting here every day. This is the internet. People can say anything they want. There is no requirement, or even expectation, of veracity. Apple used to regularly post App Store transparency reports. Seeing the actual numbers might help to put things into perspective. They didn't do that for 2026. Instead they just posted a press release with much of the same information. Can't blame them for that. Nobody ever read the yearly reports anyway. where else should developers discuss this if not here? That's a good point. But just because you make a good point doesn't mean there's any answer. You can post pretty much anything you want here. It's just that this forum is a disaster. You're not going to get any meaningful replies. We're discussing it right now, aren't we? This is as good as it gets. You can go elsewhere on the internet for a more welcoming anti-Apple echo chamber if you want. That might make you feel better, but it isn't going to get your apps reviewed any faster. Also, I should caution about "discussions" on this forum with respect to App Review and developer account issues as it may involve personal and/or unflattering information. In many cases, people simply post Apple messages or e-mails with no context at all. That's frustrating. But on the rare occasions that they do provide some additional information, it always makes App Review look good. I also do not quite understand the defensive position here. The only thing I would be defensive about is an accusation of being defensive. I've had good experiences and bad experiences with Apple. We are not asking Apple to act as our QA department. That was one of your bullet points. We are asking for a review process where submitted information is actually read, answers are considered That'd be nice, eh?

The review waiting time is catastrophic. The rumours are that it's the same inside Apple due to AI slop. It's overwhelmed the review process and Apple has had to turn to AI on the review side. It may take some time for Apple's AI to learn to match AI input to AI review. we provide a clear, structured, and detailed explanation If you find yourself needing to provide that kind of documentation for the reviewers, then it would probably be even worse for end users. The quality of the review process feels extremely poor. We can see what reviewers are doing inside the app, and frankly, even our junior QA testers test products more carefully and more logically. App Review is not a testing service. They're looking for malware, frauds, scams, and people inventing new ways to break laws. We are talking about complex products that involve licensing, registrations, data protection, compliance disclosures, financial partners, and other serious requirements. Are you on the right platform? Apple makes consumer electronics and services. While they do a have a "Pro" trademark they like to slap on products to double the price, that does not fundamentally change the nature of the business or market. It is becoming impossible to plan launches, honor business commitments, coordinate with partners, or run a serious product roadmap when the review process works this way. You can set your own release schedule in App Store Connect. But until you get used to the system, it's best not make any assumptions or expectations. This is a genuine appeal from a team that is trying to do everything correctly, transparently, and professionally, but is being blocked by a review process that feels careless, inconsistent, and extremely inefficient. Apple, what is happening with App Review? An appeal to the gods? This is a developer support forum. It was originally intended for technical programming questions. But it turned out those were few and far between. Instead, it's become a venue for complaining about App Review. And that was before AI slop. Apple does regularly have "meet with Apple" sessions where you can talk to App Review directly.

I did. But thanks for the loop error. This is what they said when I posted to there before I posted to here: "We removed your post “Times New Roman superscript & Unicode font fallback on Tahoe because it contained information about beta software." You probably included something like this, "2022 laptop, M2, Tahoe 26.6.1". They're very picky about anything beta-related in that forum. The system automatically choses the best font to represent a given glyph based on a number of different aspects. This is called the font cascade list. Individual apps can, in theory, modify the cascade list. But you can't as an end user. And to be honest, I can't imagine any 3rd party app providing that level of fine-grained font control. You'll just need to find a font you can use for all content where you need these superscripts.

Am I allowed to integrate them into my website No. is it against the ToS of the Apple Developer Program? It's against the license included with the SF Symbols download.

b. The app is using iOS 27 as the build SDK. No difference I think. You're doing this. You would need to run Xcode 26 to use the iOS 26 SDK. Can't answer that. If you submit today, you should use iOS 26 as Apple won't accept apps built with beta software. If you submit after iOS 27 is released, you can use either. Sometime next year, if Apple follows previous policies, iOS 27 will be required.