Can't install app to device/simulator

JeremyK · December 11, 2018, 4:31pm

I have a problem with Fire from .2347 but not all apps. Just one, but I tried all Fire versions I have from .2335 which work up to this one (some are missing and can’t be downloaded now). 2343 works just fine. The app won’t install to a simulator or device. On a simulator, I get:

Running /usr/bin/xcrun simctl install 43AD35F7-3C08-49DC-BA77-90D71F86B47C “/Users/Jeremy/Documents/GitHub/StockSoftware/Mobile/LogOnn/bin/Debug/iOS Simulator/Logonn.app”
simctl install: +An error was encountered processing the command (domain=IXUserPresentableErrorDomain, code=1):
simctl install: +This app could not be installed at this time.
simctl install: +Failed to chmod /Users/Jeremy/Library/Developer/CoreSimulator/Devices/43AD35F7-3C08-49DC-BA77-90D71F86B47C/data/Bundle/Application/2EAE4D06-64F2-4E71-8FFA-97068358EC6E/Logonn.app/Logonn : No such file or directory
simctl install: +Failed to chmod /Users/Jeremy/Library/Developer/CoreSimulator/Devices/43AD35F7-3C08-49DC-BA77-90D71F86B47C/data/Bundle/Application/2EAE4D06-64F2-4E71-8FFA-97068358EC6E/Logonn.app/Logonn : No such file or directory
simctl install: +Underlying error (domain=MIInstallerErrorDomain, code=4):
simctl install: + Failed to chmod /Users/Jeremy/Library/Developer/CoreSimulator/Devices/43AD35F7-3C08-49DC-BA77-90D71F86B47C/data/Bundle/Application/2EAE4D06-64F2-4E71-8FFA-97068358EC6E/Logonn.app/Logonn : No such file or directory

on a device, it gets to 70% copying the file then:

Installation progress: 70% VerifyingApplication
Error: AMDeviceInstallApplication | e8000067 (-402653081)
Deployment of app bundle failed.

mh · December 11, 2018, 4:36pm

Hmm. Nothing really changed here in weeks. The error sounds like a forked-up Simulator. I suggest resetting/cleaning it or even deleting and setting up a fresh one, and rebooting the Mac.

I assume the files in the .app all look good?

JeremyK · December 11, 2018, 5:03pm

Tried all of that (including trying a simulator I’ve not picked before, but then there’s also a problem deploying to a device), and there’s nothing showing in console either. The only consistent thing is if I build with .2343 all is well, later ones not so.

They look exactly the same if I look at the contents (obviously something will be different inside the exec file but the rest looks the same)

JeremyK · December 11, 2018, 5:11pm

Even if I build it with .2343 and try to run it with latest (i.e. don’t rebuild, just run), it fails. In fact, I just tried using the /usr/bin/xcrun simctl install xxx command in terminal, and if it’s built with the older one it works, with the later it fails (same error).

mh · December 12, 2018, 3:01am

hmm. Send me both good and bad app bundle and verbose rebuild log. I’ll have a look in the morning. (Just got back home to ).

JeremyK · December 12, 2018, 10:29am

Welcome home . I’ve done that, and one further snippet of useful info as I was doing it, I thought I’d try to see what the app store made of the builds to see if it is build related or deployment, and it’s almost certainly the former. I built a release version with .2343 and the app store accepted it, but the one from latest gives this:

ERROR ITMS-90207: “Invalid Bundle. The bundle at ‘Logonn.app’ does not contain a bundle executable.”

I’ve also sent you the activity log from application loader, though I’ve looked and can’t see anything that may help (other than the place the error occurs). Looking in the package, they look the same, and there is an exec so I can only guess there’s something in it that it doesn’t like but I have no idea how to investigate that.

mh · December 12, 2018, 2:54pm

The logs are a bit hard too compare because one is a rebuilt (which builds sim and device) and the other is not (ie sim only). ion you could redo a rebuild with both, that’d be cool. that said, from what I can tell, they look identical enough.

the same goes for the two app bundles, the Info.plist is the same; both binaries seem x86_64 (I’m assuming these are sim bundles, so thats good). im surprised by hoe different the Assets.car and the .nibs looks (id expect a few random bytes to differentiations, but there’s more), but those aren’t generated by us. The binary looks more different that id expect as well, but I don’t know enough about the structure to tell if that’s ok… I’ll ask Carlo.

side note, is this only this app that fails, or all apps you build with .2349? iirc there was some leaks issue you retested and said was fixed — so I assume other apps are fine?

jeremy · December 12, 2018, 3:05pm

I’ll do a rebuild with both and re-send shortly - sorry about that! I was trying to be consistent.

Just this one, that’s why I assumed it was me, as that’s the default setting It’s also why I thought I’d do a rebuild of my other app store app to see if that worked OK (but have the dropbox problem).

mh · December 12, 2018, 3:23pm

