Xcode 8 won't load plug-ins

[0xced]

Joe Groff tweet

@fzwob Xcode 8 uses library validation. It won't load in-process plugins anymore.

That’s very bad news for Alcatraz and the current plug-ins ecosystem. 😢

[RobertGummesson]

Yep, looks like the era of Xcode plug-ins is over. 😥 I will personally be looking into porting my ones and hope the extensions are not too limited.

[alanhamlett]

I'm looking for docs on creating Xcode Source Editor Extensions... anyone find them yet?

Xcode 8 adds support for Xcode Source Editor Extensions: Application Extensions provide additional commands in the Xcode Editor menu. These extensions can manipulate both text and selections. To create them, use the new Xcode Source Editor Extension target template in the macOS Application Extensions section when creating a project. (23194974)

I don't have the Xcode Source Editor Extension target template in my Xcode 8 Beta, and these headers are the only thing Google found on the subject: https://gist.github.com/OdNairy/62de23d6627d518c38fed078a0581046

Also, this video about Using and Extending the Xcode Source Editor: https://developer.apple.com/videos/play/wwdc2016/414/

[0xced]

To create an Xcode Source Editor Extension, you have to add a new target to a project. The Xcode Source Editor Extension template is not available when creating a project.

Unfortunately, as its name imply, a Source Editor Extension only has access to the source code editor part of Xcode. So only a few plug-ins can be rewritten with the new official extension API. 😢

[fzwo]

In his tweets to me, Joe Groff asked for radars for missing functionality, implying that they are interested in giving us a powerful system. So I’d invite every dev whose plug-in is not supported under the new system to file radars.

f.

Am 14.06.2016 um 10:59 schrieb Cédric Luthi notifications@github.com:

To create an Xcode Source Editor Extension, you have to add a new target to a project.

Unfortunately, as its name imply, a Source Editor Extension only has access to the source code editor part of Xcode. So only a few plug-ins can be rewritten with the new official extension API. 😢

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/alcatraz/Alcatraz/issues/475#issuecomment-225820887, or mute the thread https://github.com/notifications/unsubscribe/AA7w_Z84ugZq3rYCc18nhM4VVz1g9buXks5qLm17gaJpZM4I0xyf.

[erikolofsson]

This is very unfortunate. For the plugins that I need I would suspect a very small portion of the functionality is feasible with the new plugin infrastructure.

A workaround is to remove the signature from Xcode.app. You can do this with https://github.com/steakknife/unsign

[fzwo]

@neonichu tweets that the template shows up when adding a new target to an existing macOS project.

[guillaumealgis]

@erikolofsson I doubt this would solve the problem. Even if being itself unsigned, Xcode will probably refuse to load unsigned code. Maybe you could tamper with the extension loading function once Xcode's signature is removed, but that would probably also implies disabling SIP... And well this doesn't seems like a good idea at all.

(Not to mention that we have not much to gain by irritating Apple on this kind of things, and everything to gain by playing nice and providing helpful feedback)

[pdcgomes]

@guillaume-algis I tired it a couple of hours ago and it did work.

[guillaumealgis]

@pdcgomes you mean unsigning Xcode with https://github.com/steakknife/unsign to make it load arbitrary plugins? To be honest I'm at work and I did not have time yet to play with the thing much. That was just random thoughts on the matter ;)

[pdcgomes]

Yes, correct. But agreed, not the way forward. I'm just concerned with how fast they'll be able to push additional extension points. We shall see!

[pdcgomes]

Managed to sit down with some of the Xcode engineers that are working on Xcode Extensions earlier today. As expected, anything that doesn't involve pure text manipulation can't really be achieved with the current extension point. The good news is that this is just the beginning and they're very keen on getting as much feedback as they possibly can, so definitely submit radars with very clear use case cases.

Unfortunately there are no clear timelines, so who knows how long it'll take until we have a rich public API and more extension points.

And yes, they've confirmed that by removing code signing, existing plugins will work. Having that said, it adds even more friction to the whole process, so the average user will probably either opt out or just be completely unaware of it. The way forward is to definitely clearly document valid use cases and file radars.

Both sad and exciting times ahead.

[dabing1022]

Xcode Extensions- Your Life Will Change

[alanhamlett]

Looks like the user has to invoke new extensions from a menu or keyboard shortcut. This is a bummer.

[JasonWorking]

Bad news.~

[borisyurkevich]

Good news, Xcode 8 protected from old dangerous plugins. Stop thinking about yourself and think about the greater good. We all get safer tool. Horrible story with Xcode Ghost should never happen again. Please don't break Xcode signature. Remember that's priority should be to create great products, not making your development live more fun and pleasant.

[alanhamlett]

