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 received this message when trying to submit a build using Rork.com. Can anyone tell me what this is and how to fix it? There is a problem with the request entity - You are not allowed to create 'iOS' profile with App ID 'XXXXXXXX'. ✖ Failed to create Apple provisioning profile Error: build command failed.

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.

Hi everyone. I’m working on an iOS app that uses Firebase Cloud Messaging (FCM) to send push notifications. I’m encountering an issue when trying to send notifications either from Firebase Functions or directly using the FCM token with the Firebase Admin SDK and REST API. Error Message: FirebaseMessagingError: Auth error from APNS or Web Push Service code: 'messaging/third-party-auth-error' message: 'Auth error from APNS or Web Push Service' What I’ve Set Up: iOS App Registered in Firebase Bundle ID: Kilovative-Designs.ParkAware APNs Key downloaded from Apple Developer Portal Team ID and Key ID correctly entered in Firebase Console Firebase Admin SDK Service Account setup and used for sending Device is successfully receiving FCM tokens Subscribed to topics and calling Messaging.messaging().subscribe(toTopic:) works Using firebase-admin to send FCM messages via sendToDevice or sendToTopic What I’ve Tried: Tested push via firebase-admin in Node.js (got same APNs auth error) Tested with both topic-based and direct token-based push Confirmed the .p8 key is uploaded in Firebase, with correct Key ID and Team ID Tried generating a new APNs Auth Key Firebase Admin SDK is initialized with the correct service account Using Node.js firebase-admin with a known good FCM token, and sending this payload: { notification: { title: "Test Notification", body: "This is a direct FCM test" }, token: "cxleOwi73EhFh9C5_V4hED:APA91bE3W..." } Returns: FirebaseMessagingError: Auth error from APNS or Web Push Service Questions: Are there known conditions under which Firebase throws this error even if the APNs Auth Key is present? Does the Bundle ID need to start with com. in the Apple Developer Portal and Firebase for APNs authentication to work? Could this be a certificate or provisioning profile mismatch issue (even when using a .p8 key)? Is there a way to manually validate APNs authentication from Firebase outside of actual push delivery? Any insight or guidance would be incredibly helpful. I’m new to developing and have tried repeated efforts to fix this issue but still haven’t resolved it. 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.

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

I’m developing an app that uses Family Controls to block other apps. I’ve already received approval from Apple for the entitlement, and everything works perfectly when I run the app from Xcode on a physical device. However, when I upload the same build to TestFlight, the app installs and runs, but the Family Controls functionality doesn’t work — it seems like the entitlement isn’t being applied in the TestFlight version. So I’d like to ask: 👉 Do Family Controls entitlements work automatically on TestFlight builds, or is there any additional step required to enable them?

i have been added to an apple membership organization, and given App manager's rights b ut my build keeps failing and asking me to get more access

Merhaba, iOS üzerinde bir sözleşme onay uygulaması geliştiriyorum. Kullanıcıların dijital ortamda sözleşmeleri okuyup onaylaması gerekiyor. Ancak hukuki geçerlilik konusunda bazı tereddütlerim vardı. Bursa’da yaşayan biri olarak bu konuda bir avukata danışmam gerekti. Şans eseri https://www.avukatcanata.com ile karşılaştım ve hem bireysel hem ticari sözleşmeler konusunda gerçekten çok net açıklamalar sundular. Özellikle elektronik imza ve KVKK uyumu hakkında verdikleri bilgiler sayesinde projemi yasal zemine oturtabildim. Eğer bu tarz uygulamalar geliştiriyorsanız, mutlaka bir hukukçu görüşü alın. Yanlış bir adım size veya kullanıcınıza ciddi sonuçlar doğurabilir. Teşekkürler 🍏

If an iOS app gets terminated by watchdog due to, for example, hanging the main thread, is that considered to be a crash or something different. I'm asking because, according to google and AI, Crashlytics can detect and report these,but in my experience it does not. If I deliberately cause a watchdog termination by for example sleeping on the main thread for a long time then these never appear in Crashlytics. I know Apple folks here don't comment on non Apple software, so I'm not asking about Crashlytics, just wondering and interested about watchdog timeout terminations and how they differ from a "regular" crash.

