In our Unity App for iOS build, when we opened the PDF from the app, it is automatically opening in landspace mode instead of portrait. In the android and windows apps, we are able to open in the portrait mode. We tried to make the changes in the project settings but it did not change. Any way in which we can acheive this would be helpful for us.

How can I allow the popup I am encountering while I run my UI tests with video recording in the Github actions. Since these tests are running on VMs, it's not possible to manually click Allow. Also the remote robot cannot interact with OS-level dialogs.

I could use the Metal System Trace before the most recent update, but now whenever I try to profile using the Metal Counter instrument, I get the [Warning] GPU Service reported error: Selected counter profile is not supported on target device. What is the issue here?

I regularly bump into folks confused by this issue, so I thought I’d collect my thoughts on the topic into a single (hopefully) coherent post. If you have questions or comments, put them in a new thread here on the forums. Feel free to use whatever subtopic and tags that apply to your situation, but make sure to add the Debugging tag so that I see your thread go by. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Testing and Debugging Code Running in the Background I regularly see questions like this: My background code works just fine in Xcode but fails when I download the app from the App Store. or this: … or fails when I run my app from the Home screen. or this: How do I step through my background code? These suggest a fundamental misunderstanding of how the debugger interacts with iOS’s background execution model. The goal of this post is to explain that misunderstanding so that you can effectively test and debug background code. Note The focus of this post is iOS. The advice here generally applies to any of iOS’s ‘child’ platforms, so iPadOS, tvOS, and so on. However, there will be some platform specific differences, especially on watchOS. This advice here doesn’t apply to macOS. It’s background execution model is completely different than the one used by iOS. Understand the Fundamentals The key point to note here is that the debugger prevents your app from suspending. This has important consequences for iOS’s background execution model. Normally: iOS suspends your app when it’s in the background. Once your app is suspended, it becomes eligible for termination. The most common reason for this is that the system wants to recover memory, but it can happen for various other reasons. For example, the system might terminate a suspended app in order to update it. Under various circumstances your app can continue running after moving to the background. A great example of this is the continued processed task feature, introduced in iOS 26 beta. Alternatively, your app can be resumed or relaunched in the background to perform some task. For example, the region monitor feature of Core Location can resume or relaunch your app in the background when the user enters or leaves a region. If no app needs to be executing, the system can sleep the CPU. None of this happens in the normal way if the debugger is attached to your app, and it’s vital that you take that into account when debugging code that runs in the background. An Example of the Problem For an example of how this can cause problems, imagine an app that uses an URLSession background session. A background session will resume or relaunch your app in the background when specific events happen. This involves two separate code paths: If your app is suspended, the session resumes it in the background. If your app is terminated, it relaunches it in the background. Neither code path behaves normally if the debugger is attached. In the first case, the app never suspends, so the resume case isn’t properly exercised. Rather, your background session acts like it would if your app were in the foreground. Normally this doesn’t cause too many problems, so this isn’t a huge concern. On the other hand, the second case is much more problematic. The debugger prevents your app from suspending, and hence from terminating, and thus you can’t exercise this code path at all. Seek Framework-Specific Advice The above is just an example, and there are likely other things to keep in mind when debugging background code for a specific framework. Consult the documentation for the framework you’re working with to see if it has specific advice. Note For URLSession background sessions, check out Testing Background Session Code. The rest of this post focuses on the general case, offering advice that applies to all frameworks that support background execution. Run Your App Outside of Xcode When debugging background execution, launch your app from the Home screen. For day-to-day development: Run the app from Xcode in the normal way (Product > Run). Stop it. Run it again from the Home screen. Alternatively, install a build from TestFlight. This accurately replicates the App Store install experience. Write Code with Debugging in Mind It’s obvious that, if you run the app without attaching the debugger, you won’t be able to use the debugger to debug it. Rather: Extract the core logic of your code into libraries, and then write extensive unit tests for those libraries. You’ll be able to debug these unit tests with the debugger. Add log points to help debug your integration with the system. Treat your logging as a feature of your product. Carefully consider where to add log points and at what level to log. Check this logging code into your source code repository and ship it — or at least the bulk of it — as part of your final product. This logging will be super helpful when it comes to debugging problems that only show up in the field. My general advice is that you use the system log for these log points. See Your Friend the System Log for lots of advice on that front. One of the great features of the system log is that disabled log points are very cheap. In most cases it’s fine to leave these in your final product. Attach and Detach In some cases it really is helpful to debug with the debugger. One option here is to attach to your running app, debug a specific thing, and then detach from it. Specifically: To attach to a running app, choose Debug > Attach to Process > YourAppName in Xcode. To detach, choose Debug > Detach. Understand Force Quit iOS allows users to remove an app from the multitasking UI. This is commonly known as force quit, but that’s not a particularly accurate term: The multitasking UI doesn’t show apps that are running, it shows apps that have been run by the user. The UI shows recently run apps regardless of whether they’re in the foreground, running in the background, suspended, or terminated. So, removing an app from the UI may not actually quit anything. Removing an app sets a flag that prevents the app from being launched in the background. That flag gets cleared when the user next launches the app manually. Note In some circumstances iOS will not honour this flag. The exact cases where this happens are not documented and have changed over time. Keep these behaviours in mind as you debug your background execution code. For example, imagine you’re trying to test the URLSession background relaunch code path discussed above. If you force quit your app, you’ll never hit this code path because iOS won’t relaunch your app in the background. Rather, add a debug-only button that causes your app to call exit. IMPORTANT This suggestion is for debugging only. Don’t include a Quit button in your final app! This is specifically proscribed by QA1561. Alternatively, if you’re attached to your app with Xcode, simply choose Product > Stop. This is like calling exit; it has no impact on your app’s ability to run in the background. Test With Various Background App Refresh Settings iOS puts users in control of background execution via the options in Settings > General > Background App Refresh. Test how your app performs with the following settings: Background app refresh turned off overall Background app refresh turned on in general but turned off for your app Background app refresh turned on in general and turned on for your app IMPORTANT While these settings are labelled Background App Refresh, they affect subsystems other than background app refresh. Test all of these cases regardless of what specific background execution feature you’re using. Test Realistic User Scenarios In many cases you won’t be able to fully test background execution code at your desk. Rather, install a TestFlight build of your app and then use the device as a normal user would. For example: To test Core Location background execution properly, actual leave your office and move around as a user might. To test background app refresh, use your app regularly during the day and then put your device on charge at night. Testing like this requires two things: Patience Good logging The system log may be sufficient here, but you might need to investigate other logging solutions that are more appropriate for your product. These testing challenges are why it’s critical that you have unit tests to exercise your core logic. It takes a lot of time to run integration tests like this, so you want to focus on integration issues. Before starting your integration tests, make sure that your unit tests have flushed out any bugs in your core logic. Revision History 2025-08-12 Made various editorial changes. 2025-08-11 First posted.

