We have set of mobile UI test for website written with Java, using Selenide, Cucumber, Chromedriver. All these test running fast on chrome browser emulator. Now I'm trying to run all my tests on real iOS device, using:
Appium 1.6.3;
ios_webkit_debug_proxy 1.7.1 (Built with libimobiledevice v1.2.0, libplist v1.12);
Xcode 8.2.1 (8C1002);
WebDriverAgent;
iPhone 5s (two real devices - iOS v9.2.1 and iOS v10.2.1);
MacOS Sierra 10.12.3
Test successfully passes, but it is dramatically slow. For comparison, one small scenario take 3 min 20 sec on real device, and 20 seconds on chrome emulator.
Is it possible to optimize work of ios_webkit_debug_proxy, appium or WebDriverAgent?
Looks like ios_webkit_debug_proxy makes some heap dumps during test run and this makes test slow. Am I correct? Is it possible to run tests against real iOS device without ios_webkit_debug_proxy?
Please, help me with this.
I’ve installed appium 1.6.4-beta and was surprised. My test become faster in ~4 times!
Execution time on real device comparable with chrome emulator (for one 7-step scenario: 23 sec on chrome emulator and 50 sec on real iOS device!)
Previously I’ve mentioned that execution time of this scenario took about 3 minutes (for appium 1.6.3).
Related
I have a new Surface Laptop 3 for Windows development. I'm just starting to learn Xamarin.Forms and I'm using Visual Studio 2019. The device emulators work fine as does debugging on a physical Android. I'd like to debug on an iOS device. However, I only own a Late 2011 MBP (16GB RAM, SSD). I am limited to High Sierra and XCode 10.1. Is this Macbook good enough for me to at least debug and just learn Xamarin.Forms using iOS devices?
If you want to release your app some time soon, you'll be required to use the iOS 13 SDK (source). To use the iOS 13 SDK you'll need Xcode 11+, unfortunately
Xcode 11 requires a Mac running macOS Mojave 10.14.4 or later. (source)
And Mojave is not intended to run on devices older than 2012 (see here for example). Anyway, this does not necessarily mean that you can't use your old MBP at all. Even though Mojave is not intended to run on devices that old, people have been able to run it anyway. Have a look at dosdude1's Mojave patcher. I have been able to successfully install Mojave on my (early 2011) MBP and it works without any reason for complaint. However, since the OS is not intended to run on our MBP YMMV.
And please note (shamelessly copied from this answer of mine)
This is probably a violation of Apples ToS
If you want to release your application in the App Store you might still run into troubles (unlikely, albeit, still conceivable)
You'll have to trust dosdude1, the patches are not open source, as far as I can tell
The machine is not guaranteed to work as it did before
Xcode iOS simulator running incredibly slow while app is building. UI and response is very laggy.
I am using Xcode 8.0 release on OSX 10.11.6
Has anyone else experienced this? If so anyone have any solutions?
The iOS Simulator does not have access to the GPU. It makes use of the CPU for all rendering.
Compilation takes up a ton of your CPU and disk I/O bandwidth.
Given that, you should expect the simulator to run slower than normal than when you're not compiling because it is getting resource starved by the compilation.
I had the same problem and it was solved after upgrading to macOS Sierra 10.12.5 Beta
I am getting this error with Xcode7.
Xcode cannot launch apps on the simulated device “iPhone 5”,
as it is currently running app with pid 3626 on “iPhone 6s Plus”.
Only one simulated device may be used at a time
I am not running any other app but the simulator still shows the message above.
I restarted XCode but it still did not work.
There are no active processes running for iOS simulator in the activity monitor.
Close the simulator (cmd+Q) and retry.
Also, make sure that another Xcode project is not using it.
Restarting xcode worked for me.
I'm using Xcode 6.1 and iOS Simulator 8.1. It takes a long time to run the simple apps that I've written using the iOS Simulator. Build process was ok but then the iOS Simulator will show the black blank launch screen then the app screen for like 5 minutes before the app launch. Many times it shows error "Lost connection to iPhone 6(/5/4s)". Tried to re-start Xcode and iOS Simulator, and MacBook Pro multiple times already. Tried to reset "Content and Settings" in the iOS Stimulator, but doesn't help.
What could be the possible causes? Any advice/solution? Thank you.
I suggest that you boot up the device that you want to use prior to the Build&Run in Xcode. If you hit Build&Run in Xcode while the device is not booted, you will need to wait for the device to boot. This can take a long time depending on your I/O load (eg: if Spotlight is indexing at the same time you are trying to boot, or if your home directory is on a slow volume like a network mount).
Just open up iOS Simulator.app ahead of time and select the device you want to test on from the Hardware->Devices menu. Then it will be ready when you need it.
Make sure 'slow animations' is not selected under the Debug tab in the iOS Simulator. That fixed the issue for me.
Googled on this issue and some said it's a Xcode bug with the 6.1 beta, but I had the 6.1 release version installed alreadt. I even try the 6.2 beta, hoping Apple has a fix for this, but no luck, still the same.
So desperate that I decided to upgrade my 3 years old MacBook Pro RAM and harddisk to SSD. Problem solved with the upgrade! The iOS Simulator runs normally now.
I am using MacOs Maverick for development. We have a nice test suite that requires roughly 8 minutes to finish. We have asynchronous calls with timeouts if we do not get a respond in time.
Everything works fine if I keep the focus on the test runner environment which is in my particular case adl from flex SDK. As soon as I switch to a different application the available resources for this particular process get reduced and our events no longer trigger in time. This causes a lot failures.
I know you can disable App Nap for applications via the info dialog but you do not have the same option for adl or any other executable that is not defined as ".app".