Deprecate iOS Objective-C create template flutter create --ios-language objc

[jmagman]

We have metrics that show in 2024 Q1 less than 1% of flutter create apps were Objective-C. Deprecate and remove the flag and templates.

1. Remove the checkbox from the Intellij plugin (VS Code extension does not seem to use this flag anywhere) Remove iOS languages from new project creation flutter-intellij#7439
2. Add a deprecation warning that the flag will be removed in a future release. Let that sit for a stable release or so to see if we get complaints.
3. Remove the --ios-language flag and templates from the tool.
4. Optionally: recreate Objective-C sample, example apps with the Swift template

Users will still be able to open ios/Runner.xcworkspace and add Objective-C code or replace the Swift code that's there with Objective-C.

macOS never had a flutter create -i objc option and only provided a Swift template #70598 (comment)

[stuartmorgan]

We have metrics that show in 2024 Q1 less than 1% of flutter create apps were Objective-C

Just app template, or is this actually all create calls? If we remove the flag entirely that would affect plugins too. (I don't expect that to a problem, I just want to make sure we're looking at all the relevant metrics.)

[jmagman]

For the same 3 month period, for flutter create -t plugin 92% was swift and 8% was objc.

[jmagman]

@stuartmorgan based on that number, would you like me to keep the -t plugin -i objc template for the plugin code? If I remove it from just the app code it would mean example/ would be a Swift app.

[stuartmorgan]

Interesting. I'm not surprised that it's higher since most people probably don't plan to interact with the native app code, whereas a plugin developer by definition is going to write native code, but I am surprised that it's that high. It would be nice to reduce our plugin template complexity, but that feels high to cut off (although of course someone sufficiently knowledgeable could still make a new plugin in Obj-C without a template).

What do you think about keeping it for plugins but having it print a box at the end saying we are considering removing support for creating Obj-C plugins in the future, with a pointer to a tracking issue we file, and asking them to comment about what their use case is for using Obj-C instead of Swift?

Alternately if it's reasonably easy to make a mixed-mode plugin (I forget the current state; is it easy now that everything is modules? /cc @hellohuanlin who has probably played with that the most recently), we could remove the template, and just update the plugin docs to explain how to add some Obj-C source to a plugin.

[jmagman]

What do you think about keeping it for plugins but having it print a box at the end saying we are considering removing support for creating Obj-C plugins in the future, with a pointer to a tracking issue we file, and asking them to comment about what their use case is for using Obj-C instead of Swift?

That sounds good to me. Are you okay with example/ becoming Swift even when the plugin is Objective-C? That actually sounds like a good thing as most apps are Swift, not Objective-C, so it's closer to the real-world use-case of their plugins.

[stuartmorgan]

Yes, I definitely don't want to keep the app template complexity around just for plugin examples; your point is an excellent one, and I would also bet that the vast majority of plugin examples don't have changes in the native code.

[flutter-triage-bot]

The triaged-tool label is irrelevant if there is no team-tool label or fyi-tool label.

[loic-sharma]

Not sure if this is a blocker, but FYI the add-to-app iOS module template only supports Objective-C: #23955

[jmagman]

Not sure if this is a blocker, but FYI the add-to-app iOS module template only supports Objective-C: #23955

Oh very good point, I forgot about that. We could probably relatively easily swap that to a Swift template? It just was never prioritized.

[jmagman]

What do you think about keeping it for plugins but having it print a box at the end saying we are considering removing support for creating Obj-C plugins in the future, with a pointer to a tracking issue we file, and asking them to comment about what their use case is for using Obj-C instead of Swift?

@stuartmorgan how do you think this should work in the IntelliJ workflow (it doesn't look supported for VS Code)? flutter/flutter-intellij#7439

Maybe we remove the radio button, and it's only supported from the command line for plugins? Or we keep the radio, but it's only enabled when the Project Type is "Plugin"?

[DanTup]

(VS Code extension does not seem to use this flag anywhere)

It is actually used, but we only pass it if it's not "swift":

https://github.com/Dart-Code/Dart-Code/blob/e3fa54627377b8246b52e6f9de414c224e649307/src/extension/commands/flutter.ts#L177

I can update the VS Code extension easily, but we should try not to make changes that break older versions of the plugins (at least for a little while).

Could we just ignore the flag when it's not supported and output a message (so the user would see some output telling them why the language wasn't what they'd configured)? (and I can update the text on the setting to indicate which Flutter versions/project types it works for).

(note: for VS Code, this is a setting that you set once and applies to all executions of the Flutter: New Project command, it's not chosen each time, so we can't enable/disable it based on the project type as suggested for IntelliJ above).

[stuartmorgan]

Maybe we remove the radio button, and it's only supported from the command line for plugins?

I think this is the most straightforward option. Making a new plugin isn't a frequent activity, so it's fine if people doing it have to hunt a bit to figure out how to use a deprecated path.

[DanTup]

In that case, does it seem reasonable for VS Code to:

1. Add "This setting is only supported for Flutter 3.22 and earlier" to the setting description
2. Never send the --ios-language flag if Flutter version is > 3.22

That will retain current behaviour for existing (and earlier) SDKs and make it easier to remove the flag in some distant future (because we'll know that all VS Code extensions since [approximately now] will not try to send it)?

[stuartmorgan]

Couldn't we just remove the setting instead? It doesn't seem like a big deal if people using new version of the VS Code lose UI access to this flag earlier than we drop it in the command line.

[DanTup]

It doesn't seem like a big deal if people using new version of the VS Code lose UI access to this flag earlier than we drop it in the command line.

We could, but I try to avoid removing/breaking functionality if not necessary.. it's more understandable for this functionality to stop working in a future SDK release than be taken away by the VS Code extension if you're still using the same SDK.

The VS Code extension already handles a lot of differences in SDK Versions so an extra condition like this is very minor (and easy to remove in future at the point we deem the older SDKs are not going to be supported by the extension).