I have a Apple Developer accounts for development purposes only and that is also used for testing builds via TestFlight. Is the Age Ratings Responses updates due by the end of January 2026 still required even to send builds to TestFlight?

Hi! A couple of months ago my app was archiving just fine. Since an xcode update the build fails. Here is what shows at the end of the log. Thank you in advance for any help! Run custom shell script 'Run Script' Failed to package [project folder] Command PhaseScriptExecution failed with a nonzero exit code

I tried using Create ML of Xcode 26.0 beta 7 to generate a model using the "Word Tagging" template, and I received the error: Training progress unavailable - Unexpected error. Using Create ML of XCode 16.4 with the same documentation, I was able to build the model and use it in a test app. I'd like to understand why Create ML of Xcode 26 no longer works.

Moving the cursor left and right becomes extremely sluggish, though up-down movement and mouse clicks are normal. The Apple Store Genius checked the hardware and even reinstalled the OS, but the issue remains.

In Simulator Korean character system has not working well. I want to type "", however, if I type the same thing on the simulator's virtual keyboard (Korean), it comes out as ''. I think this is caused by IME system in ios simulator bug. I think this has been happening since IOS 17.

It seems as though using any initializer of SubscriptionOfferView or StoreView will create a memory leak. This can be simply reproduced by adding this to your SwiftUI view: SubscriptionOfferView(groupID: "yourgroupID", visibleRelationship: .all, useAppIcon: true) or StoreView(ids: ["monthly", "yearly"]) Tested on iOS 26 beta 2

