One technique that I've seen used successfully elsewhere is to use dashed lines where the 'draw' segment length is what's animated and covers the entire stroke. The 'don't draw' segment is set to be excessively long (i.e. at least as long as the overall stroke length itself.) Then by animating the length of the 'draw' segment between zero and whatever the stroke length is, it emulates 'drawing' the stroke as if it were a pen. Hope that makes sense.

Here's my approach. Handles both single- and multi-scalar characters equally thanks to allSatisfy. public extension CharacterSet { func contains(_ character: Character) -> Bool { character.unicodeScalars.allSatisfy(contains) } func containsAll(in string: String) -> Bool { string.unicodeScalars.allSatisfy(contains) } } Some other useful/helpful operators... public extension CharacterSet { static func + (lhs: CharacterSet, rhs: CharacterSet) -> CharacterSet { lhs.union(rhs) } static func - (lhs: CharacterSet, rhs: CharacterSet) -> CharacterSet { lhs.subtracting(rhs) } }

This may not be related to you having two different versions. One thing that an Apple engineer at WWDC pointed out to me is any time you do a new install of an app, you have to manually launch that app at least once before they make its widgets available in the widget browser. This apparently does not include launching it from Xcode (which they said is an issue that they are working on.) As such, in our case, when debugging our app, we had to minimize (i.e. go back to the home screen) the app, then manually tap on the icon to bring it right back to the front. Once we did that, our widgets would show up in the browser again. Again, make sure to minimize, not close the app or you'll kill your debug session. Minimize, tap the icon to open it back up again and you should be good to go. Their reasoning is they only want things to appear in the browser that you have explicitly accessed, not simply installed, and since you're basically doing new installs throughout the dev process, that can cause the issue.

Actually, it does work. I just ran into the exact same issue. Fix was easy though. You have to remember to explicitly set the following... view.translatesAutoresizingMaskIntoConstraints = false This is because by default, the system will create constraints that match the frame, and *that* is what you're fighting with, not the playground itself. That said, remember, if you are viewing a view alone (i.e. not in a UIViewController) technically you can only set the width and height as the position will always be top-centered of the preview area. If you want to be able to move your views anywhere, create a 'parent' view representing your screen or whatever, then place your views within that.

Had the same issue, but figured it out. It's because of the format of the texture. I was using a JPG file that I was loading into a UIImage, then handing that to the shader. Worked fine on a real device, but not in the simulator. I took the JPG and loaded it in Photoshop, change the color space to 'Apple RGB', then saved it as a PNG instead of JPG and it now works great in the simulator and on a device. You can find more information in Apple's developer documentation here - https://developer.apple.com/documentation/metal/developing_metal_apps_that_run_in_simulator where they specifically say certain formats will not work in the simulator. Hope this helps!