src/libraries/System.Runtime/tests/System.Globalization.Calendars.Tests/CalendarTestWithConfigSwitch/CalendarTests.cs:25

• The test comment says the legacy behavior "On mobile, this does not throw", but after removing the Apple mobile skip this test will run on Apple mobile and still asserts a FormatException. Either update the comment to the specific platform(s) where it doesn’t throw (e.g., Android-only), or extend the skip/condition so the assertion matches actual mobile behavior.

        [Fact]
        [SkipOnPlatform(TestPlatforms.Android, "Doesn't throw on mobile")]
        public static void TestJapaneseCalendarDateParsing()
        {
            CultureInfo ciJapanese = new CultureInfo("ja-JP") { DateTimeFormat = { Calendar = new JapaneseCalendar() } };

            DateTime dt = new DateTime(1970, 1, 1);
            string eraName = dt.ToString("gg", ciJapanese);

            // Legacy behavior which we used to throw when using a year number exceeding the era max year.
            //
            // On mobile, this does not throw, but instead produces a DateTime w/ 95/01/01
            Assert.ThrowsAny<FormatException>(() => DateTime.Parse(eraName + " 70/1/1 0:00:00", ciJapanese));
        }

src/libraries/System.Collections/tests/BitArray/BitArray_CtorTests.cs:280

• Re-enabling this test on Apple mobile means it will allocate a BitArray of length int.MaxValue-30 (~256MB+), which is likely to OOM or heavily destabilize test runs on memory-constrained devices. Consider reducing the allocation size while still covering the clone path, or gating this test (e.g., OuterLoop / platform-conditional) for constrained environments.

        [Fact]
        public static void Clone_LongLength_Works()
        {
            BitArray bitArray = new BitArray(int.MaxValue - 30);
            BitArray clone = (BitArray)bitArray.Clone();

            Assert.Equal(bitArray.Length, clone.Length);
        }

src/libraries/System.Runtime/tests/System.Runtime.Tests/System/Runtime/CompilerServices/RuntimeFeatureTests.cs:49

• In DynamicCode_Jit(), the Apple mobile-specific expectation (IsDynamicCodeSupported == true, IsDynamicCodeCompiled == false) was removed, and the remaining else-branch now asserts IsDynamicCodeCompiled == true for all non-NativeAOT runtimes. iOS/tvOS generally do not support JITted dynamic code, so this would make the test incorrect if/when the ActiveIssue gate is removed; consider restoring a platform-specific expectation (or using an existing PlatformDetection predicate that reflects dynamic code compilation support).