Hello, I've encountered unexpected behavior related to version information in our app logs, and I'd like to ask for some advice. We reviewed logs collected from a user running our app (currently available on the App Store). The logs are designed to include both the build number and the app version. Based on the build number in the logs, we believe the installed app version on the user's device is 1.0.3. However, the app version recorded in the logs is 1.1.5, which is the latest version currently available on the App Store. In our project, we set the app version using the MARKETING_VERSION environment variable. This value is configured via XcodeGen, and we define it in a YAML file. Under normal circumstances, the value defined in the YAML file (MARKETING_VERSION = 1.0.3) should be embedded in the app and reflected in the logs. But in this case, the version from the current App Store release (1.1.5) appears instead, which was unexpected. We'd like to know what might cause this behavior, and if there are any known factors that could lead to this. Also, is it possible that MARKETING_VERSION might somehow dynamically reflect the version currently available on the App Store? YAML: info.plist:

For the Linux version of my application which is written in C++ using Qt, I display the CHM format help files with this code: QString helpFile{ QCoreApplication::applicationDirPath() + "/Help/" + tr("DeepSkyStacker Help.chm","IDS_HELPFILE") }; QString program{ "kchmviewer" }; QStringList arguments{ "-token", "com.github.deepskystacker", helpFile }; helpProcess->startDetached(program, arguments); (helpProcess is a pointer to a QProcess object) The -token com.github.deepskystackerpart of that ensures that only a single instance of the viewer is used for any code that uses that invocation. Are there any chm file viewers for macOS that are capable of that sort of trick? The ones I've found on the App Store give minimal information and appear to be very simple minded tools that are not not intended for integration into an application as above. I know that MacPorts offers ports of kchmviewer but I'd prefer not to use either that or HomeBrew ... David

I have a parental control app that uses FamilyControls, ManagedSettings, and DeviceActivityMonitor across two extension targets (DeviceActivityMonitor and ShieldConfiguration). The main app target received its Family Controls (Distribution) entitlement without issue. I then submitted requests for the same entitlement for both extension targets on April 16. Both still show as "Submitted" with no update after 12 days. Two questions: What is the typical turnaround time for extension entitlement requests? The main app was approved relatively quickly. Is there anything additional required for extension targets beyond the standard request? I submitted through the normal entitlement request flow. I didn't include any supplementary documentation as none was requested. These are the last blocker for App Store submission. Any guidance appreciated.

My App is not compatible with iPhone 15 but can run on iPhone 14 perfectly fine, what could be the problem? I am new to App development.

Hi everyone, I’m hoping someone here can shed some light on what’s going on with Apple’s one-hour security delay when trying to register an iPhone for development use. I’m currently setting up an app build using Expo / EAS and a paid Apple Developer account. Every time I scan the device registration QR code or try to authorise my iPhone as a development device, I get hit with a “security delay — try again in one hour” message. This happens every single time, even if I wait the full hour. The device is the same iPhone I always use, signed in to the same Apple ID, and verified with 2FA. The only thing unusual about my setup is that I’m using Starlink for internet access. Because Starlink uses dynamic IP routing and your exit node changes frequently (depending on which satellite or ground station you’re on), it looks like I’m signing in from a new location each time — sometimes even hundreds of miles apart. It seems that Apple’s security system flags each of these as a “new login” or “new device registration,” then enforces a one-hour safety lockout. That makes it basically impossible to register my device and proceed with iOS builds or testing. Has anyone else run into this problem while using Starlink (or other dynamic-routing connections like VPNs or cellular hotspots)? And if so — is there any known workaround or setting to whitelist a device, stabilise verification, or bypass the repeated one-hour wait? This feels like an over-protective security feature that doesn’t play well with modern satellite internet setups. Any insights from the Apple engineers or other developers would be hugely appreciated. Thanks, Tim Lazenby

How to replicate: Design a icon in icon composer Save it and put the .icon file in your project, then in your targets put the name of the .icon file in there. Either clean build folder or restart IDE One Error: unable to open dependencies file (/Users/user/Library/Developer/Xcode/DerivedData/project-fqrfzzkwgrutdabmcqjeupvyetci/Build/Intermediates.noindex/project.build/Debug/project.build/assetcatalog_dependencies_thinned) And one warning: Icon export exited with status 255, signal 0 Is this a known issue or a easy fix? Or is it a issue on my end? Thanks

