Apologies if this isn't tagged right but dev tools and services seemed the most appropriate since this is related to the workbench Ad Tester tool. I'm seeing a behavior where the preview link is not being generated. Specifically, I am seeing a POST request to the following URL consistently fail: https://iadworkbench.apple.com/adtester/api/v1/ads/previewLink?orgId=1127861 Variations/scenarios I have tried so far: All possible ad format choices on all possible devices All options for the placement type Both third party and uploaded creative sources Uploaded creative sources appear to be failing to upload as well A simple div with a "hello world" content fails as a third party creative source Multiple apple accounts I created a new account specifically to test if my primary apple ID was experiencing issues with this Multiple browsers I have tried multiple versions of Chrome/Firefox/Safari I tested with and without browser extensions to determine whether an extension was interfering or not Clearing session/local storage along with cookies I also created new profiles in browsers to verify that I was getting a fresh browser environment In all of these cases, the API request to generate a preview link is consistently failing with a 500 error code. It's worth noting that the web preview option works, but this isn't a truly accurate test environment and can't be solely relied on when testing ad content. I don't know exactly when this started happening as I have not used it in the last couple of weeks but I have used the workbench ad tester extensively in the past the same way I have been trying with my current test without issue. That coupled with the fact that the request for the preview link consistently fails in all of the test scenarios I've outlined above leads me to believe there is a problem with the API that is responsible for generating the preview links.

The target was chosen as IPhone and IPad. I can also run this build on my IPad. The info.plist content of all our other applications is the same and there were no problems until today. I don't understand why it is being rejected now.

Was working ok, then after my latest attempt at submitting a .PKG it crashes right after displaying the list of previous submitted things. This make it impossible to make progress with my project, unless there's another way of getting it to TestFlight (not using Xcode). Transporter 1.3.2 on Intel Mac Sequoia 15.0

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.

The app I'm working on has iOS 16.0 as target. Recently Live Activities support was added, but then it started crashing when running on iOS 16.0 devices. After some investigation, I've found that the culprit was the presence of NSUserActivityTypeLiveActivity and WidgetCenter.UserInfoKey.activityID, even though they were inside an @available(iOS 17.2, *) block. If I comment these two variables, the app work as expected. I've also tried adding #if canImport(ActivityKit) around the code, but without success. But if the @available isn't working, how can I prevent this? It looks like a bug, since the documentation says that NSUserActivityTypeLiveActivity is supported but iOS 14.0+, but I'm pretty sure it was introduced on 16.1. This is the only output I get with the crash: dyld[66888]: Symbol not found: _$s9WidgetKit0A6CenterC11UserInfoKeyV10activityIDSSvgZ Referenced from: <D6EFF120-2681-34C1-B261-8F3F7B388238> /Users/<redacted>/Library/Developer/CoreSimulator/Devices/8B5B4DC9-3D54-4C91-8C88-E705E851CA0F/data/Containers/Bundle/Application/DB6671FF-CB07-4570-BD63-C851D94FAF29/<redacted>.app/<redacted>.debug.dylib Expected in: <C5E72BB5-533F-3658-A987-E849888F4DFC> /Library/Developer/CoreSimulator/Volumes/iOS_20A360/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 16.0.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks/WidgetKit.framework/WidgetKit

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!

Why as an IDE, many developers want to use the functions are not available, such as code formatting, if the function is not available, why not even a plug-in center, I have been using IDEA for code development, with Xcode development, feel very inconvenient to use

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")

開発アプリで通知確認を行うため、UDIDをプロビジョニングプロファイルに追加する必要があります。 iPhoneのUDIDは取得することができたのですが、AppleWatchのUDIDを取得する方法が分かりません。 Xcodeと接続してUDIDを取得しようとしましたが、iPhoneのみ認識がされAppleWatchが認識されていません。 AppleWatchもデベロッパモードをONしなければならないとAppleから返答をもらったが、その方法がわからないのでどなたかご教授お願い致します。

