In my tests, Xamarin.iOS always seems to use two generations. That is, GC.MaxGeneration always returns 1. The Xamarin Cross-Platform Performance Documentation seems to support that by referring to the Mono SGen Documentation, which states the SGen uses two generations. On the other hand, the Xamarin API Documentation of GC.MaxGeneration suggests that MaxGeneration can increase over time.
Is GC.MaxGeneration fixed in Xamarin.iOS, or can it increase given enough time?
Also, just in case: Has the behaviour changed in the last year? Reason for this question: Alongside the current stable release of Xamarin iOS, we are using Cycle 6 Service Release 4 for bugfixes for an older product.
Related
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.
Recently i got a project which was build on Xamarin on Mac.Now, when i try to open this project on visual studio for MAC (As you all know Xamarin is now visual studio for MAC) it shows some errors regarding Monotouch.
The question is : Do i really need to convert app to unified API ? i know there is tutorial on official Xamarin doc to change app to unified API, but if there is any other way to open app without migrating to unified api.And what will be advantages and disadvantages of migration?
There are quite a few reasons why you might consider updating, but I will highlight some of the more important ones. Firstly consider that Apple as a manufacturer of hardware and software have always striven to keep their devices upto date, as such lagging behind as an iOS app developer can absolutely effect the demand for your app.
Firstly it already became a push or jump situation, as Xamarin stopped updating or supporting feature additions to their 'classic api' (As of writing we are on iOS 10.3).
The complete removal of classic support is scheduled for next fall
with the release of Xamarin.iOS 10.0.
Secondly the unified API is required to meet apples desire to support 64bit architecture:
The new Unified APIs are required to support 64 bit device
architectures from a Xamarin.iOS mobile application. As of February
1st, 2015 Apple requires that all new app submissions to the iTunes
App Store support 64 bit architectures.
As to your concern regarding the dissadvantages, I will simply say that the migration can either go smoothly, or not so smoothly. It's worth bearing in mind that the 'unified api' uses different native data types which may require some work arounds depending on the current structure of your original code.
The biggest point is what I mentioned earlier, in Apples App Store if you linger behind in terms of keeping your app up to date with the latest SDK, API, or anything else Apple decide to upgrade, then it is akin to giving up on that application.
I've put together some links below that may aid you in the migration process:
Native Types - Describes the new native data types that you will need to use in a Unified API app.
32/64 bit Platform Considerations - Considerations in choosing 32-bit and 64-bit modes for your application.
Updating Existing iOS Apps - Follow these steps to update an existing Xamarin.iOS app to use the Unified API.
Binding Objective-C Libraries - This document describes the process used to create C# bindings of Objective-C APIs and how the idioms in Objective-C are mapped to the idioms used in .NET.If you are binding just C APIs, you should use the standard .NET mechanism for this, the P/Invoke framework.
Binding Definition Reference Guide - This is the reference guide that describes all of the attributes available to binding authors to drive the binding generation process.
Updating UI Components - This is a guide to the process for updating UI componenets to the latest versions within the unified api.
I have a Xamarin Forms app that is currently on the App Store that I built and submitted in October 2016 (with what I assume was the latest versions of Xamarin Studio and Xamarin.iOS back then). The app has a size of 50 mb on the App Store.
After doing a few updates to the app, I build it now (AppStore config, then Archive) and the size is 82 mb. Confused by this balloon in size, I switched back to the git tag of the version that is currently in the App Store. I can build the same exact tag/version/code for that October 2016 release and it's App Store size is now 80 mb.
I am using the latest Xamarin Studio (6.3 build 863), Xamarin.iOS (10.8.0.175), etc.
Why has the size grown by 60%? No application code or libraries have changed, only newer versions of Xamarin Studio and Xamarin.iOS. How do I figure out what is going on here? I can do an Add-Hoc build on my device and see that is only taking up ~55 mb, very close to what I see from the App Store.
Also, note that I am not comparing the .ipa size. I am comparing the "Estimated App Store Size" shown from the archive screen in Xamarin Studio after archiving a build. The same size difference is reflected after submitting the signed build via application loader to iTunes Connect and verifying from iTunes Connect > Activity > All Builds > App Store File Sizes.
Update Sept 5th 2017
Not sure what changed but now with the latest version of Xamarin iOS, Version: 10.12.0.20 (just updated), my app size is now back down in the 60mb range... Didn't change anything else.
I can do an Add-Hoc build on my device and see that is only taking up ~55 mb,
You likely have some different options between your configuration, e.g.
managed linker settings, e.g. Don't link versus Link SDK;
targeted architectures, e.g. armv7+arm64 versus armv7+armv7s+arm64;
How do I figure out what is going on here?
Compare your build logs, in particular the options given to the mtouch tool. That will generally pinpoint the difference quickly.
I am comparing the "Estimated App Store Size"
Always compare the IPA (file) size. The algorithm to guess the final size is known to be often (very) wrong. The estimation also comes from Apple's tools so they will vary with the version of Xcode you're using (which is unlikely to be identical to the one you used last fall).
Side note: the final size is even trickier to guess when bitcode is enabled (which is only for tvOS and watchOS builds right now).
My guess is that xamarin is packing a lot of unneeded stuff, maybe old images or similar that you are no longer using. I have experienced that myself.
Go to you project folder and delete everything in the obj folder
<myproject>/iOS/obj/
Usually you will see two folders in there: iPhone and iPhoneSimulator.
Delete those and build everything again, there's a good chance that will solve it
Are you using the same version of Xamarin to build your code. I am willing to bet that is the issue. Something changed in how Xamarin builds apps since the last time you released it and is blowing up your app build size.
If you actually have the same code you released back then do you know what version of Xamarin you used back then? Honestly since the only thing that's changed is the Xamarin compiler it is most definitely the issue.
There are four things to do:
DELETE bin and obj folder from client project
CHANGE architecture to only support 64
CONFIGURE the linker.
Best is to try and build your app with linker active, but the more nuget packages you use, the less likely this is
and most importantly:
Set your build config to RELEASE and not DEBUG
(if you forget that, stores will accept your app but size can easily be doubled or even trippled)
This is how the minimal setup should look like:
Then dont forget that XAMARIN adds libraries like crazy to your app. I once read that the smallest app with NO content at all is at least 7 MB. This only gets larger with each package and each new dependency.
Currently our Xamarin Android app (PCL) is huge in my opinion, even in release mode. I suspect it is due to supported architectures. Currently we have them all selected. Does anyone know if we have to select all of these? We are not using the Android NDK at all as well.
I will copy part of my answer from here.
Make sure you are at least checking the following architectures: armeabi-v7a and x86. You could do the other three but we do not since we use LLVM compiling in release mode, which is not compatible with the 64 bit architectures (except for armeabi, which is deprecated). The good thing about that is that all of the 64 bit architectures can still use 32 bit builds so they all still get covered if you check those 3.
So I would just check those 3 unless you have a specific reason to check the other ones. We have had 0 problems installing our app on devices using those 3 only.
On a side note, turning on LLVM compiling and optimizing your icons/images will help with the final APK size.
*Edit: Since writing this we ran into a bug only on certain devices (Android Nexus 9) which leads to app crashes when launching the app. The solution is to check the arm64-v8a architecture. This will probably increase app size so weigh the pros and cons and see how much of a difference it makes in your APK size after including the architecture or split your APK for each architecture if necessary.
No you do not have to select all of them. You can create an .apk per ABI if you wanted to to reduce the size of your .apk. Note: The encouraged method is that you develop and publish a single .apk. However this is not always practical, and sometimes it's better to create separate ones. Although this answer only goes into depth about different CPU Architectures (ABI), you could also create different .apk for screen size, device features, and API levels.
https://developer.xamarin.com/guides/android/advanced_topics/build-abi-specific-apks/
http://developer.android.com/google/play/publishing/multiple-apks.html
I would recommend grabbing a tool like WinDirStat(https://windirstat.info/) or Disk Inventory X(http://www.derlien.com/) to investigate why your .apk is so large. You might find other reasons why your .apk is large such as resources(images, raw files), assemblies, etc.
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.