iphone 15 pro max ios 26 Stuck at the developer mode startup interface and unable to swipe up.

Le build iOS via EAS échoue systématiquement lors de la phase Xcode. Bien que les capacités Family Controls et App Groups soient activées sur le portail Apple Developer et configurées dans le app.json, les profils de provisionnement générés par EAS sont rejetés par Xcode car ils ne contiendraient pas les droits nécessaires. Configuration du projet : Targets (4) : App principale + 3 extensions (ShieldConfiguration, ShieldAction, ActivityMonitorExtension). Capabilities requises : Family Controls (Development), App Groups. EAS CLI Version : 18.0.6 (et versions antérieures testées). Erreur Xcode récurrente : error: Provisioning profile "[expo] com.*****.*** AdHoc 177230..." doesn't support the Family Controls (Development) capability.. error: Provisioning profile "... AdHoc ..." doesn't include the com.apple.developer.family-controls entitlement.. Ce qui a déjà été tenté (sans succès) : Configuration app.json : Ajout manuel des entitlements pour le bundle principal et configuration du plugin react-native-device-activity. Nettoyage Credentials : Suppression totale des profils et des identifiants sur le site Expo.dev ET sur le portail Apple Developer. +1 Forçage Sync : Utilisation de eas build --clear-cache et réponse "No" à la réutilisation des profils existants. Observation étrange : Le terminal indique souvent ✔ Synced capabilities: No updates, alors que les droits viennent d'être modifiés sur le portail Apple. Sur le portail Apple, les profils affichent pourtant bien "Family Controls (Development)" dans les capacités activées. Je met en piece jointe un des profiles.

There is a bug in Unity Plugins: Corehaptics.AssetPickerDrawer throws exceptions and draws incorrectly when fieldInfo or assetType is null (FB17305973). I fixed it and created a pull request: https://github.com/apple/unityplugins/pull/47 It has been months and this bug is really annoying.