simctl install: +Failed to chmod /Users/Jeremy/Library/Developer/CoreSimulator/Devices/B9A39176-4262-4904-AE19-79C315FE6375/data/Bundle/Application/2535E48B-256B-407C-AB23-4649A78174A3/Logonn.app/Logonn : No such file or directory
simctl install: +Failed to chmod /Users/Jeremy/Library/Developer/CoreSimulator/Devices/B9A39176-4262-4904-AE19-79C315FE6375/data/Bundle/Application/2535E48B-256B-407C-AB23-4649A78174A3/Logonn.app/Logonn : No such file or directory
simctl install: +Underlying error (domain=MIInstallerErrorDomain, code=4):
simctl install: +        Failed to chmod /Users/Jeremy/Library/Developer/CoreSimulator/Devices/B9A39176-4262-4904-AE19-79C315FE6375/data/Bundle/Application/2535E48B-256B-407C-AB23-4649A78174A3/Logonn.app/Logonn : No such file or directory

does this file exist? the one it tries to chmod and fails?

mh · December 12, 2018, 3:25pm

Also, can you do an ls -la in there .app folder generated by build? I wanna see of all the file rights are proper.

jeremy · December 12, 2018, 3:26pm

No, because the install didn’t work. When I run the “xcrun simctl install” myself in terminal, I get the error before that. I guess you are doing the chmod regardless of the simctl result?

mh · December 12, 2018, 3:28pm

Also, can you try sunning simctl manually for the following combos:

new broken bundle, but with “good” exe copied over manually
new broken bundle, but with “good” Info.plist copied over manually
new broken bundle, but with “good” exe AND Info.plist copied over manually

and

old bundle with broken stuff exe/plist copied over?

mh · December 12, 2018, 3:28pm

I’m not doing chmod, simctrl does? To me it seems as off simctrl fails to copy the exe as part of the bundle, and then fails to chmod the missing exe. and App Store also somehow doesn’t see the bundle. (I assume if you exact the .ipa again, it’s there?). Does /Users/Jeremy/Library/Developer/CoreSimulator/Devices/B9A39176-4262-4904-AE19-79C315FE6375/data/Bundle/Application/2535E48B-256B-407C-AB23-4649A78174A3/Logonn.app/ exist after deploy of the broken app fails? what’s in it?

jeremy · December 12, 2018, 3:30pm

total 17704
drwxr-xr-x 22 Jeremy staff 704 12 Dec 15:28 .
drwxr-xr-x 5 Jeremy staff 160 12 Dec 15:28 …
-rw-r–r-- 1 Jeremy staff 778208 28 Jun 09:59 142100.wav
-rw-r–r-- 1 Jeremy staff 17938 12 Dec 15:28 AppIcon60x60@2x.png
-rw-r–r-- 1 Jeremy staff 23263 12 Dec 15:28 AppIcon76x76@2x~ipad.png
-rw-r–r-- 1 Jeremy staff 1154808 12 Dec 15:28 Assets.car
-rw-r–r-- 1 Jeremy staff 21357 28 Jun 09:59 ChaChing.mp3
-rw-r–r-- 1 Jeremy staff 1852 12 Dec 15:28 Info.plist
-rw-r–r-- 1 Jeremy staff 7631 12 Dec 15:28 KeyboardView.nib
-rw-r–r-- 1 Jeremy staff 58371 12 Dec 15:28 LaunchImage-700-568h@2x.png
-rw-r–r-- 1 Jeremy staff 75184 12 Dec 15:28 LaunchImage-700-Landscape@2x~ipad.png
-rw-r–r-- 1 Jeremy staff 59783 12 Dec 15:28 LaunchImage-700-Landscape~ipad.png
-rw-r–r-- 1 Jeremy staff 74902 12 Dec 15:28 LaunchImage-700-Portrait@2x~ipad.png
-rw-r–r-- 1 Jeremy staff 59165 12 Dec 15:28 LaunchImage-700-Portrait~ipad.png
-rw-r–r-- 1 Jeremy staff 58339 12 Dec 15:28 LaunchImage-700@2x.png
drwxr-xr-x 57 Jeremy staff 1824 12 Dec 15:28 LogOnnStoryboard.storyboardc
-rwxr-xr-x 1 Jeremy staff 6626880 12 Dec 15:28 Logonn
-rw-r–r-- 1 Jeremy staff 9 12 Dec 15:28 Pkginfo
drwxr-xr-x 4 Jeremy staff 128 12 Dec 15:28 Settings.bundle
drwxr-xr-x 3 Jeremy staff 96 12 Dec 15:28 _CodeSignature
-rw-r–r-- 1 Jeremy staff 4669 28 Jun 09:59 colorPalette.plist
-rw-r–r-- 1 Jeremy staff 7902 12 Dec 15:28 embedded.mobileprovision

mh · December 12, 2018, 3:31pm

Wait: your new exe is called LogOnn, the old one is Logonn. why is that? note that iOS is case sensitive.

mh · December 12, 2018, 3:34pm

