Error copying source file iOS

[JojoIce]

When iOS is selected as target platform and "generate project!" is selected an exception is thrown:

Preparing the project... com.badlogic.gdx.utils.GdxRuntimeException: Error copying source file: generator/ios/data/Media.xcassets (Internal) To destination: /.../test/ios/data/Media.xcassets/Contents.json (Absolute) at com.badlogic.gdx.files.FileHandle.copyFile(FileHandle.java:718) at com.badlogic.gdx.files.FileHandle.copyTo(FileHandle.java:603) at com.github.czyzby.setup.data.files.CopiedFile.save(projectFile.kt:106) at com.github.czyzby.setup.data.project.Project.saveFiles(project.kt:121) at com.github.czyzby.setup.data.project.Project.generate(project.kt:89) at com.github.czyzby.setup.views.dialogs. GenerationPrompt$doBeforeShow$1.run(generationPrompt.kt:45) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Unable to generate project due to an exception. Try again.

Maybe some files are missing? (generator/ios/data/Media.xcassets) Worked in 1.9.11.2 and somewhere between there and this version it was broken.

[tommyettinger]

Hm, generate works here on the current version, with iOS selected. It looks like the error is due to trying to copy Media.xcassets, which is a folder, to Contents.json, which is a file. I don't seem to have this issue in the current version, and I don't have a Mac I can test on (if it's a MacOS-specific bug). It sounded like you had created an iOS project successfully by setting the libGDX version to 1.9.13 in #41 ; is this resolved now, or does it still sometimes occur?

[JojoIce]

Ah, indeed I have downloaded the same version on Mac an Win and it works on win but fails on Mac (always)... The old mantra write once debug everywhere still holds... On mac you end up with the folder Media.xcassets containing an empty Contents.json and no more files or folders there and the Base.lproj is missing next to Media.xcassets. Other than that it seems to have completed OK. Regarding #41 I remembered from earlier that many files were copied from a resource folder, so I just downloaded from github and poached the data folder and that seems to have "completed" the project.

And it seems to have been right after 1.9.11.2 that it broke, so that was the last one where ios was working on mac. Just desperately grasping at straws here, could it have anything to do with the "." in folder name or possibly some slashes leaning in the wrong direction? It doesn't make a whole lot of sense that it would be able to create the Contents.json and then not be able to copy the contents... but maybe some kotlin mac specifics going on, and it is what you say it tries to copy a folder into a file because it gets confused by the . in the folder name? Guessing the Media.xcassets folder was introduced in 1.9.11.3?

[tommyettinger]

I really hope this is fixed in Release 1.9.14.2. I did create an iOS project and the Contents.json file in question is empty with a 1.9.14.1 project, but correctly filled-out on a 1.9.14.2-created project. I did not try to build the project because I don't have a Mac. That was the only Contents.json file I could find that was incorrect before, but I still may have missed something else.

[JojoIce]

You are correct, unfortunately in all points including the last one as well it seems: Preparing the project... com.badlogic.gdx.utils.GdxRuntimeException: Error copying source file: generator/ios/data/Base.lproj (Internal) To destination: /.../test/ios/data/Base.lproj/LaunchScreen.storyboard (Absolute) at com.badlogic.gdx.files.FileHandle.copyFile(FileHandle.java:718) So yes first problem is solved, but now it got stuck on another file. Hopefully, now it will be a simple fix for Base.lproj/LaunchScreen.storyboard as it seems to be the same kind of problem.

[tommyettinger]

Thanks, I'll get on this right now.

[tommyettinger]

Well, here's a snapshot build so you can test: gdx-liftoff-1.9.14.3-SNAPSHOT.jar.zip . This should be the same as building the latest commit.

[JojoIce]

Quick lunchbreak test, and it seems to have been resolved! I have not tested sending to apple, but creation of project including iOS on Mac completes without error in liftoff. Great! I think this can be closed, or if you do that with the release.

If I get time later on today, I will try to create a "Super-Koalio" iOS project and upload it unchanged to Apple to see if that works as an ultimate test.

[JojoIce]

So I tested with the Koalio template and that worked in iOS! Well sort of... It got displayed in lower left quadrant of the screen and was very squeezed horizontally, but I am assume that is just because the template wasn't really ready for mobile (even though touch control was implemented) and has nothing to do with liftoff.

[tommyettinger]

Sounds about right; I don't imagine the original Super Koalio demo was tested much on iOS, or if it was, not on Retina displays. I'll see if there's a way to address #28 and then push a release.

[tommyettinger]

OK! 1.9.14.3 is released, and the README.md is also updated now. I think I can close this now? I'm probably inviting in some other sort of build issue as soon as one gets fixed, but we'll see...

[JojoIce]

This is great... almost. I am sad to say that lower left quadrant thing with Koalio really is a problem and it is like that for everything I have tested and it was not a problem in the 1.9.11.2 version. Seems like Gdx reports half screen resolution for iOS devices. Tested on both iPhone and iPad. Not sure what the problem is.

[tommyettinger]

Hmm! @JojoIce , can you try making a project with 1.9.11.2 , but then only after making the project, just change the gdxVersion in gradle.properties to 1.9.13? That would help figure out if it has to do with generated configuration files, or something in libGDX 1.9.12 or 1.9.13. There's also a possibility that RoboVM is a factor, so could you try with and without changing the robovmVersion to 2.3.12 ? I still have no idea where to even start looking for changes... I guess git blame...

[JojoIce]

This is such a pain to debug. It does not work well to test from computer to mobile for some odd reason, so I have to send to apple and then download via testflight... Timeconsuming. It also seems to be two problems (at least) at the same time with similar symptoms that really confused me. Some issues only show up on phone and other on iPad... So what I think works is: robovmVersion=2.3.11 gdxVersion=1.9.11 and possibly remove the png from the ios/data/ Too late to really verify, but I think that higher than 1.9.11 then screen is only one quarter of the display, and for SOME devices where there is no matching size of png in the data folder, the screen will clip to whatever closest png size. There seems to be no narrow and tall image for a phone like iPhone 8 or 12 for example, so it will then have black borders at top and bottom, or at other devices it looks like it is OK, but the resolution is less than the phones and scaled up (not initially noticeable). This seems to happen even though the LaunchScreen is available (and only that should be used) but I have to test again to verify. This is all very confusing, and I think it is a combination of things. I will try to get another test tomorrow, to see what has to be done to latest release to make it work fine on iOS devices.

So possibly one gdx problem and one liftoff problem.

[JojoIce]

So this issue was really 3 different ones. Fist one already handled, but will continue here unless you want to break up the topics.

So I created an issue on libgdx: 6453 That is (sadly) closed, but as I explained further down in that ticket it seems like 1.9.12+ brutally breaks many existing apps, including 100% of the two templates I tested using liftoff. Classic and Super-Koalio.

That is naturally not great and can be very confusing to all new people coming to liftoff and possibly several not so new as well (at least this one).

So again, maybe step one version down more (1.9.11) or document why the behaviour is as it is. That part I still have not quite grasped. Best way is maybe to fix the templates so they work if possible. Using Viewport somehow could be the solution, but unsure there. Could be lots of work.

[tommyettinger]

I'm attempting to figure out why classic gets clipped, because it really shouldn't be doing anything that risks clipping. I did find some places in super-koalio (well, one place) where the screen width is used and it should use getBackBufferWidth(), I think. I think you found something related with the PNG in the data folder, but I have no idea what is going on there... Maybe an asset is missing in one of the lists... It is odd that a missing PNG of a certain size can shrink the usable screen space.

[JojoIce]

Thanks for shooting ideas. I have some ideas of what is happening. I am not sure, but this is what I think.

There are at least two different problems.

First off, apple used an approach for Splash-screens (or whatever you call the initial image that shows just before the game actually starts). One can provide a specific image for each resolution, but with some scaling so something like Default-375w-667h@2x.png is an image of 750x1334. Sometime it include ipad sometimes it does not include the @ and so on. All that strange stuff directly in the data folder. It is very confusing and when a new device appears on the market it will not display or work correctly... Apple finally realised that it was not a good solution and instead created the storyboard. It is slightly more complex, but much better. With that you just specify one splashscreen and describe where you want to place images as percentages of screen size and scale and so on, so that it looks good on any screen resolution and formfactor. For that you would use a tool in xcode (or steal an existing one;)).