Recently a bunch of folks have asked about why a specific symbol is being referenced by their app. This is my attempt to address that question. If you have questions or comments, please start a new thread. Tag it with Linker so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Determining Why a Symbol is Referenced In some situations you might want to know why a symbol is referenced by your app. For example: You might be working with a security auditing tool that flags uses of malloc. You might be creating a privacy manifest and want to track down where your app is calling stat. This post is my attempt at explaining a general process for tracking down the origin of these symbol references. This process works from ‘below’. That is, it works ‘up’ from you app’s binary rather than ‘down’ from your app’s source code. That’s important because: It might be hard to track down all of your source code, especially if you’re using one or more package management systems. If your app has a binary dependency on a static library, dynamic library, or framework, you might not have access to that library’s source code. IMPORTANT This post assumes the terminology from An Apple Library Primer. Read that before continuing here. The general outline of this process is: Find all Mach-O images. Find the Mach-O image that references the symbol. Find the object files (.o) used to make that Mach-O. Find the object file that references the symbol. Find the code within that object file. Those last few steps require some gnarly low-level Mach-O knowledge. If you’re looking for an easier path, try using the approach described in the A higher-level alternative section as a replacement for steps 3 through 5. This post assumes that you’re using Xcode. If you’re using third-party tools that are based on Apple tools, and specifically Apple’s linker, you should be able to adapt this process to your tooling. If you’re using a third-party tool that has its own linker, you’ll need to ask for help via your tool’s support channel. Find all Mach-O images On Apple platforms an app consists of a number of Mach-O images. Every app has a main executable. The app may also embed dynamic libraries or frameworks. The app may also embed app extensions or system extensions, each of which have their own executable. And a Mac app might have embedded bundles, helper tools, XPC services, agents, daemons, and so on. To find all the Mach-O images in your app, combine the find and file tools. For example: % find "Apple Configurator.app" -print0 | xargs -0 file | grep Mach-O Apple Configurator.app/Contents/MacOS/Apple Configurator: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64] … Apple Configurator.app/Contents/MacOS/cfgutil: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64] … Apple Configurator.app/Contents/Extensions/ConfiguratorIntents.appex/Contents/MacOS/ConfiguratorIntents: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64] … Apple Configurator.app/Contents/Frameworks/ConfigurationUtilityKit.framework/Versions/A/ConfigurationUtilityKit: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit dynamically linked shared library x86_64] [arm64] … This shows that Apple Configurator has a main executable (Apple Configurator), a helper tool (cfgutil), an app extension (ConfiguratorIntents), a framework (ConfigurationUtilityKit), and many more. This output is quite unwieldy. For nicer output, create and use a shell script like this: % cat FindMachO.sh #! /bin/sh # Passing `-0` to `find` causes it to emit a NUL delimited after the # file name and the `:`. Sadly, macOS `cut` doesn’t support a nul # delimiter so we use `tr` to convert that to a DLE (0x01) and `cut` on # that. # # Weirdly, `find` only inserts the NUL on the primary line, not the # per-architecture Mach-O lines. We use that to our advantage, filtering # out the per-architecture noise by only passing through lines # containing a DLE. find "$@" -type f -print0 \ | xargs -0 file -0 \ | grep -a Mach-O \ | tr '\0' '\1' \ | grep -a $(printf '\1') \ | cut -d $(printf '\1') -f 1 Find the Mach-O image that references the symbol Once you have a list of Mach-O images, use nm to find the one that references the symbol. The rest of this post investigate a test app, WaffleVarnishORama, that’s written in Swift but uses waffle management functionality from the libWaffleCore.a static library. The goal is to find the code that calls calloc. This app has a single Mach-O image: % FindMachO.sh "WaffleVarnishORama.app" WaffleVarnishORama.app/WaffleVarnishORama Use nm to confirm that it references calloc: % nm "WaffleVarnishORama.app/WaffleVarnishORama" | grep "calloc" U _calloc The _calloc symbol has a leading underscore because it’s a C symbol. This convention dates from the dawn of Unix, where the underscore distinguish C symbols from assembly language symbols. The U prefix indicates that the symbol is undefined, that is, the Mach-O images is importing the symbol. If the symbol name is prefixed by a hex number and some other character, like T or t, that means that the library includes an implementation of calloc. That’s weird, but certainly possible. OTOH, if you see this then you know this Mach-O image isn’t importing calloc. IMPORTANT If this Mach-O isn’t something that you build — that is, you get this Mach-O image as a binary from another developer — you won’t be able to follow the rest of this process. Instead, ask for help via that library’s support channel. Find the object files used to make that Mach-O image The next step is to track down which .o file includes the reference to calloc. Do this by generating a link map. A link map is an old school linker feature that records the location, size, and origin of every symbol added to the linker’s output. To generate a link map, enable the Write Link Map File build setting. By default this puts the link map into a text (.txt) file within the derived data directory. To find the exact path, look at the Link step in the build log. If you want to customise this, use the Path to Link Map File build setting. A link map has three parts: A simple header A list of object files used to build the Mach-O image A list of sections and their symbols In our case the link map looks like this: # Path: …/WaffleVarnishORama.app/WaffleVarnishORama # Arch: arm64 # Object files: [ 0] linker synthesized [ 1] objc-file [ 2] …/AppDelegate.o [ 3] …/MainViewController.o [ 4] …/libWaffleCore.a[2](WaffleCore.o) [ 5] …/Foundation.framework/Foundation.tbd … # Sections: # Address Size Segment Section 0x100008000 0x00001AB8 __TEXT __text … The list of object files contains: An object file for each of our app’s source files — That’s AppDelegate.o and MainViewController.o in this example. A list of static libraries — Here that’s just libWaffleCore.a. A list of dynamic libraries — These might be stub libraries (.tbd), dynamic libraries (.dylib), or frameworks (.framework). Focus on the object files and static libraries. The list of dynamic libraries is irrelevant because each of those is its own Mach-O image. Find the object file that references the symbol Once you have list of object files and static libraries, use nm to each one for the calloc symbol: % nm "…/AppDelegate.o" | grep calloc % nm "…/MainViewController.o" | grep calloc % nm "…/libWaffleCore.a" | grep calloc U _calloc This indicates that only libWaffleCore.a references the calloc symbol, so let’s focus on that. Note As in the Mach-O case, the U prefix indicates that the symbol is undefined, that is, the object file is importing the symbol. Find the code within that object file To find the code within the object file that references the symbol, use the objdump tool. That tool takes an object file as input, but in this example we have a static library. That’s an archive containing one or more object files. So, the first step is to unpack that archive: % mkdir "libWaffleCore-objects" % cd "libWaffleCore-objects" % ar -x "…/libWaffleCore.a" % ls -lh total 24 -rw-r--r-- 1 quinn staff 4.1K 8 May 11:24 WaffleCore.o -rw-r--r-- 1 quinn staff 56B 8 May 11:24 __.SYMDEF SORTED There’s only a single object file in that library, which makes things easy. If there were a multiple, run the following process over each one independently. To find the code that references a symbol, run objdump with the -S and -r options: % xcrun objdump -S -r "WaffleCore.o" … ; extern WaffleRef newWaffle(void) { 0: d10083ff sub sp, sp, #32 4: a9017bfd stp x29, x30, [sp, #16] 8: 910043fd add x29, sp, #16 c: d2800020 mov x0, #1 10: d2800081 mov x1, #4 ; Waffle * result = calloc(1, sizeof(Waffle)); 14: 94000000 bl 0x14 <ltmp0+0x14> 0000000000000014: ARM64_RELOC_BRANCH26 _calloc … Note the ARM64_RELOC_BRANCH26 line. This tells you that the instruction before that — the bl at offset 0x14 — references the _calloc symbol. IMPORTANT The ARM64_RELOC_BRANCH26 relocation is specific to the bl instruction in 64-bit Arm code. You’ll see other relocations for other instructions. And the Intel architecture has a whole different set of relocations. So, when searching this output don’t look for ARM64_RELOC_BRANCH26 specifically, but rather any relocation that references _calloc. In this case we’ve built the object file from source code, so WaffleCore.o contains debug symbols. That allows objdump include information about the source code context. From that, we can easily see that calloc is referenced by our newWaffle function. To see what happens when you don’t have debug symbols, create an new object file with them stripped out: % cp "WaffleCore.o" "WaffleCore-stripped.o" % strip -x -S "WaffleCore-stripped.o" Then repeat the objdump command: % xcrun objdump -S -r "WaffleCore-stripped.o" … 0000000000000000 <_newWaffle>: 0: d10083ff sub sp, sp, #32 4: a9017bfd stp x29, x30, [sp, #16] 8: 910043fd add x29, sp, #16 c: d2800020 mov x0, #1 10: d2800081 mov x1, #4 14: 94000000 bl 0x14 <_newWaffle+0x14> 0000000000000014: ARM64_RELOC_BRANCH26 _calloc … While this isn’t as nice as the previous output, you can still see that newWaffle is calling calloc. A higher-level alternative Grovelling through Mach-O object files is quite tricky. Fortunately there’s an easier approach: Use the -why_live option to ask the linker why it included a reference to the symbol. To continue the above example, I set the Other Linker Flags build setting to -Xlinker / -why_live / -Xlinker / _calloc and this is what I saw in the build transcript: _calloc from /usr/lib/system/libsystem_malloc.dylib _newWaffle from …/libWaffleCore.a[2](WaffleCore.o) _$s18WaffleVarnishORama18MainViewControllerC05tableE0_14didSelectRowAtySo07UITableE0C_10Foundation9IndexPathVtFTf4dnn_n from …/MainViewController.o _$s18WaffleVarnishORama18MainViewControllerC05tableE0_14didSelectRowAtySo07UITableE0C_10Foundation9IndexPathVtF from …/MainViewController.o Demangling reveals a call chain like this: calloc newWaffle WaffleVarnishORama.MainViewController.tableView(_:didSelectRowAt:) WaffleVarnishORama.MainViewController.tableView(_:didSelectRowAt:) and that should be enough to kick start your investigation. IMPORTANT The -why_live option only works if you dead strip your Mach-O image. This is the default for the Release build configuration, so use that for this test. Revision History 2025-07-18 Added the A higher-level alternative section. 2024-05-08 First posted.

