[Discussion] Convert Xvim to an Xcode extension

[FWFabio]

The new Xcode 8 won't allow plugins anymore. Instead they're launching a new extension mechanism that allow for direct access to the source code editor view.

I'm planning to explore the possibility at WWDC and will update the issue as soon as I have more info.

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/35165827-discussion-convert-xvim-to-an-xcode-extension?utm_campaign=plugin&utm_content=tracker%2F252770&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F252770&utm_medium=issues&utm_source=github).

[JugglerShu]

Finally this day comes... I don't know if this turns out good news or bad one. I hope we can reuse the code we made so far.

[duhanebel]

There is not much details for now. We surely can't use the text editor extension because as far as I can see those are triggered by menu items. There's zero documentation on the topic at the moment and I believe most of feature didn't make into the first beta of Xcode 8. It's quite hard to understand what's the way forward.

What's worse is that I think Apple is killing the standard plugin architecture with Xcode 8 to boost security: only signed extensions can be loaded and they execute in a separate process.

[JugglerShu]

I think at least there should be work around. The only thing I need to make XVim work is that a dynamic library can be loaded into Xcode process. Because Xcode7.3 and before the plugin system loads a plugin I used it to load a dynamic library. Even if new Xcode itself doesn't load any 3rd party library, if we have root privilege we can inject a dynamic library into Xcode process by ourself.

[EkkoG]

Apple add a quick comment feature for Xcode 8 by use VVDocumenter-Xcode (https://twitter.com/onevcat/status/742732675983638533) there maybe some way to convert standard plugins to new Xcode extensions.

[duhanebel]

@jugglershu that won't work because Xcode 8 library loading is protected by System integrity Protection :/

[bjaskj]

Bump, vim func in Xcode is a must.

[haaakon]

It does not look good for XVim on XCode 8. Can everyone please send radars and try to get Apple to let this be possible in XCode 8? Not looking forward to using XCode without Vim mode :(

[SixFiveSoftware]

I submitted a radar for vim key bindings a few months ago and it was closed as a duplicate.

[squarefrog]

I wonder if we'll have a better idea after Session 414: Using and Extending the Xcode Source Editor. @haaakon what have you put in your radar? What exactly are extensions lacking?

[jklausa]

@duhanebel would disabling SIP help? I'd really fucking hate to run an unsafe system just to able to use the IDE, but if this is what it takes...

[duhanebel]

Disabling SIP should be enough but it's a pain in the back to disable it on each software update and I'm not sure how long Apple will allow us to.

[haaakon]

@squarefrog The System integrity Protection should allow the plugin. Maybe the plugin has to be integrated directly to XCode as the VVDocumenter plugin has?

@duhanebel have you confirmed that its possible to disable it and then run XVim?

[duhanebel]

@haaakon I'm not running 10.12 yet but even so, this first Xcode beta seems fairly incomplete. I need to go to the lab this afternoon (it's 9am here) and confirm with somebody form the Xcode team. Provided that they're willing to tell me!

[JugglerShu]

So I made it work with Xcode 8.0 beta. But it is tricky and I can't recommend you to do it by yourself. I'm working on how to make it possible by everyone now. And due to the changes in Xcode 8.0, it seems XVim leads some crashes too (but this is not big problem since I can fix it anyway...)

Update: Well I found it's not as tricky as I expected... I think I can publish how to do it soon.

[squarefrog]

:+1: looks like a promising start!

[duhanebel]

@JugglerShu how did you manage to load it? Do you want me to ask anything to the Apple engineers at WWDC?

[keith]

After asking in the WWDC labs it sounds like providing a rich enough API to be able to build XVim isn't something that is currently planned.

[duhanebel]

@keith that doesn't sound good. Not even with the editor extensions? I haven't seen any docs on that after the announcement but perhaps is coming in a future seed?

[JugglerShu]

@keith Ask them how apple engineers are using Xcode without XVim? hah.

@duhanebel It was actually easy. Please wait my announcement about it. Also I think APIs cannot have enough flexibility to support XVim since it is really complex and cannot be done with just simple method calls. It should require some callbacks or rather a kind of framework that is dedicated to support XVim.

[haaakon]

@JugglerShu maybe your plugin can get special access? At least we as a community have to push Apple letting them know that this is a core feature for alot of XCode developers

A guy from Apple replies in a Twitter conversation about XVim:

(https://twitter.com/jeremyhu/status/743316938940514305)

So if all 4000+ people that have starred the XVim repo report radars and talk to Apple, maybe we can turn them around on this :)

[yury]

@haaakon it should be separate radars? or I can vote somewhere?

[haaakon]

@yury i think it's best to create separate radars, the reported bugs aren't public. But you can publish your radar at http://www.openradar.me/ as well to make it public (not made by Apple)

Maybe @JugglerShu can share the details on what we should report as missing needed to add XVim to Xcode 8?

[jdschroeder]

@yury You basically vote by creating a radar. It'll likely be marked as a duplicate, and as I understand it, highly duplicated issues do tend to get the attention of Apple engineers, so the more of us filing radars, the better.

[yury]

@haaakon, @jdschroeder thanks. Posted to radar.

[davidquon]

Can someone make a template for what the radar should be asking for (or post links to Open Radars)?

[jklausa]

https://openradar.appspot.com/radar?id=5523443067912192

[squarefrog]

Given that it's unlikely apple will create vim key bindings as a first class plugin, I wonder if it's more worthwhile stating what functionality is missing from extensions?

From a cursory glance it seems that there is no text input listener or delegate method available which would be the first request. It seems text substitution is possible,

I suppose a shouldChangeText: which returns bool type call would allow the basic movement. This could pass the text through if in insert mode etc.

What else specifically?

[haaakon]

I agree @squarefrog , @JugglerShu should tell us and we can submit radars for it :)