@borisyurkevich the new api is not yet ready but they disabled the current one anyway.

We all want secure plugins, but the way Apple disabled the current plugins without providing a sufficient replacement is why this is bad news.

[ghost]

@alanhamlett Apple Maps

[alanhamlett]

No point in arguing why Apple does things, let's just file Radars for the extension features we need and hope they get implemented:

https://bugreport.apple.com/

[BeauNouvelle]

It would have been nice if we were given a transitionary period at least. Given time to port the plugins we have that will work with the new system, AND given time to submit radars for the added functionality. Everything we have built is pretty much dead overnight.

I'm glad we now have colors, and documentation creation built in to Xcode 8, as they were my most used plugins.

At least we'll be able to sell them on the mac store right?

[ianmasters]

@BeauNouvelle

It would have been nice if we were given a transitionary period at least.

This is Xcode 8 beta; by it's very definition the transitory period! Your feedback to Apple as they push toward public release is critical to make them aware of what you think should be done.

[iphone-andy]

So why xcode8 can't load old plugins , Is there any hack ideal to fix it

[ianmasters]

@iphone-andy it's to prevent executing potentially unsafe / insecure / unsigned code that could be malicious or otherwise.

[Isuru-Nanayakkara]

@borisyurkevich I've used plug-ins extensively and never came across any "dangerous" plug-ins. Third party plug-ins is what made Xcode, otherwise a terrible IDE, tolerable. What Apple should have done is provide a way to sign Xcode plug-ins instead of disabling everything altogether.

[BeauNouvelle]

I've already filed a bug report about it. I'm sure if enough of us say something they'll at least give us more time to transition.

[borisyurkevich]

@Isuru-Nanayakkara issue is not in current plugins but in the fact that Xcode allows not signed code. This lead to the Xcode ghost attack. BTW used many IDE's and Xcode is way ahead of everything else. I shipped many apps and never felt a need to install a plugin.

[erikolofsson]

I think we could keep using the current plugin system safely by:

• Create self signed certificate and add it as trusted to Key Chain
• Walk through all of Xcode.app and find all internal plugins
  • Verify the signature of the plugin against the Xcode main app signature
  • If verified put in list of verified plugins
• Resign Xcode.app (and optionally xcodebuild) and all verified plugins with the self signed certificate
• Sign all of the custom plugins you want to use with the self signed certificate.

[osolo]

[rant] I am personally quite upset by this change. Hardening Xcode.app doesn't fix the Xcode Ghost problem, it just forces malicious parties to move elsewhere in the toolchain. I can think of 10 different ways to inject bad code that doesn't involve changing Xcode.

On the other hand, Xcode is now broken for me. I use 5-10 plugins from Alcatraz and Xcode 8 will suck without them. I have to disable the whole OS's system protection to get them back. How does THAT help security?

Also, if you watch the WWDC session, you see how concerned the Xcode team was about performance of plugins. This is such a non-issue. I've both used and written plugins for Xcode and other IDEs (namely Visual Studio) and this has never been a real issue. But now the IPC approach I'm afraid we can never things like real time code editing in plugins. Too bad. RIP plugins. [/rant]

[lechium]

i am absolutely disgusted with this decision. Xcode ghost had NOTHING to do with plugins. this is just another one of those decisions treating everyone like the lowest common denominator. this "safety first" mentality that has destroyed any possibility of swift being a useful language is infecting all of their other decisions across the board. its making me seriously reconsider my line of work.

The engineers shouldn't be worried about plugin performance, its OUR choice to use them, and it should remain OUR choice, if it hinders performance, thats OUR problem, not theirs. This reeks of sony's PS3 other OS debacle.

[iandundas]

lol. On the other hand, we're presumably going to see an expanding and fully-supported extensions API instead of a pyramid of unstable hacks which is how plugins were developed before.

[lechium]

i prefer the unstable hacks since it brings the ability to tweak, fix and improve ANY part of Xcode. Im so fed up with their new cultural shift, It's one thing to treat end users like knuckle-dragging morons, treating developers like this is completely unacceptable.

[guillaumealgis]

While I understand the frustration, let's try to keep the conversation civil, and focused on how we can make the most of this decision please 😊

Ranting about Apple being closed and secretive will take us nowhere. Thanks! 👍

[lechium]

fair enough, sorry. just wish there was a way to get them to reverse course on these decisions. i know all my plugins ive authored that i use daily arent going to work with the extensions. i think my only solution personally is to stick with xcode 7.

[BeauNouvelle]

Submit a radar about it. Apple won't know how upset you are by writing about it here. Let them know, if enough of us do it, they might be able to come up with something where Xcode can support both in the short term.

[osolo]

