Add a GatherFrameworksStep that computes the frameworks an app needs, and
returns the result to the MSBuild tasks.
Then we use that list of frameworks to link the native executable correctly.
New framework - but it includes some of iOS API that were previously in
QuickLook.framework. Types were moved but remains in the old namespace
until `XAMCORE_4_0` is defined.
* [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.
Moved some code from uikit.cs since the type moved a while ago. That
ease code sharing with macOS (XM) but it stays into the UIKit namespace
(for XI) until `XAMCORE_4_0` to ensure binary compatibility.
* adding Speech
* Style changes and fixed copyright
* fixing requested changes
* adding spacing to make less red in diff
* adding [DisableDefaultCtor] to SFSpeechRecognitionResult and SFTranscription
* Update src/speech.cs
Co-Authored-By: Alex Soto <alex@alexsoto.me>
* Update src/speech.cs
Co-Authored-By: Alex Soto <alex@alexsoto.me>
* Update src/speech.cs
Co-Authored-By: Alex Soto <alex@alexsoto.me>
* Adding PencilKit to the src
* forgot the mac constants
* adding PencilKit and fixed whitespace
* removing whitespace
* removed mac capabilities and added ignore for PencilKit.todo
* removed newline
* added the iOS-PencilKit.ignore file
* removed pencilkit.todo
* adding DesignatedDefaultCtor
No change in beta 2
This enable PushKit on watchOS and macOS.
Availability macros suggest this is available on tvOS 13 but the
headers are not in the tvOS SDK (at least in beta 2)
No change in beta 2
This enable some API in macOS. Headers are now present and some types are
marked as unavailable on macOS - but, sadly, nothing got marked as new
for 10.15 :|
* adding Sound Analysis
* set up error domain and added CMTimeRange for all platforms except watch
* removed whitespaces
* removed more whitespaces
* edited framework files and constants. Changed header names and added todo files
* Apply feedback
* fixing head and skipping functions with class issues
* fixing spacing-tab issues
So far this only applies to `QTKit`...
XM will now, by default, avoid natively link with QTKit unless it's
instructed to so explicitly using `--link-prohibited-frameworks`
ref: https://github.com/xamarin/xamarin-macios/issues/6039
I'm not sure why we have an entry in our list of frameworks claiming that
iTunesLibrary was introduced in macOS 10.9, when we didn't have any bindings
for the library back then.
In any case we also have an entry for iTunesLibrary in our list of frameworks
claiming that iTunesLibrary was introduced in macOS 10.14.
I looked at some of Apple's documentation for the types in iTunesLibrary, and
they all claim to be introduced in macOS 10.13 [2].
And to make matters even more interesting, Apple's documentation for the
framework itself states the library is in
/Library/Frameworks/iTunesLibrary.framework, and ships with iTunes 11.0+ [1]
(which is introduced in 2012).
Then I looked at a macOS 10.14 machine, and the framework is available at
/System/Library/Frameworks/iTunesLibrary.framework, and
/Library/Frameworks/iTunesLibrary.framework is just a symlink there
(/System/Library/Frameworks/iTunesLibrary.framework does not exist on my macOS
10.13 machines, while /Library/Frameworks/iTunesLibrary.framework does). From
this I conclude that the framework was converted into a
system framework in macOS 10.14, and as such our claim that the framework was
introduced in 10.14 is at least somewhat right.
So treat iTunesLibrary as any other framework introduced in macOS 10.14, and
remove our (duplicated) framework entry for 10.9 (for which we didn't have any
bindings anyway).
Also fix the path to the framework, I'm wonder how this got past our tests in
the first place.
[1] https://developer.apple.com/documentation/ituneslibrary: "... located at /Library/Frameworks/iTunesLibrary.framework ... The iTunes Library framework is available to users running iTunes v11.0 or above."
[2] https://developer.apple.com/documentation/ituneslibrary/itlibrary?language=objc
Linking with CoreNFC crash applications on iOS 12 on iPad (and likely
other device not supporting, or supported, for NFC).
This used to work on iOS 11.x (when introduced). The solution is to
always **weak** link CoreNFC (since we can't guess devices)
https://github.com/xamarin/xamarin-macios/issues/4628
* CoreFoundation/DispatchData: avoid possible integer overflow
* Network: move attributes for types introduced in Xcode10 from the
members to the types.
* Network: for callbacks that surface INativeObjects, rather than using
* Hide P/Invokes that are not currently surfaced so xtro tests can track this
* guidelines: Ip -> IP
* SecIdentity2: fix a leak by releasing the returned array, check for handle being null.
* SecTrust2: check for handle being null.
Fixes this problem in the MT4134 test:
Process exited with code 1, command:
/Applications/Xcode83.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -Wno-receiver-forward-class -Wno-objc-missing-super-calls -gdwarf-2 -I/Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/MonoTouch.iphonesimulator.sdk/usr/include -isysroot /Applications/Xcode83.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator10.3.sdk -Qunused-arguments -fobjc-legacy-dispatch -fobjc-abi-version=2 -mios-simulator-version-min=11.4 -arch x86_64 -c -o /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.Tests.BundlerTool.CreateTemporaryDirectory513/mtouch-test-cache/x86_64/registrar.o -x objective-c++ /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.Tests.BundlerTool.CreateTemporaryDirectory513/mtouch-test-cache/registrar.m
In file included from /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.Tests.BundlerTool.CreateTemporaryDirectory513/mtouch-test-cache/registrar.m:2:
/Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.Tests.BundlerTool.CreateTemporaryDirectory513/mtouch-test-cache/registrar.h:47:9: fatal error: 'MetalPerformanceShaders/MetalPerformanceShaders.h' file not found
#import <MetalPerformanceShaders/MetalPerformanceShaders.h>
Note that the error is because the test is building with Xcode 8.3 (and this
is also why the problem wasn't found by the PR bots: they don't have older
Xcodes installed to run this particular test).
Unify the code to detect frameworks that aren't supported in the simulator (we
had switches in two places, now this data is stored per framework).
Also remove some of the Metal frameworks for some of the platforms from these
lists (since they're now available in the simulator in some cases), which
fixes#4422.
It also seems CoreAudioKit is now available in the simulator (it wasn't in the
first Xcode 7 beta, but apparently added in a later beta. This made our
exclusion incorrect, but we never noticed).
https://github.com/xamarin/xamarin-macios/issues/4422