You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm kind of surprised this enum was introduced at all, I thought we had discussed holding off on all iOS 14 changes until the 1.20 stable branch was cut, then updating to iOS 14 without options to fallback, the way it was done in previous years.
\cc @xster
I think that should continue to be the plan for new OS features. In this case I believe @ctrysbita specifically needed the enum, and planned to remove it by the time iOS 14 was released.
Hi, I think there are still some problems with our rules for new iOS features.
According to the statistics from App Store Support, 81% of all iPhone devices use iOS13. There are still a lot of users keep using iOS12- or their devices cannot upgrade to iOS13. If the latest framework only support the behavior for latest version of iOS, our app may work quite different than native behavior on these devices (about 1/5) without any choice. Developers cannot make the app behave according to specific iOS version.
Our material widget library also keeps the deprecated material 2014 style and the old transition animation before Android 9 which means developers can switch the standard to use according to the actual OS version.
I agree it would be nice to support old OS versions, but the reason why we have avoided it (besides a few cases) is because it's a big maintenance burden for Flutter. It's tough just to keep up with the latest OS versions, and adding the need to maintain older versions as well is, we think for now, not the best use of limited resources.
In this case, I think it's fair to deprecate iOSVersionStyle now and default to iOS14 style. We can wait to fully remove iOSVersionStyle until iOS14 adoption is the obvious majority.
@ctrysbita our current stable has only the present styling and we expect the next stable release to roll out after iOS 14 is past golden master. We believe it shouldn't be a mainstream use case to have to toggle between the 2 styles actively on the same SDK revision. Do you have a specific use case for it?
For an example.
Currently in my flutter app, I use FadeUpwardsPageTransitions for Android 8.0-, OpenUpwardsPageTransitions for Android 9.0+ and CupertinoPageTransitions for iOS. For each platform and OS version the app will behave like their native apps.
But @justinmc is right, if our resources are quite limited, deprecate the old style and only support for the latest one would be better.
I think we should totally remove iOSVersionStyle altogether, and close this issue once that is done. There was some discussion about this here.
@ctrysbita Are you available to open another PR removing iOSVersionStyle and the enum? iOS14 is being released tomorrow, so it's probably time to start doing that.
I don't believe this has been given the attention it deserves. At the very least we should commit to supporting the last two versions, and automatically. We're just throwing out work every time there is an iOS release. These things can be built in such a way that bit rot will be minimal.
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.
Activity
jmagman commentedon Jul 29, 2020
\cc @justinmc @edwardaux @ctrysbita
jmagman commentedon Jul 29, 2020
I'm kind of surprised this enum was introduced at all, I thought we had discussed holding off on all iOS 14 changes until the 1.20 stable branch was cut, then updating to iOS 14 without options to fallback, the way it was done in previous years.
\cc @xster
justinmc commentedon Jul 29, 2020
I think that should continue to be the plan for new OS features. In this case I believe @ctrysbita specifically needed the enum, and planned to remove it by the time iOS 14 was released.
jmagman commentedon Jul 29, 2020
If the deprecation lands in master now, it should get to stable coinciding with when iOS 14 releases.
ctrysbita commentedon Jul 30, 2020
Hi, I think there are still some problems with our rules for new iOS features.
According to the statistics from App Store Support, 81% of all iPhone devices use iOS13. There are still a lot of users keep using iOS12- or their devices cannot upgrade to iOS13. If the latest framework only support the behavior for latest version of iOS, our app may work quite different than native behavior on these devices (about 1/5) without any choice. Developers cannot make the app behave according to specific iOS version.
Our material widget library also keeps the deprecated material 2014 style and the old transition animation before Android 9 which means developers can switch the standard to use according to the actual OS version.
justinmc commentedon Jul 30, 2020
I agree it would be nice to support old OS versions, but the reason why we have avoided it (besides a few cases) is because it's a big maintenance burden for Flutter. It's tough just to keep up with the latest OS versions, and adding the need to maintain older versions as well is, we think for now, not the best use of limited resources.
In this case, I think it's fair to deprecate iOSVersionStyle now and default to iOS14 style. We can wait to fully remove iOSVersionStyle until iOS14 adoption is the obvious majority.
xster commentedon Jul 30, 2020
@ctrysbita our current stable has only the present styling and we expect the next stable release to roll out after iOS 14 is past golden master. We believe it shouldn't be a mainstream use case to have to toggle between the 2 styles actively on the same SDK revision. Do you have a specific use case for it?
ctrysbita commentedon Aug 2, 2020
For an example.
Currently in my flutter app, I use
FadeUpwardsPageTransitionsfor Android 8.0-,OpenUpwardsPageTransitionsfor Android 9.0+ andCupertinoPageTransitionsfor iOS. For each platform and OS version the app will behave like their native apps.But @justinmc is right, if our resources are quite limited, deprecate the old style and only support for the latest one would be better.
jmagman commentedon Sep 15, 2020
@justinmc Can this be closed as of #62741?
Let's never do this again...
justinmc commentedon Sep 15, 2020
I think we should totally remove
iOSVersionStylealtogether, and close this issue once that is done. There was some discussion about this here.@ctrysbita Are you available to open another PR removing
iOSVersionStyleand the enum? iOS14 is being released tomorrow, so it's probably time to start doing that.ctrysbita commentedon Sep 16, 2020
@justinmc Sure, I'm working for it.
justinmc commentedon Sep 16, 2020
@ctrysbita Thanks for the quick response! Tag me for review whenever you want.
ctrysbita commentedon Sep 22, 2020
@justinmc Now this can be closed.
justinmc commentedon Sep 22, 2020
Awesome, thank you!
lukepighetti commentedon Oct 17, 2020
I don't believe this has been given the attention it deserves. At the very least we should commit to supporting the last two versions, and automatically. We're just throwing out work every time there is an iOS release. These things can be built in such a way that bit rot will be minimal.
github-actions commentedon Aug 11, 2021
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.