Just me, or SpriteKit in GMs terribly broken?

I've updated to ElCap GM, XCode 7GM, and iOS 9GM and a project I'm working on seems to be broken at every turn.


  • Atlases don't work properly
  • Atlasses in Asset Catalogs don't work properly
  • still getting PKPhysics* types in methods expecting SKPhysics* types
  • the Actions editor is buggy as **** and doesn't properly handle image references
  • sizing of physics bodies based off of textures seems to not work right...


I've filed bugs where possible (way back in early betas), some of these issues are intermittent or difficult to track down... but it certainly doesn't seem to me that SpriteKit is anywhere near ready for release. Am I doing something just fundamentally wrong?


At this point, my project is so full of kludges to avoid crashing left and right, I don't know if I'll every be able to release it 😠

Replies

Thank you for your comments and feedback!


Like every team at Apple, we are committed to our users by providing top quality frameworks. We do acknowledge all the issues being brought up on the forum here, and the team has a process of providing more visibilities to these issues whenever we can by replying directly to forum posts.


One thing I would like to point out is, the main communication channel to us is still perferred via the BugReport system. It provides you the ability and visibility to track these bugs when engineering team have acknowledged and fixed these issues. Our engineering team has spent a lot of time reading these posts on the forums and orginated bug reports ourselves to make sure they are tracked and addressed in the upcoming software release. All of these bugs have also gone through detailed investigation, and testing, but the downside is you will not get the instant feedback when these issues weren't originated by you directly.


We appreciate all the feedback from you when trying to incorporate SpriteKit in your upcoming projects, and would love to help you succeed by providing a top quality product.

Do you also acknowledge that by not acknowledging the many problems Sprite Kit has had in iOS 9 that you've inadvertantly wasted an enormous amount of time of developers blindly battling with the issues?


If so, what do you plan on doing to make sure there's never a repeat of this disdainfully manner in which you've treated your users?

I have to second that.


I've been in IT for last 30 years and I've never seen a major vendor release something so broken and then treat their developers so badly.


To paraphrase..


– SpriteKit on IOS 9 was simply not up to Apple's standards – it clearly needed more time and testing.


- You’ve tarnished Apple’s reputation … You should hate each other for having let each other down.


To paraphrase..


We are taking many steps to learn from this experience so that we can grow SpriteKit into a service that our developers will love.


And also ..


The Sprite Kit on launch clearly demonstrates that we have more to learn about QUALITY. And learn we will. The vision of SpriteKit is both exciting and ambitious, and we will press on to make it a service we are all proud of by ????.


From the mobileme email if you're not with me.

Like so many developers, I'm astonished and appalled by the temerity of Apple to knowingly break SpriteKit apps with the ios 9 release.


To wittingly break all SK apps and betray the trust, resources, money, time, and hard work so many developers have invested in SK is patently smug. I can only guess Apple strategists decided SK developers would not revolt enmasse and flee to platforms like Unity because of significant technical debt/investment we've all already put into our apps. Apple is a juggernaut and enjoys user status as a luxury brand but irrevocably alienated its SK developers. It's a case of moral hazard: as small independent software vendors, we startups are subject to the whim and externalities of a monolithic Apple Business Machine. Without developer revolt, there is no financial impact, PR backlash, or opprobrium.


I've wasted months--and am still wasting time even with ios 9.2.x fixes--conjuring workarounds for numerous issues.

When will ios 9.2 be released? It would have been great to deploy a working app for the holidays on ios 9.x. With lingering SK problems and dependency on an official 9.2.x release, it now seems impossible to get an app--no matter how cool and how much it showcases SK features--approved and circulated in time for the holidays. Worst of all, the audience for a functional SK app will be confined to just people who upgrade from 9.0 to 9.2.


Alas, for the intrepid SK developers--we happy few, we band of brothers--battling SKTexture bugs and issues, I've posted a Stack Overflow reply that distills some of my issues/experiences with SKTexture

http://stackoverflow.com/a/33562642/4333414


To Apple Staff, I will file official bugs/code examples on the serialization/deserializtion behavior (and workarounds) that I'm seeing with SKTexture.


Sincerely,

RO