Hi Support Team, I am new here. I am unable to add my fonts to the asset catalog there is no option to add new font set when I click the plus sign. When I drag my files in they show up as data. I have a Contents.json in the font folder called BeVietnamProFont.font. Is there something I am doing wrong? Thanks SO much! { "info": { "version": 1, "author": "xcode" }, "properties": {}, "fonts": [ { "filename": "BeVietnamPro-Black.ttf", "weight": "black", "style": "normal" }, { "filename": "BeVietnamPro-BlackItalic.ttf", "weight": "black", "style": "italic" }, { "filename": "BeVietnamPro-Bold.ttf", "weight": "bold", "style": "normal" }, { "filename": "BeVietnamPro-BoldItalic.ttf", "weight": "bold", "style": "italic" }, { "filename": "BeVietnamPro-ExtraBold.ttf", "weight": "heavy", "style": "normal" }, { "filename": "BeVietnamPro-ExtraBoldItalic.ttf", "weight": "heavy", "style": "italic" }, { "filename": "BeVietnamPro-ExtraLight.ttf", "weight": "ultralight", "style": "normal" }, { "filename": "BeVietnamPro-ExtraLightItalic.ttf", "weight": "ultralight", "style": "italic" }, { "filename": "BeVietnamPro-Light.ttf", "weight": "light", "style": "normal" }, { "filename": "BeVietnamPro-LightItalic.ttf", "weight": "light", "style": "italic" }, { "filename": "BeVietnamPro-Regular.ttf", "weight": "regular", "style": "normal" }, { "filename": "BeVietnamPro-Italic.ttf", "weight": "regular", "style": "italic" }, { "filename": "BeVietnamPro-Medium.ttf", "weight": "medium", "style": "normal" }, { "filename": "BeVietnamPro-MediumItalic.ttf", "weight": "medium", "style": "italic" }, { "filename": "BeVietnamPro-SemiBold.ttf", "weight": "semibold", "style": "normal" }, { "filename": "BeVietnamPro-SemiBoldItalic.ttf", "weight": "semibold", "style": "italic" }, { "filename": "BeVietnamPro-Thin.ttf", "weight": "thin", "style": "normal" }, { "filename": "BeVietnamPro-ThinItalic.ttf", "weight": "thin", "style": "italic" } ] } ![]("https://developer.apple.com/forums/content/attachment/56835f04-d1c1-468f-808b-9a786562d367" "title=Screenshot 2025-07-13 at 1.05.05 PM.png ;width=539;height=630")

