I have trouble determining why my iOS emulator is not updating in real time as I update my code. Each time I make changes, the terminal registers the updates, however the emulator doesn't refresh the view. This is my console output:
Compilation complete. Watching for files changes.
File Change detected. Starting incremental compilation...
Compilation complete. Watching for file changes.
If anybody could please point me in the direction of this issue, that would be superb as there isn't much else to go by on any other forums.
I found that when running the application from a file path which contained a space, the real time updates had trouble. After ensuring all directories within the project absolute path contained no spaces, the livereload worked.
You need to be more clear on what you did to "not work".
Here's how I do it to make things livereload.
tns run ios
If I do above without a device plugged in, it automatically uses the Emulator. If I have a device plugged in, it uses the device.
Livereload works for both instances, such as when I add things to the template.
Related
Message from debugger: Xcode has killed the LLDB RPC server to allow the debugger to detach from your process. You may need to manually terminate your process.
I keep running into errors when trying to run Xcode projects. The first one involved a code signing issue and after fixing that I am now running into this debugging issue. I never had issues like this before but once I upgraded by iPhone to 15.6.1 is when these issues started to occur. This happens to every application I attempt to run.
Could someone please explain what this message means and if they have any solutions to how I can solve this?
This happens when the process of attaching the debugger to the new process goes too slowly and Xcode thinks lldb is stuck. One common cause of that for remote debugging is if there's no "host side" copy of the system libraries that are loaded into your binary on the phone. iOS applications are really complex these days, with lots of shared libraries and lots and lots of symbols. lldb has to read them all since you might want to put a breakpoint on any one of them.
The debugging protocol lldb uses has the advantage of ubiquity but it wasn't designed for high speed data transfer. When lldb has to read all that symbol information from the process being debugged, that goes pretty slowly.
Xcode gets around this by copying the system libraries from your device to a cache on the host Mac, putting them in a place lldb knows to look for them. It has to do that every time it sees a device with a new OS. It sounds like that process has failed.
The cache is stored on the Mac you are debugging from in:
~/Library/Developer/Xcode/iOS Device Support/<OS Version>
There might be no directory for your 15.6.1, or there may be one, but it doesn't actually have all the files. You can often fix this by deleting the <OS Version> directory in the Device Support, and then unplugging and re-plugging in your device. The next time Xcode runs you should see some message about "preparing device for debugging" - which is it copying these files over. If that still doesn't work, it's best to file a bug with the Apple BugReporter so we can look into it more deeply.
I'm developing an iOS app.
I have placed it in a workspace with other targets (frameworks) that I use in the app. I can run the app fine, but once double tap the home button and I close it completely, I can't run it again.
I tap on the icon, and sometimes it launches the app then quits immediately, or sometimes it simply doesn't open it.
Is there a way to fix it or to find what is causing this problem?
PD: the reason why I'm doing this is to test wether reopening the app from a local notification loads the correct data for the notification that has been opened. Trying to open by tapping on the notification doesn't work either.
Neither the debugger or the console are printing anything out.
This happens when you use frameworks in your project that were not customized to work properly in the simulator. Basically, the iOS simulator uses i383 (for 32-bit) and x86_64 architectures, rather than the arm and arm64 architectures that the real devices use. For some reason, when you create a framework, Xcode doesn't set it up to retain the compiled i386/x86_64 architecture code after the app is quit. It will, however, retain the compiled arm/arm64 code, so you can be sure that the app will function normally on real devices.
I personally get around this issue by using real devices when I need to test features that rely on quitting and relaunching, but there are ways to write custom build schemes on your framework to fully support the simulator. I'm not going to put a link here, though, because the specific workarounds are very diverse and I myself have not tested any of them.
I am working to add a TopShelf implementation to my tvOS app. I am also working to create a Collection View implementation that has a similar functionality from within the app. Both work fine in the simulator on my Mac but don't work when deploying to my Apple TV using TestFlight. I tried using the USB-C cable to try to capture some logs or see what is going on when the UIActivityIndicator just spins. I thought it could be related to trying to download too many images or some other networking issue. I started caching the images and again that works well in the simulator but not on the device.
When I plugged into the device and ran the app it worked as it should, even with a higher number of downloads. I later updated the version via TestFlight and was back at the same position. Right now I am in a position where the app works every time with my own view controller and the TopShelf part, but does not work at all if deployed via TestFlight. I can't get any logs to figure out what is going on because when I connect the USB cable and run the app, it starts working.
Has anyone seen similar behavior or know of any way to troubleshoot what is going on?
I was able to determine there were a couple of things going on. The first was that the simulator was setup for a build configuration of debug. I went in to Edit Scheme and changed the Build Configuration for Run to "Release." This allowed me to recreate on the simulator what I was seeing on the device. It also made it a lot easier to debug as I could easily add logs to track down where the code was hanging.
The root of the problem was that I had a while loop doing nothing while I waited for a network block to update a flag. I've used this hack in other situations and have never run into a problem. If I added one NSLog command to the while loop it would flow through fine, but with nothing in the loop it just hung even though the network dispatch was done downloading data.
To fix this, I read up on using
dispatch_semaphore_wait(sema, DISPATCH_TIME_FOREVER)
which solved my problem (and I'm assuming made my code a lot more reliable too).
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 have an app which connects to my server to fetch scores, register users etc - the usual stuff.
If I run it on the simulator, it works fine.
If I run it on the device using xcode it works fine, and continues to work fine even once I disconnect the device from xcode and use the app directly from the phones desktop.
However when I build an .ipa file and use that, the app does not connect to my server - it just timeouts.
Does anyone have an idea about what could be causing a difference between how it works on the phone when it was put there directly via an xcode build + run, and when it is dropped on as an .ipa using organizer/iTunes?
As far as I am concerned they should be exactly the same, so I have no idea about where to even start looking.
I am building with the dev target as iOS3.2, using xcode4.2 and iOS sdk5.0. Have tried it out on a 3GS and iPod Touch 4th gen both with the same result.
If any more info is needed then I can give that, but fundamentally everything works, so I suspect that maybe there is a permissions error or a file I need to include that I'm not aware of. This project was originally designed by someone else and they are no longer around, other projects I have made connected to my server without any issues so I'm really hoping someone can help.
See my last comment above, the error was simply down to release builds attempting to look for an incorrect server address.