NOTE (2022-07-09): Xcode finally added this functionality in Xcode 14, please see release notes here:
New Features in Xcode 14 Beta 3
When editing code, the Edit > Duplicate menu item and its corresponding keyboard shortcut now duplicate the selected text — or the line that currently contains the insertion point, if no text is selected. (8614499) (FB5618491)
-
Close Xcode
-
Open below directory in Finder with Cmnd + Shift + G
/Applications/Xcode.app/Contents/Frameworks/IDEKit.framework/Versions/A/Resources/
-
Open
IDETextKeyBindingSet.plist
with a text editor. -
Add this in:
<key>Duplication</key>
<dict>
<key>Duplicate Current Line</key>
<string>moveToBeginningOfLine:, deleteToEndOfLine:, yank:, insertNewline:, moveToBeginningOfLine:, yank:</string>
<key>Duplicate Lines</key>
<string>selectLine:, copy:, moveToEndOfLine:, insertNewline:, paste:, deleteBackward:</string>
<key>Delete Line</key>
<string>selectLine:, deleteBackward:</string>
</dict>
-
Open Xcode and go to
Xcode preferences
->Key Bindings
->Text
tab -> Scroll till you seeDuplication
-
Click on
Duplicate Current Line
, add a shortcut for it, eg. Cmnd + D (remove any other bindings for this key)
@Sidelobe not really.. because you should check for any breaking changes before inserting new lines into a file too.. while it’s not likely that you’d break it by adding a hot key property, it is possible some conflicting entry was added to the new file that you could break with the addition. Either way it’s best to check before blindly changing. Checking also takes only a second as there should be little to no changes in the file between updates aside from your own. A diff would give a handful at lines at most; one of those changes would be your change ironically saving you the time to remember/find and type it out since you could copy it from there. I’d say write a shell script to add those lines to that file but if you did this, you could also have it check for differences before doing so which would take even less time.
Honestly, adding the lines to the new file is the the more likely route to encounter a breaking change. If you were completely replacing the updated file with the modified file it would at least be removing any conflicting or breaking additions they added to the updated version which likely aren’t detrimental to the operation of the software to remove.. simply inserting into the file without seeing what might have changed first is actually worse than skipping the diff step from my approach. But if you enjoy wasting time and possibly causing headaches when creating a conflict the software isn’t expecting and has no way of reporting the cause of… sure skip the most important step of the process. I mean… you could even have the script make a temp new file with the additions then compare its hash to your previous.. if it matches rename the new file to the XCode path.