I'm trying to understand how the API works to perform a function that can continue running if the user closes the app. For a very simple example, consider a function that increments a number on screen every second, counting from 1 to 100, reaching completion at 100. The user can stay in the app for 100s watching it work to completion, or the user can close the app say after 2s and do other things while watching it work to completion in the Live Activity. To do this when the user taps a Start Counting button, you'd 1 Call BGTaskScheduler.shared.register(forTaskWithIdentifier:using:launchHandler:). Question 1: Do I understand correctly, all of the logic to perform this counting operation would exist entirely in the launchHandler block (noting you could call another function you define passing it the task to be able to update its progress)? I am confused because the documentation states "The system runs the block of code for the launch handler when it launches the app in the background." but the app is already open in the foreground. This made me think this block is not going to be invoked until the user closes the app to inform you it's okay to continue processing in the background, but how would you know where to pick up. I want to confirm my thinking was wrong, that all the logic should be in this block from start to completion of the operation, and it's fine even if the app stays in the foreground the whole time. 2 Then you'd create a BGContinuedProcessingTaskRequest and set request.strategy = .fail for this example because you need it to start immediately per the user's explicit tap on the Start Counting button. 3 Call BGTaskScheduler.shared.submit(request). Question 2: If the submit function throws an error, should you handle it by just performing the counting operation logic (call your function without passing a task)? I understand this can happen if for some reason the system couldn't immediately run it, like if there's already too many pending task requests. Seems you should not show an error message to the user, should still perform the request and just not support background continued processing for it (and perhaps consider showing a light warning "this operation can't be continued in the background so keep the app open"). Or should you still queue it up even though the user wants to start counting now? That leads to my next question Question 3: In what scenario would you not want the operation to start immediately (the queue behavior which is the default), given the app is already in the foreground and the user requested some operation? I'm struggling to think of an example, like a button titled Compress Photos Whenever You Can, and it may start immediately or maybe it won't? While waiting for the launchHandler to be invoked, should the UI just show 0% progress or "Pending" until the system can get to this task in the queue? Struggling to understand the use cases here, why make the user wait to start processing when they might not even intend to close the app during the operation? Thanks for any insights! As an aside, a sample project with a couple use cases would have been incredibly helpful to understand how the API is expected to be used.