What I think happens with the first approach (weirdly named images) is that the ios device somehow pics the image from the data folder that (best) fits the display and shows it while the app preps and loads. However if no image really fits, like the first time I tested on a new iPhone with the notch, no image would fit that (narrow tall) formfactor. It seems like it then picks the closest image somehow, BUT (not sure if this is a gdx bug) the screen that Gdx then reports thereafter will be the size of that image and not the actual device screensize! This is quite baffling but it really seems to be the case. So on the iPhone 12 it had black border top and bottom in the game. At that point I fully made the switch to storyboard.

Removing the png in data and instead using storyboard is the way. I saw that it looks like you simply copied the setup from somewhere in Libgdx, but images in data AND storyboard does not really make sense since they do the same thing if I have understood anything right. I don't know if images possibly is a fallback in case it runs on a very old iOS version maybe, but I have supplied it like that to apple and there were no complaints (and they do let you know about most things that in any way can be wrong).

So I think that removing your images in ios/data/ would be a good thing, since they can be the source of some odd behaviour.

The other thing is more of a gdx thing I think. See libgdx#6454

and as mentioned before libgdx#6453

The way I read the response is that they don't really care that many existing games will not display properly on iOS on 1.9.12+. The classic template has no single getWidth() and yet it does not at all render properly for example. Sadly that means that you have three options:

