chore(ios): drop iOS 9 support #11385
Conversation
|
|
Is this really necessary? I see many apps that want to support this version, as well as competitive frameworks that still maintain it. And since it's compiled out during build time anyways, it doesn't hurt anyone. |
| } | ||
|
|
||
| [(UIMutableUserNotificationAction *)[self notificationAction] setAuthenticationRequired:[TiUtils boolValue:value]]; | ||
| DebugLog(@"[WARN] This property is not available in iOS 10+."); |
There was a problem hiding this comment.
mark as deprecated/removed in 9.0.0 in our docs
| } | ||
|
|
||
| [(UIMutableUserNotificationAction *)[self notificationAction] setDestructive:[TiUtils boolValue:value]]; | ||
| DebugLog(@"[WARN] This property is not available in iOS 10+."); |
There was a problem hiding this comment.
mark as deprecated/removed in 9.0.0 in our docs
There was a problem hiding this comment.
Actually these properties are available but at creation time only for iOS 10+. Manual setters are not available. I think I should delete these setters.
There was a problem hiding this comment.
@sgtcoolguy Deleted setters as these are creation-only. These properties are already used while calling - (void)_initWithProperties:(NSDictionary *)properties.
| } | ||
|
|
||
| [(UIMutableUserNotificationAction *)[self notificationAction] setBehavior:[TiUtils intValue:value]]; | ||
| DebugLog(@"[WARN] This property is not available in iOS 10+."); |
There was a problem hiding this comment.
mark as deprecated/removed in 9.0.0 in our docs
| } | ||
|
|
||
| [(UIMutableUserNotificationAction *)[self notificationAction] setActivationMode:[TiUtils intValue:value]]; | ||
| DebugLog(@"[WARN] This property is not available in iOS 10+."); |
There was a problem hiding this comment.
mark as deprecated/removed in 9.0.0 in our docs
|
@hansemannn Is it necessary, I suppose not we: could try to maintain backwards compatibility with every version of every OS. But we kept iOS 9 around for at least one (possibly 2) full breaking release cycles past our own internal usage thresholds before. This cleans up some of our code, and according to analytics we have near-zero usage on iOS 9 devices (and looking at Apple/3rd party stats also confirms this - there's really only the interesting case of old iPads "stuck" at 9 due to Apple's OS upgrade limit on them). Additionally, what's not really shown/discussed here is that the minimum iOS version also plays role in the JS polyfilling layer we have. Moving up one major version should help drop a significant number of shims/polyfills for ES6 support. (See https://caniuse.com/#compare=safari+9,safari+10&compare_cats=JS ) |
|
Despite the fact that probably only 20 % of the Titanium actually use the Appcelerator Analytics, I feel like the benefits are not enough to do this right now. iOS 8 was dropped just in SDK 8.0.0, but if no one complains now, it's probably okay. |
|
|
||
| this.minIosVer = this.tiapp.ios['min-ios-ver'] || defaultMinIosVersion; | ||
|
|
||
| if (version.gte(this.iosSdkVersion, '10.0') && version.lt(this.minIosVer, '10.0')) { |
There was a problem hiding this comment.
I think maybe this check and the check on 2125 used to be useful (this line looks to have been to force people down the right path #8198) but now our minimum is 10 maybe it's redundant?
this.iosSdkVersion >= 10 and this.iosSdkVersion >= 6 will always be true nowadays, and this.minIosVer < 10 being true seems to duplicate the check on 2128 where we force the minimum to 10 if someone sets it to 9??
|
FR Passed. |
https://jira.appcelerator.org/browse/TIMOB-27641