App Store requirements

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?

That’s what I thought (it’s worked for years like this without an issue btw), using Xcode 14.3.1.

Sure…
debuglog.txt (61.3 KB)
Info.plist.txt (1.8 KB)
Thanks marc

Jmm. im wondering whether this fx for linker parameters, wjhkich wa necessary for Xcode 15, in fact does not work for Xcode 14 :frowning:

-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…

1 Like

Build 20230907-120838-elements-develop [water] should have that fix

I’ll try it, but presumably will need access to firehose again?

Sorry, hadn’t realized that had expired. fixed :wink:

Thanks, I’ll try it as soon as I see it appear there. Meanwhile, I’ll d/l XC15 and try that too.

1 Like

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…).

Beta 8 still seems fine :crossed_fingers:t3:

Still the same, sadly, with the updated elements on XC14. Log…
debuglog.txt (29.7 KB)

               -> 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).

:wink:

Ah, OK, I did a clean and re-built it, and it fails, here’s the last bit with the error:

    <- Phase Flow Analysis finished, took 0.095s.
                  -> Phase Generating Output started.
E:                   Internal error: System.DllNotFoundException: RemObjects.Elements.LLVM.dll assembly:<unknown assembly> type:<unknown type> member:(null)
  at (wrapper managed-to-native) LLVM.Interop.LLVMInterop.LLVMInitializeX86AsmPrinter()
  at RemObjects.Elements.Toffee.Output.ObjcOutput..cctor () [0x000db] in <524302e7829f4984838ae5e683626185>:0 
                  <- Phase Generating Output finished, took 0.022s.
               <- Target Toffee-iOS failed compiling for Device.
            <- Task Compile failed for LogOnn, took 3.8657s (4.040s).
         <- Task RemObjects.EBuild.Elements.ElementsBuildProject failed for LogOnn, took 0.0000s (4.048s).
      <- Project LogOnn failed, took 4.048s.
      Project 'LogOnn' failed to build.
      Solution 'LogOnn' failed to build project 'LogOnn'.
   <- Task RemObjects.EBuild.BuildSolution failed for LogOnn, took 4.0600s (4.060s).

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 :wink:

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.

Can you try manually running

sudo ln -s -f ./mac/libRemObjects.Elements.LLVM.dylib ./libRemObjects.Elements.LLVM.dylib

Good news! Short story, it works.

Longer story, I copied the dylib file up a level, re-ran the build, uploaded and it was just accepted. All good for iOS 12 !

Yes, and yes.

I removed the file I manually copied, and can confirm running that did indeed do what I’d expect so no idea why the install.sh didn’t.

1 Like

awesome. glad to know that was it. That was with Xcode 14, I assume?

Very strange. If you run sh install.sh again, does it fail with the same error again?

Yes

No. Only this one:

ln: ./Core/libRemObjects.Elements.LLVM.dll.dylib: No such file or directory

hmm. dll.dylib.

my .sh file reads

sudo ln -s -f `pwd`/mac/libRemObjects.Elements.LLVM.dylib /usr/local/lib/libRemObjects.Elements.LLVM.dylib
sudo ln -s -f `pwd`/mac/libRemObjects.Elements.LLVM.dylib ./libRemObjects.Elements.LLVM.dylib
sudo ln -s -f `pwd`/mac/libRemObjects.Elements.LLVM.dylib ./Core/libRemObjects.Elements.LLVM.dll.dylib

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)?