I use .scaleEffect(x: 1, y: -1, anchor: .center) to reverse the messages list, so that the latest message always at the bottom. This is correct in ios18, but blurred the whole view in ios26. Complete code: ScrollView { Rectangle() .fill(.clear) .frame(height: 10) // if messages.isEmpty { // MessagesEmpty() // .padding(.horizontal, 10) // .scaleEffect(x: 1, y: -1, anchor: .center) // } MessageInput(chat: chat) .padding(.horizontal, 10) .scaleEffect(x: 1, y: -1, anchor: .center).id("#messag-input-identifier") LazyVStack(spacing: 10) { ForEach(messages) { (message: Message) in MessageItem(message: message, activation: $activeMessageId, audioAdapter: AudioAdapter.shared).id(message.id) } .padding(.horizontal, 10) .scaleEffect(x: 1, y: -1, anchor: .center) } Rectangle() .fill(.clear) .frame(height: 20) } .scaleEffect(x: 1, y: -1, anchor: .center) As shown in the screenshot WechatIMG49.jpg(using ios26beta which is incorrect), WechatIMG50.jpg(using ios18 which is correct) my messages list displays normally on iOS 18, but when using iOS 26 Beta, the entire view is blurred. IOS 26 Beta(Error): IOS 18(Correct):

I’m developing an iOS application using CoreNFC and working with ISO7816 tags. My use case involves exchanging APDU commands with a hardware device, but some operations can take more than 20 seconds. From my testing, I see that: The NFC reader session itself lasts about 60 seconds. But once a tag is connected, the connection seems to drop after ~20 seconds, and I receive a “connection lost” / session invalidated error. My questions are: Is this ~20-second connection window a hard limit enforced by iOS? Is there any way to extend this timeout for long-running APDU operations? If not, what’s the recommended design pattern for handling these scenarios? For example, should I split the process into smaller APDU commands and prompt the user to re-tap when the session times out? Any guidance or best practices for handling long NFC exchanges on iOS would be greatly appreciated.

When I migrate to swift6.2, the photopicker always giving the warning like below: Call to main actor-isolated initializer 'xxxfunction' in a synchronous nonisolated context it's so weird，because no matter it's a viewbuilder or a struct view，it can't fix the warning.

We have developed apps for the App Store for more than 7 years. One day, out of the blue we noticed all our apps have been removed and our account was pending termination. We really didn't know what was going on since we behaved correctly and honestly during all those years of development. After we asked for more info on why our account was in pending termination state we received this reply: Hello [redacted], We received your complaint filed on 2 October 2024 pursuant to the Regulation (EU) 2019/1150 of the European Parliament and of the Council of 20 June 2019 on promoting fairness and transparency for business users of online intermediation services (“P2B Regulation”). This correspondence serves as a response to your complaint. We thoroughly evaluated the activity associated with your Apple Developer Program membership. Our investigations confirm that your Apple Developer Program membership has been repeatedly used for dishonest and fraudulent activity in violation of Section 3.2(f) of the Apple Developer Program License Agreement, which states: “You will not, directly or indirectly, commit any act intended to interfere with any of the Apple Software or Services, the intent of this Agreement, or Apple’s business practices including, but not limited to, taking actions that may hinder the performance or intended use of the App Store, Custom App Distribution, TestFlight, Xcode Cloud, Ad Hoc distribution, or the Program (e.g., submitting fraudulent reviews of Your own Application or any third party application, choosing a name for Your Application that is substantially similar to the name of a third party application in order to create consumer confusion, or squatting on application names to prevent legitimate third party use). Further, You will not engage, or encourage others to engage, in any unlawful, unfair, misleading, fraudulent, improper, or dishonest acts or business practices relating to Your Covered Products (e.g., engaging in bait-and-switch pricing, consumer misrepresentation, deceptive business practices, or unfair competition against other developers).” We found a pattern of manipulative or misleading behavior. As a result of this behavior, your Apple Developer Program membership has been flagged for termination. These behaviors can include, but are not limited to, inaccurate metadata describing your app or service, misleading app content, engaging in inauthentic ratings and reviews manipulation, providing misleading customer support responses, providing misleading responses in App Store Connect, engaging in misleading purchasing or bait and switch schemes, or other dishonest or fraudulent activity within or outside of the app. Our recent investigation and review of your developer account confirm violations of the App Review Guidelines. Specifically, we received a notice claiming that your [redacted app] allowed users to download media content without authorization from the relevant third-party sources. Our investigations confirmed this behavior which constitutes direct and egregious violations of App Review Guidelines 2.3.1 and 5.2.3. In addition, your binary submission from 1 October 2024 continued to include references to impermissible conduct under Guideline 5.2.3. Given the egregious nature of the violations, your app was removed and your Apple Developer Program account has been flagged for termination. For the sake of clarity, we have included relevant excerpts from the App Review Guidelines below for reference: 2.3.1 (a) Don’t include any hidden, dormant, or undocumented features in your app; your app’s functionality should be clear to end users and App Review. All new features, functionality, and product changes must be described with specificity in the Notes for Review section of App Store Connect (generic descriptions will be rejected) and accessible for review. Similarly, marketing your app in a misleading way, such as by promoting content or services that it does not actually offer (e.g. iOS-based virus and malware scanners) or promoting a false price, whether within or outside of the App Store, is grounds for removal of your app from the App Store or a block from installing via alternative distribution and termination of your developer account. (b) Egregious or repeated behavior is grounds for removal from the Apple Developer Program. We work hard to make the App Store a trustworthy ecosystem and expect our app developers to follow suit; if you’re dishonest, we don’t want to do business with you. 5.2.3 Audio/Video Downloading: Apps should not facilitate illegal file sharing or include the ability to save, convert, or download media from third-party sources (e.g. Apple Music, YouTube, SoundCloud, Vimeo, etc.) without explicit authorization from those sources. Streaming of audio/video content may also violate Terms of Use, so be sure to check before your app accesses those services. Authorization must be provided upon request. The guiding principle of the App Store is to provide a safe and enjoyable experience for users and a great opportunity for all developers to be successful. We work hard to make the App Store a trustworthy ecosystem and expect our app developers to be honest with users and with us. Manipulative or misleading behavior degrades user trust in the App Store and is grounds for removal from the Apple Developer Program. [...] Sincerely, Apple We immediately checked upon the issue and noticed that the feature that Apple has been mentioning was enabled by mistake due to a technical malfunction inside our app and explained this to Apple in detail. We have also immediately submitted a new update to completely remove the code that allow the download of media content from the third party website in order to avoid an issue like this would ever happen in the future and also explained the situation to Apple, being completely transparent. Apple is currently ignoring our explanation and also the fact that we immediately addressed the issue and nothing was done in bad faith. The update we submitted should have completely fixed permanently the issue and yet we got our account terminated. An account with an app downloaded 50M times that have users worldwide and a 4.5 star rating. We never engaged in dishonest or fraudulent behavior and tried to explain this. It’s really disappointing and unfair to be falsely accused of dishonest behavior, and having no way to resolve the issue. We have been at complete disposal and all the facts reported are true and we have always been honest with our users and with Apple. We heavily invested in the Apple ecosystem having our app implemented Siri support, CarPlay support, MacOS support, Widget support and recently working also on the Apple Watch support. I really hope someone of the Apple Review Team could look into this and gave us the opportunity to fix this issue.

I investigated what network interface names are assigned to carrier networks on a dual SIM iPhone by examining the output of getifaddrs(). (An part of the program used for this is provided below.) ////////////// struct ifaddrs *interfaces = NULL; struct ifaddrs *an_interface = NULL; if (0 == getifaddrs(&interfaces)) { an_interface = interfaces; while (an_interface != NULL) { if( an_interface->ifa_addr->sa_family == AF_INET) { NSString* name = [NSString stringWithUTF8String:an_interface->ifa_name]; NSLog(@"Interface name is: %@", name); } an_interface = an_interface->ifa_next; } } freeifaddrs(interfaces); In this investigation, it appeared that the interface name for the sXGP SIM selected under "iPhone > Settings > Cellular > Cellular Data" was always "pdp_ip0". (A screenshot of "Cellular Data" is provided below. this is sample of sXGP selected )" [QUESTION] Is the SIM selected in Settings of iPhone always assigned to "pdp_ip0"? [BACKGROUND] I am developing a VoIP application and opening sockets by specifying IP addresses for communication. On a dual SIM iPhone, multiple networks (IP addresses) are visible. Therefore, I need to determine which network to use. My question is whether I can reliably make this decision based on the network interface name. If the SIM selected in Settings is always assigned to "pdp_ip0", I intend to open the socket using the IP address of "pdp_ip0". Alternatively, should I use a different method to select the appropriate network interface?

I discovered when editing photos with the PhotoKit API, PHContentEditingOutput's renderedContentURL is a file in the app container's tmp directory with a filename that seems to follow the format render.<uuid>.JPG, and that file does not get deleted if the edit does not complete successfully (the user cancels the edit request, an error occurs, the app crashes, etc). I understand the system is supposed to automatically delete tmp files every once in a while, but some users are noticing my app's Documents & Data inflates, so I'm considering deleting these render files each time the app is launched. But I don't want to delete everything in the tmp directory as there could possibly be other data in there. What's the best way to remove those temporary files? Does the filename always start with render. no matter the device language? I thought I'd delete files in NSTemporaryDirectory() with that prefix but then I discovered in Mac Catalyst the location is not the tmp directory directly, they're in tmp/TemporaryItems/<bundleid>. Thanks!

Hi developers, The iOS 18 has been unsigned since 09/23, which is much earlier than Apple usually does. In addition, the new features in IOS26 are tough to get used to; therefore, the sign for IOS18.7 is urgently needed by a large number of Apple users! Please see discussions on every social media across various languages.

I have a project that need to get serial number and network SSID. I have looking anywhere to get those 2 value but no luck to find it. is there anyway i can get those information from the device?

Title / Summary Crash in libquic.dylib when app is backgrounded and issues an HTTP/3 request Description On iOS 26, the app crashes inside libquic.dylib while performing a network request using HTTP/3 (QUIC) after the app has moved to the background. The crash happens within low-level QUIC / libquic internals. Reproduction Steps Launch the app, perform normal operations. Background the app (press home / switch away). While in background, trigger a network request that uses HTTP/3 / QUIC. Observe that the app crashes (stack trace pointing into libquic.dylib). Expected Behavior The HTTP/3 request in background should either be handled gracefully (fail or complete) without causing a crash; the app must not be terminated due to internal libquic failures. Actual Behavior The app crashes with signals/exceptions coming from libquic.dylib (in the QUIC / packet building / encryption / key state logic) when a HTTP/3 request is made in background. Environment / Device Information • OS: iOS 26 • Device: iPhone 13 Pro Max • Network environment: (Wi-Fi / Cellular) • HTTP/3 support: enabled in URLSession / Network framework Stack Trace： 8eedc0df3d914b0faf8def9af3b21574-symbolicated.crash

When the UITextField is touched, it crashes on "[UITextField becomeFirstResponder]" iOS 15.3.1 keyboard: Chinese keyboard of system

Dear Apple Developer Relations Team, We are currently reviewing the documentation for the UIDesignRequiresCompatibility Info.plist key. In the documentation, there is a warning that states: "Temporarily use this key while reviewing and refining your app’s UI for the design in the latest SDKs." However, in the adoption guide for Liquid Glass: Adopting Liquid Glass, we did not see any explicit requirement to force adoption of the Liquid Glass design. We have the Gojek app, which currently uses the UIDesignRequiresCompatibility key. To ensure long-term stability, we would like clarification on the following points: Future Support of the Key: Is it safe to continue using the UIDesignRequiresCompatibility key? Can you confirm whether this key will remain supported or if there are plans for it to be deprecated/removed in future iOS versions? Liquid Glass Adoption: Our app’s design guidelines do not align with the Liquid Glass style. Can you confirm that adoption of Liquid Glass is not mandatory, and that apps can continue to use their existing custom design guidelines without any restrictions? Compatibility with iOS 26: Are there any required changes we need to make to our existing views to ensure that the UI will continue to render as it does today on iOS 26 and beyond? We want to make sure we provide the best user experience while remaining compliant with Apple’s guidelines. Your clarification would help us plan our design and development roadmap accordingly. Thank you for your support and guidance.

We are seeing an issue in Safari on iOS 26 where the a automatic unfocus of on select box dismisses the second one. <select name="choice1" onblur="console.log('onblur1');" onfocus="console.log('onfocus1');"> <option value="first">First Value</option> <option value="second" selected>Second Value</option> <option value="third">Third Value</option> </select> <select name="choice2" onblur="console.log('onblur2');" onfocus="console.log('onfocus2')"> <option value="first">First Value</option> <option value="second" selected>Second Value</option> <option value="third">Third Value</option> </select> select something in choice1. quickly tap choice2 before onblur1 is logged. At the timing of onblur1 the selection menu for choice2 is dismissed. Anyone know how to fix this behavior?

I need to automate updating to latest iOS betas as part of my ci script, but I can't get it to install iOS 26.0 beta for the life of me, using xcodes or xcodebuild. I can see the version listed using xcodes runtimes --include-betas, and I tried sudo xcodes runtimes install "iOS 26.0-beta1", but I would get the error Downloading Runtime iOS 26.0-beta1: 0% Error: ProcessExecutionError()\ I also tried xcodebuild -downloadPlatform iOS -buildVersion 23A5260l, where I found the specific build id on apples dev images website. But I would get the error iOS 23A5260l is not available for download. Specific version download failed, trying downloadPlatform ios latest... And similar error for trying xcodebuild -downloadPlatform iOS -buildVersion 26.0 or other version ids I found online. But this command would work for any other versions and betas listed on the website. I was able to install iOS 26.0 through xcodebuild -downloadPlatform iOS, which automatically installed it for me, but this is unideal for my situation, as I want to control which betas to install instead of just the latest one (like iOS 18.6 beta that just came out). Is anyone else also struggling with these errors? xcodes version 1.6.2 Xcode version 26.0 Beta (installed and selected through xcode)

Hello, In our app we provide a button that initiates a phone call using tel://. For normal numbers, tapping the button presents the standard iOS confirmation sheet with Call and Cancel. If RTT is enabled on the device, the sheet instead shows three options: Call, Cancel, and RTT Call. However, when dialing a national emergency number, this confirmation dialog does not appear at all — the call is placed immediately, without giving the user the choice between voice or RTT. Is this the expected system behavior for emergency numbers on iOS? 
And if so, how does RTT get applied in the emergency-call flow — is it managed entirely by the OS rather than exposed as a user-facing option? Thanks in advance for clarifying.

Hello, I’m facing an issue while trying to add iOS devices to Apple Business Manager (ABM) using Apple Configurator during enrollment. When going through the setup process, the device fails to complete enrollment and times out. I’ve tried it multiple times. The device does appear in ABM during the process and I am able to assign it to different MDM servers but since the setup times out and fails, the device is automatically released. I have tried this with multiple iOS devices and it times out on every single one of them. Steps attempted: Factory reset and re-enrollment of the device Ensured network connectivity is stable and tested on multiple Wi-Fi networks Tried the following process using Apple Configurator on Mac (wired): Created a Wi-Fi profile in Configurator Connected the iPhone via cable and used Prepare (manual configuration) Used the “MDM server” placeholder and trusted anchors (as recommended) Linked the device to the ABM organization Skipped Setup Assistant steps Attached the Wi-Fi profile, then prepared and wiped the device Verified that the device should appear in ABM Attempted to assign the device to my MDM in ABM Despite these checks, the enrollment process times out. I’m attaching a screenshot of the error for reference. Could someone advise what might be causing this timeout or how I can further troubleshoot this? Any guidance would be greatly appreciated. Thanks in advance.

We are currently implementing App Clips in our app. While we have carefully optimized the App Clip size to keep it lightweight (~3.69MB), we have noticed that on the first load, displaying the App Clip Card and activating the “Open” button takes a surprisingly long time (approximately 2–3 seconds). Subsequent loads appear to perform normally. We understand that this behavior may not be directly controllable from the app development side, but we would like to know if there are any possible ways to improve it. Minimizing the time it takes for users to access the content is extremely important, as delays on the first interaction can negatively impact the user experience. Any guidance or best practices to make the App Clip Card and its “Open” button respond faster on first load would be greatly appreciated.

Hi, in the Human Interface Guidelines, Apple writes: Avoid using a segmented control in a toolbar. Toolbar items act on the current screen — they don’t let people switch contexts like segmented controls do. Along with this image: Source I'm confused by this example. The screenshot seems to be showing a segmented control in a toolbar. Is this saying that the Phone app's All/Missed toggle is different from a segmented control? Under iOS 26 it seems to take a different style compared to a regular segmented control. If so, which component is used to create this filter? Could you please clarify the guidelines? Thank you.

Hello, we are developing hardware that needs to connect to an iPhone via Wi-Fi to send requests to a server. On Android, we have managed to create a programmatic local hotspot within the app to facilitate connection and improve the user experience. On iOS, however, Personal Hotspot must be manually enabled from the system settings, and the user must manually enter the SSID and password, which significantly degrades the UX. My questions are: Is there a workaround, unofficial method, or private API to generate a local hotspot from an app on iOS, similar to what can be done on Android? Is there an alternative within the MFi program or through specific frameworks to facilitate a quick and automatic connection between the hardware and the iPhone without relying on the manual Personal Hotspot? Are there any best practices for improving the local Wi-Fi connection experience between an accessory and an iPhone in the absence of hotspot controls? I would appreciate any guidance, experience, or resources that would help me better understand the feasible options in iOS for scenarios where fast and direct communication between hardware and mobile devices via Wi-Fi is required.

Area ImageCaptureCore / ICDeviceBrowser Description On iOS 26.1 beta, calling requestControlAuthorization() requestContentsAuthorization() always returns .notDetermined and never transitions to .authorized or .denied. This prevents apps from properly accessing device control or contents authorization. The issue occurs regardless of device state or prior requests. Steps to Reproduce 1. Create and start an ICDeviceBrowser instance. 2. Call requestControlAuthorization() or requestContentsAuthorization(). 3. Inspect the returned ICAuthorizationStatus. Expected Result • The system should prompt the user if necessary. • A final status of either .authorized or .denied should be returned. Actual Result • The completion handler always reports .notDetermined. • No user prompt appears and the status does not change. Version / Build • iOS 26.1 beta • Xcode Hardware • [iPhone 15 Pro, iPad Pro (M2)] Impact This regression blocks development and testing of features relying on ImageCaptureCore. Applications depending on device browsing and content access cannot proceed, which significantly affects workflows involving external device integration. Notes This appears to be a regression compared to earlier iOS releases.