Can you resend me the rebuild logs, but make sure level is set to Diagnostic? I think what you sent is just “verbose”, I dont see the CompilerOutput listed, which Diagnostic should do. What’s your AssemblyName set to, Logonn or LogOnn?

jeremy · December 12, 2018, 4:12pm

Fails.

Success !

Fails.

So it is, good spot. OK, so here’s a new test:
Build with latest, open package and change the exec name to Logonn, and manual simctl:
Success !

So, definitely that is the issue.

Will do shortly, you asked for the verbose one, so I’ll do the diagnostic now.

LogOnn. It’s always been set to that, as is the project name.

jeremy · December 12, 2018, 4:22pm

I just checked the one in an iPad from the app store, and it’s Logonn.

I’ve also opened some other projects I have with mixed case, and they deploy fine. I’ll see if I can work out what settings may be different.

mh · December 12, 2018, 4:44pm

Hmm, ok. So somehow the exe name has always been lowercased (except for the first char) in the past, but no longer is. But the PList still gets

	<key>CFBundleExecutable</key>
	<string>Logonn</string>

very freaky. Do you have CFBundleExecutable set explicitly in your Resources/Info.list?

Reviewing how this works…

    lPList.AddValue('CFBundleExecutable', Path.GetFileName(lExecutableName), true); // ok, this always overwrites whats in the project's Plist. good.

  var lExecutableName := Setting["BinaryName"].Value;
  MapSetting("AssemblyName", "BinaryName");

That’s AssemblyName. good.

And from the build log:

           -> Task RemObjects.EBuild.Elements.ElementsApplyLegacySettings started for LogOnn, Toffee-iOS.
               Mapping DefineConstants=DEBUG;TRACE;TestCounts;DeviceTest to ConditionalDefines
               Mapping AssemblyName=Logonn to BinaryName
               Mapping CodesignCertificateName=iPhone Developer: Jeremy Knowles (F7M8L62S66) to CodeSignCertificateName
               Mapping MacIconFile=.\Resources\App.icns to ApplicationIcon
            <- Task RemObjects.EBuild.Elements.ElementsApplyLegacySettings finished for LogOnn, Toffee-iOS, took 0.0009s (0.0011s).

It seems that despite what you said above, AssemblyName is set to Logonn , lower-case O. I see this above in both versions of the log.

So this oars is correct, the proper AssemblyName/BinaryName that (apparently) is in the project gets written into the Info.plist. Now, why is the actual exe not valid that…

:             CompilerOutput for Toffee-iOS
D:               - <CompilerOutput-Device-arm64: /Users/Jeremy/Library/Application Support/RemObjects Software/EBuild/Obj/LogOnn-A29754483E035F7E930AFA68640D1BD1F6FCD444/Debug/Toffee-iOS/Device/arm64/Logonn.a [Target: Toffee-iOS]>
D:               - <CompilerOutput-Device-arm64: /Users/Jeremy/Library/Application Support/RemObjects Software/EBuild/Obj/LogOnn-A29754483E035F7E930AFA68640D1BD1F6FCD444/Debug/Toffee-iOS/Device/arm64/Logonn.o [Target: Toffee-iOS]>
D:               - <CompilerOutput-Simulator-x86_64: /Users/Jeremy/Library/Application Support/RemObjects Software/EBuild/Obj/LogOnn-A29754483E035F7E930AFA68640D1BD1F6FCD444/Debug/Toffee-iOS/Simulator/x86_64/Logonn.a [Target: Toffee-iOS]>
D:               - <CompilerOutput-Simulator-x86_64: /Users/Jeremy/Library/Application Support/RemObjects Software/EBuild/Obj/LogOnn-A29754483E035F7E930AFA68640D1BD1F6FCD444/Debug/Toffee-iOS/Simulator/x86_64/Logonn.o [Target: Toffee-iOS]>

so far so good. the compiler uses the “correct” name

-o "/Users/Jeremy/Library/Application.../Simulator/x86_64/LogOnn"

but the linker also gets the wrong output name… lets see

          var lFinalBinaryName := Setting["FinalBinaryName"];

and there we have it. FinalBinaryName is set by ElementsPrepareToffeePlatform, which runs before ElementsApplyLegacySettings now, and thus doesn’t see the BinaryName yet, and falls back to it’s default (project name).

This happened as part of some refactoring I did a couple weeks ago :(. Will fix.

Workaround for now would be to really set the AssemblyName to LogOnn, so that project name and assembly name match, as that will hide this bug.

jeremy · December 12, 2018, 5:41pm

There was a CFBundleIdentifier but it was empty for some reason.

Incidentally, Logonn is what I actually want it to be. I’ve gone through and changed all the references to all be lowercase and it now deploys fine.

Btw, fire (in project tree) won’t let things be renamed if you’re just changing the case, and I had some weird overlaying stuff when I tried:

Thanks for the help, and I’ve learned a few more diagnostic ideas