Currently, if as a library author you are shipping dependencies as code, you can use the #if DEBUG preprocessor check to execute logic based on whether app is being built for Debug or Release. My concern is more about the approach that should be taken when distributing frameworks/xcframeworks. One approach I am thinking of using is checking the presence of {CFBundleName}.debug.dylib in the main bundle. Is this approach reliable? Do you suggest any other approach?

Hello, There seems to be a regression with macOS SDK 15 and dynamically loading libraries if Address Sanitizer is turned on. Seems to only affect Debug builds, and .frameworks. I've also reported this via the Feedback Assistant: FB16513866 Here's a minimal repro, if anyone is interested: https://gist.github.com/peter-esik/6b00432e411be85333e14ae7d953966e I thought I'd post this here, as according to my web searches, this isn't a very well-known bug at this point.

I want to create a dynamic library for my iOS project, which would be loaded at runtime. In Xcode, there are templates available for creating a static/dynamic lib for MacOS. But under the iOS tab, there is only a "static library" template. So, I used the "static library" template and in its build settings I changed the Mach-O type to "dynamic library". Now after building it, I use the file command on the generated file and it tells me it is a dynamic lib. But the generated file still has .a extension, which is usually for static libs. I'm aware we can tell Xcode in build settings to change the .a extension to something else, say .dylib but this seems like a hacky way to create a dynamic library. What is the correct way? I am aware that standalone dylibs are not supported on iOS, and we need to wrap them in a framework. For my use case, the framework will literally be a wrapper, it won't have any source files of its own. It should only contain the dynamic lib generated from some independent codebase. I am not sure how to place the dylib in the framework.

Hi everyone, I'm developing a visionOS application using Unity with an enterprise developer account. I applied for the Main Camera Access entitlement, but at the time of submission, the email address associated with my Apple ID was deactivated, so I couldn’t receive any email communication from Apple. Later, I updated the email address for my Apple ID. Now, in the Apple Developer portal under Identifiers, I can see that my app has been granted Main Camera Access, and I can also add the corresponding capability in Xcode. However, according to Apple’s documentation(https://developer.apple.com/documentation/visionos/building-spatial-experiences-for-business-apps-with-enterprise-apis): “To use entitlements, you need to include both the entitlement file and a corresponding license file in your app. After Apple approves your app for one or more entitlements, you receive a license file, along with additional instructions.” I never received this license file, possibly due to the deactivated email. I don't know where to find it or how to retrieve it now. What exactly is this license file? If it was originally sent to an unreachable email, how can I request it again or get it resent? Where in the Apple Developer portal (or elsewhere) can I access or download this file? Any help or guidance would be greatly appreciated! Thanks in advance.

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.

Hi, I’m currently developing a watchOS app and ran into an issue where I can’t enable Developer Mode on my Apple Watch. Device info: Apple Watch Series 9 (watchOS 10.4) Paired with iPhone 14 Pro (iOS 17.4.1) Xcode 15.3 (macOS 15.5, Apple Silicon) Issue: When I try to run the app on my physical watch device, Xcode prompts that Developer Mode needs to be enabled. However, there is no approval request on the Apple Watch, and no Developer Mode option appears under Settings → Privacy & Security. I’ve already tried the following: Rebooting both devices Unpairing and re-pairing the watch Erasing and setting up the watch again Signing out and back into my Apple ID Using the latest Xcode version (15.3 and 16.3 both tested) Running clean builds and checking provisioning profiles Attempting install via both simulator and physical device Still no luck — the app will not launch on the Apple Watch due to Developer Mode being disabled, and the option is missing entirely from Settings. I visited an Apple Store Genius Bar, but they couldn’t help and told me to contact Developer Support. I’ve already submitted a support request, but in the meantime I wanted to ask here in case anyone else has experienced this and found a workaround. Thanks in advance.

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.

Weirdness going on here. Our app is crashing on startup with iPad 7s running iOS 18.5. Before updating to iOS 18.5, it was working fine on iPad 7s. Even with iOS 18.5, it is working fine on every device we have tried including dozens of other iPads and iPhones. We have narrowed it down to the SquareReaderSDK. If we remove that SDK, it will launch and work without issues. But, many of our users need the SquareReaderSDK. The crash happens at app load, before appDelegate didFinishLaunchingWithOptions. So we can't figure out any way to debug the issue. Is anyone else having a similar issue? Square thinks it is an Apple issue.

In the availability and pricing section, we have reviewed the plans and we will be upgrading to 50 or 100 million calls/month but before we do, we have a couple questions. Does the API have rate limit or throttling? Do you have additional weather forecast endpoints like hail, radar, or pollen forecast? I see in this thread https://developer.apple.com/forums/thread/795642 that air quality is not available Thanks