I am running into an issue where when layers are grouped, the icon is not shown as it does within the preview in the Icon Composer app Is this a bug or is it some setting within the group/app?

I'm trying to authenticate to a git host using SSH keys stored in 1Password. I have ~/.ssh/config with mode 600 set with a symlink: Host * IdentityAgent "~/.1password/agent.sock" But ssh-add -l shows no identities. If I set $SSH_AUTH_SOCK, ssh-add -l works just fine. I'd love to not have to do this, though. Why doesn't ssh-add seem to read ~/.ssh/config? The built-in version is OpenSSH_10.0p2, LibreSSL 3.3.6. I've searched fruitlessly for an answer anywhere else.

Hey, I've been having a lot of problems with Xcode 16 not seeing changes made to code in local Swift packages (the packages are inside the root directory of the project). Whenever I make any change like renaming a variable or type, or adding new methods or whatever, autocomplete doesn't see those changes and when I type in that new type/variable manually it gives me an error. However, building the project still works fine, even with the errors never going away. The only way for it to notice the code changes is to clean the project and build it again which takes a long time. At first, I thought this was connected to the new "Explicitly built modules" feature in Xcode 16, but I turned it off and it still happens. Any ideas what I can try? I'm on the latest Xcode version, but this problem has been happening since Xcode 16 originally came out. Thanks! Dennis

We're facing critical stability issues with a Xamarin-based iOS warehouse management app and need expert validation of our crash log analysis. We’re seeing recurring issues related to: Auto Layout Threading Violations Memory Pressure Terminations CPU Resource Usage Violations These are causing app crashes and performance degradation in production. We've attached representative crash logs to this post. Technical Validation Questions: Do the crash logs point to app-level defects (e.g., threading/memory management), or could user behavior be a contributing factor? Is ~1.8GB memory usage acceptable for enterprise apps on iOS, or does it breach platform best practices? Do the threading violations suggest a fundamental architectural or concurrency design flaw in the codebase? Would you classify these as enterprise-grade stability concerns requiring immediate architectural refactoring? Do the memory logs indicate potential leaks, or are the spikes consistent with expected usage patterns under load? Could resolving the threading violation eliminate or reduce the memory and CPU issues (i.e., a cascading failure)? Are these issues rooted in Xamarin framework limitations, or do they point more toward app-specific implementation problems? Documentation & UX Questions: What Apple-recommended solutions exist for these specific issues? (e.g., memory management, thread safety, layout handling) From your experience, how would these issues manifest for users? (e.g., crashes, slow performance, logout events, unresponsive UI, etc. JetsamEvent-2025-05-27-123434_REDACTED.ips ) WarehouseApp.iOS.cpu_resource-2025-05-30-142737_REDACTED.ips WarehouseApp.iOS-2025-05-27-105134_REDACTED.ips Any insights, analysis, or references would be incredibly helpful. Thanks in advance!

I have a ContentView in my app which includes the line of code FileUploadProgressAttributes. this struct is defined in a file included in the target FileUploadProgressExtension. and it is an ActivityAttributes. in ContentView I imported FileUploadProgressExtension, and the xcode is able to find the FileUploadProgressAttributes during prebuild. but during build, it gives me Undefined symbols for architecture arm64: "FileUploadProgressExtension.FileUploadProgressAttributes.init(filename: Swift.String) -> FileUploadProgressExtension.FileUploadProgressAttributes the workaround i found is to add the file with the FileUploadProgressAttributes to my app's target, but I'm not sure if this is the right thing to do. When Xcode created the extension for me, it added the extension target as a target dependency of my app. so obviously if i added this file to my app target it makes the extension target pointless. First time working with widgets so I'm not sure if I'm missing something.

