Overview

If we use webView.loadFileURL(indexURL, allowingReadAccessTo: readAccessURL) on an iPad it loads the data and navigation works. But if we place two hands on top of the screen and move a bit, all click events are not working anymore. It works again if we call loadFileURL again. We filled a bug report: FB19812304

Through IOS 26 public beta 5, the “use as ringtone” option will freeze the Music app, which must be closed and restarted. Is this capability supposed to apply to songs in Apple Music or only for MP3 WMA music files in the files app? If it is only applicable to music files and not Apple Music, then it should not appear as an option in the share menu of an apple song. I have a 15 pro.

Hello App Review Team, We kindly seek your assistance regarding our app, which has remained in the “Waiting for Review” status since our initial submission on July 30. In order to refresh the process, we have submitted several new builds. We also reached out via email and submitted an expedited review request, but unfortunately, there has still been no progress. It has now been close to a month, and this extended delay is starting to impact our app’s revenue. We would greatly appreciate it if you could let us know whether there are any issues with our submission, or if additional materials are required from our side to help move the review forward. Our Appid: 6630392320 Thank you very much for your time and support.

In iOS 18 betas, the App Store search bar has been moved to the bottom of the screen. This breaks years of usability and is inconsistent with Apple’s own apps—Calendar, Reminders, Maps, Safari, Files, Wallet, and Shortcuts—all of which keep search at the top. I (and many others) hold the phone in one hand and tap with the other. Top placement is faster, more natural, and aligns with established Apple design. The “thumb reach” argument does not fit real-world usage for a large portion of users. What I want is consistency across all Apple apps: put the search bar at the top everywhere. Apple already made this mistake with Safari’s bottom address bar in iOS 15 and had to add a toggle after backlash. Please don’t repeat history. Feedback ID: FB19598638 If you agree, please follow your own feedback and reference this thread. The more reports Apple sees, the more likely this gets fixed.

Can someone please tell me which experimental WebKit feature would cause safari to keep timing out on certain sites with a lot of Java script due to heavy cpu drainage. I can provide analytics data if this helps.

What is the correct way to track the number of items in a relationship using SwiftData and SwiftUI? Imagine a macOS application with a sidebar that lists Folders and Tags. An Item can belong to a Folder and have many Tags. In the sidebar, I want to show the name of the Folder or Tag along with the number of Items in it. I feel like I'm missing something obvious within SwiftData to wire this up such that my SwiftUI views correctly updated whenever the underlying modelContext is updated. // The basic schema @Model final class Item { var name = "Untitled Item" var folder: Folder? = nil var tags: [Tag] = [] } @Model final class Folder { var name = "Untitled Folder" var items: [Item] = [] } @Model final class Tag { var name = "Untitled Tag" var items: [Item] = [] } // A SwiftUI view to show a Folder. struct FolderRowView: View { let folder: Folder // Should I use an @Query here?? // @Query var items: [Item] var body: some View { HStack { Text(folder.name) Spacer() Text(folder.items.count.formatted()) } } } The above code works, once, but if I then add a new Item to that Folder, then this SwiftUI view does not update. I can make it work if I use an @Query with an #Predicate but even then I'm not quite sure how the #Predicate is supposed to be written. (And it seems excessive to have an @Query on every single row, given how many there could be.) struct FolderView: View { @Query private var items: [Item] private var folder: Folder init(folder: Folder) { self.folder = folder // I've read online that this needs to be captured outside the Predicate? let identifier = folder.persistentModelID _items = Query(filter: #Predicate { link in // Is this syntax correct? The results seem inconsistent in my app... if let folder = link.folder { return folder.persistentModelID == identifier } else { return false } }) } var body: some View { HStack { Text(folder.name) Spacer() // This mostly works. Text(links.count.formatted()) } } } As I try to integrate SwiftData and SwiftUI into a traditional macOS app with a sidebar, content view and inspector I'm finding it challenging to understand how to wire everything up. In this particular example, tracking the count, is there a "correct" way to handle this?

