We have noticed the following message from Apple when performing
submissions with Xamarin.iOS:
> ITMS-90338: Non-public API usage - The app references non-public
> selectors in WcBc.iOS: behaviorTypes, convolutionState,
> discoverAllContactUserInfosWithCompletionHandler:,
> discoverAllContactsCompletionBlock,
> discoverUserInfoWithEmailAddress:completionHandler:,
> discoverUserInfoWithUserRecordID:completionHandler:,
> discoverUserInfosCompletionBlock, displayContact, drawableResizesAsynchronously,
> encodeToCommandBuffer:sourceImage:convolutionState:,
> encodeToCommandBuffer:sourceImage:destinationImage:state:,
> getProperty:onChannel:responseHandler:, hasProperty:onChannel:responseHandler:,
> initWithEmailAddresses:userRecordIDs:, initWithMIDIEntity:dataReadyHandler:,
> initWithZoneID:options:, initWithZoneID:subscriptionID:options:,
> isPublicDatabase, mouseUpAction, newDrawable, propertyChangedCallback,
> removeAllAppearanceStreams, replaceTextStorage:, retrieveConnectedPeripherals,
> retrievePeripherals:, setDiscoverAllContactsCompletionBlock:,
> setDiscoverUserInfosCompletionBlock:, setDrawableResizesAsynchronously:,
> setEditedMask:, setMouseUpAction:, setMovieControlMode:,
> setProperty:onChannel:responseHandler:, setPropertyChangedCallback:,
> setSocketFamily:, setTemporaryAttributes:forCharacterRange:, setUserRecordIDs:,
> sourceOffset, subscriptionOptions, takeBackgroundColorFrom:, takePasswordFrom:,
> temporalAntialiasingEnabled, userRecordIDs. If method names in your source code
> match the private Apple APIs listed above, altering your method names will help
> prevent this app from being flagged in future submissions. In addition, note
> that one or more of the above APIs may be located in a static library that was
> included with your app. If so, they must be removed. For further information,
> visit the Technical Support Information at http://developer.apple.com/support/technical/
All of them have been removed but without a break in the API excep
"initWithMIDIEntity:dataReadyHandler:" wich does look like an error on
Apples side.
Empty stubs are used as much as possible except on those cases in which
a handler is called or an output variable should be modified (buffer,
out param) to minimize the users surprise at runtime.
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
beta 3 included a ton of bad update of availability. While it correctly
changed `13` to `14`, is also added `API_UNAVAILABLE(ios` to everything
```diff
-SR_EXTERN API_AVAILABLE(ios(13.0)) API_UNAVAILABLE(watchos) API_UNAVAILABLE(tvos, macos)
+SR_EXTERN API_AVAILABLE(ios(14.0)) API_UNAVAILABLE(ios, watchos) API_UNAVAILABLE(tvos, macos)
```
Those were corrected (lot of noise) if beta 4, along with few API
changes.
xharness needs to inspect project files, but can't do so through imported
projects, so move some of the logic from the imported shared.csproj to the
main csproj.
This fixes an issue where mtouch would complain about a missing --target-framework argument when it's not actually needed:
/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/bin/mtouch --launchsim bin/iPhoneSimulator/Release/MyApp.app [...]
error MT0086: A target framework (--target-framework) must be specified.
what makes this worse is that passing --target-framework to mtouch makes
mlaunch fail, because mlaunch doesn't accept a --target-framework argument.
We have noticed the following message from Apple when performing
submissions with Xamarin.iOS:
> ITMS-90338: Non-public API usage - The app references non-public
> selectors in WcBc.iOS: behaviorTypes, convolutionState,
> discoverAllContactUserInfosWithCompletionHandler:,
> discoverAllContactsCompletionBlock,
> discoverUserInfoWithEmailAddress:completionHandler:,
> discoverUserInfoWithUserRecordID:completionHandler:,
> discoverUserInfosCompletionBlock, displayContact, drawableResizesAsynchronously,
> encodeToCommandBuffer:sourceImage:convolutionState:,
> encodeToCommandBuffer:sourceImage:destinationImage:state:,
> getProperty:onChannel:responseHandler:, hasProperty:onChannel:responseHandler:,
> initWithEmailAddresses:userRecordIDs:, initWithMIDIEntity:dataReadyHandler:,
> initWithZoneID:options:, initWithZoneID:subscriptionID:options:,
> isPublicDatabase, mouseUpAction, newDrawable, propertyChangedCallback,
> removeAllAppearanceStreams, replaceTextStorage:, retrieveConnectedPeripherals,
> retrievePeripherals:, setDiscoverAllContactsCompletionBlock:,
> setDiscoverUserInfosCompletionBlock:, setDrawableResizesAsynchronously:,
> setEditedMask:, setMouseUpAction:, setMovieControlMode:,
> setProperty:onChannel:responseHandler:, setPropertyChangedCallback:,
> setSocketFamily:, setTemporaryAttributes:forCharacterRange:, setUserRecordIDs:,
> sourceOffset, subscriptionOptions, takeBackgroundColorFrom:, takePasswordFrom:,
> temporalAntialiasingEnabled, userRecordIDs. If method names in your source code
> match the private Apple APIs listed above, altering your method names will help
> prevent this app from being flagged in future submissions. In addition, note
> that one or more of the above APIs may be located in a static library that was
> included with your app. If so, they must be removed. For further information,
> visit the Technical Support Information at http://developer.apple.com/support/technical/
All of them have been removed but without a break in the API excep
"initWithMIDIEntity:dataReadyHandler:" wich does look like an error on
Apples side.
Empty stubs are used as much as possible except on those cases in which
a handler is called or an output variable should be modified (buffer,
out param) to minimize the users surprise at runtime.
Turns out we don't actually _need_ to know, in every case we use this knowledge it's
a performance improvement to not process the framework assemblies, so skip this for
now, since there's no harm done (except to the planet) to do some extra processing
by processing all assemblies in these cases.
This requires passing the root directory around in multiple places, since ResolveAllPaths
doesn't have access to the static class where we define the root directory.
Also call ResolveAllPaths in a few more places to ensure paths everywhere are resolved.
In .NET projects there's a default value for most properties, which means that
there won't necessarily be an AssemblyName property in a csproj. We need to know the
AssemblyName, so calculate it from the csproj filename (which is how .NET does it).
This turned out slighly complicated, because we're pass an XmlDocument around,
and the XmlDocument doesn't know the file from where it was loaded, so we need
to keep that information separately.