Future of Spritekit?

>my main question to Apple moderators

Not likely that will happen...devForums are primarilydev-to-dev - meaning you can enjoy the sharing of their opinions if you like. As well, Apple tends to avoid discussing future plans, etc. Remember, it's called development for a reason.

Good luck.

There is virtually no official participation by Apple employees in these forums. (Occasionally, an Apple engineer will give a technical clarification or ask for more information.) As well, Apple basically never comments on future product plans. So, you're not going to get an answer to the question you ask.

Also, Apple basically never abandons a support for a framework unless it has been replaced by a better one, and only after a long transition period. About the worst that's likely to happen is that you'll run into a bug or performance issue that Apple is slow to fix, and you'll have to find a workaround. (For example, the Sprite Kit classes SKAudioNode and SKShapeNode are generally regarded as terrible, but you can use AVFoundation for sound, and SKSprite Node for shapes without much difficulty. And, who knows? Apple might improve those classes on day.)

Lastly, AFAIK, when Sprite Kit first appeared, it was generally regarded as being based on Cocos 2D. Whether that's true or not, you should find the two systems fairly similar, so you don't need to worry about wasting a huge conceptual investment in Sprite Kit, if you decide you don't like it.

Hi,

Thanks for the info, yes, you are correct concerning being similiar to Cocos2dx, it's based on node, which I'm familar with, the only drawback is performance, which if i'm not mistaken, performance would be better using Swift, than Javascript ( JSB ) bindings ( Cocos Creator ). Do you think, we will ever see cross - platform in the sense of Android compiling.......? I've read some articles that Google is considering adopting / supporting Swift with the Fuchsia OS? Thanks again for the response........God Bless...

Sincerely,

Sunday

It's not a question of the Swift language, but of the Sprite Kit framework, which is never going to appear under another operating system. If there is something similar to Sprite Kit available, you might be able to design your app so that references to the framework are compartmentalized or wrapped, but most of the rest of the code can be shared across platforms, but starting out with that in mind is probably a bad idea. (It vastly increases the difficulty of the app, probably ensuring that you never finish it on the first platform, let alone others.)

Sunday, I would stay within the Apple ecosystem at all costs. Nothing scares me more than the idea of spending months developing something outside our little walled garden here and then finding out you can't upload it or whatever. So yeah, I would 100% say go with Sprite Kit. I've been using it since day 1 and it's a fantastic framework. Easy to learn too.

Yah, this is something really worth discussing. I have my reservations about SpriteKit even though I'm practically married to it at this point. I did two releases within the last half-year, one of which was a major one - and while I'm happy SpriteKit served me well with these, it did take a long time to get it to do what I wanted. I'm talking years here. Also, support and peer discussion seems pretty lacking.

As SpriteKit is highly inspired by Cocos2d, it was a natural transition for me having worked with Cocos2d for a couple of years. I've also been an iOS developer from the very beginning, 10 years in total, so I love that I can use the same tools (Xcode) and keep to the same language (now Swift). In short, being in the iOS ecosystem with SpriteKit allows me to make simple games with potentially great returns while at the same time strengthening my career in UIKit. So if I choose to go to a high-profile UIKit job, all this counts as experience. It works for me since I'm not likely ever going to join a game company (benefits are worse, hierarchy is greater, crunching is practiced, etc.), and would rather join an app company if I get bored of entrepreneurship.

However, if I were planning to go fully into games, I would wholeheartedly pick Unity over SpriteKit. The cross-platform support alone is enough to choose it when we're talking about games that are independent from iOS practices (most of them). In Unity you can now even export to Nintendo Switch, let alone all the other consoles and handhelds, so I feel like nowadays iOS exclusiveness needs to be argued well (because there are certain cases where being an Apple darling is great).

A good example of this to me is GNOG (https://www.gnoggame.com/). It's very experimental, artistic and just great, and it represents this sort of artistic indie branch of gaming that at least attracts me. GNOG would do great as an iOS exclusive and could easily be Apple's favorites (in fact it kind of is), and you could build it with SceneKit if you wanted to. However with Unity they can have PS4, Nintendo Switch and everything in-between. Even if the increased financial market isn't the benefit you're looking for, it also just expands your userbase to a whole other type of people and communities. And as a VR-able game, GNOG can support AR on mobiles and VR on consoles and PC.

Then there's content creation. If anything, Unity beats SpriteKit/SceneKit in this. If you're interested in doing ARKit, you'll likely be working with 3D. Setting up an AR scene isn't so terribly difficult in SpriteKit/SceneKit, and the re-emergence of AR with ARKit gives you a market. However, AR is only the enabler and it's now "hot" and open to everyone. In the future it's not going to be the hardware that you compete with, it's going to be what kind and quality of content can you provide. Already now, the first boost of ARKit has passed, users have tried the gimmick apps and will need content next if they plan to stay interested. Ask yourself: what development platform should I choose when my main goal is going to be creating an immersive, rich 3D experience, with perhaps a progressing storyline, sophisticated AI, game mechanics, plugins, etc.? Unity, of course.

At the end it depends on what your goals are. If you want to do small apps and you happen to like being native, lowish-level and create systems from scratch (I do), then SpriteKit is fine. However, if you wish to reach more people, create bigger experiences, focus more on content than systems and/or target a job in a game company, Unity is a better choice by far. And I'm not knocking SpriteKit. After all, my apps do provide me my living. I also now have a fantastic template for a game project along with plug-and-play classes for SpriteKit (after years of toil), which makes developing apps super-easy. However, if I could go back in time to 2010, I would tell myself to just go with Unity over Cocos2d to avoid years of pain. Even now, switching to Unity (starting from scratch) might be a reality for me in the next few years, since I'm getting quite a lot of pressure from partners to be cross-platform and have an easier development platform/environment.

Sorry for the long diatribe 🙂. I hope this is helpful and I sure do welcome any rebuttals 😀.

I've been learning SpriteKit for 9 months now, basically learning it and working in it full time. I am building a rather complex strategy game targeted to mobile. I am a professional software engineer, but first-time game developer. My experience learning SpriteKit has been both good and bad, and here in 2022 I am still wondering what the future of SpriteKit is, as it is not clear at all, and this question was posted 4 years ago.

The good part of my experience has been that SpriteKit seems to be an extremely well-designed framework, and seems to perform really well, as long as you closely follow Apple's recommended way of doing things. My game loads up huge dynamic tile maps, and places thousands of objects/nodes on the maps. So far SpriteKit and the SKTileMapNode have worked amazingly well.

However, the documentation, online support, availability of books, and learning materials has been extremely lacking, which has made learning it very frustrating. I really wish Apple would provide more examples of how to do certain things in SpriteKit. This is the aspect I see as the most concerning in terms of its future: there seems to be way too little support from Apple for how to use this nice framework.

I don't know the reasons why Apple does not put more effort or money behind teaching the community how to use this framework (I'm sure they have their reasons), but to me this is the biggest problem in terms of its future: teaching the community of developers how to use this wonderful framework. I am continuing to try to use SpriteKit, but the days are numbered until I switch to Unity, not because I want to, but because it seems like there are more learning resources out there for Unity.

I do think that SpriteKit would be much more actively used if there was more robust documentation and code examples. It truly is a nice framework when you eventually figure out how to do certain things with it.