Issue Description: On iOS 26 and later, a CoreGraphics crash occurs when rendering images using -[UIImage drawInRect:blendMode:alpha:]. Based on the call stack, the crash happens inside CoreGraphics. Under what circumstances does the function upscale_provider_get_bytes_at_position_inner in the stack get called? When attempting to reproduce locally, this code path is never reached even when scaling images. Steps to Reproduce: There are a large number of crash reports in production, but the issue cannot be reproduced locally/offline. Expected Results: Explain under what conditions calling -[UIImage drawInRect:blendMode:alpha:] will reach the upscale_provider_get_bytes_at_position_inner logic. Ideally, provide a code example or demo. Provide the root cause of the crash and a workaround/mitigation. Current Behavior: Calling -[UIImage drawInRect:blendMode:alpha:] causes intermittent crashes in production. Xcode Version Used: Xcode Version 26.0 (17A324)

This is not a minor visual glitch or a negligible beta bug; this is a catastrophic telecom and safety failure. In iOS 27 Developer Beta, attempting to activate Wi-Fi Calling for US carriers (like RedPocket, Mint, T-Mobile, etc.) that require an E911 address registration completely hard-crashes the Settings app. You cannot activate Wi-Fi Calling, you cannot register your emergency address, and your cellular service is effectively crippled. As an SRE, I pulled the Console logs and traced the crash. It is absolutely unacceptable that Apple is still relying on the ancient, long-deprecated ⁠UIWebBrowserView⁠ inside ⁠TPSCloudCallingWebViewController⁠ for a critical emergency service configuration page. The Settings app is dying from a dual-concurrency crash caused by aggressive iOS 27 refactoring colliding with this legacy web container: The Apple Intelligence / TextInputUI Collision: On page load, the new text prediction engine blindly scans the legacy web input fields and throws a fatal exception: ⁠-[UIThreadSafeNode _smartReplyUpdateInProgress]: unrecognized selector sent to instance⁠. The old web node simply doesn't support the new Smart Reply APIs. The WebKit Thread Violation: This input system failure (⁠RTIInputSystemClient⁠ invalidation) cascades into a complete WebKit thread deadlock. The engine attempts to parse the carrier's CSS and throws a fatal UIKit assertion: ⁠Modifying properties of a view's layer off the main thread is not allowed⁠. The OS instantly sends a ⁠SIGABRT⁠ to ⁠com.apple.Preferences⁠. I have tried every possible workaround: Disabling JavaScript, removing 3rd-party/foreign keyboards, turning off predictive text, and even using MITM proxies to strip the CSS from the carrier's gateway. Nothing works. The crash happens instantly on load because the TextInputUI injection and the background-thread layer mutation are hardcoded into the OS framework. It is utterly absurd that a broken Smart Reply UI prediction path can block a user from registering an emergency 911 address and activating their phone service. Apple, you need to fix this immediately. Either rewrite ⁠TPSCloudCallingWebViewController⁠ to use a modern ⁠WKWebView⁠, or patch ⁠TextInputUI⁠ to gracefully handle legacy ⁠UIThreadSafeNode⁠ instances. Do not ship another beta with a broken carrier service page.

I don’t even see the waitlist of the Apple Intelligence program, i think it’s lacking instruction’s how to apply, when it comes out etc.

There seems to be a lack of clarity about how this Siri AI rollout is working. Does the indexing have anything to do with getting taken off the waitlist, or are they completely separate? Also, what is the expected wait time and has anyone gotten the new Siri after the initial wave of approvals (after 4 hours after the keynote)? The waitlist is extremely slow compared to the initial Apple Intelligence waitlist from a couple of years ago.

