Final Fantasy iOS Game Shuts Down Over Unfixable Bug (theverge.com) 32
The Verge's Jay Peters reports: Square Enix has shut down the iOS version of Final Fantasy Crystal Chronicles and removed it from the App Store following an unfixable bug that blocked people from accessing content they had paid for. [...] The company says that if you made in-app purchases in January 2024 or later, you're eligible to request a refund by contacting Apple Support. Square Enix says that Final Fantasy Crystal Chronicles will continue to be supported on other platforms. The game is also available on Android, PlayStation, and Nintendo Switch. "The issue is due to changes made to the in-app purchases model," Square Enix says in a post. "Further investigation revealed that we are unable to completely fix the bug and implement the new changes, making it unlikely to resume service for the game." Square Enix says it started receiving reports on January 24th about the issue, which "extends to the full paid version of the game."
Re:But (Score:4, Funny)
I'm waiting for the release of Technical Debt Tycoon!
Thank Apple. (Score:4, Insightful)
This is Apple's abusive store practices yet again making life painful for their users. But that's ok - they're users won't ever blame Apple.
Re:Thank Apple. (Score:4, Insightful)
This is Apple's abusive store practices yet again making life painful for their users. But that's ok - they're users won't ever blame Apple.
Millions of developers use Apple's in-app purchase system every day. If they can't figure out how to make it work, odds are, the problem is not the in-app purchase system.
The way I read this is "We didn't bother testing on the latest OS version before it shipped. It broke something. We don't want to pay a developer to figure out what's wrong, because this game isn't making us much money anymore, so we're just going to shut it down and blame Apple."
Sadly, that seems to be becoming the rule, rather than the exception. The only real long-term fix would be for Apple to open up iOS a lot more so that users could install the previous version of iOS in a thin VM and keep incompatible apps running.
Re:Thank Apple. (Score:4, Informative)
Well, if it's a system change that broke a program that was previously working, then blaming Apple is the correct thing to do.
Re: (Score:2)
Well, if it's a system change that broke a program that was previously working, then blaming Apple is the correct thing to do.
It's entirely possible that it was always broken, and it just took this long to get enough complaints for anybody to look at it. It's also entirely possible that they were relying on undocumented behavior, and that it only worked because of a bug that got fixed. So no, it isn't necessarily the correct thing to do.
Re: (Score:2)
It worked for over a year, then suddenly broke. The complaints didn't start until a few weeks ago.
Also, from Square Enix's press release, "The issue is due to changes made to the in-app purchases model. Further investigation revealed that we are unable to completely fix the bug and implement the new changes, making it unlikely to resume service for the game."
Blaming Apple is the correct thing to do. They made changes to the in-app purchase model that broke users' ability to access content they'd purchased
Re: Thank Apple. (Score:2)
Apple has introduced breaking changes in iOS regularly for over a decade, constantly breaking people's allocating and forcing the developers to update or see their applications removed permanently from the store.
Google has done it to a much lower level, and due to the open source nature of Android, if there's an Android game you played years ago, there's a good chance you can somehow run it in an emulator.
No such chance for ios. Apple is definitely responsible for those breaking changes and making thousands
Yay! (Score:4, Insightful)
Three cheers for walled gardens ... Three cheers for DRM ... Three cheers for paywalls! Long live the cloud! Hip, hip, hooray!
Re: (Score:3)
Except Apple didn't change anything.
This isn't the first time either - Square Enix had to remove an app because they refused to modify their app - the location of a file changed and the way they accessed it used a path that was hardcoded. When Apple changed the location, if you did it the proper way using the API call, it transparently worked. But they chose to hard code the path and
Re: (Score:2)
So no three cheers from you? :(
Re: (Score:2)
Thats not entirely true. To update an old ios app to be uploadable into the store is significant amount of work due to apple themselves deprecating stuff and requiring you use a newer xcode. You can't just "update the api call" and expect it to be publishable.
How is it possible? (Score:4, Insightful)
If it is an unfixable bug it must be out of their control. Bug is surely an euphemism and they do not want to say the real reason.
Re: (Score:3)
I'd agree, the only "unfixable bug" is a problem that's either beyond your control to fix, or some behavior that you are unwilling to fix.
I wonder if this is a problem with the way they want their in-app purchases to behave? Like if they intentionally designed it in a way that violates some of Apple's ToS, to get a bigger cut of the purchase, and Apple finally is putting their foot down in 2025? So either Apple is blocking the method they're using to skirt the rules, or they've convinced (by threat of leg
Re: (Score:2)
We hired all the cheapest devs we could find that they claim we need to hire better people. Therefore the fix is impossible!
Re: (Score:2)
I'd agree, the only "unfixable bug" is a problem that's either beyond your control to fix, or some behavior that you are unwilling to fix.
I wonder if this is a problem with the way they want their in-app purchases to behave? Like if they intentionally designed it in a way that violates some of Apple's ToS, to get a bigger cut of the purchase, and Apple finally is putting their foot down in 2025? So either Apple is blocking the method they're using to skirt the rules, or they've convinced (by threat of legal action) Square Enix to disable the code that's violating the ToS. And now since Square Enix can't have their way, they're taking the "nuclear option" of taking their ball and going home.
It's impossible to really know without more information, but that seems to be the most likely string of events.
My guess is that it probably has to do with not wanting to properly support replaying app store transactions. You're supposed to be able to replay the transactions and get back purchases that didn't get credited to your account correctly. But if you do things the stupid way and don't tie the identifiers from the in-app purchases to a specific server account, then it could be possible for someone to cheat the system and replay them after creating a new server-side account, and restart with all of their in-
Re: (Score:2)
What would it even mean to replay transactions on a new device if your game and character has been transferred? And what would it mean if your game and character has not been transferred? Surely in either case, the replay would involve doing precisely nothing.
Re: (Score:2)
What would it even mean to replay transactions on a new device if your game and character has been transferred?
It would mean verifying that every purchase was actually received and logged in your account, and adding any that weren't.
And what would it mean if your game and character has not been transferred? Surely in either case, the replay would involve doing precisely nothing.
It *should* do nothing in the first case, and presumably should add back anything that hasn't already been used by the previous character in the second case (and presumably remove it from the other character), unless a previous bug in the app (or possibly a really badly timed network outage) caused the purchase to not get credited to you correctly. My assumption is that such a failure c
Re: (Score:2)
Re: (Score:2)
Somone stepped on the bug, and we tried but we just can't get it buzzing again. It mostly just lays there oozing.
Re: (Score:2)
i haven't read tfa but what comes to mind as "unfixable": bug meant loss of data. so the code is fixable, but it's no longer possible to reconstruct state = screwed.
really nasty bug.
Wait, why do *I* have to request a refund? (Score:2)
They already know which users made purchases in the eligible time frame. They should just issue the refunds. By putting the burden on the user, the company will be taking the money and running.
Not that this should surprise anyone but sad sad sad.
Re: (Score:3)
My guess from the description is they fucked up their data model and don't have a link between their users back to their Apple ID so they literally can't figure out who is who or who they would owe money to and have to rely on Apple's data and support to refund.
What they should have done is asked Apple to just refund everyone and be done with it but that would be the ethical thing to do.
Re: (Score:2)
Well obviously, because they know that only a small number of people will bother, so they automatically get to keep the rest for themselves.
SHA-256 Purchase Receipts (Score:4, Informative)
It's not a bug. It's because Square Enix doesn't want to update the game to handle purchase receipts signed with SHA-256 [apple.com].
Crystal Chronicles was released in 2020. The game is essentially one giant collection of free demos, with IAPs to unlock the specific games inside. Square opted to do on-device verification of IAPs (which is generally a good thing), which means the app relies on purchase receipts sent over by the App Store.
Up until 2023 [apple.com], these receipts were signed with an SHA-1 certificate, at which time Apple started a process to migrate over to a much stronger SHA-256 certificate. Between then and the end of last month, both certificates were available. But on January 24th, Apple moved to the last phase of the migration as the SHA-1 certificate expired.
As a result, the current build of Crystal Chronicles cannot read Apple's modern receipts. It would need to be updated to handle the SHA-256 receipts. In fact, Square can't even submit a new build of the game to the App Store without SHA-256 support, as that has been a requirement since August of 2023.
There are a few other ways around this as well, though all would take more effort on Square's part. Apps that rely on server-side verification weren't affected by the certificate change (that's all handled by Apple's servers). And there are now functions in the StoreKit API such as Transaction [apple.com] that fully offload the cryptographic process to the OS, abstracting away these kinds of changes. Though I don't believe this was available in 2020 when the game was first released.
Dev-wise, there may be other things that Square would need to do to bring the game into compliance with current App Store rules as well. The minimum SDK version Apple accepts right now is iOS 17 [apple.com], for example. So the project would need ported from what I'd wager is the iOS 13 SDK. That shouldn't be a big deal for a well-written app. But a poorly-written, minimum-effort port - especially one making heavy use of external libraries - could definitely have issues.
Ultimately, Square kind of tried to have their cake and eat it too, and it backfired on them. Had they not relied on IAPs, this issue would have been avoided. Alternatively, if they had gone fully in the other direction and used server-side verification, this issue would have been avoided. But the on-device route, while noble in some respects, also comes with the most maintenance work, which they are now opting out of doing.
Re:SHA-256 Purchase Receipts (Score:4)
So this is another example of having to constantly change things just to keep them the same.
Re: (Score:3)
Yes and no.
Cryptography is one of the areas where a lot of leeway is needed. As computers get faster and algorithms get weakened by attacks, it is critical that old algorithms are retired and replaced with new ones that can stand up to attacks for the coming decades. Otherwise we'd still be using the now trivially broken MD5.
Frankly, I'm surprised it has taken Apple this long to implement SHA-2 everywhere. The NIST stopped allowing it for digital signatures in government services over a decade ago, and web
Re: (Score:3)
Otherwise we'd still be using the now trivially broken MD5.
Note that MD5 is not that bad. It is still competent at protecting files against corruption or third party tampering, because a collision attack is not currently possible. The attack that is possible is when the data provider is the malicious party: the data provider can construct two distinct files with the same md5sum. This could be used to trick someone into validating one (binary, contract, etc) then actually using another. However once the data is created, it's not possible to subsequently create a sec
Re: (Score:2)
Are you sure about that? This is getting outside of my specialty here, but Wikipedia notes that the Flame malware was able to counterfeit a Microsoft MD5 signing certificate in 2012 [wikipedia.org]. That seems like exactly the kind of collision attack that warrants retiring it for signing certificates.
I do agree that it still seems fine as a basic file ha
Re: (Score:2)
There are two cryptographic properties here. Collision resistance means it's not possible to create two different files with the same hash. The collision resistance of MD5 is broken, which is why that attack worked. They were able to get Microsoft to sign something which contained their data, and produce some different data at the same time with the same hash. It was an attack against collision resistance because they created one file and had involvement with the creation of the other.
"Here's a file and a h
Unfixable bug? (Score:3)
That's kind of like an immovable object or an irresistible force. These things do not exist.
It would be more truthful to say that they don't *want* to fix the bug, perhaps because of the expense.