I started using Xamarin.UITest for cross-platform testing (IOS & Android).
With Android it worked instantly without any problem and it keeps forking even after any SDK update or JDK.. name it!
But for iOS there was so many issue encountered with the device agent that didn't want to start, the wrong Xcode commande one, the wrong Xcode. Some time it worked, but out of no where it crashes.. then you must clean, rebuild, retry, cross your fingers it doesn't crash or at least that it will launch..
But now April 19 2019, I had an iOS update, combine with an Xcode update and sadly, it doesn't work anymore. I made a lot of research and attempt to recover my test case:
Downgrade Xcode to 10.1
Downgrade Xcode commande line tool to 10.1
downgraded the OS!
To finally rethink it. It's not a good solid testing tool if it breaks at every updates.
On the AppCenter it still works for both platform. But to create your test, you have to run them locally.. You can't anymore with iOS and if you find how to make it work, let me tell you : "See you for the next update!"
So the question is:
What are the alternative to do some automated UI test for iOS & Android using Xamarin?
Xamarin.UITest Xcode 10.2 support
Sorry to hear about your difficulty with the Xcode update.
Unfortunately Xcode minor updates for the last several releases have tended to break local iOS simulator testing, and occasionally device testing. I've seen this be an issue since at least as early as Xcode 9.x versions.
For context, Xcode 10.2 support was added in this package: https://www.nuget.org/packages/Xamarin.UITest/2.2.7.2002-dev
If you or future readers of this discussion still do end up using Xamarin.UITest, I recommend checking the release notes when new minor versions of Xcode come out to see if that support has been confirmed. Typically the support has been added in the 1st Xamarin.UITest package released after a new minor version of Xcode has been released.
(I generally haven't seen this issue with patch versions though, for example Xcode 10.2.1 didn't seem to cause any issues when it came out if it was run against a test suite that was working for Xcode 10.2)
Other testing frameworks
As for other testing frameworks, if you're using App Center itself; then Appium (JUnit) or Calabash are both able to be used with App Center Test and can be used cross-platform to run against your IPA/APK, generally regardless of what was used to write the apps in the first place, like Xamarin.UITest. (Though each framework has slightly different set up requirements and limitations.)
Outside of App Center Test, there may be other testing frameworks you can use; but that gets more into individual developer opinion which strictly speaking is out-of-scope for Stack Overflow answers.
Appium Studio which holds all the pros of native Appium. It also supports parallel execution with built-in test reporting mechanism. They also provide cloud devices with which you can check whether it is feasible for your project. Check out their documentation for more features.
Related
I am new to Xcode and iOS coding. I updated my app to iOS 9, and I would like to submit it to the app store. Is this possible? Or will they not accept an iOS 9 build?
It works fine on both iOS 9 and iOS 8 devices.
PetahChristian is right. Apple does not allow you to submit beta build with beta version of Xcode, which is indeed suboptimal thing, as you won't be able to test your app until final version of Xcode comes out (this is all just in case you switched to Swift 2.0, otherwise just use Xcode 6.4 to submit the build).
Let's just hope that our users will be willing to accept possibly buggy apps when iOS 9 kicks in, as developers simply can't test them properly :).
You can't submit an app using a beta version of Xcode.
As long as you did not update your project to Swift 2.0, you should be able to submit it using the released version of Xcode.
If you upgraded your project and it won't compile with Swift 1.2, you'll have to wait until Xcode 7 is released.
Update:
The beta has several purposes:
To test Apple's code and report bugs to Apple.
To gain early access to new features and functionality of the SDK. You beta test your new or upgraded app on iOS 9 and fix bugs. When Xcode is released, you test against the release, then submit it.
To test existing apps to make sure they still work properly on (a prerelease of) iOS 9. You fix any bugs that may have turned up, but keep your code compatible with Swift 1.2 and Xcode 6. You submit using Xcode 6, and are able to submit any bug fixes in advance of Xcode 7 being released.
Ideally, you get to do all three things, but updating your app generally involves maintaining and working on different branches of your project.
This allows you to both support and fix issues for your released version, and add new features to an upcoming version.
I'm writing up a slideshow on keeping Xcode versions up to date.
It's not difficult to find out when Xcode versions BEGIN support, but not when Apple officially ENDS support.
Maybe the correct answer is "when the next version comes out," but the Xcode version tends to continue working for quite some time after the next variant comes out, and I know some folks that insist on using the old variant until the wheels fall off.
Eventually, the old version will no longer work on the current OS, and we need to hold back the OS to continue running the Xcode variant.
I need to find that point. I call it "The eBay Threshold." That's when we can no longer run the defined variant of Xcode on a new Mac, and need to buy old used Macs to run it.
As you might guess, this is a point of frustration for me. I hates ISO9001, as practiced by some outfits...
Thanks!
As you note, Apple stops supporting a version when the next version comes out. "When will it stop working" cannot have a definitive source because there is no firm definition of "working" in the absence of regression testing, and Apple does not regression test old versions of Xcode against new OS X releases.
The requirements are of course contradictory (which I expect you know). It makes some sense to demand near-total reproducibility. In that case, you must never upgrade the OS beyond the point release that existed when the next version of Xcode came out. Upgrading the OS beyond that means running Xcode in an untested mode, using "well, it seems to run" as your only criteria. At the very least, you would need to regression test your own software.
Obviously VMs are the best way to achieve this for a build infrastructure. The VMs need to be very carefully protected from outside traffic since they cannot receive even security updates without breaking their reproducibility.
Of course few develop Mac software this way. (This answer only makes sense for Mac development, and even then assumes that you are not submitting to the App Store. MAS and iOS development must keep up with the latest version of Xcode by Apple policy.)
I've created an iPhone game which utilizes some code from an old version of the Cocos2D iPhone game development framework and I've got a wee bit of a problem running it on iOS 7.
The version of Cocos2d from which the code was used was probably 0.98.
The actual class is called QuadParticleSystem (in newer versions it's been deprecated by CCParticleSystemQuad).
The actual issue is that the game runs fine on iOS 6 and below. It even runs fine on iOS 7 if the deployment target is set to iOS 6.0 and SDK version set to 7 (at least when put on the device directly using XCode).
The problem is that when the game is uploaded to the appstore, Apple seems to strip out the whole iOS 6 compatibility thing and the particle emitters fail to show up among other things like alpha transitions, invisibility etc.
(They initialize correctly and everything, but they simply DO NOT render).
I've considered (and tried somewhat) upgrading the Cocos2D version, but due to the old third-party frameworks I've used for other things there is a hell of a lot of linking/dependency/deprecation errors which could take forever to fix (if it's at all possible, which I doubt) In other words, I've wasted too much time on the project already and am looking for a quick fix.
If no one knows any solutions could anyone at least direct me to docs where I can see how to create/insert a new particle emitter system in the existing code?
I've thought about using SpriteKit's native emitter system, but I don't know how to incorporate it within the current code (as I've never had dealings with SpriteKit) and am not sure if it's even possible.
I've also thought of maybe upgrading the GL ES framework within that old version of Cocos2D just in case Apple have killed off some functionality of older versions of OpenGL. Then again that could take a while.
I am just starting iOS/iPhone development and I would like to start using XCode 4 instead of XCode 3.2. Is XCode 4 stable/feature complete enough for beginning iPhone development or should I stick with XCode 3.2?
I have run into far too many problems using beta versions of XCode, especially since you can't really have two versions of XCode one the same system. Apple already has a history of releasing things to developers before they are truly ready (just look at iAds for the iPad which were released months ago and have yet to deliver a single ad). So, if even Apple isn't ready to label XCode 4 as ready-to-go then you can rest assured its not really ready to go.
I recommend sticking with 3.2. That's what I'm doing until XCode 4 is officially supported.
Using XCode 4 calls everything you do into question. Having a problem with an API? Maybe it's XCode, maybe its your code, maybe its a bug in the API. You just don't know.
I would say no, it's not ready. I tried using it as my main development environment for about a week, and eventually switched back to 3.2. For one thing it crashed fairly regularly, but I could get passed that.
The big thing that caused me to switch back was a bug where the iOS simulator would think that certain resources existed in my app that didn't. Deleting the app from the simulator didn't work, cleaning the project didn't work, and deleting the derived data folder didn't work. Since it's not officially released, finding help for problems like this is a pain as well.
This is just one instance of the kind of problems you'll run into while using it, so I'd recommend avoiding it for now.
You can use Xcode 4 if you do not plan on using the current version (Preview 6) for submitting apps to the App Store.
iOS Dev Center:
Xcode 4 Developer Preview 6 includes
iOS SDK 4.2, bug fixes, and additional
features. To compile submissions for
the App Store, continue to use Xcode
3.2.5 and iOS SDK 4.2.
I have iPhone application in the App Store. Do I have to compile my app with iOS 4.2 SDK in order to allow it run on iOS 4.2 devices? Or compiling using iOS 4.2 is required only to allow using new features of new iOS?
I will appreciate if you can clarify this issue...
Thanks!
Yoash
Do I have to compile my app with iOS
4.2 SDK in order to allow it run on iOS 4.2 devices?
No, it will run on the new firmare just fine. At least if the new firmare does not reveal some bugs in your code (which happens).
You don't need to recompile it to let it run on newer OS versions, but like you already guessed, you need to recompile it when you want to use the newer features (eg. AirPlay, "Multitasking" etc).
The old version should still run.
The app might not play well with new features like multitasking on iPad, so it is worthwhile trying to get some testing and feedback done as soon as you can in case there are issues.
If you download the XCode 4 pre-release from the developer portal, you can use the new static analyser to look for problems in the code: this is not just for SDK issues but also things like memory leaks.
Apple recommends that you always compile with the latest SDK, even if you are targeting older versions.
Unless you run into a specific issue that is causing incompatibilities, it is wise to take this advice. A lot of small bugs and performance issues are fixed with each new iteration of the SDK.
That being said - you can continue to use the older SDK's, and Apple will still accept the apps you build. For mature apps that are only going through minor tweaks, this is probably the safest course to avoid introducing new bugs.