We ship a default, pre-built, simlauncher for iOS simulator applications.
This speeds up compilation for the default (non linked) simulator builds
quite a lot (no call to `clang` is needed). However it force us to keep
track of frameworks manually - `mtouch` can track them but requires
calling clang/ld to finish things up (killing the optimization).
It's easy to forget some (new) frameworks since they can be loaded
dynamically (on demand) _most_ of the time. Sadly there are a few cases
where doing so cause (hard to diagnose) problems - so we can't depend
on them being loaded, correctly for us.
The new test case loads the `otool -L` output (make when we build
simlauncher[32|64]-sgen) and compares it with mtouch's GetFramework
logic *and* with our namespaces (which is pretty close, with a few
exceptions, to the framework names). This will make it harder to
forget [weak] frameworks when adding new bindings :)
Fixes https://github.com/xamarin/xamarin-macios/issues/6951
* [WatchKit] Remove this framework for iOS while keeping backwards compatibility. Fixes#6492.
* Copy all generated sources and modify them to throw PlatformNotSupported exceptions.
* Adjust some existing source code to also throw PlatformNotSupported exceptions.
* Sprinkle Obsolete attributes generously.
* Stop generating code for the WatchKit framework for iOS.
Fixes https://github.com/xamarin/xamarin-macios/issues/6492.
* [introspection] Adjust test.
* [mtouch] Don't link with WatchKit, and show a warning if we detect code that want to use WatchKit.
* [xtro] Remove WatchKit for iOS.
* [introspection] Don't check obsoleted NSString fields for null.
There's probably a reason the field was obsoleted.
* [introspection] Add exception for the WatchKit framework.
* [xtro] Ignore obsolete enums.
There's probably a reason they're obsoleted.
In particular it solves a confusion between WKWebKit.WKErrorCode and
WatchKit.WKErrorCode: for iOS, the latter is obsoleted, and this way we always
process the former instead.
* [mtouch] Adjust wording for MT4178 to be more accurate.
* [WatchKit] Make more API obsolete/hidden.
Two classes managed to slip past the first time.
* [tests] Adjust test after WatchKit removal.
Basic application (size) for doing an `HttpClient.GetAsync`, release/llvm, 64bits only
- NSUrlSessionHandler (master): 6.4 MB
- NSUrlSessionHandler (PR#5936): 7.7 MB
- NSUrlSessionHandler (this PR): 6.4 MB
The size increase occurs because of the reference to .net `X509*` types.
This brings a lot of additional code, including managed cryptographic
code, inside the application - even when the feature is **not** used.
The solution is to expose an API that only use native (OS) types, which
are mostly already part of the application. This has a very low impact
on existing applications.
It's still possible to hook back to .NET validation if needed (it should
not in most cases) but, in this case, the extra price will only be
_paid_ if used (and can be lower if the code is needed by something else
from the application).
In comparison using other `HttpClient` handler produce app sizes of
- HttpClientHandler (managed): 10.4 MB
- CFNetworkHandler: 6.8 MB
Based on/supersede https://github.com/xamarin/xamarin-macios/pull/5733
Fix https://github.com/xamarin/xamarin-macios/issues/4170
* [tests] Add introspection tests to ensure there are native linking instructions for all frameworks. Fixes#3976
or a good, documented (in test code) reason for not needing it.
https://github.com/xamarin/xamarin-macios/issues/3976
* Fix failures
- static registrar failed on 32bits because one type in PhotoUI missed
its `onlyOn64: true`
- link with the top, not the sub-frameworks
* [tvos] Fix mistakes in tvOS where some extranous types triggered unrequired/unavailable (or missing) frameworks
* [watchos] Fix watchOS frameworks mapping