I've got a large and complex app which has several dependencies upon 3rd party libraries (installed as pods). The app is structured according to Model-View-Controller design and there is a requirement to implement the Model part as an .xcframework so it can be included and used in the original app along with a few new apps. However, Apple documentation states that umbrella frameworks are not supported (Technical Note TN2435). The Model code has several dependencies which would be totally unfeasible to replace or remove, for example it uses RealmSwift for database storage. Obviously it would be impossible to write one's own database storage scheme in place of using Realm. However, if my framework uses Realm as a dependency, then its now become an umbrella framework. So therefore not supported according to Apple documentation. So what are options/solutions?

Hi guys! I have gone through an absolute nightmare, trying to solve the issue that I am about to tell you about. As the title says, I am getting the error: Library '/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/17/lib/darwin/libclang_rt.profile_driverkit.a' not found I trimmed off part of that directory as I did not want to reveal that information about my computer. From what I can tell, the file in question is no longer even a part of Xcode. I have searched, it is not on my computer anywhere. I have also downloaded older versions of Xcode to search with it. None of them have it. I have literally tried everything under the Son to solve this issue. I have been stuck on it for two days. I have even resorted to doing something I hate, which is asking for ChatGPT to assist me with solving the issue. No help there. I am at my wits end. So I am coming to you guys, have you seen this error? Any ideas at all? The odds are pretty good whatever you recommend I have probably already tried 200 times over. But I am still open to hearing anything. Have any of you had this error? Any ideas? I am on the latest version of macOS. The project is for a macOS app. M4 Mac mini. Any additional information I can provide, that will be helpful? At this point, I am leaning more towards this being a bug with Xcode than anything.

Hi, I am having an issue with xcodebuild -showdestinations command. Steps to reproduce: Create a new iOS application project in Xcode or use an existing one. Navigate to this project in a terminal. Run xcodebuild -project 'your-project-name.xcodeproj' -scheme 'your-scheme' -showdestinations What I expect: All destinations available in the Xcode UI should be listed. What I get: It depends. For new projects, I consistently get only generic platform destinations and my connected physical device. When I run the same command on an older project, I sometimes see all the expected destinations. It seems to be a roughly 50/50 chance between the two outcomes. Is there a way to get consistent results from xcodebuild -showdestinations? What can I do to ensure all destinations are listed reliably? Here is a more detailed log and a screenshot: ❯ xcodebuild -workspace 'WorkoutDiary.xcworkspace' -scheme 'WorkoutDiary' -showdestinations Command line invocation: /Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild -workspace WorkoutDiary.xcworkspace -scheme WorkoutDiary -showdestinations User defaults from command line: IDEPackageSupportUseBuiltinSCM = YES 2025-06-17 19:13:50.261 xcodebuild[34753:6177985] DVTDeviceOperation: Encountered a build number "" that is incompatible with DVTBuildVersion. 2025-06-17 19:13:50.342 xcodebuild[34753:6177959] [MT] DVTDeviceOperation: Encountered a build number "" that is incompatible with DVTBuildVersion. Resolve Package Graph Resolved source packages: <REDACTED> Available destinations for the "WorkoutDiary" scheme: { platform:macOS, arch:arm64, variant:Designed for [iPad,iPhone], id:<REDACTED>, name:My Mac } { platform:iOS, arch:arm64, id:<REDACTED>, name:<REDACTED> } { platform:iOS, id:dvtdevice-DVTiPhonePlaceholder-iphoneos:placeholder, name:Any iOS Device } { platform:iOS Simulator, id:dvtdevice-DVTiOSDeviceSimulatorPlaceholder-iphonesimulator:placeholder, name:Any iOS Simulator Device } ❯ xcodebuild -workspace 'WorkoutDiary.xcworkspace' -scheme 'WorkoutDiary' -showdestinations Command line invocation: /Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild -workspace WorkoutDiary.xcworkspace -scheme WorkoutDiary -showdestinations User defaults from command line: IDEPackageSupportUseBuiltinSCM = YES 2025-06-17 19:13:52.393 xcodebuild[34757:6178035] DVTDeviceOperation: Encountered a build number "" that is incompatible with DVTBuildVersion. 2025-06-17 19:13:52.472 xcodebuild[34757:6178020] [MT] DVTDeviceOperation: Encountered a build number "" that is incompatible with DVTBuildVersion. Resolve Package Graph Resolved source packages: <REDACTED> Available destinations for the "WorkoutDiary" scheme: { platform:macOS, arch:arm64, variant:Designed for [iPad,iPhone], id:<REDACTED>, name:My Mac } { platform:iOS, arch:arm64, id:<REDACTED>, name:<REDACTED> } { platform:iOS, id:dvtdevice-DVTiPhonePlaceholder-iphoneos:placeholder, name:Any iOS Device } { platform:iOS Simulator, id:dvtdevice-DVTiOSDeviceSimulatorPlaceholder-iphonesimulator:placeholder, name:Any iOS Simulator Device } { platform:iOS Simulator, id:DBFB9613-0261-4544-908A-335570F3C35F, OS:18.3.1, name:iPhone 11 } { platform:iOS Simulator, id:A48C309C-231A-4197-A295-900F89C94D86, OS:18.3.1, name:iPhone 16 Pro Max }