Hi all — I’m building a Wallet-style transaction details view using FinanceKit and I’m running into a gap around merchant location. What I’m seeing FinanceKit gives me great core fields (amount, currency, status, dates, MCC, merchantName, transactionDescription), but I’m not seeing any address or place/location metadata on a Transaction. For example, a small/local merchant where I can plausibly infer a single place: Fetched transaction: Transaction( id: 8D142B16-3E0E-40B8-945A-2E7C0CF65F1D, accountID: 14939CF4-DBC3-4A9D-8292-5FEA495B8461, transactionAmount: 47.24 USD, creditDebitIndicator: .debit, transactionDescription: "Local Dental Care", originalTransactionDescription: "Local Dental Care", merchantCategoryCode: 8021, merchantName: "Local Dental Care", transactionType: .pointOfSale, status: .booked, transactionDate: 2025-08-20 22:27:50 +0000, postedDate: 2025-08-21 11:22:06 +0000 ) Because this appears to be a single-location practice, I can usually resolve it to a place using MapKit search heuristics. But for big-box chains, I don’t get enough signal to determine which store: Fetched transaction: Transaction( id: 3F8E9F74-7565-4D24-9038-8FD709184799, accountID: 14939CF4-DBC3-4A9D-8292-5FEA495B8461, transactionAmount: 441.77 USD, creditDebitIndicator: .debit, transactionDescription: "The Home Depot", originalTransactionDescription: "The Home Depot", merchantCategoryCode: 5200, merchantName: "The Home Depot", transactionType: .pointOfSale, status: .booked, transactionDate: 2023-12-27 23:07:02 +0000, postedDate: 2023-12-29 03:09:41 +0000 ) There’s no store number, address, phone, or any stable identifier. With hundreds of locations, I can’t deterministically choose a map pin or fetch the right brand assets. What I’m trying to achieve I’d like to replicate the Apple Wallet experience: show a small map snapshot and merchant visuals (logo/name that match Apple Maps / the Place Card) on the transaction detail screen. Without a location hint, I have to either: Ask users to pick a store manually, or Make a guess based on a coarse, app-defined region …neither of which feels great. Questions Is there any way in FinanceKit today to access merchant location or a resolvable identifier (e.g., address, city/state, store number, Apple Maps place identifier, network merchant ID/MID, terminal ID, etc.)? If not, can FinanceKit expose additional merchant metadata (even opt-in / privacy-preserving) to enable Wallet-like enrichment? A few examples that would unblock this: merchantAddress (or components: street/city/region/postalCode/country) merchantPhone (often unique per store) merchantIdentifier (stable per physical location, e.g., network merchant ID / store number) mapsPlaceURL or mapsPlaceIdentifier (linkage to the Apple Maps Place Card) brandAssetURL (logo/brand reference similar to what Wallet shows) With even one of the above, I could reliably: Render an accurate map snapshot, Fetch the correct brand assets, and Avoid prompting the user or inferring via fuzzy search. Context / constraints I do not want to (and shouldn’t need to) request or monitor the user’s device location to resolve a merchant’s store location. For small merchants, MapKit text search is often enough. For large chains, I need a store-level identifier. If there’s an existing field or recommended approach I’m missing, I’d love pointers. If not, please consider this a feature request for richer merchant metadata in FinanceKit so developers can build Wallet-quality transaction details. Thanks!

Hi! How can I create a toolbar animation in SwiftUI like the one shown at 16:54 in WWDC session?

Hi, is it me or latest beta has pronlem with brightness? i have iPhone 16 pro, and now i must keep disabled auto brightness , at keep slider more or less at maximum, in order to clearly see the screen. fabrizio

