Hi Marco, I'm using UIKit in Touchgram (because it was started ages ago) so can't help specifically but have spent most of the last 3 years in this space so happy to help. Touchgram is probably the most complex iMessage app extension ever built (especially when I wrap v1.3) - it's effectively a full Keynote-level layout system plus gesture recognition plus exposing SpriteKit features such as shaders, animations & particles... all inside iMessage...to send interactive messages. Responding to the Delete Main.Storyboard point The result is a bank screen on the iPhone and the app icon in the middle of a blank screen on the simulator If you are seeing that, you are launching the app from XCode. You need to launch the Message Extension to debug it, which will bring it up inside Messages. Note that this is very fragile - I sometimes have to launch a couple of times and do a dance of quitting XCode/Simulators.

Hey, another SpriteKit-using iMessage app here - Touchgram has been on the store since 2019, massive update coming real soon now. I just checked my app info.plist and I have armv7 same as the original poster. This does ring faint bells for me of the early days but couldn't find a diary entry about it. Be very careful about your names matching including case sensitivity.

Fixed it. I logged into Slack using the same email address as my Apple ID (which interestingly mapped to an email address to which it is forwarded, in a related domain). Down the bottom of the page was a section with two outstanding invites. For some reason, I had not received any emails alerting me to these invites. Pending invitations WWDC 2022 Digital Lounges

I am trying to understand nuances of exactly the same issue as M-S with a digital currency being used to buy assets such as card templates. The good news from a design is that, from conversations with users and Apple employees, most people are fine with the idea of a digital currency for such in a non-game context. Technically, I'm still confused and think there are some missing pieces. Assuming your currency is a consumable, because that's the only IAP model that makes sense for topping up a balance: The App Store Review Guidelines says: 3.1 Payments ... 3.1.1 In-App Purchase: Any credits or in-game currencies purchased via in-app purchase may not expire, and you should make sure you have a restore mechanism for any restorable in-app purchases. 3.1.2 Subscriptions … 3.1.2(a) Permissible uses: Subscriptions may include consumable credits, gems, in-game currencies We seem to have an obligation but no supported method or helper tools. Apple feedback 2022-12 The official word from Ross L at Apple via the Q&A on Slack yesterday was Consumable in-app purchases are not restorable via StoreKit. However, you do need to make sure you permanently keep track of the user’s balance for this consumable currency. and then One option that many developers choose is to offer an in-app account, and store all this data on their own server. When I pushed for how There isn't any list of specifically accepted paradigms, but as long as you properly investigate and test your solution and it allows users to access their currency without losing it, it should be good. My intention Generate a local UUID on the app Use appAccountToken (iOS15 on) so the UUID can be associated with all purchases Persist the UUID and the currency balance using NSUbiquitousKeyValueStore so it's shared amongst devices and will be restored if they setup a new device. On our marketplace server, store a list of purchases associated with that UUID so they can be restored if necessary. This mirrors the behaviour of IAP being restorable items but we have to use our own approach rather than just IAP items because: we intend to have vastly more items available than the IAP limits using digital currency allows for micropayments and more granularity on pricing than IAP levels our rights system allows for items to be reusable with or without payment depending on the rules set per-item by the artists.

I don't misunderstand weak variables. I don't know if Scott's theory is right that it's a change in SKMove's allocation or if it was a compiler change to how ref counting and weak checks work. The point I am making is that this is a change in behavior that's been there at least 2 years so is likely to catch people by surprise. This code hasn't been changed in a long time. There's more detail I didn't go into earlier that made this even weirder to diagnose. I have the same code running in a pure application and it does not immediately nil the weak reference there. The only place where this behaviour appeared was running inside the context of an iMessage app extension.

Just curious: in the old behavior, what was the lifespan of these objects that you never kept a strong reference to? Did they dealloc right after your perform() (which would defeat the attempt to cache them) or at some point much later? It's a good question and the short answer is probably caching didn't give much benefit. SKActions are very commonly used in groups where the group action has a strong ref plus targetNode.run(ska) implies that the node is hanging onto the action for at least some running time. There can be repeated triggering via timers. I wasn't evaluating when they disappeared and these 1 or 2 strong refs are why I was nervous about my declarative code retaining a strong ref. As I explained above, this code's operating across domains. It is very similar to UI framework code where you have your own objects in Swift (or C++) which map to low-level UI objects and cross-references can be dangerous sources of leaks. I'm still thinking about making the ref weak again for safety and just using a local to fix this allocation. My opinion hasn't changed on the legality of this behaviour - the guard at the bottom means it's certainly legal for the weak property to have been cleaned up before used, but it's a very surprising change (especially only in the extension).

I'm going to post this in multiple places as I just went through this dance and NONE of the advice worked. iOS 17.3.1 and XCode15.2. I think the precipitating issue was that my provisioning profile expired. I restarted, wiped DerivedData, created new certs, new profiles, double-checked the device was included in the list, had a happy thought when the device list needed its annual reset ... all the advice here and elsewehere didn't fix. What DID seem to turn the corner was simply building a new app with XCode managing signing and running it on the device! When I did that, before it deployed to the device, I got the Codesign auth popup on Mac so it could have access to the keychain. After authorising and running that app from XCode, I was able to deploy my app to device!

I'm going to post this in multiple places as I just went through this dance and NONE of the advice worked. iOS 17.3.1 and XCode15.2. I think the precipitating issue was that my provisioning profile expired. I restarted, wiped DerivedData, created new certs, new profiles, double-checked the device was included in the list, had a happy thought when the device list needed its annual reset ... all the advice here and elsewehere didn't fix. What DID seem to turn the corner was simply building a new app with XCode managing signing and running it on the device! When I did that, before it deployed to the device, I got the Codesign auth popup on Mac so it could have access to the keychain. After authorising and running that app from XCode, I was able to deploy my app to device!

Does that imply that you no longer need to use the command-line to change active SDK? OR Did you assume the user knows to do that after installing side-by-side? xcode-select --switch

Confirmed this is still a problem in the simulators with the shipping XCode16. It's nothing to do with SwiftData - it's any Document app including creating one from the standard app templates as per my Stack Overflow question. The problem is related to using iOS18 in the simulator - an earlier OS in a new simulator created from XCode16 has no problems. It stops anyone from testing FileDOcument apps on iOS18 simulators, which is a pretty serious brake on development.

As requested, added a separate FB15343012 for just the document-based app case, including attached sample from a brand new project.