I created 2 iOS projects in Xcode: Project 1: 4 targets (main app + 3 app extensions) 4 static libraries the main app's target dependencies include - 3 app extensions and the 4 libs. the main app's binary is linked to all 4 libs similarly, each extension is linked to all 4 libs Project 2: 5 targets (main app + 3 app extensions + 1 framework) 4 static libraries the main app's target dependencies include - 3 app extensions and the framework each extension is dependent only on the framework the framework's target dependencies include all the 4 static libs As per my understanding, the app bundle size for Project 2 should be less than that of Project 1, since we eliminate duplicating the static libs for each target by using a framework instead. However, I have found that the bundle size is more for Project 2 as compared to the bundle size of project 1. I do not understand, why?

Has anyone here successfully set up macOS as a globally accessible, multiuser development server using native remote login (SSH) and VS Code Remote?

Background Assets can support a maximum of 200G. Will the Apple server perform file comparison? For example, file0 is included in both a.aar file and b.aar file. On the Apple server, does it occupy twice the size of a single file?

We have a .ipa file that we need to side load on iPhone via USB connected to a MAC. IPA file will be on MAC. We can't use enterprise license. We have a business use case where we need to side load the app. Any way to do that or can be reach apple support for this? Please help. Note: The iPhones attached will not have the Apple ID logged in. There are companies who are side loading the app for business purpose on the customers phone.

