It's definitely a blurry line, this `run` tool invokes your Swift file with `swift file.swift` which runs it in immediate mode. Technically it is compiling your code to memory and and immediately executing it, but is it that different from JIT in Python or Node scripting?
CTRL-Labs themselves acquired the wristband tech from North/Thalmic, who pivoted into smart glasses for a few years before being acquired by Google.
> In an interesting twist, CTRL-Labs purchased a series of patents earlier this year around the Myo armband, a gesture and motion control device developed by North, formerly known as Thalmic Labs. The Myo armband measured electromyography, or EEG, to translate muscle activity into gesture-related software inputs, but North moved on from the product and now makes a stylish pair of AR glasses known as Focals. It now appears the technology North developed may in some way make its way into a Focals competitor by way of CTRL-Labs.
I don't really see what advantage typed throws are giving him in this article, since he just wraps arbitrary errors and then uses his lookup function - isn't that basically the same as `catch let error as DecodingError`?
As far as I understand it, this is allowing TS types to be valid JS syntax that are just ignored by vanilla JS engines. So it is intentionally identical to TS, it just won’t have any affect on the execution of your code.
This doesn't work globally like the other shortcuts, but Ctrl+left/right will move the cursor to word boundaries in camelCasedWords, which is great for programming. I quickly tested it and it worked in Xcode and Sublime Text but not in TextEdit. (You also have to disable the system shortcuts for moving between spaces)
> Developers are encouraged to download the Apple Developer app where additional WWDC20 program information — including keynote and Platforms State of the Union details, session and lab schedules...
Sounds like there's going to be some sort of interactive lab, I wonder what format it will be.
There are two identifiers: Identifier for Advertisers (IDFA) and Identifier for Vendors (IDFV).
IDFA is the same across all apps on a device. However, it can be reset by the user or disabled (in which case it returns all 0s). Also, apps have to disclose (to Apple) that they use the IDFA - not sure if that's visible to the user in the App Store anywhere.
IDFV is unique per vendor - that is, each app has a different ID, but two apps from the same developer will have the same ID. I believe this is also reset when resetting the device.
The FBSDK doesn't require developers to enable the IDFA, so the unique identifier in the phone home request is either the IDFV (effectively unique) or just a UUID that the FBSDK generates and stores on launch.
"we are working closely with Apple to fill the remaining gaps" - definitely sounds like it. I think Apple has made the right call tightening security around kernel extensions but I'm glad they're working with 3rd party developers (even if it's only big ones) to ensure the functionality is still there. They also mentioned the existing version will still work, it will just need to be explicitly enabled.
I think the point he's trying to make is that the CK implementation of the APIs common to CK and SC may (or may not) make use of the secure enclave, and that's one reason to have different implementations.