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 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.
Post not yet marked as solved
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.
Post not yet marked as solved
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
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.
Post not yet marked as solved
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.
Post not yet marked as solved
Answering my own question - look at what's up there now as of v1.0.1 of Touchgram. https://apps.apple.com/us/app/touchgram-for-imessage/id1447336478?ls=1They accepted videos showing the app including in compact view.I got the review through last night, it went back into review (without me having to press Submit for Review again, which was a minor puzzle if needed)
Post not yet marked as solved
I got a similar rejection for Touchgram in 2019 when I tried to show Messages being launched from Springboard:?Your app preview includes content that does not sufficiently reflect the app in use. Specifically, your preview:- Displays other apps.- Shows footage other than the app in use.They included a screenshot of the springboard starting frame.I then trimmed the video further to show how it starts with the app icon in the middle of the Compact view of iMessage and they clipped that frame and left the status as rejected for the same reaons as above.Have just further trimmed the video so it shows the iMessage extension in Compact mode, which means iMessage's transcript and the bar of app icons is visible. Will be very interesting to see if this is accepted. I have an alternate theory that the App Preview is regarded as only being for the app, even when 99% of your functionality is in the extension.