1. Have to have Templates that don't display correctly on iOS.
2. Remove all the Templates that suffer (for all platforms) to not create faulty templates.
3. Try to fix all the Templates, but the information I have seen so far did not help me even to see how the Classic template should be fixed. Probably adding viewport somehow, but very unclear. Somehow it should be obvious, but even the gdx-setup creates a project that is flawed in the same way, so not even the gdx devs are fully on board on how to do this obvious thing correctly.

Hopefully the #6454 will result in something that makes things more clear, and that it is not a very complicated fix.

[JojoIce]

Ah. This might save you a lot of headache: libgdx#6366 Have not looked into it, but you (we) are not alone with this problem fortunately!

So option 4, wait for next release and hope the fix will be a lot easier.

[JojoIce]

So it seems like this finally is properly acknowledged and seen as a problem (#6454), and will hopefully be fixed. The way I see it 1.9.12 - 1.9.14 is lost for iOS development. I will personally stick with 1.9.11, but fortunately someone else will have to decide how to do with liftoff ;)

I am cautiously hoping that all the templates will start working again with 1.9.15. If not, then hopefully only minor changes are needed with some migration path laid out.

[tommyettinger]

So, ok, there was a missing image in data/ ; it was present in the liftoff JAR but was not getting put into projects. Here's a SNAPSHOT jar that includes that fix: gdx-liftoff-1.9.14.4-SNAPSHOT.jar.zip But, as I understand it, storyboards are a better approach. And, as I continue to filter through these issues, apparently the default template is also broken in gdx-setup... I look forward to that PR. It's probably a one-line fix to set the SpriteBatch's projection matrix, so should be easy to apply to liftoff too.

[JojoIce]

I had a quick look and "fixed images" is not even mentioned that they can be used on the apple pages, so I would just remove them, and make sure that the part for the storyboard is available: `

UILaunchStoryboardName

<string>LaunchScreen</string>

`

https://developer.apple.com/design/human-interface-guidelines/ios/visual-design/launch-screen https://developer.apple.com/documentation/uikit/app_and_environment/responding_to_the_launch_of_your_app https://developer.apple.com/news/?id=voseytot

I guess there is a bit of a violation to have the liftoff logo in the storyboard according the Apples guidelines, but meh...

In all the games I am testing I have removed all fixed images in the data folder and it seems to be fine.

I guess the original topic is fixed and the derailed following topics will hopefully just be fixed in next Gdx release, so it is OK to close this if you want.

[tommyettinger]

Err, do I need to add that UILaunchStoryboardName key to liftoff now, or was it already there? Hopefully everyone who's paying money to Apple to release an app will take the short amount of time to customize the app icons, since that is a huge part of the identity of an app.

[JojoIce]

Very short on time, but as I remember the storyboard stuff is all there so you only need to remove the "fixed images"/splash screens in the data folder.

I was a bit unclear with the logo on the storyboard. I think Apple states that the splash / storyboard should not be used to advertise the logo. So even though people hopefully would replace the liftoff logo, it is showing a "bad example" of how to do it (maybe people will just replace the image and leave the storyboard the same?). According to apple it should be very similar to the main screen / first page showing or something like that (as I remember), so that it looks like it starts fast. On the other hand 100% of casual games do exactly the logo advertisement, and you could also argue that you want to show the logo when the game starts during the time that you load resources, and then the storyboard probably should show exactly the logo. So as I said, meh...

I'd say keep it as it is and maybe if you want to be really helpful and clear, add a link to Apple where they describe how to create a proper storyboard and the guidlines.