I admit I am doing something unusual, and I would not be surprised if it didn't work. I am surprised, however, because after performing the equivalent operations on four bundles, all of the bundles work fine on macOS 15.6.1, but only two of them work on macOS 26.1 (beta 2). I don't know what causes the different outcomes. What I am trying to do is get Java to pass the macOS 26 AppKit UI SDK linkage checking without having to rebuild the JDK using Xcode 26. Rebuilding works for the latest SDK, but it is very inconvenient and may not work for older JDKs. It usually takes a while before the JDK build team successfully transitions to a new Xcode release. My approach is to use vtool to update the sdk version in the LC_BUILD_VERSION load command of $JAVA_HOME/bin/java, which is the launching executable for the JDK. I performed this operation on four JDKs: 25, 21, 17, and 11. (I ran vtool on macOS 15.) It was completely successful on JDK 25 and 21. The JDK launches correctly on macOS 15 and macOS 26. On macOS 26, AppKit uses the new UI, which is the desired outcome. The JDK runs despite that fact that I signed the modified $JAVA_HOME/bin/java with my developer ID, which is inconsistent with the JDK bundle signature. (Redoing the bundle signing is part of the JDK build process; if that were necessary, I would stick with rebuilding the JDK.) The operation was not successful on JDK 17 and 11. I noticed two problems, which are not obviously related. When vtool created the new version of the java program, it lost the tool definition. $ vtool -show-build-version java java: Load command 10 cmd LC_BUILD_VERSION cmdsize 32 platform MACOS minos 11.0 sdk 11.1 ntools 1 tool LD version 609.8 $ vtool -set-build-version 1 10.0 26.0 -output a.out java /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/vtool warning: code signature will be invalid for a.out $ vtool -show-build-version a.out a.out: Load command 22 cmd LC_BUILD_VERSION cmdsize 24 platform MACOS minos 10.0 sdk 26.0 ntools 0 Adding back the tool definition didn't seem to matter. When I try to run the revised executable (in the context of the JDK bundle), it works on macOS 15, but on macOS 26, it is rejected as damaged. If I run the revised executable outside the JDK bundle, it runs (but fails because it can't find the rest of the JDK, which is expected). In all cases, GateKeeper rejects the revised executable because it has not been notarized, but that doesn't seem to stop the program from executing.

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

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

Just recently, any pkg file that I create with pkgbuild will install the Payload's application as a zero-byte file in the /Applications directory. This has been working for years without issue for me. Here are the commands I am using with company specific items replaced: pkgbuild --analyze --root MyApplicationRootDirectory standalone.plist plutil -replace BundleIsRelocatable -bool NO standalone.plist pkgbuild --identifier MyIdentifier --version 1.0 --install-location /Applications --root MyApplicationRootDirectory --component-plist standalone.plist --sign 'Developer ID Installer: MyCompany (MySignId)' --timestamp installer.pkg Any ideas on what could be causing the issue? I have verified the following: The application being added to the pkg is both signed and notarized using the correct Developer ID Application certificate. The resultant pkg file is both signed and notarized using the Developer ID Installer certificate. Verified the pkg contents using "pkgutil --expand" to dump the contents. Verified the pkg's Payload contents by extracting the data using "cat Payload | gunzip | cpio -1". This results in an application file that is a binary match for file added in the "pkgbuild --root" argument. My application is the only file within the directory passed to the "pkgbuild --root" argument. There are no warnings in the System Settings / Privacy & Security Panel when running the package installer. I have a valid Mac Developer account. I am building the application and the pkg file on the same computer. Thank you for any insight.

I have two feedbacks now where I’ve been requested additional info, and provided it, but the feedback still has an “unread” dot, and is still in the “Requests” folder. I’ve asked multiple times to clear this status in one of those feedbacks (FB14888965), but got no response. Not the end of the world as long as the engineers are notified, but iirc the dot would disappear as soon as I replied.

