I'm working on a macOS app that uses a JSContext and I want to debug it with the Safari Web Inspector. According to Session 402 at WWDC 2016 the following entitlement is required: <key>com.apple.webinspector.allow</key> <true/> This is easy enough to add, but it causes the app to crash at launch with a code signing issue. The console shows that taskgated-helper is reporting just before the crash: Unsatisfied entitlements: com.apple.webinspector.allow For anyone who finds this, here's what you need to know: https://webkit.org/blog/13936/enabling-the-inspection-of-web-content-in-apps/ Basically, there's now a inspectable property on both the WKWebView and JSContext. Unfortunately, there's no mention of the old entitlement in the WebKit blog post, so it's impossible for folks using the old technique to find. Hopefully this post will bridge this gap. It also might be something for @eskimo to add to his (always helpful) code signing documentation. -ch

I'm in the process of updating an app that uses complications that originally had a deployment target of watchOS 4.3. These complications used CLKComplicationSupportedFamilies defined in Info.plist. There are no CLKComplicationDescriptors in use. Updated complications that use a new CLKComplicationDescriptor.identifier display correctly in the complication picker, but the original complication that's using CLKDefaultComplicationIdentifier displays "--" or "---" depending on placement. This happens whether you are using a ComplicationController instance or WidgetKit. Using CLKDefaultComplicationIdentifier as the identifier when creating the CLKComplicationDescriptor doesn't work: the complication doesn't appear in the picker. My question is there a way to "upgrade" an older complication configured by the customer to a new complication identifier? I'm not using WidgetKit for this project so a widgetMigrator isn't an option. -ch

There are use cases where someone who's using an Apple Pencil may not want to enter text via Scribble. A simple example is writing "UIViewController" in a text view is unlikely to be successful. I'd like to disable Scribble in this case and let the keyboard become the input mechanism. (Disabling Scribble system-wide in Settings is both cumbersome and overkill.) The closest I can come to making this happen is by adding a UIScribbleInteraction on a UITextView and returning false when scribbleInteraction(shouldBeginAt:) is called. This disables Scribble on the text view, and prevents writing from being converted into text, but the input widget still appears on screen and isn't very useful. Here is a sample project that demonstrates the problem: http://files.iconfactory.net/craig/bugs/Scribbler.zip Hopefully, I'm doing something wrong here. If not, I'm happy to submit this as a FB. -ch

The Markdown changes are welcome, but what I really want to know is if I can link to stuff on my website: https://files.iconfactory.net/software/arcade/UnityBigSur-Screenshot.png https://files.iconfactory.net/software/arcade/UnityBigSur.zip -ch

If you enter "nasty" it gets converted to "*****". And we know many bug have this trait. And it happens to the best of us: https://developer.apple.com/forums/thread/674633 –ch