[JugglerShu]

Now the master branch should work with Xcode 8 beta.

What it actually does is removing code signature from Xcode-beta.app . So if you don't like to unsign the Xcode, just don't use it.

With new Makefile, when invoke make, it will ask you if it is OK to remove Xcode signature. press y to it to proceed and after that is as same as before.

The original Xcode file is backed up as

• /Path/to/Your Xcode.app/Contents/MacOS/Xcode_orig

so you can revert to the original by copying it as

• /Path/to/Your Xcode.app/Contents/MacOS/Xcode

If something is totally corrupted, just re-download the original Xcode from Apple (Makefile is not really well tested yet.)

[jklausa]

I mean, yeah, that is a workaround but I can't be the only one that's more than slightly worried that this involves stripping the signature of the IDE.

[haaakon]

Cool that you got it working @JugglerShu , this will probably be unsafe to use, and i guess you won't be able to submit apps and such with XCode that way? Seems to me like i won't use this solution because of the security risks, but i don't know enough about it to know for sure yet.

As asked before, could you give som feedback on what is needed for XCode 8 to work with XVim on a Apple Supported way? This way we can submit radars for the feature to be implemented as soon as possible.

[jklausa]

and i guess you won't be able to submit apps and such with XCode that way?

well that one is fairly easily worked-around, you could have Xcode-XVim, that's codestripped and with Xvim enabled that you use for development, and untouched, signed Xcode.app that's used to make final builds of your app.

not ideal by any means, of course.

[JugglerShu]

@haaakon So you mean you may not submit your app developed by the Xcode without its signature? As far as I understand it (Well, I don't know well about Apple's signature system but just from the general signature logic), stripping signature from Xcode doesn't affect the generated app as far as it is working as usual. I don't think they are using any information from the signature of Xcode to sign your app. Is this not correct?

The main part of XVim can be implemented by hooking key input. So if every key input can be intercepted and processed by our code, main part should be implemented. (Of course we need an access to the text.)

Also some feature requires access to Xcode operations (like split window, open counterpart).

Things which looks difficult is command line and visual mode part. Command line is embedded in the Xcode view. I don't think they are going to prepare command line just for XVim... I don't know how extension works but if it is possible to display window (even in another process), it might be workaround. For visual mode, we need an API to select specific part(including block) and update it as key input.