I have an Xcode project setup as follows: 3 static libraries 1 framework target, whose Mach-O type is set to Dynamic Library main app target (iOS app) The target dependencies are as follows: In framework's build phase [Link with libraries], I have the 3 libs statically linked. In the main app's build phase [Link with libraries], I have only the framework, which is dynamically linked. As per my understanding: The libs are statically linked to the framework. So, the framework binary would contain code from all the libs. The framework is dynamically linked to the main app (iOS app in this case). So, the main app's binary only has a reference to the framework's binary, which would be loaded in the memory at runtime. Assuming my understanding is correct, I'm stuck with the following problem: All 3 libs build successfully The framework builds successfully The main app target doesn't build. The compilation is successful, but the build fails with linker errors. Please let me know if I am doing something incorrectly, or if a configuration is missing. Below are more details: The linker gives the following error: Undefined symbols for architecture arm64: "StringUtils.GetStr() -> Swift.String", referenced from: dynamic_fw.AppDelegate.application(_: __C.UIApplication, didFinishLaunchingWithOptions: [__C.UIApplicationLaunchOptionsKey : Any]?) -> Swift.Bool in AppDelegate.o "TWUtils.GetNum() -> Swift.Int", referenced from: dynamic_fw.AppDelegate.application(_: __C.UIApplication, didFinishLaunchingWithOptions: [__C.UIApplicationLaunchOptionsKey : Any]?) -> Swift.Bool in AppDelegate.o ld: symbol(s) not found for architecture arm64 clang: error: linker command failed with exit code 1 (use -v to see invocation) And the command shown in the logs for linking phase is: Ld /Users/raunit.shrivastava/Library/Developer/Xcode/DerivedData/dynamic-fw-foqtqhpopkmoapfufzxbfloamnpr/Build/Products/Debug-iphonesimulator/dynamic-fw.app/dynamic-fw normal (in target 'dynamic-fw' from project 'dynamic-fw') cd /Users/raunit.shrivastava/Desktop/dynamic-fw /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -Xlinker -reproducible -target arm64-apple-ios17.5-simulator -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator17.5.sdk -O0 -L/Users/raunit.shrivastava/Library/Developer/Xcode/DerivedData/dynamic-fw-foqtqhpopkmoapfufzxbfloamnpr/Build/Intermediates.noindex/EagerLinkingTBDs/Debug-iphonesimulator -L/Users/raunit.shrivastava/Library/Developer/Xcode/DerivedData/dynamic-fw-foqtqhpopkmoapfufzxbfloamnpr/Build/Products/Debug-iphonesimulator -L. -L./StringUtils -L./TWFramework -L./TWUtils -L./dynamic-fw -F/Users/raunit.shrivastava/Library/Developer/Xcode/DerivedData/dynamic-fw-foqtqhpopkmoapfufzxbfloamnpr/Build/Intermediates.noindex/EagerLinkingTBDs/Debug-iphonesimulator -F/Users/raunit.shrivastava/Library/Developer/Xcode/DerivedData/dynamic-fw-foqtqhpopkmoapfufzxbfloamnpr/Build/Products/Debug-iphonesimulator -F. -F./StringUtils -F./TWFramework -F./TWUtils -F./dynamic-fw -filelist /Users/raunit.shrivastava/Library/Developer/Xcode/DerivedData/dynamic-fw-foqtqhpopkmoapfufzxbfloamnpr/Build/Intermediates.noindex/dynamic-fw.build/Debug-iphonesimulator/dynamic-fw.build/Objects-normal/arm64/dynamic-fw.LinkFileList -Xlinker -rpath -Xlinker @executable_path/Frameworks -Xlinker -rpath -Xlinker ./\*\* -dead_strip -Xlinker -object_path_lto -Xlinker /Users/raunit.shrivastava/Library/Developer/Xcode/DerivedData/dynamic-fw-foqtqhpopkmoapfufzxbfloamnpr/Build/Intermediates.noindex/dynamic-fw.build/Debug-iphonesimulator/dynamic-fw.build/Objects-normal/arm64/dynamic-fw_lto.o -Xlinker -export_dynamic -Xlinker -no_deduplicate -Xlinker -objc_abi_version -Xlinker 2 -fobjc-link-runtime -L/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/iphonesimulator -L/usr/lib/swift -Xlinker -add_ast_path -Xlinker /Users/raunit.shrivastava/Library/Developer/Xcode/DerivedData/dynamic-fw-foqtqhpopkmoapfufzxbfloamnpr/Build/Intermediates.noindex/dynamic-fw.build/Debug-iphonesimulator/dynamic-fw.build/Objects-normal/arm64/dynamic_fw.swiftmodule -Xlinker -sectcreate -Xlinker __TEXT -Xlinker __entitlements -Xlinker /Users/raunit.shrivastava/Library/Developer/Xcode/DerivedData/dynamic-fw-foqtqhpopkmoapfufzxbfloamnpr/Build/Intermediates.noindex/dynamic-fw.build/Debug-iphonesimulator/dynamic-fw.build/dynamic-fw.app-Simulated.xcent -Xlinker -sectcreate -Xlinker __TEXT -Xlinker __ents_der -Xlinker /Users/raunit.shrivastava/Library/Developer/Xcode/DerivedData/dynamic-fw-foqtqhpopkmoapfufzxbfloamnpr/Build/Intermediates.noindex/dynamic-fw.build/Debug-iphonesimulator/dynamic-fw.build/dynamic-fw.app-Simulated.xcent.der -framework TWFramework -Xlinker -no_adhoc_codesign -Xlinker -dependency_info -Xlinker /Users/raunit.shrivastava/Library/Developer/Xcode/DerivedData/dynamic-fw-foqtqhpopkmoapfufzxbfloamnpr/Build/Intermediates.noindex/dynamic-fw.build/Debug-iphonesimulator/dynamic-fw.build/Objects-normal/arm64/dynamic-fw_dependency_info.dat -o /Users/raunit.shrivastava/Library/Developer/Xcode/DerivedData/dynamic-fw-foqtqhpopkmoapfufzxbfloamnpr/Build/Products/Debug-iphonesimulator/dynamic-fw.app/dynamic-fw

Hello, I have an iphone but not an ipad Actually a relative has an iPad. The problem I encoutered was when i was testing an app that I had built prior (so I had the ipa file) but no acces to Xcode. The thing is when I wanted to test it on my iphone, everything WENT SMOOTH and ok. When I tried on iPAD, I encounteed the problem I could not unlock the hidden "developer mode" option in any way, I tried so many things, checked and rechecked, the option was and stayed hidden, I could not activate it. Therefore I could not test the app. In the apple store I was required to give a screenshot for iPAD but that failed. because I could not produce ANY, since I could not run my app on iPAD. I actually have no idea how I activated the ability to turn on the developer mode on my iphone, it was just there and I activated it perhaps because I had added the email of my iphone to the developer account somehow? somehwere? But for iPAD I just could not find a way to do it, don't know if adding it somewhere could trigger something on the ipad to allow it to show the developer mode option so I can activate it finally? Anyway, I tried things I read on internet, methods that mention how to activate the developer mode ability on an ios devide though WINDOWS, there were 2 but one I did not trust much, and even I think i tried it and in the end it did not work for some incompatibility making that method obsolete or something? the other I am not sure but probably same idea. I would like to know, how to activate the ABILITY to SHOW the option to activate the developer mode on iPAD (or any other device but for now I am focuson on iPad) please, and without using macbook or xcode!? Could Apple or anyone offer some guidance? That would help a fellow developer. Thank you. Ps. No I cant get the mac or xcode for now (but hopefully in a far future, but for now I can't). Thanks

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.

Title basically explains what my issue is, from what I understand the only way to set an icon in an tauri app is using a icns file, I could be wrong but I don't know how to get macos theme changing stuff to work with it because of the icns file.