After combing the forums and release nodes, here are some extra notes to help other developers using Apple-Hosted Background Assets. I don't promise I got this perfect, but it may help direct you. AssetPack.Status is an OptionSet (not an enum!) - Critical API detail missing from guide It's a bitmask where values can be combined 2⁰ (1) = available to download 2¹ (2) = update available 2² (4) = up to date 2⁶ (64) = downloaded Example: status value 69 = 0b1000101 = available + up to date + downloaded Use .contains() method to check specific flags AssetPack.version property - Undocumented feature Auto-assigned by App Store Connect for Apple-hosted packs Increments with each upload of same asset pack ID No file deduplication across asset packs Same file in two packs = counts twice toward 200GB limit Best practice: create separate pack for shared files Shared namespace path requirements Asset pack ID is NOT part of file path Each file must have unique relative path across ALL app's asset packs Example: Foo/10/239/414.png and Bar/10/239/414.png are distinct and won't collide Additional url(for:) bugs beyond iOS 26.1 fix iOS 26 Beta 5: "item with same name already exists" error Workaround: Request URL for directory, then manually append filename TestFlight-only availability - Major limitation not mentioned! Apple-hosted packs currently ONLY work for internal testers on TestFlight or from App Store. Won't work from Xcode until "later this year" HTTP 400 errors expected for non-TestFlight installs ba-serve port workaround URL override port bug exists on multiple device types Use ba-serve -p 443 instead of custom ports

I try to distribute my App again, but receive now the error that the Minimum IOS is not supported by Info.plist with Runner. i have latest XCode and the error stays whatever IOS I Set in General and in the building rules. Any one has an idea or had same issue since recent Xcode / project Updates ? thanks so much

I'm on Mac Studio with Apple M1 Max and I recently upgrated to Sequoia 15.4. After that, Docker won't run anymore. I tried almost all proposed solutions on the web to make Docker to work with Sequoia 15.4 (e.g. workaround at GitHub), without success. Because of this, now I'm stuck in all of my development activities. For example, I cannot develop and deploy anymore my projects and applications. What can I make to solve that?

Calling dlopen then dlclose causes an increase in the amount of memory used by the program. If I create a loop that calls dlopen / dlclose repeatedly on the same dynamic library, memory usage increases continuously. Is this a bug, or am I using dlopen / dlclose incorrectly? I can reproduce this by modifying the sample code in the Apple Developer docs Creating Dynamic Libraries. If I modify Runtime.c, changing the line void *lib_handle = dlopen(lib_name, RTLD_NOW); to add the infinite loop, as below: void *lib_handle = dlopen(lib_name, RTLD_NOW); for (int ii = 0; ; ++ii) { printf("loop %i\n", ii); int close_err = dlclose(lib_handle); printf("close error: %i\n", close_err); printf("dlopen(%s, RTLD_NOW)\n", lib_name); lib_handle = dlopen(lib_name, RTLD_NOW); } then opening and closing the dynamic library will succeed, but memory usage (as reported by top) will rapidly increase. I'm running on x86_64 macOS 13.6.6. Full code for the modified Runtime.c is attached, the rest of the code is available in the Apple Developer docs. Any suggestions? Many thanks, Chris Runtime.c

Hi all, I’m developing a watchOS app and have seen cases where the app is terminated by the system — for example, due to CPU usage limits being exceeded (watchdog termination). Here’s a portion of one of the crash reports: Exception Type: EXC_CRASH (SIGKILL) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: CAROUSEL 2343432205 <RBSTerminateContext| domain:10 code:0x8BADF00D explanation:[app<app_name>:898] Failed to terminate gracefully after 5.0s ProcessVisibility: Foreground ProcessState: Running WatchdogEvent: process-exit WatchdogVisibility: Foreground WatchdogCPUStatistics: ( "Elapsed total CPU time (seconds): 11.280 (user 9.800, system 1.480), 100% CPU", "Elapsed application CPU time (seconds): 5.162, 46% CPU" ) reportType:CrashLog maxTerminationResistance:Interactive> My questions: 1.) Is there any way to get notified (via Crashlytics, Xcode Organizer, or any other reporting mechanism) when this type of system-level termination happens — similar to how we’re notified of crashes? 2.)Is there any way for a watchOS app to receive runtime warnings from the system when it’s about to exceed CPU or memory limits — similar to UIApplication.didReceiveMemoryWarningNotification on iOS? Thanks in advance!