Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixed non notched window size on notched devices when sideloading an app #31

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

Luki120
Copy link
Contributor

@Luki120 Luki120 commented Mar 28, 2023

What does this implement/fix? Explain your changes.

  • See title. This happened because the way the system detects the resolution of the iPhone changed starting from xcode 6/7 and iOS 9. Now a UILaunchStoryboardName key in the Info.plist is needed instead of a bunch of png files. Relevant sources:

    Source

    Source 2

Does this close any currently open issues?

Any relevant logs, error output, etc?

Any other comments?

  • Note: this leaves no way to provide a launch screen image since there's no Storyboard file. However, the previous way doesn't work either in modern iOS versions + it has this "bug" if you sideload the app, so it can be used as a workaround until there's actually a way to ship a launch screen image with Theos

Where has this been tested?

Operating System: Kubuntu 22.04.2 LTS x86_64

Platform: Linux

Target Platform: iOS

Toolchain Version: Swift 5.7.2

SDK Version: 15.5

⇝ replaces UILaunchImageFile with UILaunchStoryboardName
@PoomSmart
Copy link
Contributor

Doesn't this remove backward compatibility? Will it be better to add a separate template for building apps on modern OS versions using Theos?

@Luki120
Copy link
Contributor Author

Luki120 commented Mar 28, 2023

Well I guess yeah, is it worth it though? There’s probably not many people making apps for < iOS 9, which is less common than tweaks, otherwise two new templates would’ve to be made for both Objective-C and Swift, but sure that’s also a solution

@L1ghtmann
Copy link
Member

L1ghtmann commented Jul 30, 2023

I'd argue against modifying the current templates as-is w/o adding legacy counterparts as targeting legacy iOS versions is still a supported use case for Theos. That being said, it does seem a bit much to add two new templates -- one for the ObjC app and one for the Swift -- with only an Info.plist change. Do we think it would be worthwhile to simply comment out the 'legacy' implementation, with a short message describing when you'd want to uncomment it, and add the changes proposed here?

@leptos-null
Copy link
Member

Do we think it would be worthwhile to simply comment out the 'legacy' implementation ...

No, comments in plists are not well supported and we should avoid this. Also, I feel like it does not provide a great user experience in my opinion.

@L1ghtmann
Copy link
Member

Fair enough. So does out-of-the-box legacy support take priority over sideloading support or do we want to add a couple "legacy"/"modern" templates? I'm kinda leaning towards the priority scenario personally

@Luki120
Copy link
Contributor Author

Luki120 commented May 18, 2024

Idk, as you said providing new templates with just an Info.plist change seems like too much, however sideloading a Theos app is also a common scenario, since you’ll most likely want your app to work on jailed. Realizing your app’s screen size suddenly looks different without knowing why until you start googling and find that the issue is in your plist isn’t a great user experience either imo.
I’d prioritize sideloading support for newer deployment versions while also let the Theos user know in some way how to provide launch images for older iOS versions, which doesn’t involve comments in plists, as per Leptos comment. Maybe some kind of section on theos.dev?

@L1ghtmann
Copy link
Member

Hm. I think we have three options assuming we don't go with additional templates:

I am sort of leaning toward one of the first two, but open to hear others' thoughts.

@Luki120
Copy link
Contributor Author

Luki120 commented Jun 8, 2024

I'd go with either 2 of 3 if it were me

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants