Someone could help me ?
I have a problem with Xcode 12.4, the application takes more than 5 minutes to launch the app and stay blocked building the app.
It's not a problem with my application because i have tried with the new app and the problem still be the same.
TL;DR
Run once and wait for the Simulator home screen to load. After loaded, re-run the app from Xcode. 🤷♂️
Explanation
I am not sure if this will actually fix the issue, but usually, I fully open the Simulator.app for that device and wait for the Home screen to load before running the app. I think Springboard (Xcode) waits to get a handshake response when the device has fully launched and then attaches the process. This handshake was a bottleneck for me.
Other potential causes
Disable Springboard injection apps like Sherlock.app.
Reduce the number of simulators open at a given time to increase available RAM.
Reduce the number of open apps so that Xcode gets more CPU time to run.
Disable Debug executable setting (or other runtime settings) in Edit Scheme in Xcode to check if the Xcode debugger is faulty (workaround).
Try a newer Mac (2017 or later, but ideally an M1) as they have more RAM and are faster.
Reduce App Bundle size - smaller Asset Catalogs, Preview Content folders, fewer third-party libraries, and no duplicate source files (including the iCloud Desktop/Document Sync zombie files bug).
Disable iCloud Desktop and Documents Folder syncing. Or at least wait till the whole laptop has been synced. The bird daemons et al. are quite intensive.
Related
Having perused many other questions concerning unusual app crashes without any success at solving my problem, I have decided to post this question.
I have an app that crashes at random. Some users (in test) never have crashes, others have an occasional crash. This app is installed via XCode on testers phones, straight from the development machine. The app never crashes when in use, only upon startup a day or two after installation and use.
The app is instrumented with Crashlytics, and no crashes are detected, nor are Out Of Memory warnings. No crash logs are left on the phone after this behavior.
Crashlytics works. I injected test crashes and they were properly detected.
Once the app crashes, it will not restart. The splash screens appears for an instant and then the app closes.
The app uses Core Data and I use ObjectiveRecord https://github.com/supermarin/ObjectiveRecord as the Core Data interface. There are no aborts anywhere in the code (at least none that I added/left in)
The app downloads about 1500 images (photographs) at initialization time, and whenever the photos collection is updated. The filenames are stored in Core Data, not the binary data.
As an experiment, I took the container from the same app on another phone and replaced the container on the defective phone. No difference. Replacing the container on the good phone with the container from the bad phone made no difference either.
If I reinstall the app on the target phone, without deleting the original install, all works as expected. This leads me to believe that I am not suffering from database corruption - obviously, I may be wrong, but if advice can be offered as to how to test this, I will happily accept it.
I am at my wits' end here - any advice as to what the problem might be, or how to diagnose the problem will be gratefully received.
EDIT -- The app is for IOS 9, iphone only.
I shall answer my own question. I have been distributing the app to my 4 testers using a MacBook. I only have one license, and rather than downloading it and moving it between my iMac and MacBook, I was just allowing Xcode to generate a new certificate.
This doesn't work. Ever.
It invalidated all of the copies of the app that I installed.
The moral of the story is: beware of licensing issues - even if you have a license.
and the hint was:
Aug 29 15:48:28 iPhone amfid[170] : /private/var/containers/Bundle/Application/25BE181B-C30F-41FF-87A3-88C8E63BB3B3/TEST.app/TEST not valid: 0xe8008018: The identity used to sign the executable is no longer valid.
Live and learn I guess......
I've been experiencing, of late, a weird problem with every App I create. When I deploy it to a device, I notice that it takes a long time to launch. Whether I'm debugging via Xcode or just launching it anywhere, anytime. When I tap the App icon, it takes about 4 seconds before the actual App launches. During that time, the device is pretty much frozen until the App launches.
However, I have an App that's been distributed through the App Store and it doesn't seem to have this problem. It launches immediately. But when I provision my phone via Xcode (the same App that's on the App Store), I experience this problem.
My question is, is there some sort of debug info that's built into the App binary that causes these long delays during launch that's not built into release versions? If so, is there a way to disable it on debug builds?
I believe it's bug on xcode 6 I've experienced the same issues. I've figured out a way to launch my apps quicker.
Set Xcode to build into a fixed DerivedData location—otherwise every time you blow away DerivedData, you’ll have to repeat all these step. Go to XCODE
Settings > Derived Data > Advance > Select "Unique"
Make a new script. Say: quick_compile.sh. Give it the standard “#!/bin/bash” or whatever at the top and chmod +x it. 3. Do a clean build of your project. 4. Go to the Xcode Report navigator (Cmd-8), and choose the report for your recent build. 5. Type “merge” into the upper-right hand filter, expand the log for the “Merge Khan_Academy.swiftmodule” phase, and copy the contents minus the first line into your script.
Do the same for “i386.swiftmodule”. 3. Do the same for “link”. 4. Do the same for the file you’re iterating on (e.g. ContentItemView.swift); put this at the top of your script
Once you’ve got this set up for a file, just run your script to update the build for that new file. 2. Launch the app with Cmd+Ctrl+R in Xcode.
You’ll have to repeat these steps whenever new files are added to the project or to change the file you’re iterating on, unfortunately, but it’s good when you’re working on something focused
I Learned this efficient method from #andy_matuschak twitter he made
a post a while ago on how to do this so i don't take any credit for
it. I believe he released a PDF explaining it better. If you can't follow these instructions look for the pdf file
I was seeing the same problem #purrrminator was. I have an iOS 8.3 device used for testing here at a large company with a good number of provisions that ultimately found their way on to this thing. I app I'm testing now was taking many seconds to launch.
Based on:
https://apple.stackexchange.com/questions/148792/installed-provision-profiles-not-seen-on-ios8
What I did was set the time manually to a date well into the future allowing the existing provisions to expire and get auto-pruned. A quick reboot (for good measure) and a fresh install of the app and I was good to go (a reset was not an option for me).
Try to reset phone settings (not content!). It may solve some performance problems occasionally.
The only reason that I've experienced the same problem was in fact that I got tons of provision profiles installed on the device. Our development team has over 100 apps, so iOS has to deal with all the provision profiles mess while launching the app.
For some reason, whenever I try to run any app created in Xcode (even brand new ones), something happened (?) and now Springboard takes up a ridiculous amount of CPU until it launches. Once it's launched it's fine, but until then it will often respring if there's not enough memory. It runs fine in the Sim, just not on the physical phone. No clue why. I can provide logs or info, I'm just not sure what to put here; I've looked at most logs etc.
Where do you want to run the app? On a real device or in the Simulator? If you're using a real device, unplug it, open /Library/Developer/Xcode/iOS DeviceSupport and delete the folder with the iOS version of your device. After that, reconnect it. Does that help?
Also, please provide any logs you get and information about your system versions, devices and the Xcode version.
While using Xcode 5.1 to deploy our iOS application I am seeing quickly build and say "Running on iPad Name" but it doesn't launch the application for a little over 7 minutes. When I tap on the status bar at the top for more information it says "SandboxingApplication."
This does not happen on other iPads that we use with the same application.
Any ideas? I've tried all the basics like restarting the device, Xcode, and my computer.
You already said it:
This does not happen on other iPads that we use with the same
application.
That's the point, you'll have to reinstall the iPad. Some time ago I had a iPhone 3GS for testing on which it sometimes also took minutes to launch the app. Xcode behaved like what you described, showing "Running on DeviceName".
But although this iPhone is older it hadn't been always this slow. After I restored it from iTunes it again was pretty much faster.
Finally with the help of #flowmachine1 this is solved! It was fixed by:
Deleting Derived Data
Clean Project
Delete App and Reinstall
Thanks so much!
It could be really any issue, but here are some troubleshooting tips.
Restart Xcode and iPad (You already did it)
Try to create a new Project, and try to run it on the iPad Air (Let me know the comments below what happens)
Reinstall Xcode (Most common fix)
Also report to Apple, if none of those fixes work, https://developer.apple.com/bug-reporting/.
Thank you.
I've nailed down one cause, for my situation at least. The app's sandboxed area is huge (gigabytes) as it contains a large amount of resources (as discussed here). Wiping out these resources prevents the delay in the sandboxing process (with the unfortunate side effect of rendering half of the app unusable).
I can only assume that, as part of attaching the debugger, some processing of each file in the sandbox has to occur every time, and it is this process that is taking the time.
The resources are in the application support directory. If anyone knows of a way to mark or relocate these files to improve the speed of the sandboxing process I'd be very interested to hear (and would award the bounty).
Well, I'm running apps on an iPad Air here and it runs in just a few seconds, using Xcode 5.1 and Xcode 6 (beta 4). So, I'd guess three possibilities here:
Your Mac's HDD is failing, or your app is very large (having GiBs of files OR thousands and thousands of small files). You already said your app has 27MB, so size shouldn't be the issue here. Unless you're talking about a 27MB .ipa file, which is compressed. If your IPA contains 27MB, the app itself can be rather big (not enough for 7 minutes sandboxing time, but affects the sandboxing time.)
You're out of RAM memory on your mac, which causes memory swapping. This can easily lead to 7 minutes build time.
Your USB cable (or port) is damaged. I tried using a damaged cable before, and even with the basic templates that Xcode has I would take several minutes to run it on the device.
I'm debugging an iPad app and I'm getting a GIGANTIC list of processes to attach to when selecting the "choose target" drop down in Instruments.
It's literally showing every single process that I have run and terminated when I start and stop my app that I'm debugging. They are listed under the Attach To Process->System section, that's where my IOS apps to debug always show up, but they never get removed, so I have to dig through hundreds of entries.
I've tried restarting xcode, instruments and IOS simulator... Is there any way to clear this without restarting my mac? I'd hate to have to do that every time.
Everytime you exit your app in the iOS simulator, it creates what is called a "Zombie Process". To this date, the only way you can clear these processes is by rebooting your mac.
Also, when you want to choose a target for your Instruments application, the process you will want to select will most likely be the highest-numbered process for the app you are currently testing.
Here is a stackoverflow reference regarding the zombie processes left behind by XCode: Xcode leaving zombie processes after running iOS tests/simulator