I cannot find this specific KDK for my build 22H417. I need help locating and downloading this Developer Kit. Error Domain=KMErrorDomain Code=34 "Missing Developer Kit: As of macOS 13.0, you will need to install a KDK matching your build 22H417 to rebuild kernel collections." UserInfo={NSLocalizedDescription=Missing Developer Kit: As of macOS 13.0, you will need to install a KDK matching your build 22H417 to rebuild kernel collections.} I

Hello, According to documentation, the App Store does not re-download the entire app when updating, but instead generates an update package containing only the changed content compared to the previous version. I’d like to clarify the following points: 1. Granularity of file changes If only part of a large file changes, does the update package include the entire file, or does it patch only the modified portions within that file? 2. Guideline on separating files The documentation recommends separating files that are likely to change from those that are not. How should this be interpreted in practice? 3. Verifying the diff result Is there a way for developers to check the actual diff result of the update package generated by the App Store without submitting the app? Is there a diff command tool or comparison method closer to the actual App Store update process? 4. Estimating update size during development For apps with large-scale resources, minimizing update size is critical. Are there any tools or best practices to estimate the size of the update package before submitting to the App Store? Any clarification or reference materials would be greatly appreciated. Thank you.

Production build on eas failing for a couple of days. Submitted a request for information day before yesterday, but I was wondering if anyone else has been having this problem. I will post any update from Apple if/when I get it.

I have an issue when i use external tester with a public link and emails. Test fly is well installed but when i have to open the app, it just charge as seen in the screen.

在Mac OS 15.2 使用 Xcode 16.2 构建项目时，我遇到了以下错误： Showing All Errors Only Prepare packages Prepare build Build service could not create build operation: unable to load transferred PIF: The workspace contains multiple references with the same GUID 'PACKAGE:1Y9CU7L2QFO7OX4UJBYP19ZPPL5MJNV3R::MAINGROUP' Activity Log Complete 2024/12/24, 15:26 0.2 seconds

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 am developing an iOS in-app SDK for collecting code coverage data. The SDK writes coverage data to a specified file by calling __llvm_profile_set_filename and __llvm_profile_write_file. This implementation worked correctly until I switched to Xcode 26.0 to build my project. Now, when __llvm_profile_write_file() is executed, it crashes with the following error stack. Can anyone provide any assistance? Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000001 Exception Codes: 0x0000000000000001, 0x0000000000000001 Termination Reason: Namespace SIGNAL, Code 11, Segmentation fault: 11 Terminating Process: exc handler [454] Thread 96 name: Dispatch queue: com.test-coverage.processing Thread 96: Crashed: 0 Demo 0x122602ea8 initializeValueProfRuntimeRecord (in Demo) (InstrProfilingValue.c:351) 1 Demo 0x00000001226064c0 writeOneValueProfData (in Demo) (InstrProfilingWriter.c:153) 2 Demo 0x0000000122606308 writeValueProfData (in Demo) (InstrProfilingWriter.c:234) 3 Demo 0x00000001226060d0 lprofWriteDataImpl (in Demo) (InstrProfilingWriter.c:401) 4 Demo 0x0000000122605d98 lprofWriteData (in Demo) (InstrProfilingWriter.c:261) 5 Demo 0x0000000122604804 writeFile (in Demo) (InstrProfilingFile.c:536) 6 Demo 0x122604664 __llvm_profile_write_file_alias + 228 7 Demo 0x000000011c6dd108 -[BDTestCoverage p_dumpMainCoverageInfoWithCustomKey:] (in Demo) (TestCoverage.m:995) 8 Demo 0x000000011c6dcef8 -[BDTestCoverage p_dumpAllCoverageProfileWithCustomKey:] (in Demo) (TestCoverage.m:970)

I have an xCode project called Vision + CoreML I wanted add some charts into it so I started installing cocoapad for the first time I followed all the steps from installing the latest ruby version to running pod install The critical .xcworkspace had been never created no matter how many times pod install was run. It is nowhere to be found. Could anyone advise me on what went wrong here? Here are some files used to generate Podfile platform :ios, '15.0' target 'Vision + CoreML' do use_frameworks! # Comment the next line if you don't want to use dynamic frameworks pod 'Alamofire', '~> 5.6' # Pods for Vision + CoreML pod 'Charts' end and here is the command prompt output ls MacBook-Pro-3:NotAbgabe myusername$ ls App Main View Configuration Models Documentation Podfile Extensions README.md Image Predictor Vision+Core-ML.xcodeproj LICENSE I ran all the commands under the NotAbgabe folder. Not sure if xcworkspace is hidden somewhere between the files

Hi! Do the consoles in the App Store Connect differ by country? In particular, there are mentions on the Internet that in China the publisher can make refunds to users, but there is no such function in the American account.

I am integrating On Demand Resources into my Unity game. The resources install without any problems if the internet connection is stable: all resources are installed. While testing various scenarios without an internet connection, I encountered the following problem: if I turn off the internet during installation, I don't get any error messages, but if I turn the internet back on, the download no longer continues (and I still don't get an error). If I reopen the application with a stable internet connection, the download will always be at 0%. Please tell me what I am doing wrong. #import "Foundation/Foundation.h" #if ENABLE_IOS_ON_DEMAND_RESOURCES #import "Foundation/NSBundle.h" #endif #include <string.h> struct CustomOnDemandResourcesRequestData; typedef void (*CustomOnDemandResourcesRequestCompleteHandler)(struct CustomOnDemandResourcesRequestData* handler, const char* error); #if ENABLE_IOS_ON_DEMAND_RESOURCES struct CustomOnDemandResourcesRequestData { NSBundleResourceRequest* request; }; extern "C" CustomOnDemandResourcesRequestData* CustomOnDemandResourcesCreateRequest(const char* const* tags, int tagCount, CustomOnDemandResourcesRequestCompleteHandler handler) { NSMutableArray* tagArray = [NSMutableArray array]; for (int i = 0; i < tagCount; i++) { const char* tag = tags[i]; if (tag != NULL) { [tagArray addObject:[NSString stringWithUTF8String:tag]]; } } NSSet* tagSet = [NSSet setWithArray:tagArray]; CustomOnDemandResourcesRequestData* data = new CustomOnDemandResourcesRequestData(); data->request = [[NSBundleResourceRequest alloc] initWithTags:tagSet]; [data->request beginAccessingResourcesWithCompletionHandler:^(NSError* error) { dispatch_async(dispatch_get_main_queue(), ^{ const char* errorMessage = error ? [[error localizedDescription] UTF8String] : NULL; handler(data, errorMessage); }); }]; return data; } extern "C" void CustomOnDemandResourcesRelease(CustomOnDemandResourcesRequestData* data) { [data->request endAccessingResources]; delete data; } extern "C" float CustomOnDemandResourcesGetProgress(CustomOnDemandResourcesRequestData* data) { return data->request.progress.fractionCompleted; } extern "C" float CustomOnDemandResourcesGetLoadingPriority(CustomOnDemandResourcesRequestData* data) { float priority = (float)data->request.loadingPriority; return priority; } extern "C" void CustomOnDemandResourcesSetLoadingPriority(CustomOnDemandResourcesRequestData* data, float priority) { if (priority < 0.0f) priority = 0.0f; if (priority > 1.0f) data->request.loadingPriority = NSBundleResourceRequestLoadingPriorityUrgent; else data->request.loadingPriority = (double)priority; } extern "C" const char* CustomOnDemandResourcesGetResourcePath(CustomOnDemandResourcesRequestData * data, const char* resource) { NSString* resourceStr = [NSString stringWithUTF8String: resource]; NSString* path = [[data->request bundle] pathForResource: resourceStr ofType: nil]; if (path == nil) { return NULL; // или другое значение по умолчанию } const char* result = strdup([path UTF8String]); // копируем строку return result; // в C# нужно будет освободить память } extern "C" void CustomOnDemandResourcesFreeString(const char* str) { free((void*)str); } #else // ENABLE_IOS_ON_DEMAND_RESOURCES struct CustomOnDemandResourcesRequestData { }; extern "C" CustomOnDemandResourcesRequestData* CustomOnDemandResourcesCreateRequest(const char* const* tags, int tagCount, CustomOnDemandResourcesRequestCompleteHandler handler) { CustomOnDemandResourcesRequestData* data = new CustomOnDemandResourcesRequestData(); if (handler) handler(handlerData, NULL); return data; } extern "C" void CustomOnDemandResourcesRelease(CustomOnDemandResourcesRequestData* data) { delete data; } extern "C" float CustomOnDemandResourcesGetProgress(CustomOnDemandResourcesRequestData* data) { return 0.0f; } extern "C" float CustomOnDemandResourcesGetLoadingPriority(CustomOnDemandResourcesRequestData* data) { return 0.0f; } extern "C" void CustomOnDemandResourcesSetLoadingPriority(CustomOnDemandResourcesRequestData* data, float priority) { } extern "C" const char* CustomOnDemandResourcesGetResourcePath(CustomOnDemandResourcesRequestData * data, const char* resource) { return NULL; } extern "C" void CustomOnDemandResourcesFreeString(const char* str) { } #endif // ENABLE_IOS_ON_DEMAND_RESOURCES

Hi, I’m having trouble installing GPT 1.1 on macOS Sequoia 15.3.1 using Xcode Command Line Tools 16.0. I downloaded Evaluation Environment for Windows Games 2.1, mounted the image, and opened the README file. Then, I followed Option 2 to build the environment from scratch: Set up your development and Homebrew environment Ensure you are using Command Line Tools for Xcode 15.1. You can download this older version from: https://developer.apple.com/downloads Note: There is a header file layout change that prevents using newer versions of the macOS SDK. softwareupdate --install-rosetta arch -x86_64 zsh /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" which brew brew tap apple/apple http://github.com/apple/homebrew-apple brew -v install apple/apple/game-porting-toolkit At first, I noticed that I needed to use CLT 15.1, which is not supported on later macOS versions (including mine). Even when I tried using 15.3 (which is somehow supported), I received a message stating that I needed CLT v16.0 or higher to install GPT. After following all the steps and waiting for the installation to complete, I got the following error: ==> Installing apple/apple/game-porting-toolkit ==> Staging /Users/tycjanfalana/Library/Caches/Homebrew/downloads/7baed2a6fd34b4a641db7d1ea1e380ccb2f457bb24cd8043c428b6c10ea22932--crossover-sources-22.1.1.tar.gz in /private/tmp/game-porting-toolkit-20250316-15122-yxo3un ==> Patching ==> /private/tmp/game-porting-toolkit-20250316-15122-yxo3un/wine/configure --prefix=/usr/local/Cellar/game-porting-toolkit/1.1 --disable-win16 --disable-tests --without-x --without-pulse --without-dbus --without-inotify --without-alsa --without-capi --without-oss --without-udev --without-krb5 --enable-win64 --with-gnutls --with-freetype --with-gstreamer CC=/usr/local/opt/game-porting-toolkit-compiler/bin/clang CXX=/usr/local/opt/game-porting-toolkit-compiler/bin/clang++ checking build system type... x86_64-apple-darwin24.3.0 checking host system type... x86_64-apple-darwin24.3.0 checking whether make sets $(MAKE)... yes checking for gcc... /usr/local/opt/game-porting-toolkit-compiler/bin/clang checking whether the C compiler works... no configure: error: in `/private/tmp/game-porting-toolkit-20250316-15122-yxo3un/wine64-build': configure: error: C compiler cannot create executables See `config.log' for more details ==> Formula Tap: apple/apple Path: /usr/local/Homebrew/Library/Taps/apple/homebrew-apple/Formula/game-porting-toolkit.rb ==> Configuration HOMEBREW_VERSION: 4.4.24 ORIGIN: https://github.com/Homebrew/brew HOMEBREW_PREFIX: /usr/local Homebrew Ruby: 3.3.7 => /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/3.3.7/bin/ruby CPU: 14-core 64-bit westmere Clang: 16.0.0 build 1600 Git: 2.39.5 => /Library/Developer/CommandLineTools/usr/bin/git Curl: 8.7.1 => /usr/bin/curl macOS: 15.3.1-x86_64 CLT: 16.0.0.0.1.1724870825 Xcode: N/A Rosetta 2: true ==> ENV HOMEBREW_CC: clang HOMEBREW_CXX: clang++ CFLAGS: [..] Error: apple/apple/game-porting-toolkit 1.1 did not build Logs: /Users/xyz/Library/Logs/Homebrew/game-porting-toolkit/00.options.out /Users/xyz/Library/Logs/Homebrew/game-porting-toolkit/01.configure /Users/xyz/Library/Logs/Homebrew/game-porting-toolkit/01.configure.cc /Users/xyz/Library/Logs/Homebrew/game-porting-toolkit/wine64-build If reporting this issue, please do so to (not Homebrew/brew or Homebrew/homebrew-core): apple/apple In config.log, I found this: configure:4672: checking for gcc configure:4704: result: /usr/local/opt/game-porting-toolkit-compiler/bin/clang configure:5057: checking for C compiler version configure:5066: /usr/local/opt/game-porting-toolkit-compiler/bin/clang --version >&5 clang version 8.0.0 Target: x86_64-apple-darwin24.3.0 Thread model: posix InstalledDir: /usr/local/opt/game-porting-toolkit-compiler/bin configure:5077: $? = 0 configure:5066: /usr/local/opt/game-porting-toolkit-compiler/bin/clang -v >&5 clang version 8.0.0 Target: x86_64-apple-darwin24.3.0 Thread model: posix InstalledDir: /usr/local/opt/game-porting-toolkit-compiler/bin configure:5077: $? = 0 configure:5066: /usr/local/opt/game-porting-toolkit-compiler/bin/clang -V >&5 clang-8: error: argument to '-V' is missing (expected 1 value) clang-8: error: no input files configure:5077: $? = 1 configure:5066: /usr/local/opt/game-porting-toolkit-compiler/bin/clang -qversion >&5 clang-8: error: unknown argument '-qversion', did you mean '--version'? clang-8: error: no input files configure:5077: $? = 1 configure:5066: /usr/local/opt/game-porting-toolkit-compiler/bin/clang -version >&5 clang-8: error: unknown argument '-version', did you mean '--version'? clang-8: error: no input files configure:5077: $? = 1 configure:5097: checking whether the C compiler works configure:5119: /usr/local/opt/game-porting-toolkit-compiler/bin/clang [...] dyld[15547]: Symbol not found: _lto_codegen_debug_options_array Referenced from: <E33DCAC4-3116-3019-8003-432FB3E66FB4> /Library/Developer/CommandLineTools/usr/bin/ld Expected in: <43F5C676-DE37-3F0E-93E1-BF793091141E> /usr/local/Cellar/game-porting-toolkit-compiler/0.1/lib/libLTO.dylib clang-8: error: unable to execute command: Abort trap: 6 clang-8: error: linker command failed due to signal (use -v to see invocation) configure:5123: $? = 254 configure:5163: result: no configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "Wine" | #define PACKAGE_TARNAME "wine" | #define PACKAGE_VERSION "7.7" | #define PACKAGE_STRING "Wine 7.7" | #define PACKAGE_BUGREPORT "" | #define PACKAGE_URL "" | /* end confdefs.h. */ | | int | main (void) | { | | ; | return 0; | } configure:5168: error: in `/private/tmp/game-porting-toolkit-20250316-15122-yxo3un/wine64-build': configure:5170: error: C compiler cannot create executables See `config.log` for more details Does anyone have any ideas on how to fix this?