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.
Related
I'm a free developer and I use my swift application on my iPhone 7. I'm using Swift 3 and iOS 10.
So the problem is, sometimes (like 2 of 10 times) when I start the app, iOS freezes like 5 seconds before my app actualy comes to the screen. In this time I only see the app icon is in the highlighted state. This only happens with my own app, not with other apps.
My app also does nothing special on startup and this only happens on the real device, the debugger in Xcode always starts immediately.
So is this a normal behavior? And does it work properly when I decide to put it on the App Store?
Thanks in advance.
I have had this happen to me before. No, this does not happen when it is put out on the App Store. One way to get around this is to use TestFlight. You can upload your archive to apple and select on the 'TestFlight' tab of your app. Click on internal testing and then click on your email and the version of the app you want to test. You should then get an email on your Apple ID telling you to test the app, and it will let you download it. Good question :)
To test the same version which would have been uploaded to the store quickly, change the build configuration to release. To do so, click on your app's name (top left), press edit schema, click the build configuration dropdown, also deselect debug executable. (make sure to turn it back when you're going to debug, or create a new schema with the above settings to let you switch quickly in the future)
You might also try using instruments, that lag on startup might happen if you're trying to load many things in memory on your initial view controller's viewDidLoad or app delegate's didFinishLaunchingWithOptions load, especially when trying to load big files such as images, videos or large plists. You might want to try using instruments (the time profiler instrument specifically) in order to check it out.
Maybe I have a stupid question, but after the update to Xcode 7, I sent a new version of my app to the App Store (via standard: Archives - Organizer - Upload to App Store). But now it is my build in iTunes Connect in tab Prerelease with status Processing (btw more than 12 hours), and I do not know why. Why is my build in Prereleasse tab? Previously, I uploaded new build the same way and I could have it for a few minutes to submit for review. Thx for help.
Update: After more than 48 hours, I can finally submit my new build for review! ;-)
The issue seems to be related specifically to Xcode 7. Some people have mentioned these work arounds to get it to go:
1) Use Application Loader and not Xcode to submit to iTunes.
2) Re-submit with new Xcode 7.1 beta.
3) Re-submit with old Xcode 6.4.
Your milage may vary.
Edit: Problem seems to be solved now, it appears to have been related to that exploited Xcode issue in China which caused significant iTunes Connect delays.
It's not the feature of Xcode, instead it's actually a feature of iTunes connect by itself.
All your uploaded archives go directly to "Prerelease" tab and lets you the privilege to distribute those to some specific users for beta testing, through TestFlight(optional), before you actually set it for production.
This process lets you debug your app performance and lets you actually maintain a build log, without actually releasing the app for public. When you are all set, you pick the best from Prerelease builds and release that to actual production environment, for public.
More documentation from Apple is available here
And by the way, I think your Processing issue should be automatically resolved if you give it some time (possibly 24 hours or so) or you might need to remove your app and upload that once more. You might know, Apple is too much busy to maintain it's App Store's security, right now ;)!!!
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 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
We need to test our app in the context of an iOS upgrade (e.g., 5.1 -> 6.0). Unfortunately, Apple doesn't allow downgrading devices. We thought of doing it in the simulator, but different versions of the simulator are different environments in themselves. I think we can copy the bundle from one simulator to the other, but that won't migrate the keychain (will it?).
Thanks!
To test a transition from one state (before) to another (after), you need a way to put the app in the before state.
Your app surely won't be running while the OS is being updated, so you really only need to worry about the app starting up and discovering that the OS has been updated. There are a couple options:
Copy all your app's data files from a device running the "old" iOS version (5.1 according to your question) to a device running the new (6.0) version. The organizer in Xcode will let you easily copy your app's "container" from a device to your Mac or vice versa.
Make your app write it's data in the "old" format. It's not uncommon for an app to have methods for reading and writing data in different formats depending on the environment, so it's often easier to get your app to write data out in the old format than to actually copy from an old device.
Whichever path you choose, think about any other places (like user defaults) where you might made OS version-dependent changes and set those back to values that correspond to the previous OS. This applies especially to keychain items, which aren't stored in your app's sandbox.
Unit testing frameworks (like Apple's XCTest framework) generally have a setup mechanism that you could use to reset your app to the before state, including copying files, adding and removing keychain items, setting defaults items, etc. You can then add unit tests that run whatever code might be involved in an update and test the results. With a set of easily repeatable tests you'll be able to debug any problems more easily.
However you approach it, the goal is to put the app in the same state that it would be in if it were running for the first time after an OS update occurred. You don't have to worry about simulating the actual OS update, you only need to trick the app into thinking that the update has just happened.
For now, you can still install iOS 8.2. When a new version is released, Apple leaves both versions open for installation for a short time. While that "signing window" is open you can upgrade a device, test, and then restore it from an image of the older version. So you could do some intensive testing while the window is open, but obviously that's not a long-term solution (it typically lasts only a few days).
If you have the budget for it, you could install 8.2 on a device, put a big sticker on it saying "do not upgrade", and keep it on 8.2 for as long as it's relevant. Install your app on that device and take a backup (with backup encryption enabled so that keychain entries will be included), then restore that backup to another device that's on 8.3 - this is basically the same procedure you'll go through when doing an upgrade/restore through iTunes so it should be pretty close. It won't be exactly the same as an OTA update on-device of course, but for that, see option 1 above (and see it soon).