When an Advanced Experience is created for an App Clip, using the Camera app to scan a QR Code whose URL matches the pattern configured in the Advanced Experience will present the App Clip card. Currently, this App Clip card is presented even if the App Clip or main app is already installed In the device. Is it possible to show the card only when neither the App Clip nor main app is installed? For example: User who does not have the App Clip/main app installed on their device scans a QR code that matches an Advanced Experience User taps the yellow button and sees the App Clip card User taps ”Open” on the card and launches the App Clip, the App Clip is now installed in the device. User returns to the Camera app and scans the same QR code again Camera recognizes the QR code, yellow button appears, user taps it At this point, is it possible for the user to be taken directly to the installed App Clip instead of presenting the App Clip card again?

Hi, For an app that is device dependent (communication through bluetooth and network) for proprietary device in specialized applications, is allowed the use of license key on app store without in app purchases? The app is useless for users without the hardware Thanks

When performing custom layout in AppKit, it's essential that you pixel align frames using methods like backingAlignedRect. The alignment differs depending on the backingScaleFactor of the parent window. When building custom Layouts in SwiftUI, how should you compute the alignment of a subview.frame in placeSubviews() before calling subview.place(...)? Surprisingly, I haven't seen any mention of this in the WWDC videos. However, if I create a Rectangle of width 1px and then position it on fractional coordinates, I get a blurry view, as I would expect. Rounding to whole numbers works, but on Retina screens you should be able to round to 0.5 as well. func placeSubviews( in bounds: CGRect, proposal: ProposedViewSize, subviews: Subviews, cache: inout Void ) { // This should be backing aligned based on the parent window's backing scale factor. var frame = CGRect( x: 10.3, y: 10.8, width: 300.6, height: 300.1 ) subview.place( at: frame.origin, anchor: .topLeading, proposal: ProposedViewSize(frame.size) ) }

Take this piece of code for example: Menu { ... } label: { Image(systemName: "ellipsis.circle") .resizable() .foregroundStyle(Color.primary) .frame(width: 24, height: 24) .contentShape(.circle) .padding(.spacing8) .glassEffect(.regular.interactive(), in: .circle) } .tint(nil) When tapped, the interactive liquid glass effect expands in response, but the expanded glass is then clipped by the original bounds of the view. In this example, the button would briefly show up as a highlighted square due to the clipping. If I add enough padding around the Menu's label, the expanded glass effect is be able to show unclipped, but this feels like a hack. Is this a bug in the framework, or am I doing something wrong? I have submitted FB19801519 with screen recording and demo project.

I often get questions about third-party crash reporting. These usually show up in one of two contexts: Folks are trying to implement their own crash reporter. Folks have implemented their own crash reporter and are trying to debug a problem based on the report it generated. This is a complex issue and this post is my attempt to untangle some of that complexity. If you have a follow-up question about anything I've raised here, please put it in a new thread with the Debugging tag. IMPORTANT All of the following is my own direct experience. None of it should be considered official DTS policy. If you have a specific question that needs a direct answer — perhaps you’re trying to convince your boss that implementing your own crash reporter is a very bad idea — start a dedicated thread here on the forums and we can discuss the details there. Use whatever subtopic is appropriate for your issue, but make sure to add the Debugging tag so that I see it go by. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Scope First, I can only speak to the technical side of this issue. There are other aspects that are beyond my remit: I don’t work for App Review, and only they can give definitive answers about what will or won’t be allowed on the store. Implementing your own crash reporter has significant privacy implications. IMPORTANT If you implement your own crash reporter, discuss the privacy impact with a lawyer. This post assumes that you are implementing your own crash reporter. A lot of folks use a crash reporter from another third party. From my perspective these are the same thing. If you use a custom crash reporter, you are responsible for its behaviour, both good and bad, regardless of where the actual code came from. Note If you use a crash reporter from another third party, run the tests outlined in Preserve the Apple Crash Report to verify that it’s working well. General Advice I strongly advise against implementing your own crash reporter. It’s very easy to create a basic crash reporter that works well enough to debug simple problems. It’s impossible to implement a good crash reporter, one that’s reliable, binary compatible, and sufficient to debug complex problems. The bulk of this post is a low-level explanation of that impossibility. Rather than attempting the impossible, I recommend that you lean in to Apple’s crash reporter. In recent years it’s acquired some really cool new features: If you’re creating an App Store app, the Xcode organiser gives you easy, interactive access to Apple crash reports. If you’re an enterprise developer, consider switching to Custom App Distribution. This yields all the benefits of App Store distribution without your app being generally available on the store. iOS 14 and macOS 12 report crashes in MetricKit. This is a very cool feature, and I’m surprised by how few people use it effectively. If you previously dismissed Apple crash reports as insufficient, I encourage you to reconsider that decision. Why Is This Impossible? Earlier I said “It’s impossible to implement a good crash reporter”, and I want to explain why I’m confident enough in my conclusions to use that specific word. There are two fundamental problems here: On iOS (and the other iOS-based platforms, watchOS and tvOS) your crash reporter must run inside the crashed process. That means it can never be 100% reliable. If the process is crashing then, by definition, it’s in an undefined state. Attempting to do real work in that state is just asking for problems [1]. To get good results your crash reporter must be intimately tied to system implementation details. These can change from release to release, which invalidates the assumptions made by your crash reporter. This isn’t a problem for the Apple crash reporter because it ships with the system. However, a crash reporter that’s built in to your product is always going to be brittle. I’m speaking from hard-won experience here. I worked for DTS during the PowerPC-to-Intel transition, and saw a lot of folks with custom crash reporters struggle through that process. Still, this post exists because lots of folks ignore this reality, so the subsequent sections contain advice about specific technical issues. WARNING Do not interpret any of the following as encouragement to implement your own crash reporter. I strongly advise against that. However, if you ignore my advice then you should at least try to minimise the risk, which is what the rest of this document is about. [1] On macOS it’s possible for your crash reporter to run out of process, just like the Apple crash reporter. However, possible is not the same as easy. In fact, running out of process can make things worse: It prevents you from geting critical state for the crashed process without being tightly bound to OS implementation details. It would be nice if Apple provided APIs for this sort of thing, but that’s currently not the case. Preserve the Apple Crash Report You must ensure that your crash reporter doesn’t disrupt the Apple crash reporter. This is important for three reasons: Some fraction of your crashes will not be caused by your code but by problems in framework code, and accurate Apple crash reports are critical in diagnosing such issues. When dealing with really hard-to-debug problems, you need the more obscure info that’s shown in the Apple crash report. If you’re working with someone from Apple (here on the forums, via a bug report, or a DTS case, or whatever), they’re going to want an accurate Apple crash report. If your crash reporter is disrupting the Apple crash reporter — either preventing it from generating crash reports entirely [1], or distorting those crash reports — that limits how much they can help you. IMPORTANT This is not a theoretical concern. The forums have many threads where I’ve been unable to help folks debug a gnarly problem because their third-party crash reporter didn’t preserve the Apple crash report (see here, here, and here for some examples). To avoid these issues I recommend that you test your crash reporter’s impact on the Apple crash reporter. The basic idea is: Create a program that generates a set of specific crashes. Run through each crash. Verify that your crash reporter produces sensible results. Verify that the Apple crash reporter produces the same results as it does without your crash reporter With regards step 1, your test suite should include: An un-handled language exception thrown by your code An un-handled language exception thrown by the OS (accessing an NSArray out of bounds is an easy way to get this) Various machine exceptions (at a minimum, memory access, illegal instruction, and breakpoint exceptions) Stack overflow Make sure to test all of these cases on both the main thread and a secondary thread. With regards step 4, check that the resulting Apple crash report includes correct values for: The exception info The crashed thread That thread’s state Any application-specific info, and especially the last exception backtrace [1] A particularly pathological behaviour here is to end your crash reporter by calling exit. This completely suppresses the Apple crash report. Some third-party language runtimes ‘helpfully’ include such a crash reporter, which makes it very hard to debug problems that occur within your process but outside of that language. Signals Many third-party crash reporters use UNIX signals to catch the crash. This is a shame because using Mach exception handling, the mechanism used by the Apple crash reporter, is generally a better option. However, there are two reasons to favour UNIX signals over Mach exception handling: On iOS-based platforms your crash reporter must run in-process, and doing in-process Mach exception handling is not feasible. Folks are a lot more familiar with UNIX signals. Mach exception handling, and Mach messaging in general, is pretty darned obscure. If you use UNIX signals for your crash reporter, be aware that this API has some gaping pitfalls. First and foremost, your signal handler can only use async signal safe functions [1]. You can find a list of these functions in sigaction man page [2] [3]. WARNING This list does not include malloc. This means that a crash reporter’s signal handler cannot use Objective-C or Swift, as there’s no way to constrain how those language runtimes allocate memory [4]. That means you’re stuck with C or C++, but even there you have to be careful to comply with this constraint. The Operative: It’s worse than you know. Captain Malcolm Reynolds: It usually is. Many crash reports use functions like backtrace (see its man page) to get a backtrace from their signal handler. There’s two problems with this: backtrace is not an async signal safe function. backtrace uses a naïve algorithm that doesn’t deal well with cross signal handler stack frames [5]. The latter point is particularly worrying, because it hides the identity of the stack frame that triggered the signal. If you’re going to backtrace out of a signal, you must use the crashed thread’s state (accessible via the handlers uap parameter) to start your backtrace. Apropos that, if your crash reporter wants to log the state of the crashed thread, that’s the place to get it. Your signal handler must be prepared to be called by multiple threads. A typical crashing signal (like SIGSEGV) is delivered to the thread that triggered the machine exception. While your signal handler is running on that thread, other threads in your process continue to run. One of these threads could crash, causing it to call your signal handler. It’s a good idea to suspend all threads in your process early in your signal handler. However, there’s no way to completely eliminate this window. Note The need to suspend all the other threads in your process is further evidence that sticking to async signal safe functions is required. An unsafe function might depend on a thread you’ve suspended. A typical crashing signal is delivered on the thread that triggered the machine exception. If the machine exception was caused by a stack overflow, the system won’t have enough stack space to call your signal handler. You can tell the system to switch to an alternative stack (see the discussion of SA_ONSTACK in the sigaction man page) but that isn’t a complete solution (because of the thread issue discussed immediately above). Finally, there’s the question of how to exit from your signal handler. You must not call exit. There’s two problems with doing that: exit is not async signal safe. In fact, exit can run arbitrary code via handlers registered with atexit. If you want to exit the process, call _exit. Exiting the process is a bad idea anyway, because it will prevent the Apple crash reporter from running. This is very poor form. For an explanation as to why, see Preserve the Apple Crash Report (above). A better solution is to unregister your signal handler (set it to SIG_DFL) and then return. This will cause the crashed process to continue execution, crash again, and generate a crash report via the Apple crash reporter. [1] While the common signals caught by a crash reporter are not technically async signals (except SIGABRT), you still have to treat them as async signals because they can occur on any thread at any time. [2] It’s reasonable to extend this list to other routines that are implemented as thin shims on a system call. For example, I have no qualms about calling vm_read (see below) from a signal handler. [3] Be aware, however, that even this list has caveats. See my Async Signal Safe Functions vs Dyld Lazy Binding post for details. [4] I expect that it’ll eventually be possible to write signal handlers in Swift, possibly using some facility that evolves from the the existing, but unsupported, @_noAllocation and @_noLocks attributes. If you’d like to get involved with that effort, I recommend that engage with the Swift Evolution process. [5] Cross signal handler stack frames are pushed on to the stack by the kernel when it runs a signal handler on a thread. As there’s no API to learn about the structure of these frames, there’s no way to backtrace across one of these frames in isolation. I’m happy to go into details but it’s really not relevant to this discussion [6]. If you’re interested, start a new thread with the Debugging tag and we can chat there. [6] (Arg, my footnotes have footnotes!) The exception to this is where your trying to generate a crash report for code running in a signal handler. That’s not easy, and frankly you’re better off avoiding signal handlers in general. Where possible, handle signals via a Dispatch event source. Reading Memory A signal handler must be very careful about the memory it touches, because the contents of that memory might have been corrupted by the crash that triggered the signal. My general rule here is that the signal handler can safely access: Its code Its stack (subject to the constraints discussed earlier) Its arguments Immutable global state In the last point, I’m using immutable to mean immutable after startup. It’s reasonable to set up some global state when the process starts, before installing your signal handler, and then rely on it in your signal handler. Changing any global state after the signal handler is installed is dangerous, and if you need to do that you must be careful to ensure that your signal handler sees consistent state, even though a crash might occur halfway through your change. You can’t protect this global state with a mutex because mutexes are not async signal safe (and even if they were you’d deadlock if the mutex was held by the thread that crashed). You should be able to use atomic operations for this, but atomic operations are notoriously hard to use correctly (if I had a dollar for every time I’ve pointed out to a developer they’re using atomic operations incorrectly, I’d be very badly paid (-: but that’s still a lot of developers!). If your signal handler reads other memory, it must take care to avoid crashing while doing that read. There’s no BSD-level API for this [1], so I recommend that you use vm_read. [1] The traditional UNIX approach for doing this is to install a signal handler to catch any memory access exceptions triggered by the read, but now we’re talking signal handling within a signal handler and that’s just silly. Writing Files If your want to write a crash report from your signal handler, you must use low-level UNIX APIs (open, write, close) because only those low-level APIs are documented to be async signal safe. You must also set up the path in advance because the standard APIs for determining where to write the file (NSFileManager, for example) are not async signal safe. Offline Symbolication Do not attempt to do symbolication from your signal handler. Rather, write enough information to your crash report to support offline symbolication. Specifically: The addresses to symbolicate For each Mach-O image in the process: The image’s path The image’s build UUID [1] The image’s load address You can get most of the Mach-O image information using the APIs in <mach-o/dyld.h> [2]. Be aware, however, that these APIs are not async signal safe. You’ll need to get this information in advance and cache it for your signal handler to record. This is complicated by the fact that the list of Mach-O images can change as you process loads and unloads code. This requires you to share mutable state with your signal handler, which is exactly what I recommend against in Reading Memory. Note You can learn about images loading and unloading using _dyld_register_func_for_add_image and _dyld_register_func_for_remove_image respectively. [1] If you’re unfamiliar with that term, see TN3178 Checking for and resolving build UUID problems and the documents it links to. [2] I believe you’ll need to parse the Mach-O load commands to get the build UUID. What to Include When deciding what to include in a crash report, there’s a three-way balance to be struck: The more information you include, the easier it is to diagnose problems. Some information is hard to obtain, either because there’s no public API to get that information, or because the API is not available to your crash reporter. Some information is so privacy-sensitive that it has no place in a crash report. Apple’s crash reporter strikes its own balance here, and I recommend that you try to include everything that it includes, subject to the limitations described in the second point. Here’s what I’d considered to be a minimal list: Information about the machine exception that triggered the crash For memory access exceptions, the address of the access that triggered the crash Backtraces of all the threads (sometimes the backtrace of a non-crashing thread can yield critical information about the crash) The crashed thread Its thread state A list of Mach-O images, as discussed in the Offline Symbolication section IMPORTANT Make sure you report the thread backtraces in a consistent order. Without that it’s hard to correlate information across crash reports. Revision History 2025-08-25 Added some links to examples of third-party crash reports not preserving the Apple crash report. Added a link to TN3178. Made other minor editorial changes. 2022-05-16 Fixed a broken link. 2021-09-10 Expanded the General Advice section to include pointers to Apple crash report resources, including MetricKit. Split the second half of that section out in to a new Why Is This Impossible? section. Made minor editoral changes. 2021-02-27 Fixed the formatting. Made minor editoral changes. 2019-05-13 Added a reference to my Async Signal Safe Functions vs Dyld Lazy Binding post. 2019-02-15 Expanded the introduction to the Preserve the Apple Crash Report section. 2019-02-14 Clarified the complexities of an out-of-process crash reporter. Added the What to Include section. Enhanced the Signals section to cover reentrancy and stack overflow. Made minor editoral changes. 2019-02-13 Made minor editoral changes. Added a new footnote to the Signals section. 2019-02-12 First posted.

Hi, I am a new IOS developer, trying to learn to integrate the Apple Foundation Model. my set up is: Mac M1 Pro MacOS 26 Beta Version 26.0 beta 3 Apple Intelligence &amp; Siri --&gt; On here is the code, func generate() { Task { isGenerating = true output = "⏳ Thinking..." do { let session = LanguageModelSession( instructions: """ Extract time from a message. Example Q: Golfing at 6PM A: 6PM """) let response = try await session.respond(to: "Go to gym at 7PM") output = response.content } catch { output = "❌ Error:, \(error)" print(output) } isGenerating = false } and I get these errors guardrailViolation(FoundationModels.LanguageModelSession.GenerationError.Context(debugDescription: "Prompt may contain sensitive or unsafe content", underlyingErrors: [Asset com.apple.gm.safety_embedding_deny.all not found in Model Catalog])) Can you help me get through this?

Description: Hello, I recently received the following email from Apple: We're writing to inform you that your company isn't in compliance with the Apple Developer Program License Agreement (DPLA). Section 11.2 (Termination) states: (g) if You engage, or encourage others to engage, in any misleading, fraudulent, improper, unlawful or dishonest act relating to this Agreement, including, but not limited to, misrepresenting the nature of Your Application (e.g., hiding or trying to hide functionality from Apple’s review, falsifying consumer reviews for Your Application, engaging in payment fraud, etc.). Be aware that manipulating App Store chart rankings, user reviews or search index may result in the loss of your developer program membership. Please address this issue promptly. I’m trying to understand how other developers handled this warning. Could you please share your experience: Did you identify what triggered the warning? Did you need to remove or change anything in your apps? Did Apple require a formal response or evidence? How did you confirm that the issue was resolved? Any guidance would be greatly appreciated.

As of right now Icon Composer does not support creating app icons for visionOS and tvOS. It appears that only system apps can provide glass icons for those platforms. How should developers handle this? In extreme cases, the flat icon on those platforms will look wildly different from their glass counterparts. From what I have seen visionOS and tvOS also do not apply any automatic treatment like on iOS where legacy icons get a glass effect. So, third party app icons are just going to look out of place for (hopefully just) a year on those platforms? What is the recommended approach here? You could obviously fake the effect, but I feel like that would be worse.

WebAuthn can be used in Safari, but when using it with WKWebView, you need to set the default browser definition (com.apple.developer.web-browser). Is this correct? Also, is it possible that the terms of use will change or that it will no longer be available in WKWebView in the future?

How can we receive the iPadOS 18.6.1 update on an iPad? We have configured the MDM update days policy to receive recent, but not the latest, iPadOS updates; however, we are only able to get versions 18.6.2 and 18.6. Is the availability of iPadOS updates dependent on the iPad's region? Thank you in advance for your assistance.

Hi, this is the first app and time using apple forums and my question. I published an app and it says ready to distribute i have tested the link and installed it on my phone, however on the App Analytics it says "Not Enough Data". Know its been downloaded and installed because i did it but it shows as i said not enough data, is there a delay of a certain time, is there a difference between private and business. How can i find out if there has been a purchase, nothing is displaying as i was expecting.