The live result is automatically shown when the file has a preview block #Preview { MyView() }

Have you tried rebooting the device? iPad Playgrounds crashing used to be a common concern for me. At that time I was using a 1st gen iPad Pro and it would crash always if I used a // style comment, and crash often if I edited a String literal. (I contacted the devs about this but couldn’t produce some system log to their satisfaction and they couldn’t reproduce so nothing came of it). Now, about 4 months ago I got a pretty pimmped out iPad and MacBook and iPad Playgrounds has been working great. No crashes… until oh no, it was a couple weeks ago iPad Playgrounds started crashing anytime I entered a ClosedRange like 0…5. OMG! I just spent 2k on this device specifically for iPad Playgrounds and it’s crashing again. Woe is me. Confirmed that in a brand new App project typing… let i = 0… …then finishing that with 5 it would crash, always. NOOOOO. Despair. But I rebooted the device and, welp, I can type ClosedRanges again 🤷‍♀️. It hasn’t crashed again since rebooting🤞 On the MacBook I haven’t really used the 2 different ‘Playgrounds’ available except to see what they are (the ‘Playgrounds’ project type in Xcode and the ‘Playgrounds’ app available on Mac). Neither crashed in the little that I used them. So I don’t know why it crashes but a reboot seems to help in the one time it started crashing in iPad Playgrounds on my modern device (rebooting doesn’t help on my 1st gen iPad Pro though).

Are you taking about iPad Playgrounds? There you need to be updated to the latest version and new App projects will be 5.9. Older projects created with 5.8 version will stay as 5.8. To update those you’d need to create a new 5.9 project and copy/paste over the code and assets. Or possibly you could open the Package file and update the version there. I haven’t done that so can’t say if it’ll work or what the caveats/risks are.

Thank you for posting this! I got your code working in iPad Playgrounds where I’ve been trying to learn metal and it’s a whole new drawing technique for me. I’ve seen hints about drawing this way but never enough to put all the pieces together and having a small, simple example to explore has really helped it click. Before this I’ve only been drawing line and triangle strips with vertex colors so this is very exciting. Do you know any place with more simple examples of different basic techniques?

Hi, sorry for the long delay, I’m not familiar with these forums and didn’t realize no incremented post count doesn’t mean no new activity. Anyways I noticed a day or two after posting that turning off Predictive doesn’t actually fix my problem, but I’ve fiddled some more with this issue and learned a little. Mainly what I learned is we have separate primary problems. My main problem is that views get pushed up and down by that keyboard thingy coming and going. I’ve kinda figured that out by putting ignoresSafeArea in certain multiple places but reading your post more carefully I see you don’t have that problem, your view isn’t pushed up, instead it stays down and gets covered by that opaque backing of the keyboard widget. I’m guessing you’ve already discovered this but that opaque backing appears to be a bug because when I use a UITextField instead then the keyboard thingy comes up and it’s transparent outside the actual widget. In fact, using a SwiftUI.TextField, when that keyboard widget initially comes up its the full width of the screen (like some older style of this widget) but then it quickly scales out and is replaced by the shorter widget (except it has the opaque backing). A UITextField doesn’t do any of that, it only comes up with the shorter widget with no backing. I wonder if that initial full width widget that SwiftUI.TextField shows is supposed to be for a compact size class. Like it thinks its showing the keyboard thing for an iPhone or iPad Split View, but then once shown it realizes its got the whole iPad width so it switches to the shorter widget but leaves behind the opaque backing of the full width widget. I don’t know if there’s a way to fix this in SwiftUI. I’m almost certain it’s a bug and if it has to do with size class then maybe there’s a way to force or push the correct size class before it appears. Idk seems a long shot. Otherwise the only workaround I can think of is to switch a UITextField representable wrapper which may be no easy feat.

First of all I want to thank you for this ‘predictive’ hint. I’ve wrestled with that space moving up and down in the Canvas and running apps during development on iPad and had resigned to tricks to make it go away. Turning off predictive ‘fixes’ it and thank you. About your problem there’s a ViewModifier that I think is supposed keep the view from getting pushed up .ignoresSafeArea(.keyboard, edges: .bottom) Or maybe there’s a .predictive option. I don’t know, I understood that annoyance to be a safe area for the keyboard and so only tried that but couldn’t get it to reliably work but maybe you know more/better. However now knowing that it’s not strictly the keyboard but this predictive thing I’ll look again.