We're having issues getting Sign in with Google to function on TestFlight (not experiencing these issues on iOS Browser) with user unable to be authorised and proceed to logged in screens of our app. Below are the three sign-in methods tested and the exact results for each. Button 1: Default Standard Google Sign-In button (Google JavaScript SDK) embedded in the frontend. Uses the normal OAuth browser redirect flow. Auth URL: https://accounts.google.com/o/oauth2/v2/auth?... Sometimes disallowed_useragent error. Other times a 400 invalid_request error. In most cases the callback is never triggered inside the wrapper. Appears that the wrapper does not retain cookies/session data from the external Google window. Button 2: Custom Custom button calling Google OAuth through our own redirect handler. Explicitly set a custom user-agent to bypass disallowed user agent logic. Later removed user-agent override entirely for testing. Added multiple ATS (App Transport Security) exceptions for Google domains. Added custom URL scheme to Info.plist for OAuth redirect. Changing the user-agent had no effect. ATS exceptions + scheme support verified and working. Redirect still fails to propagate tokens back to the WebView. In tests a few weeks ago we got to Google’s login page, but it never returned to the app with a valid code. Now we are consistently getting disallowed_useragent error. Button 3: Default Same as Button 1 however tested outside of Vue.js with just plain JavaScript. Added new Google domain exceptions and updated redirect URIs. Behaviour matches Button 1 Google account selection sometimes worked, however now consitently disallowed_useragent error Additional Technical Attempts User-Agent Modifications Set UA to standard desktop Chrome → no effect. Removed UA override → no effect. ATS / Domain / Scheme Configuration Added: accounts.google.com .googleusercontent.com *.googleapis.com