I am experiencing random Wi-Fi and Bluetooth disconnections while using iOS 27. Both Wi-Fi and Bluetooth disconnect unexpectedly, then reconnect automatically a few seconds later. I have seen many similar reports on Reddit, so this does not seem to be an isolated issue. I have already submitted a report through Feedback Assistant with the feedback ID FB23121586. I hope this issue can be fixed soon, because it is really stressful when playing online games on my iPhone and worrying that the connection might suddenly drop. :(

In 2018, Apple staff noted that Safari App Extensions had no direct API to communicate with the containing app, and suggested app groups or opening a custom URL scheme as workarounds. On iOS Safari Web Extensions, app groups work for persistence, but opening the containing app from the native extension/background flow does not appear reliable. iOS launch policy seems to require a direct user gesture, and I have not found a documented way for the extension flow to reliably continue into the containing app. Is there a supported iOS architecture for completing an extension-initiated workflow in the containing app, or is the intended model to persist data and require the user to manually open the app? My current architecture is: JavaScript in the Safari Web Extension extracts article content from the page. The native Extension Handler receives that content via native messaging. The Extension Handler writes an encoded request into the App Group container. The containing app watches the App Group container using DispatchSource.makeFileSystemObjectSource and processes new requests. This works on macOS. It also works on iOS when the containing app is already running. The problem is that on iOS, if the containing app is not already running, there is no app process to observe the filesystem event or process the request. I have tried treating the Extension Handler as the place to do more work, but in practice it seems suited only for short-lived relay/persistence work. It is not a reliable place for my app’s main processing pipeline, which includes rendering article content and uploading it to a third-party service. My app is a Safari-native “read later” style tool that uploads simplified articles to the reMarkable Cloud. The containing app contains most of the functionality: SwiftUI UI, WebKit/WebPage rendering, account/cloud logic, and upload orchestration. The Safari extension captures the article, but the app needs to run to complete the user-visible workflow. From a user’s perspective, tapping the Safari extension toolbar button is the action that initiates the workflow. Is there any supported way for that user-initiated extension action to launch or wake the containing iOS app so it can process pending App Group requests? Or should Safari Web Extensions on iOS be designed only to persist work and then ask the user to manually open the containing app? If manual app launch is the intended model, it would be helpful for the documentation to state this explicitly. The current tripartite model strongly suggests that the JavaScript extension, native handler, and containing app can collaborate as parts of one workflow, but on iOS the containing app appears to be available only out-of-band unless already running.

Device: iPhone 17 Pro iOS Version: iOS 27 beta Problem Description I am experiencing the following issues on iOS 27 Beta: Bluetooth randomly turns off and on automatically • Bluetooth occasionally turns off by itself for a few seconds and then turns back on. • The issue is especially severe when connected to AirPods Pro 2 (latest beta firmware), but it also occurs even without AirPods connected. • It usually only starts happening frequently after the iPhone has been powered on for a long time. Restarting the device temporarily resolves it. 2. Network Connection Issues • Network frequently experiences lag and slow speeds. • The problem becomes particularly noticeable when cellular data is throttled to 1 Mbps. • Even when multiple strong Wi-Fi signals are available, the device often ignores them and continues using or automatically switches back to cellular data (relatively frequent intermittent issue). 3. Feedback Assistant completely broken • Trying to submit feedback through the Feedback Assistant app delay fails with the following error: 开始反馈时出错 请稍后再试。

How can I get in touch with Apple Engineering since this doesn’t seem to work despite being told it’s the only way? I made this post in the appropriate forum several days ago. No responses. https://developer.apple.com/forums/thread/834948

Hi team, I’m working on an ActivityKit use case where a Live Activity is useful on the Lock Screen, but not in the Dynamic Island. Today, Live Activities appear to be treated as a unified presentation across system surfaces: Lock Screen, Dynamic Island, StandBy, etc. For our app, the Lock Screen presentation is the right user experience, but showing the same activity in the Dynamic Island creates unnecessary persistent foreground UI while the user is actively using the device. Is there any supported way to create a Live Activity that appears on the Lock Screen but opts out of Dynamic Island presentation on supported iPhones? If not, I’d love to request an ActivityKit enhancement that lets developers specify supported presentation destinations for a Live Activity, for example something like: Lock Screen only or Lock Screen + StandBy, but not Dynamic Island This would be useful for apps where the Live Activity is meant to act as a passive lock-screen status/reminder, rather than an ongoing foreground indicator. Thanks!

Body We are currently evaluating an architecture approach for an iOS application and are looking for guidance on App Store Review expectations and platform limitations. Context We are modernizing an existing healthcare application that handles regulated data (PHI). The application is intended for use by internal staff and authorized third-party contractors (not a consumer-facing app, and no monetization). To support iOS distribution, we are evaluating packaging an Angular-based Progressive Web App (PWA) using a lightweight native wrapper (e.g., via PWABuilder), resulting in a WebView-hosted application. Proposed Architecture Angular PWA hosted remotely and loaded via HTTPS Packaged inside a native iOS container (WKWebView-based) Authentication via Passkeys (WebAuthn / FIDO2) Backend APIs implemented in .NET Limited offline functionality using IndexedDB (non-sensitive data only) No persistent storage of sensitive data on-device The native wrapper primarily provides distribution and lifecycle management; most functionality is delivered via the hosted PWA. Key Consideration This application is not intended to function as a general-purpose browser, but rather as a purpose-built, workflow-specific experience for healthcare operations. Questions 1. App Review / Guideline 4.2 Have developers had success getting WebView-hosted applications (primarily PWA-driven) approved when they provide a complete and production-grade user experience? How does Apple typically evaluate whether such an app meets the “minimum functionality” requirement versus being considered a repackaged website? 2. Dynamic Content / Updates Are there specific restrictions on delivering functionality dynamically via server-hosted content after app approval? At what point would backend-driven changes require a new App Store submission? 3. Data Storage & WebView Behavior Are there notable differences in how iOS handles storage (e.g., IndexedDB, local storage) in: Safari-installed PWAs WebView-based apps distributed via the App Store? Are there known limitations or caveats when relying on IndexedDB within WKWebView? 4. Platform Capabilities Are there practical limitations for WebView-based apps related to: Offline functionality File handling Long-term platform support 5. Healthcare / Regulated Data For apps handling regulated healthcare data (PHI), are there additional expectations or best practices (beyond standard guidelines) that Apple reviewers typically look for? Goal We are trying to determine whether this architecture is viable for App Store distribution before proceeding further with implementation. Any insights, experiences, or pointers to relevant documentation would be greatly appreciated.

The appeals process for when your Apple Developer account is in Pending Termination status doesn't work. The re-instate developer account form is very clear it shouldn't be used if it's pending. But the form for "I would like to appeal an app rejection or app removal" which is the correct form for pending state. Gives the error "There are no apps associated with this team." we do have apps associated. There could be thousands of developer accounts that weren't able to file an appeal correctly because of this bug. "If you would like to appeal this termination decis ion to the App Review Board, you must do so within 30 calendar days. When submitting your appeal, be sure to select "I would like to appeal an app rejection or app removal" from the drop-down menu on the Contact the App Review Team page and provide a written statement that includes the following:" Apple is very clear which to use.

Hello, We are currently developing an application that uses the Host-based Card Emulation (HCE) entitlement to enable corporate access functionality. With this entitlement, we have successfully established HCE communication and can interact with our access control systems to unlock doors. Our question is related to improving the user experience: We would like this access functionality to work without requiring the app to be in the foreground, as this adds friction for users during entry. Specifically, we would like to know: Is it possible for our app to coexist with Apple Wallet as the default contactless app, so that: Our app handles NFC interactions for corporate access (e.g., opening doors). Apple Wallet remains the default for payments. If that coexistence is not possible, and our app is set as the default contactless app, Will the system still need to launch our app into the foreground to complete a transaction (e.g., to emulate the NFC card)? Or is there a way to trigger HCE responses in the background (e.g., using a background process or service extension)? Any guidance on how to configure the app for optimal background access behavior, while maintaining compatibility with Wallet, would be greatly appreciated. Thank you in advance.

Hi everyone, I'm trying to delete an App ID from Certificates, Identifiers & Profiles on the Apple Developer portal, but I'm getting the following error: "The App ID 'XXXXXXX' appears to be in use by the App Store, so it can not be removed at this time." Here's my situation: The app was never published to the App Store — it was only created in App Store Connect (no builds were ever submitted for review, and it was never in a "Ready for Sale" state). I have already removed the app from App Store Connect via "Remove App" in App Information. The app is no longer visible in my App Store Connect dashboard. It has been over 48 hours since I removed the app from App Store Connect. Despite this, the Identifiers page still shows the error above when I attempt to delete the corresponding App ID. What I've tried: Confirmed the app no longer appears in App Store Connect (including checking "Removed Apps" filter) Waited over 48 hours for the system to propagate Cleared browser cache and retried My goal: I need to release this Bundle ID so it can be registered under a different Apple Developer account. Questions: Is there an additional waiting period beyond 48 hours before the App ID can be deleted? Is there a way to force-release this App ID, or do I need to contact Apple Developer Support directly? Has anyone experienced this same issue with an app that was never published? Any guidance would be greatly appreciated. Thank you! Environment: Apple Developer Program (Organization account) App was created in App Store Connect but never submitted for review Platform: iOS

version: iOS 17+ When requesting Photo Library access on iOS, the system displays a standard permission dialog. I just wanna save a image to user's photo library. Is it possible to replace or customize this system permission popup with a fully custom-designed UI? If customization is not allowed, is the recommended approach to first present a custom explanatory popup or screen and then trigger the system permission dialog?

I’ve found nothing about the waitlist, like when are there expected openings, how does an opening occur, and do I need to do anything else except join the waitlist? It’s been indexing for the same amount of time that I’ve been waiting for Siri, so is that a factor?

I was really considering this IDEA ONLY ANDROID HAS that Apple doesn’t tell me what you think ? I think the iOS system in the iPhones and iPad should be able to let you change your ((Fronts))because this whole just changing it into bold or the size is kind of boring it gets old so if you can reach back to me that would be nice thanks . phone number 702-559-5550

Hi all :) I tried to raise this in the group lab and was pointed here. I’m seeing a flat per-app memory ceiling of about 6 GB on iPhone, even on devices with more physical RAM and with com.apple.developer.kernel.increased-memory-limit. Measured with os_proc_available_memory() plus task_vm_info.phys_footprint, the total process budget stays around 6144 MB on both: iPhone 16 Pro Max, 8 GB RAM iPhone 17 Pro Max, 12 GB RAM This came up while running Gemma 4 multimodal support in mlx-swift-lm (PR #343). The model loads at about 4.4 GB resident, leaving roughly 1.7 GB for inference/prefill. Reducing a GPU buffer cache from 512 MB to 64 MB recovered enough headroom to avoid jetsam and allowed a full image + video + audio multimodal test to complete, so the measurement seems to reflect a real per-process limit rather than free system memory. I re-measured the ceiling on the 12 GB phone with these capabilities: increased-memory-limit only: ~6144 MB increased-memory-limit + extended-virtual-addressing: ~6144 MB, no change increased-memory-limit + increased-debugging-memory-limit: ~6656 MB I have also observed that 12 GB iPad devices expose more memory to an app than 12 GB iPhone devices but I didn't measure specifically and no longer have the device to hand. Is the ~6 GB per-process tier on Pro iPhones expected, even with increased-memory-limit? Is there any supported way for a shipping app to access more of the available RAM on 12 GB iPhone models? FB23183521

1. System/device combinations where the issue does not occur: Physical device: iOS 26.0 (23A5318c) + iPhone 16 Pro Max 2. System/device combinations where the issue does occur: System versions: Physical device: iOS 26.0 (23A5330a), iOS 26.0 (23A340) Simulator: iOS 26.0 (23A339) Device models: Physical device: iPhone 12 Reproducible in Safari, WKWebView, and UIWebView: Yes Actual behavior In WebView (and identically in Safari): Before the keyboard is shown, header/footer elements with position: fixed are correctly aligned with the screen viewport. Scrolling up/down works as expected. After the keyboard appears, the visualViewport position changes. Bug: When the keyboard is dismissed, visualViewport.offsetTop does not reset to 0. As a result, fixed header/footer elements remain misaligned: When scrolling down, the position looks correct. When scrolling up, the header/footer are visibly offset. Steps to reproduce Focus an input field → the keyboard appears Dismiss the keyboard Observe that visualViewport.offsetTop remains >0 (does not reset to zero) position: fixed header/footer elements are misplaced relative to the screen Expected behavior After the keyboard is dismissed, visualViewport.height should return to match the layout viewport, and visualViewport.offsetTop should reset to 0. When scrolling upward, fixed elements should remain correctly positioned within the layout viewport. Minimal reproducible demo A simple HTML file containing: A header and footer with position: fixed An input element to trigger the keyboard <!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8" /> <meta name="viewport" content="width=device-width, initial-scale=1.0, viewport-fit=cover" /> <title>H5 吸顶吸底页面 Demo</title> <style> * { margin: 0; padding: 0; box-sizing: border-box; } body { font-family: Arial, sans-serif; height: 2000px; /* 设置内容高度 */ background-color: #f0f8ff; /* body 背景浅蓝色 */ padding-top: 120px; /* 预留 header 高度 */ padding-bottom: 60px; /* 预留 footer 高度 */ overflow-x: hidden; } /* 吸顶 Header */ header { position: fixed; top: 0; left: 0; width: 100%; height: 120px; background-color: #ff6b6b; /* 红色 */ display: flex; align-items: center; justify-content: center; color: white; font-size: 24px; font-weight: bold; z-index: 1000; } /* 吸底 Footer */ footer { position: fixed; bottom: 0; left: 0; width: 100%; height: 60px; background-color: #4ecdc4; /* 青绿色 */ display: flex; align-items: center; justify-content: center; color: white; font-size: 18px; font-weight: bold; z-index: 1000; } /* 输入框样式 */ .input-container { margin: 100px auto; width: 80%; max-width: 600px; text-align: center; } input[type='text'] { padding: 12px; font-size: 16px; border: 2px solid #ddd; border-radius: 8px; width: 100%; box-sizing: border-box; } input[type='text']:focus { outline: none; border-color: #4ecdc4; } </style> </head> <body> <!-- 吸顶 Header --> <header>吸顶 Header (120px)</header> <!-- 主体内容 --> <div class="input-container"> <input type="text" placeholder="请输入内容..." /> </div> <!-- 吸底 Footer --> <footer>吸底 Footer (60px)</footer> </body> </html>

vesion: iOS 17+ When requesting Photo Library access on iOS, the system displays a standard permission dialog. And I just wanna save a image to user's photo library. Is it possible to replace or customize this system permission popup with a fully custom-designed UI? If customization is not allowed, is the recommended approach to first present a custom explanatory popup or screen and then trigger the system permission dialog?

Family.app keeps crashing whilst I am using Xcode 27 beta The app is very simple with just a small number of views. That's all I can say really This is the first part of the crash report output. Multiline Translated Report (Full Report Below) Process: Family [3026] Path: /Volumes/VOLUME/*/Family.app/Family Identifier: com.apple.family Version: 1.0 (1) Code Type: ARM-64 (Native) Role: Background Parent Process: launchd_sim [2846] Coalition: com.apple.CoreSimulator.SimDevice.5FAFAC9B-97A4-4FC8-ADF3-4A8C694BF68D [1639] Responsible Process: SimulatorTrampoline [1008] User ID: 501 Date/Time: 2026-06-09 20:14:55.5737 +0100 Launch Time: 2026-06-09 20:14:45.2448 +0100 Hardware Model: Mac16,12 OS Version: macOS 26.5.1 (25F80) Release Type: User BlockQuote