Having said that, I think it should take a long time to support all the features current XVim has. Maybe starting from intercepting keys and some basic features (editing text) would be realistic.

Actually I don't want to go to that way because it is so time consuming. When I want to implement something I have to look for API and if not exist I have to ask Apple to implement it and wait for several weeks or months and repeat this again and again. So as far as XVim can be loaded into Xcode process (somehow), I would use that method to support XVim until enough APIs coming up.

[JugglerShu]

@jklausa Yea, I can understand that people don't like to remove signature from apps. But I'm not so worried about it personally because it is originally signed and if once it is checked, as far as the binary hash is the same, it is "probably" OK. Some risks are like,

• You cannot detect the binary modification after removing the signature.
• You cannot detect dynamic( in process) binary patching.
• And maybe other possibility like unknown libraries are loaded into the process (but this is what XVim requires so...)

Well, actually I'm thinking one more step now. That is

• After remove the signature, sing the Xcode with the users identity.
• Then build and sign XVim with users identity.

This may permits XVim loaded into Xcode and also system should detect the binary change (as far as my understanding of the Apple's signature system is right).

[FWFabio]

@JugglerShu @jklausa The Xcode signature should have nothing to do with App submission. It's just a mechanism to validate Xcode binary's integrity. Resigning the app and the plugin with your own signature might do the trick (that's how frameworks work in iOS) but I haven't managed to sign Xcode yet because of some issues with code signing.

[JugglerShu]

@FWFabio Yes, that should be true. Unfortunately, apple official code signing tool doesn't support unsigning an app. So I used 3rd party tool to unsign but it seems the app cannot be signed once the signature is removed by the tool.

Overall, my current opinion is to make a request to Apple to open old plugin system for a signed plugins (if users accepts that signature) at least until Apple prepares enough API to support current useful plugins. Since plugins are often build by the users(including XVim), users can accept all the plugins singed by themselves and Xcode should load it. With this, there is no risk and no tricky operation is required.

[duhanebel]

@JugglerShu ah! True. Removing the signature breaks the system but if you just replace the signature it works fine! I've signed both Xcode and the plugin with my Developer ID and it loads just fine.

Re asking Apple to keep the old plugin architecture: I'll dupe the radar if you file it.

[haaakon]

Sounds like a good plan @JugglerShu

[FWFabio]

I've opened a radar re extension interface: https://openradar.appspot.com/radar?id=5537580623855616 or rdar://26940161

[jklausa]

(My radar was closed as a dupe of 26781374)

[duhanebel]

Same here!

[tkuichooseyou]

Mine was closed as a dupe of 3716281

[joshingly]

My radar got marked as a dupe of 3716281 as well.

[JugglerShu]

@duhanebel It seems that it only requires us to re-sign the Xcode and not signing to XVim. I just re-sign Xcode 8 beta and it loads XVim (which is not signed at all). Can you confirm that? I will change Makefile just to re-sign the app (It may require manual operation since I don't know which identity users want to use, though)

[ManWithBear]

@duhanebel can you provide more information about resign? I try it myself, but failed:

codesign -s <IdentityID> -v Xcode8.app
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/codesign_allocate: file not in an order that can be processed (link edit information does not fill the __LINKEDIT segment): /Applications/Xcode8.app/Contents/MacOS/Xcode
Xcode8.app: the codesign_allocate helper tool cannot be found or used

[duhanebel]

@ManWithBear that's because you're trying to sign a version that has already been stripped. Try with a fresh copy of Xcode 8

[ManWithBear]

@duhanebel helped. Thanks. Maybe put it somewhere in README?

[ghost]

JFYI force re-signing again worked for me (Xcode 8b4):

codesign -f -s <iOS or macOS signing identity> -v Xcode8-beta.app

So nice to have it working again! Thanks for all your guys' work with XVim.

[pitoneux]

if anybody wonder how to get your "signing identity" type the command:

security find-identity -p codesigning

and use what is inside double quote to sign with the command 'codesign'...

I would recommend to add a re-signing in the makefile...

[wangjiejacques]

@pitoneux can I update Xcode from app store after re-signing Xcode?