Anyone know if Apple have changed something in the requirements of the iOS version we can build for? I’ve got an app I want to keep supporting users who are still using iOS12 devices but I just got the following errors when uploading to testflight:
Asset validation failed (90208)
Invalid Bundle. The bundle ****.app does not support the minimum OS Version specified in the Info.plist. (ID: fd3415fd-28bf-42c7-a6f1-577af723a527)
Asset validation failed (90725)
SDK version issue. This app was built with the iOS 12.0 SDK. All iOS and iPadOS apps submitted to the App Store must be built with the iOS 16.1 SDK or later, included in Xcode 14.1 or later. (ID: 6353e104-14c2-45c9-94d1-4f231f291b64)
It uploads if I set the Deployment Target in Fire to be 16.4 but then the users on the older iOS versions can’t download it.
Hmm. it seems to think this app was built with the iOS 12 SDK. Not a bad deployment target, but built with an old SDK altogether. What version of Xcode (and this iOS SDK) are you building against? 14 or 15?
Can I see the full Diagnostic (re)build log, and the final Info.plist from the bundle?
Jmm. im wondering whether this fx for linker parameters, wjhkich wa necessary for Xcode 15, in fact does not work for Xcode 14
-platform_version iOS 16.4 12.0
… as always Apple is making a mess of it (for example, while Xcode 15 also documents to use tis new switch for macOS, it doesn’t work, which is why a Fire build from a few weeks back had no deployment target and only ran on macOS 14…
lemme “revert” this change, as in only use it for Xcode 15 and later, ands see if that fixes your issue…
Disclaimer, I haven’t tried latest Xcode 15 beta yet. The betas have been very unstable. Beta 2-5 were completely unusable, any (Elements) binary linked with them would just crash in weird places (like, Fire would crash in the middle of RTL2’s XmlDocument code reading an XML file, on startup; that same call to read the file would also fail in a standalone test app). No idea why until now.
Literally the only difference was whether it’d use the Beta 2-5 linker, or the Beta 1 or Beta 6 one (I was using the same SDK import files, and everything else that could affect the compile would not differ between betas).
Was very strange.
In Beta 6, all was fine again (and I haven’t had a chance to test later ones yet, I guess I should grab Beta 8 and see…).
-> Task Link started for LogOnn, Toffee-iOS.
D: Using cached data for Linker-Device.
<- Task Link finished for LogOnn, Toffee-iOS, took 0.0038s (0.003s).
Hmm, curious. do you have libRemObjects.Elements.LLVM.dylib in the folder where you’ve installed the external elements? the install.sh script should place a link there (to ./mac/libRemObjects.Elements.LLVM.dylib`).
If not, can you copy it there (or create a link) and retry?
I should probably have paid more attention to the install.sh output:
Detected platform: macOS on Apple Silicon
Touching files
Password:
Clearing GAC
sudo: gacutil: command not found
sudo: gacutil: command not found
sudo: gacutil: command not found
sudo: gacutil: command not found
sudo: gacutil: command not found
sudo: gacutil: command not found
sudo: gacutil: command not found
sudo: gacutil: command not found
sudo: gacutil: command not found
sudo: gacutil: command not found
sudo: gacutil: command not found
sudo: gacutil: command not found
sudo: gacutil: command not found
sudo: gacutil: command not found
sudo: gacutil: command not found
sudo: gacutil: command not found
sudo: gacutil: command not found
sudo: gacutil: command not found
sudo: gacutil: command not found
sudo: gacutil: command not found
sudo: gacutil: command not found
sudo: gacutil: command not found
sudo: gacutil: command not found
sudo: gacutil: command not found
sudo: gacutil: command not found
sudo: gacutil: command not found
rm: lld: No such file or directory
rm: llvm-rc: No such file or directory
rm: dsymutil: No such file or directory
rm: Core/*.deps.json: No such file or directory
Registering CodeDom
sudo: mono: command not found
Copying LLVM
usage: ln [-s [-F] | -L | -P] [-f | -i] [-hnv] source_file [target_file]
ln [-s [-F] | -L | -P] [-f | -i] [-hnv] source_file ... target_dir
link source_file target_file
ln: ./libRemObjects.Elements.LLVM.dylib: No such file or directory
ln: ./Core/libRemObjects.Elements.LLVM.dll.dylib: No such file or directory
Done.
These aren’t relevant/needed really (I should drop em), but it does seem like you don’t have Mono installed?
rm: … No such file or directory
those are fine to,. the script cleans up old stuff, and if theres no od stuff to clean up, it’ll emit this. welcome to sh
ln: ./libRemObjects.Elements.LLVM.dylib: No such file or directory
that one is weird, and its the problem. You’re running sh install.sh in the folder where the files are, right? Does ./Mac/libRemObjects.Elements.LLVM.dylib exist? it should be in the zip.
the one named .dll.dylib is the TARGET of the link, not the source (this is due to a nasty bug in .NET Core using bad names for loading dlls; unlike classic, it doesn’t drop .dll from the name, but it also doesn’t add it (on Windows), if you omit it). I dont see why this would fail…
Does this command also fail if you run it manually? does the Core folder exist (it should)?