I won't be incorporating SpriteKit into upcoming projects because of how Apple handled this situation. I have lost confidence in team-SpriteKit and Apple’s ability to develop a video game framework and work with the developers utilizing it.


The problem with the ‘main communication channel’ is that it’s primarily one way. Do you think it’s fair to ask developers with limited resources to spend their time making example projects documenting very basic functionality that doesn’t work? While you might have acknowledged individual bugs you’ve failed to address the larger issue.


Why was SpriteKit released in such an obviously broken state? Why did SpriteKit work in iOS 8 and then have so much basic functionality break in iOS 9? When will these problems be fixed? Will anything change in the future to prevent this situation from happening again?


Apple’s decision to release a framework before it’s ready will end up delaying my project by at least 2 months and has wasted many hours of my time. Is this acceptable to your team? It is not acceptable to me at all.


Even in your response there is no admission of any wrongdoing on Apple's part. Nor is there any mention of a change in process to prevent this from happening again. Nor an apology.


And yet several times you refer to SpriteKit as a “top-quality” framework. I find this a bit insulting after having dealt with so many problems over the last couple months.

I landed on this post looking for a Xcode freeze when working with SpriteKit. Bug report: 23460386


I had problems with Xcode Version 7.1 (7B91b) freezing for a minute when switching to the Scene editor while opening a .sks - file. Every time I switched to the editor, Xcode froze showing the colored wheel for a minute or more. Extremely frustrating.


My collegue sugessted that I sould use the "Default for display" resolution for my Mac book pro (retina) instead of the scaled resolution. That made all the difference and Xcode doesn't freeze anymore.


Hope it will help someone struggeling with the same problem.


/j




.

I'm having the same problem with too many points in SKShapeNode, with 10.11 (this was not a problem in 10.10). So it is not an iOS-specific issue. FWIW, my app crashes with this assertion when I get to between 133-153 points in the path (varies).

Hi ben,


Have you tried updating to OS X 10.11.2 beta 3 via the Developer Center? If the issue persists, please file a bug report so that we can better track this issue and communicate with you.


Thank you.

Is it me or beta 2 of 9.2 had better FPS than beta 3?

Hi pavelgubarev,


There should be no differnences in FPS between 9.2 beta 3 and beta 2. If you do find some though please let us know and file a radar please so we can track it.


Cheers

I've only just had time to check pavelgubarev's statement, and I've also found a significant FPS drop between beta 2 and beta 3.


Nothing else has changed code-wise my end.


How could this be happening again?

Yes , very low fps in iOS 9.2 B3

Hey Digicub!


Sadly I cannot confirm my statement because I have not beta 9.2 no more, only memories of the scene running 10 FPS faster or so. I would be greateful if you could isolate the code and send it to Apple.


Too pity we have to do it: we have no park of similar devices to compare the code side-by-side.


Cheers

Pavel

Hi Norman, thank you for your reply to my comments.


In terms of using the Bug Report tool, I submitted bug number 23069832on the 12th October, and have yet to receive any response. I submitted a sample program and screenshots of the problem. Although the issue seemed to have been resolved in 9.2 Beta 2, the SKCropNode issue I mentioned in the bug seems to have returned in 9.2 Beta 3.


If the bug reporting tool is the best way to get in contact and receive feedback, I have yet to receive any and it has been over a month. Could you please let me know why this might be the case, and if my bug has been noticed?


Thanks.

Hi Digicub,


Normally you would get a single notification once the bug was fixed. A lot of work has gone in to reducing fill rate constrains from many users of crop nodes but this particular issue has not been addressed in its entirety.


The SKCropNode is not designed to be used en masse. It is a per frame GPU mask which is orders of magnitude more expensive than taking a rasterized snapshot of a cropped node for the same visual effect. At the number of crop nodes shown in the sample you must use some rasterizing scheme to reduce overdraw. Please look at SKEffectNode.shouldRasterize or SKView.textureFromNode:crop.


If all you are doing is a rectangular crop then SKView.textureFromNode:crop is going to solve your problems. Could you let us in a little more on the use case so we can help guide you to a performant solution that is less dependent on the fill rate demands of SKCropNode?


Cheers