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.
Related
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.
I'm trying to upload my iPhone .ipa file to iTunesconnect. I've done that many times successfully using Application Loader, but lately it takes more and more time.
This night & morning I'm stuck at max 15% being uploaded, then my home network completely or partially crashes, and I have to start from the beginning, usually with resetting router first.
Some potentially useful data:
I'm using Application Loader for updating ipa
Application loader uses port 443 for https
.ipa file is about 50MB big
I've updated java as suggested on one stack overflow thread
Firewall is turned off
I have faces a similar problem some time back with Xcode 6, and it was not due to Application Loader, but either my mac or the network. How I resolved the problem was that I used a friend's Mac on a different network and it uploaded smoothly and without any problems. However while trying to fix my problem I came across multiple solutions that may work for you:
Use the default Xcode Build submission tool (The one that you get after validating your .ipa file and it says submit to the App Store)
Use Application Loader (this only works if you were trying with the Xcode uploader in the first place, however I'm assuming you weren't)
Upload from a different network (This seemed to have helped a lot of people.)
Use a different mac. Sometimes the issue could be with your machine. (You can try restarting it, but using a second mac if available would be much better.)
Use the last stable release of Xcode. When using one of the Beta's, try to use the last official release. (And also make sure you aren't using any pre-release technologies, however this should only stop you at a later stage)
You can try any of the above points, as for me a combination of 3 and 4 worked.
Hope that helps, Julian
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.
I'm working (helping out) on an iOS app. On most devices the app's stabilized storage use is within 60-80MB. The same app (and same revision) on the iPhone 6+ starts using Gigabytes of data within minutes ... to the point of filling up the storage and I can't even run the app from XCode anymore. I've only been able to get it on the iPhone 6 once, but it's a regular occurrence on the 6+. I've also tried on a range of other devices from 5th gen iPod touch to the iPhone 5 and no other device goes over the 80MB.
The only portion of code that uses a significant amount of storage is the image caching, which caches the (static) images downloaded from the server keyed on the image id. Then again this code is (or seems to be) working fine on other devices. It is also a portion of the codebase that hasn't changed in a while.
Can anyone think of a reason why this issue is only seen on the iPhone6+ (and to a much lower extent the iPhone6)?
This isn't a solution, since it's impossible to know what's happening, but you should look at the following:
Is this reproducible on the simulator? (file system is easier to view)
Does the storage get freed when the app is deleted?
Can you see the data in the device organiser in xcode (they keep moving it, but somewhere you can plug in the device, see the app, and then see the file sandbox for that app)
What data is it? This should give you a clue as to its origin
is there a set of actions in the app that kick off the problem?
If this works, you should get a clue as to the offending code. Then, update your question, unless the solution is obvious!
The problem was that malloc stack logging was enabled and not set to compact. It logged every single allocation made by the app and it was the log file that grew so large.
As to why it only occured on the iPhone6 and iPhone6+, I still don't have an answer.
The problematic file was stack-logs.773.1006c8000.REDACTED.wmQj2k.index. It grew to 700MB almost right after login.
Much thanks to #jrturton because his answer really lead to this.
I am wondering if there are any reasons corona does not ever finish "Performing Build" while building for iOS. I know having a poor internet connection (which I do not happen to have) can slow it down -- but not to the extent where I need to keep my computer running for hours...
A while back I was having problems with my provisioning profiles and I had switched to a new computer, and corona would not allow me to build. I have now though fixed that problem, and moved onto this one. A couple of months ago, before this problem, it was working fine and I was able to build for my iPad, and publish to the app store. Now I cannot release my next update or test any future version which is a huge setback.
Please let me know on how I can solve this problem!
If it works fine with android, the problem must be related to Xcode, do you check the terminal? Maybe you have the same issue with me