I am located in Taiwan and recently updated my Mac to the latest OS and installed the newest Xcode. However, I’m experiencing extremely slow download speeds when trying to add the iOS 26.2 Simulator Runtime (approx. 8GB) via Xcode > Settings > Platforms. It is currently downloading at a rate of only 500MB per hour, which is impractical. I have checked the official downloads page but couldn't find a standalone DMG link for this specific version. My questions are: Is there a direct download link (DMG) available on the Apple Developer portal for the iOS 26.2 Simulator? If no direct link exists, are there any recommended methods to accelerate the download? (e.g., using terminal commands or changing DNS settings). Any help or direct URLs would be greatly appreciated. Thank you!

Hello, We tried calling Apple support who suggested they cannot help and work thru emails and discussion forums to resolve the technical issue we are facing to post our first App in App Store. I have given admin level credential to my son (minor) allowing him to incorporate his Xcode to App Store with his credentials. Apparently, he keeps getting error he does not have enough credentials to do so and we are unable to proceed further. I acknowledge I am not a developer & Apple support team was unable to help, I wonder if there is specific support channel I need to follow to resolve the issue. His App is going to help is Robotics team in upcoming event and we appreciate if someone can kindly point me to right direction to resolve the matter at earliest.

I added an Apple Watch app target for an iOS app. If I install it directly through Xcode it runs, however it seems to be able to communicate with iphone through Watch Connectivity framework and once I close the app it seems to uninstall itself from the watch. When I installed the iphone app frist, the app does not show up on the available apps on the iphone Watch application, what could be the issue ? The iphone app was created using react native through expo. Testing Devices Iphone 13 pro max IOS 26.0.1 --- Apple Watch Series 4 WatchOS 10.6

I've created an installation package and it is failing to install on macOS 15.6. The package is, I believe, properly notarized, since it will install correctly on other macOS versions, including 15.5 The only clue I have is the output from installer: installer[8015] : Opened package is not the same at install time installer[8015] : Unable to use PK session due to incompatible packages. Terminating. installer[8015] : Install failed: The Installer could not install the software because there was no software found to install. The installer consists of a a single "component" package, and the outer "product" package. The component package is present, and I can successfully run installer manually to install it, so I don't think the component package is corrupt. Has anyone else encountered this? Are there any tools available to help me diagnose the issue? The logging is not helpful.

Hello, I was told from Developer engineers to post an Xcode issue on Feedback Assistant. It has been 6 weeks and I have yet to receive a single reply or acknowledgement on my feedback post. I would just like to at least get some sort of acknowledgement from Feedback Assistant that my post is being tracked or if a resolution is in work please. Here's the post: https://feedbackassistant.apple.com/feedback/21824703

Hello - I’m the Account Holder for an individual Apple Developer Program account. I’m working with freelance junior developers who are building my app in React Native mainly in TypeScript (.tsx) with some JavaScript, with code in GitHub. The app currently runs in Expo Go now. I’ve been directed to this forum for step-by-step guidance. Specifically I need clear, sequential instructions I can give my developers (and what I personally must do on my Mac) so they can produce a properly signed iOS build for TestFlight (internal testing), and Upload that build to App Store Connect and then submit the release to the App Store. Context: This is an individual developer account (not an organization). I am the only person with a Mac. I added them as developers but was told I need to be the one to upload the final build (is this true, and if so, what do they send me to do that, and when they send it to me, can you please tell me exactly what I need to do from there?) I was told about Swift Playground, possible SwiftUI conversion if needed, APK file, and using my Xcode for final submission, but not sure what to make of this that will get it on TestFlight from the current React Native. What I would like to ask for help with is a concise, step-by-step checklist (including exact menu names / commands or tools like EAS Submit, Transporter, or Xcode) of the developers' steps and my admin/account holder steps, so I can hand it to the developers and make sure nothing is missed to get on TestFlight. I’m on a tight timeline, so any clear, detailed guidance would be extremely appreciated. Thank you so much. I have looked everywhere and cannot find a step-by-step!

So I'm testing a microapp that is contained in an IPFS folder. I use a web3 website that is used to view NFTs and their IPFS files. The app has gyro controls, which are enabled through a confirmation gesture. In iOS 18.5, when I press "Request Permission" button I get the popup to allow the app to acess movement and orientation. In iOS26, pressing the button does nothing. Keep in mind that this only happens through the website, that uses iframes. When I load the IPFS file from a direct link, the popup appears with no issue. I think this might be because iOS26 uses WebGPU or it might be a bug since iOS26 is still in beta.

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.