Remove the Button so only the ShareLink is in the swipeActions closure. The swipeActions closure expects a View and the way it is now it’s getting the Button, not the ShareLink. Also the reason you’re getting that warning is because for a Button it’s closure is regular code. So a ShareLink is being instantiated there but that instance isn’t assigned or passed to anything. Hence, the result of ShareLink initializer (which is a ShareLink instance) isn’t being used.

Yes its possible! Its kinda complicated though. To access the external Files storage area the user has to be shown a sheet to grant access to a folder. But once granted a security scoped bookmark can be saved locally (in UserDefaults or a local file) so that folder can be accessed again without bugging the user. It took me awhile to work the whole process out and I tried to wrap it up in easy to use load and save Buttons. It had to be some kind of view to have a place to show the sheet. Anyways my implementation is working well but it’s designed to read and write to only one specific file in the selected folder with Codable objects. Thats’s something I plan to refactor but looking over the code it can give you the idea, or at least the keywords to lookup and see what the necessary parts are. See it here https://github.com/trochoid/EZIO There’s a ButtonSave and ButtonLoad view with the relevant code but they also call static functions in the EZIO class. Documentation is basically missing and, um, the error handling is atrocious embarrassed. That’s the other part I plan to refactor, please look passed it to how it otherwise works and I can answer questions.

I just went through this section and didn’t have any problems. The color picker appeared and worked as expected in both preview and running. This is on iPad. What exactly is happening? Is running never starting the app?

Just an update… I’ve reinstalled and it still crashes unfortunately. Command-/ is safe to toggle commenting code though, just have to be careful to never ever edit after a //. So I’m working very carefully like that: only code, /**/, Command-/, and still had a couple crashes unrelated to this comment bug. At least I never noticed an accidental // edit. Anyways 4.1 has been really buggy for me and I hope 4.2 brings back my jewel. Or maybe my device is just too old 🤷🏻‍♀️

Thanks Quinn, good thing I’m a procrastinator and haven’t tried to reinstall yet 😊. I just sent a Bug report (FB10034623) and will backup and reinstall in a day or 2. If I only write code and use /**/ style comments then it doesn’t crash so have been plunking along like that lol.

Also, this is iPad Playgrounds 4.1 on OS 15.4.1. There’s an OS update I haven’t installed yet, should I do that first.

The “App” type project creates a .swiftpm file, this is what you want. “Playground” projects creates a “.playgroundbook” file, these are legacy, you don’t want it. “Xcode Playground” I don’t know, I don’t have that option. Maybe its a .swiftpm file 🤷‍♀️. Look in the Files app under iCloud Drive > Playgrounds to see your project files.

Look in the Files app in iCloud Drive > Playgrounds and you will see all your projects as .swiftpm files. If what you mean is you’re seeing the files as .playgroundBook then you’re using the wrong project type, its the “App” projects that create .swiftpm files. Also what do you mean by ‘run a Swift Playground book inside a Swift Playground app’, what do you want to do with this?

Yes, I have this problem too but with the 4.0.2 update it’s gotten better, at least it feels it happens less often, usually warnings, and I haven’t needed to reboot the device to get it unstuck (relaunching app is enough). When it does get stuck I’ll do one or both of these things in either order Intentionally add a space to break code around where it’s stuck then delete the space. This triggers the compiler to start working again and hopeful clears the hang up. With the preview/Canvas panel open, at the top it says “App Preview”. Tap on that show show a menu and choose “Restart” or “Delete Data and Restart”. This will get the compiler to try again. If neither of those work (usually happens with a warning about a variable that’s no longer in my code) then I have to restart Playgrounds and that’s always rectified things since 4.0.2. You can also send feedback that this needs improving (open a project, tap top-right circle icon with 3 dots inside, select “Send Feedback” from menu). I don’t understand the technical problem with it getting stuck but a button to force a more complete recompilation I think would help.