User Profile

This problem still exists today in the latest version of macOS Catalina. I've spent the past week trying to find a reason why my iOS app that I'm porting to macOS has all these issues when I run it full-screen on my brand new Macbooks Air 2020 (core i7, 16GB).The app runs fine until I set it to full-screen. I note that my app is a SceneKit app, with a SpriteKit overlaySKScene. The SceneKit assets all seem to perform fine, but the SpriteKit assets spasmodically draw with the wrong textures, and this only happens when the app is utilising full-screen.I've employed some of the tecniques in the link provided above (I'd found it independantly), notably:self.view.window!.styleMask = NSBorderlessWindowMask self.view.window!.level = Int(CGWindowLevelForKey(Int32(kCGMainMenuWindowLevelKey))) + 1 self.view.window!.opaque = true self.view.window!.hidesOnDeactivate = true let size = NSScreen.mainScreen()!.frame.size NSMenu.setMenuBarVisible(false) self.view.window!.setFrame(CGRect(x: 0, y: 0, width: size.width, height: size.height+1), display:true)This certainly makes a big difference, the glitching of textures stops 99.9% of the time, however I'm left with about 20 unused pixels at the bottom of the screen.Given this question was asked in 2016, and the linked SO post suggests the issue was corrected in 2016, I'm wondering why I'm still seeing it in 2020. I note that the same problem occurs on my older Macbook Pro (2013, core i5, 2.3GHz) running Mojave.I don't accept that it's just that the hardware isn't up to it. If the app can run smoothly in the iOS simulator, which adds an extra layer of OS level code to the app, then it should be able to run natively on the machine, no matter the window size.I note that in the solution above, if I comment out the line:NSMenu.setMenuBarVisible(false)then the problem resurfaces. There is some odd optimisation being done by macOS around (near) full screen apps and the way they use the menu bar screen real-estate that cripples SpriteKit apps (and possibly others).Games on Apple Arcade seem to run OK, so there must be a way for this all to work. It would be nice not to hack up a workaround though.Here are some screenshots showing the issue.First, with the above solution and the menu bar set to not-visible, all runs beautifully, but I can't get the window to position itself so that it actually covers the entire screen. You can still see Xcode running behind it:Next, the image below shows what I get by commenting out the line so that even though the menu bar isn't in fact visible, it's causing a serious drop in the frame rate, and then as the final image shows, when ever I actually do something in the app that triggers some SpriteKit animations, the SKSpriteNodes within the SpriteKit overlay are drawn for a few frames using the wrong textures:

Correct. I just ran it up, and indeed it is there. At last!You can download it from the member center. Just remember to keep is separate as you won't be able to submit builds from this beta version.Test on 11.1 SeedBuild and submit from 11 GM.

Agreed. Still not present. I'm beginning to think we are being forced to wait for iPadOS to drop. Infuriating. They want us to submit updates, but we actually can't because we have no way to test.

Unfortunately, this doesn't work with the GM Seed if you want to test the 7th generation iPad (the 10.2" model). It's just not there in the list.

Me also. Makes it rather hard to test.

You're welcome; I'm glad it was helpful.No, I've not tried to direct the student back to the Schoolwork app automatically. There may be a URL that we can "open" that will trigger the Schoolwork app to open. I'm wondering if there is a documented URL scheme that can be used this way.@Malonicus, are you able to shed any light on this?

Yep, with Xcode 9.4 on High Sierra latest versions, I'm trying to prototype some SceneKit code in a macOS playground. My machine is a MacbookPro Retina (early 2013), 8gb ram.It's so unstable I have to restart Xcode (if it hasn't crashed and restarted itself) at least once an hour.I find that:1. Saving files triggers crashes.2. Editing anything other than the main playground entry code does not cause the playground to recompile automatically or quickly.3. If an error exists in anything other than the main playground entry code, you get this stupid modal dialog on the screen with "The auxiliary source module did not compile successfully." as the message. Just show me the error messages inline like any other compilation issue, thanks. And when I have two displays, that dialog insists on showing on the primary display, not the one with Xcode (which I run on the larger, secondary display).4. Code completion both automatic, and via the ESC key does not work in anything other than the main playground entry code.5. I see a lot of these SIGTERM errors after watching the beachball for 30 seconds."error: Execution was interrupted, reason: signal SIGTERM.The process has been left at the point where it was interrupted, use "thread return -x" to return to the state before expression evaluation."Honestly, the whole "swift" experience is painful. I can try reworking my playground into a mac app to see if it's more stable. God forbid kids actually try to learn with this stuff. It will turn people away.[EDIT] I've just taken my code out of the playground and copied it into a new macOS.game project. Same code with the only tweaks being the game view initialisation stuff that had to change slightly. Now, the thing runs first time, every time. So I've wasted all this time on Playgrounds which are slower to compile, less intuitive to use, can't be debugged, etc when I could simply be running the app natively and quickly on the mac.

Now that I look at my bug report list, there are still significant (IMO) issues (e.g. radar 40161525) that have not been closed. Why launch with such issues? I haven't got an iPad handy now to retest with, so maybe it's been addressed, but I'd be surprised.

My recollection is that the "done" is something that the student explicitly taps on. I don't think it's automatic. I guess that gives the student the opportunity to say when they think they are done.Perhaps someone from the ClassKit team can help us to be sure.

I posted here about a demo project (Obj-C) I put on github a little while back. In it, I show how to generate a hierarchical context tree (or at least how I do it).Here's the link again: https://github.com/pkclsoft/ClassKitIntegration.gitCheers

I think you will find that whilst iOS is indeed moving forward, SchoolWork and ClassKit have not trully been launched. As far as I know, the SchoolWork app is still in Beta.If you are not yet part of the beta program, I think you can still register at: https://developer.apple.com/contact/classkit/Best of luck.