@BeauNouvelle thank you for suggesting something actionable. I filed a radar this morning, and I hope everyone else on this thread will as well. The link to file is right here: https://bugreport.apple.com/

[tbodt]

@osolo Can you post the text of the radar so we can duplicate it?

[osolo]

@tbodt please see http://openradar.appspot.com/radar?id=4978927382560768

[osolo]

@guillaume-algis I'm wondering if you have any hard stats you can share about the number of Alcatraz installs in the wild. Maybe if that number is high enough, it would help sway opinions at Apple.

[guillaumealgis]

@osolo Nope. We have zero stats appart from the number of Github starts for Alcatraz and each plugin's repo. See https://github.com/alcatraz/Alcatraz/issues/150.

[osolo]

@guillaume-algis Doesn't Alcatraz phone home to check for upgrades? Could that be instrumented?

[vistatinchao]

are you kidding me

[Ronaldoh1]

No 😢 this can't be true.

[guillaumealgis]

Disclaimer: Take those stats with a (huge) grain of salt.

@osolo Alcatraz uses git for its update process, but we monitor nothing. One of the only stat we have is the number of clones during the last few days. This isn't very meaningful, as Alcatraz is installed by downloading a tarball (if you follow the instructions on alcatraz.io), and uses fetch not clone when updating.

Still, here are the stats I screenshot'd today:

I'd say we average at about ~250 unique cloners per day (which, again, tells us nothing).

You could also check the stats for the releases of Alcatraz using Github's API. The latest release, 1.1.18, pushed on March 26 has been downloaded 74548 times so far.

GET https://api.github.com/repos/alcatraz/alcatraz/releases/2892921

Which gives us a bit more than 570 downloads per day on average. Note that it's hard to interpret this number, as users frequently re-install Alcatraz because of the slightly broken update process (in particular, we handle Xcode version changes very poorly).

[Przemyslaw-Wosko]

i created new repo for Xcode extensions link , feel free to update it with your ported extensions. it's just repo that collects useful extensions. I hope that closing Alcatraz will not affect badly community building add-ons for poor Xcode.

[capnslipp]

FWIW, using unsign on /Applications/Xcode-beta.app/Contents/MacOS/Xcode as @erikolofsson's suggested plus adding the beta Xcode's UUID to Alcatraz and other plugins per #73 works flawlessly for me.

Of course, this reduces the security of Xcode.  For my usage though I'm not worried; I primarily use Alcatraz for color schemes and currently have only one true plugin installed— SCXcodeMinimap.

Is unsigning dev tools dangerous?  Maybe. Is it the end of open-source add-ons/hacks to Apple apps?  No, not really. Is it just the reality of Apple's protect-novice-users-while-still-technically-allowing-expert-usage?  Yup.

[FalconTT]

Well, I just posted a Apple Bug Report for my plugin; hopefully more developers will do the same thing and Apple will listen.

[alanhamlett]

This app gives unsign an easy to use GUI: https://github.com/fpg1503/MakeXcodeGr8Again

[tbodt]

unsign isn't really necessary:

codesign --remove-signature /Applications/Xcode\ beta.app

--remove-signature is an undocumented option. It does exactly what you think it does.

[tbodt]

A little-known fact about GitHub releases is that there is a download counter. It's not visible in the UI, but you can get it through the GitHub API at https://api.github.com/repos/alcatraz/Alcatraz/releases.

Version	Download Count
1.1.18	81,240
1.1.17	5,710
1.1.16	15,512
1.1.15	47,828
1.1.14	157
1.1.13	18,386
1.1.12	7,139
1.1.11	12,030
1.1.10	52,931
1.1.9	76
1.1.8	25,413
1.1.7	1333
1.1.6	37,751
1.1.5	22,576
1.1.4	2,990
1.1.3	393
1.1.2	18,413
1.1.1	4,931
1.1	10,017
1.0.9	23,546
1.0.8	19,232
1.0.7	11,897
1.0.6	2,086
1.0.4	31,383
1.0.3	39
1.0.1	45,320

[inket]

unsign isn't really necessary:

codesign --remove-signature /Applications/Xcode\ beta.app --remove-signature is an undocumented option. It does exactly what you think it does.

I believe codesign --remove-signature is fundamentally different from unsign.

When implementing Xcode unsigning in update_xcode_plugins, I tried going the codesign --remove-signature way at first, but Xcode seemed to lose access to the system keychain and couldn't login to the accounts in Preferences > Accounts > Apple IDs, so you would have to enter all your Apple ID passwords on every Xcode restart.

[nrbrook]

I've scripted the process of unsigning Xcode and updating the UUID in plugins. Feedback appreciated. https://github.com/nrbrook/MakeXcodePluginsWork