I'm working on a custom instrument that displays intervals from os_signpost data. I'd like to color the intervals in the graph based on data from an accompanying aggregate. For example, color the interval red if its duration is greater than 3 standard deviations from the mean. Is this possible?

I am passing UUID Key from View1 to View2. In View2, I need to Fetch entries using TabKey. userId is global variable working fine. Giving error TabKey. Please help. how to get rid of this error. If I keep this logic inside init method, Getting new error saying that "Cannot convert value of type 'FetchedResults' to expected argument type 'Binding' Here is the Code. @FetchRequest( sortDescriptors: [NSSortDescriptor(keyPath: \Table2.date, ascending: false)], predicate: { guard let currentUserId = AppSession.shared.currentUserId else { return NSPredicate(value: false) // Or handle the nil case as needed } return NSPredicate(format: "userId == %@ AND itemKey == %@", currentUserId as CVarArg, TabKey as CVarArg ) }(), animation: .default ) private var itab: FetchedResults

I am running Appium tests on an iOS 18 simulator, and I am encountering an intermittent issue where the device screen gets locked unexpectedly during the tests. The Appium logs show no errors or unusual activity, and all commands appear to be executed successfully. However, upon reviewing the device logs, I see entries related to the lock event, but the exact cause remains unclear. SpringBoard: (SpringBoard) [com.apple.SpringBoard:Common] lockUIFromSource:Boot options:{ SBUILockOptionsLockAutomaticallyKey: 1, SBUILockOptionsForceLockKey: 1, SBUILockOptionsUseScreenOffModeKey: 0 } SpringBoard: (SpringBoard) [com.apple.SpringBoard:Common] -[SBTelephonyManager inCall] 0 SpringBoard: (SpringBoard) [com.apple.SpringBoard:Common] LockUI from source: Now locking Has anyone experienced similar behavior with Appium on iOS 18, or could there be a setting or configuration in the simulator that is causing this issue?

Running macOS 15.4.1, Simulator 16.0 (1042.1), various iOS devices (iPhone 16, iPad 13" M4) I log into iCloud and enable iCloud Drive. Running the Files app, I noticed that I can click on "flat" documents (PDF, JPEG, etc) and they work. However, when I click on "package" documents (e.g. represented by a directory behind the scenes), I get a normal download progress, but then an alert "The operation could not be completed. No such file or directory". This seems to happen with all package documents, e.g. Keynote documents or Reality Composer objcap documents. It does not happen on actual devices logged into the same account. I've tried completely deleting and rebuilding the simulator instances in question, with no success.

I am encountering an issue where the application running on a physical device does not reflect the most recent source changes. Observed behavior On the device, the application behaves as if an older binary is running. Specifically: Newly added debug UI labels do not appear. The logs still show old debug prints instead of new ones. Steps taken to ensure a clean install: Changed the bundle identifier Set a new display name (the app still showed the old display name when I click run). Deleted the app manually from the device before every reinstall. Build and install steps Performed multiple clean builds with a fresh Derived Data path. Built from terminal using xcodebuild (Debug configuration, physical device target, automatic provisioning). Installed using: xcrun devicectl device install app Verified: The updated source files are listed under Compile Sources and compiled from the expected path. The bundled Info.plist includes the new bundle identifier and display name. Installation output confirms new bundle identifier. Question What could cause a newly built and installed application to run with behavior from an older binary? Are there recommended ways to verify that the device is actually launching the latest installed build, and to ensure stale binaries are not being executed? Any guidance on additional diagnostics or misconfigurations to check would be appreciated.