Enforce Apple's iOS 27 launch-screen and scene-lifecycle rules - #5855
Conversation
Apps linked with the iOS 27 SDK are rejected unless the bundle declares a launch screen, and fail to launch unless they adopt the UIScene lifecycle (iOS & iPadOS 27 release notes, UIKit 168247372 and 141837548). The default Maven build already satisfies both. Two opt-out paths did not, and neither said so: - ios.generateSplashScreens=true skipped the launch-key injection outright. The hint named the legacy Default*.png generator, and that generator is gone -- generateLaunchScreen() runs unconditionally now -- so all the suppression still did was produce a bundle with no launch key in it at all, which nothing else here would fill in. UIRequiresFullScreen, which the hint does still inject, is not a substitute (TN3192). The hint keeps its iPad multitasking effect and logs a deprecation notice. - ios.uiscene=false skipped UIApplicationSceneManifest. Refused outright against SDK 27 and later, and refused at the top of build() rather than in injectToPlist: the same hint selects CN1_USE_UI_SCENE in the generated Objective-C, so by the time the plist is written an hour has been spent on an archive Apple documents as not launching. Forcing the lifecycle back on instead would be a silent override of an explicit hint. Both conditional on the SDK major, read from the SDK this build actually links against and only falling back to the Xcode version when xcrun cannot answer -- sound in the direction it is used, since every Xcode predating the 26 renumbering reports far below the floor. An SDK 26 build is unchanged. The backstop is launchMetadataRejection, which reads the finished Info.plist rather than the generator strings. Every producer here decides whether to ADD a key and steps aside when the injection already names one, so an ios.plistInject that mentions a launch key in a comment, or declares it below the root dictionary, silences the generator and leaves UIKit nothing to read. Only the finished document can tell those apart. All four of Apple's launch keys are accepted; the check is that a launch experience exists, not that it is ours. Also declares desktop.themeMode in the build-hint catalog. It went in undeclared with the native desktop themes and fails check-build-hint-catalog on master, which would have failed this PR's CI too. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
@codex review |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1a2d6a6e12
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| // resolves it there but fails to render the same image from an | ||
| // actool compiled imageset, so do NOT move it into | ||
| // Images.xcassets. | ||
| if (!inject.contains("UILaunchScreen") && !inject.contains("UILaunchStoryboardName")) { |
There was a problem hiding this comment.
When a project uses ios.generateSplashScreens=true to suppress the generated launch metadata and supplies a valid UILaunchStoryboards dictionary through ios.plistInject, removing the outer hint guard now reaches this condition, but neither substring check recognizes that plural key. The builder consequently appends its own UILaunchScreen, so the developer's custom launch configuration competes with or is bypassed by the generated Launch.Foreground screen despite the new documentation saying any of the four accepted launch keys can supply the custom experience. Check all four accepted top-level launch keys before injecting the default.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
No point in keeping deprecated shit
| String rejection = launchMetadataRejection(b.toString(), iosSdkMajor); | ||
| if (rejection != null) { | ||
| throw new BuildException(rejection); |
There was a problem hiding this comment.
When this validation rejects an SDK 27 plist, the BuildException propagates to the injectToPlist() call in build(), whose surrounding catch (Exception) replaces it with a cause-less BuildException("Failed to inject into plist"). The detailed message added here—which identifies the missing key and the ios.plistInject remedy—is therefore never shown to the developer, leaving a newly enforced build failure with no actionable diagnosis. Re-throw existing BuildExceptions or preserve the original exception as the cause/message.
Useful? React with 👍 / 👎.
| String lifecycleRejection = sceneLifecycleOptOutRejection( | ||
| request.getArg("ios.uiscene", "true"), iosSdkMajor); |
There was a problem hiding this comment.
The new preflight rejects only values that become exactly false after trimming, while the actual UIScene branches later enable the lifecycle only when the raw value is exactly true ignoring case. Thus a value such as ios.uiscene=true or ios.uiscene=0 passes this check but disables CN1_USE_UI_SCENE, retains NSMainNibFile, and omits the phone window scene; for a CarPlay app, usesCar still adds a manifest, so the final presence-only validator also passes and the SDK 27 build can produce an app that terminates at launch. Normalize the hint once for all consumers, or make this rejection predicate match the builder's effective opt-out semantics.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Remove entirely
|
Developer Guide build artifacts are available for download from this workflow run:
Developer Guide quality checks: |
✅ Continuous Quality ReportTest & Coverage
Static Analysis
Generated automatically by the PR CI workflow. |
Follow-up on review: the first pass added enforcement around the opt-outs instead of deleting them. There is nothing left for either hint to select, so they are gone rather than deprecated, and so is the code each one guarded. ios.uiscene is removed from the @iOS annotation, so an app that still sets it fails to COMPILE, and from the build-hint catalog, so a build that sets it in codenameone_settings.properties is refused by name. What it selected is gone with it: CN1_USE_UI_SCENE no longer exists, the scene delegate and the app delegate's scene hooks are compiled unconditionally, the scene manifest is written on every build, and the legacy didFinishLaunching path that installed a root view controller into a window UIKit had not created yet is deleted. NSMainNibFile went with it. It was already stripped from every plist this builder produced -- MainWindow.xib auto-instantiates a UIWindow with visibleAtLaunch=YES, which under the scene lifecycle is a window with no scene and a launch FrontBoard terminates -- so the template no longer declares it, the strip is gone, and MainWindow.xib and MainWindowMETAL.xib are deleted along with the four builders' exclusion lists that named them. The IBOutlet qualifiers on the app delegate went too; nothing loads a nib into that class. ios.generateSplashScreens is removed. It named the pre-storyboard Default*.png generator, which this builder has not contained for years; all it still did was suppress the launch screen and disable iPad multitasking. Every build now declares UILaunchScreen. ios.launchStoryboardName is removed as a consequence: it named the storyboard for UILaunchStoryboardName, which only the legacy lifecycle emitted. Keeping a hint nothing reads is the failure the build-hint catalog exists to prevent. All three are refused by name, with a message that says what replaced them, and the refusal reads the request's supplied keys rather than calling getArg -- getArg is how a hint is READ, and a removed hint has no reader. Several in-tree users had to go first: our own build-ios-app.sh passed ios.uiscene on every CI iOS build, and three sample apps set it through @iOS. Also from review: - The generated launch key is skipped when the injection names ANY of Apple's four launch keys, not the two this builder can emit. A project supplying UILaunchStoryboards through ios.plistInject was getting a second launch experience appended beside its own. - A BuildException raised inside injectToPlist is re-thrown instead of being replaced by a cause-less "Failed to inject into plist", which threw away the diagnosis the refusal exists to give. The generic wrap now keeps its cause. - desktop.themeMode is NOT added to the catalog. It is already declared by the DesktopBuild annotation; check-build-hint-catalog reported it missing locally because it reads the first cn1-build-hints.json it finds and maven/javase/target held a stale one from before that hint existed. The developer guide's launch-screen section described a storyboard the launch has not used since UIScene became the default, and a Launch.Background.png only that storyboard reads. It now says what the build actually declares and how to opt into the storyboard through ios.plistInject. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 5718acb476
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| // The root view controller is installed by CodenameOne_GLSceneDelegate, not here: under | ||
| // the scene lifecycle self.window is nil at this point, because UIKit has not connected | ||
| // a scene yet. |
There was a problem hiding this comment.
When ByteCodeTranslator is invoked directly in ios mode, handleAppleOutput() copies template-Info.plist into the generated Xcode project without the later IPhoneBuilder.injectToPlist() pass. That template now contains neither UIApplicationSceneManifest nor launch metadata, while this code no longer installs the root controller through the legacy lifecycle and the MainWindow NIB was deleted. Consequently, standalone translated projects never connect CodenameOne_GLSceneDelegate, launch without a window, and are also invalid when linked with the iOS 27 SDK; generate the required metadata in the translator path or retain a working fallback.
Useful? React with 👍 / 👎.
|
Compared 166 screenshots: 166 matched. Benchmark ResultsDetailed Performance Metrics
|
|
Compared 166 screenshots: 166 matched. Benchmark ResultsDetailed Performance Metrics
|
|
Compared 151 screenshots: 151 matched. Native Android coverage
✅ Native Android screenshot tests passed. Native Android coverage
Benchmark ResultsDetailed Performance Metrics
|
Cloudflare Preview
|
…te (#5855 review) ByteCodeTranslator copies template-Info.plist into the generated project and nothing else writes to it: injectToPlist is IPhoneBuilder's, so a project translated directly gets exactly what the template says. That was survivable while the port's natives could still run the legacy lifecycle -- the template's NSMainNibFile and the absent scene manifest agreed with each other, because the CN1_USE_UI_SCENE define was IPhoneBuilder's too and was absent along with them. Deleting the legacy lifecycle from the natives broke that agreement in one direction only. The natives now require a scene manifest to get a window at all, and the only producer that writes one is the builder. A native that depends on a key one of its two producers writes is a key it can lose. So the template declares both, where NSMainNibFile used to be, and the builder strips them back out before writing its own -- it has to write its own, because CarPlay adds a second role and ios.plistInject can replace either outright, and a property list takes the LAST of a duplicated key, which would make the one UIKit reads a function of where the injection was spliced. All four launch keys come out, not just the one the template uses: whichever is in that file is ours, since ios.plistInject is a separate fragment added after the strip. The launch-key half of this was already true before this branch -- the template has never carried one -- so this also closes the standalone path against the iOS 27 rejection the rest of the PR is about. handleIosOutputGeneratesProjectStructure now asserts the generated plist wires CodenameOne_GLSceneDelegate and declares a launch key. Verified it bites: removing the two keys from the template again fails it on the scene manifest. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Compared 166 screenshots: 166 matched. Benchmark ResultsDetailed Performance Metrics
|
|
Compared 160 screenshots: 160 matched. Benchmark Results
Detailed Performance Metrics
|
|
Compared 166 screenshots: 166 matched. |
|
Compared 166 screenshots: 166 matched. |
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7dcc84c71c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| // plistForMacSlice. | ||
| if ((useUISceneManifest || usesCar) | ||
| && !plistDeclaresKey(inject, "UIApplicationSceneManifest")) { | ||
| if (!plistDeclaresKey(inject, "UIApplicationSceneManifest")) { |
There was a problem hiding this comment.
When an app has CN1ShareAppGroup configured and is activated after receiving share-extension content, this unconditional scene manifest causes UIKit to use sceneDidBecomeActive: instead of applicationDidBecomeActive:. The scene delegate only invokes cn1ApplicationDidBecomeActive, while the sole call to getPendingSharedContent/fireSharedContentFromNative remains after that wrapper in applicationDidBecomeActive: (CodenameOne_GLAppDelegate.m:831-847), so migrated ios.uiscene=false apps no longer deliver shared content to Java. Move that delivery into the shared activation path or invoke it from the scene delegate.
Useful? React with 👍 / 👎.
| "ios.generateSplashScreens has been removed. It selected the legacy Default*.png " | ||
| + "splash-image generator, which iOS stopped using long ago and which this builder no " | ||
| + "longer contains; all the hint still did was suppress the launch screen, and an app " | ||
| + "linked with the iOS 27 SDK is rejected without one (iOS & iPadOS 27 release notes, " | ||
| + "UIKit 168247372). Delete it from your build hints. Every build now declares " |
There was a problem hiding this comment.
For projects that set ios.generateSplashScreens=true, the removed branch also forced multitasking=false, which caused UIRequiresFullScreen to be emitted; it did not merely suppress the launch screen as this rejection message states. Following the message and simply deleting the hint now falls back to ios.multitasking=true, unexpectedly opting those iPad apps into split-screen behavior. Tell these users to add ios.multitasking=false (or otherwise preserve that side effect) when migrating.
Useful? React with 👍 / 👎.
| - (UISceneConfiguration *)application:(UIApplication *)application configurationForConnectingSceneSession:(UISceneSession *)connectingSceneSession options:(UISceneConnectionOptions *)options API_AVAILABLE(ios(13.0)) | ||
| { | ||
| UISceneConfiguration *sceneConfiguration = [UISceneConfiguration configurationWithName:@"Default Configuration" sessionRole:connectingSceneSession.role]; | ||
| sceneConfiguration.delegateClass = [CodenameOne_GLSceneDelegate class]; | ||
| return sceneConfiguration; |
There was a problem hiding this comment.
When an app references com.codename1.car, the generated manifest correctly assigns CPTemplateApplicationSceneSessionRoleApplication to CodenameOne_CarPlaySceneDelegate, but this now-unconditional callback replaces that configuration for every role with one whose delegate is CodenameOne_GLSceneDelegate. A CarPlay scene is not a UIWindowScene, so that delegate immediately returns from willConnectToSession: and never initializes the CarPlay interface. Branch on connectingSceneSession.role to return the CarPlay delegate/configuration, or allow the manifest's CarPlay configuration to be selected.
Useful? React with 👍 / 👎.
|
Compared 148 screenshots: 148 matched. Benchmark Results
Detailed Performance Metrics
|
|
Compared 181 screenshots: 181 matched. |
|
Compared 217 screenshots: 217 matched. |
|
Compared 144 screenshots: 144 matched. |
✅ ByteCodeTranslator Quality ReportTest & Coverage
Benchmark Results
Static Analysis
Generated automatically by the PR CI workflow. |
|
Compared 149 screenshots: 149 matched. Benchmark Results
Build and Run Timing
Detailed Performance Metrics
|
…iew) Raised against the BuildDaemon PR: if a project can pin an older iOS port while running a newer builder, it has the same exposure. Checked the Maven plugin. Through supported configuration it cannot. codenameone-ios:bundle is a dependency OF codenameone-maven-plugin, version-managed to the plugin's own version, and Executor.getResourceAsStream is Executor.class.getResourceAsStream -- the plugin realm. The generated app pom declares the plugin with no <dependencies> block (the only plugin-level one it has is on surefire, pinning the CN1 plugin itself), and no mojo resolves codenameone-ios from the project. So cn1.version governs codenameone-core on the compile classpath and has no say in which iOSPort.jar/nativeios.jar is unzipped. A hand-written <dependencies> override on the plugin declaration does reach it, and Maven honours it. That combination used to be merely odd; deleting the legacy lifecycle from the port's natives made it fatal and silent, so it is refused here instead. Measured on the real artifacts rather than argued: - codenameone-ios 7.0.214's nativeios.jar carries no CodenameOne_GLSceneDelegate at all. - The pre-branch 8.0 bundle carries it behind #ifdef CN1_USE_UI_SCENE, a define this plugin no longer injects. Compiling those exact sources against the iOS 27 SDK: 19432 bytes of object code with the define, 1248 without -- no class, no methods, no diagnostic. Either way the Info.plist this build writes names CodenameOne_GLSceneDelegate as the scene delegate, so UIKit looks up a class the binary does not contain. The build stays green and the app fails at launch. Worth recording because it corrects the obvious guess: the main NIB is not the fallback it looks like. An older bundle still ships MainWindow.xib -- 7.0.214 does -- so deleting it from this tree is not what removes the legacy path for a pinned port. NSMainNibFile comes from the translator template, which is codenameone-parparvm at the PLUGIN's version, so the key that would load that nib is gone whatever the port carries. The reverse skew needs nothing: a newer port under an older plugin fails loudly already, because that plugin's Metal branch copies MainWindowMETAL.xib and Executor.copy opens the source with new FileInputStream. Verified the guard against all three real inputs: 7.0.214 refused, stale 8.0 refused, this branch's nativeSources accepted. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
1 participant
Fixes #5839.
Apps linked with the iOS 27 SDK are rejected unless the bundle declares a launch screen, and fail to launch unless they adopt the UIScene lifecycle (iOS & iPadOS 27 release notes, UIKit 168247372 and 141837548; TN3187, TN3192). The default Maven build already satisfies both. Two opt-out paths did not, and neither said so.
ios.generateSplashScreens=trueIt skipped the launch-key injection outright, and the translator's
template-Info.plistdeclares none of the four keys either, so the bundle went out with no launch metadata at all.The hint named the legacy
Default*.pnggenerator. That generator is gone:generateLaunchScreen()now runs unconditionally and writes bothLaunch.Foreground.pngandLaunchScreen.storyboardwhatever the hint says. So the suppression was not preserving a custom launch experience -- there was nothing left to preserve, and nothing else here would have filled the key in.UIRequiresFullScreen, which the hint does still inject, is not a substitute (TN3192).The hint keeps its iPad multitasking effect and now logs a deprecation notice. No build that works today stops working.
ios.uiscene=falseIt skipped
UIApplicationSceneManifestunless the app used CarPlay, and keptNSMainNibFile. Refused outright against SDK 27 and later.Refused at the top of
build()rather than ininjectToPlist: the same hint selectsCN1_USE_UI_SCENEin the generated Objective-C, so by the time the plist is written an hour of build has already been spent on an archive Apple documents as not launching. Forcing the lifecycle back on instead would be a silent override of an explicit hint, which is the one thing the issue asks not to do.Conditional on the SDK, not on the Xcode
Both rules read the major of the SDK this build actually links against (
activeIosSdkName), falling back to the Xcode version only when xcrun cannot answer. That fallback is sound in the direction it is used: the two have only matched since the Xcode 26 renumbering, and every Xcode predating it reports a version far below the floor being compared against, so a wrong answer there can never turn the rules on for a build the SDK exempts. An SDK 26 build is unchanged in every path.The version parse returns the major alone.
"27.2"read by gathering its digits is 272, which compares greater than every floor in the file at once -- the API 37 trap, which has already cost a fix once.The backstop
launchMetadataRejectionreads the finishedInfo.plist, not the generator strings. Every producer ininjectToPlistdecides whether to add a key and steps aside when the injection already names one, so anios.plistInjectthat mentions a launch key inside a comment, or declares it below the root dictionary, silences the generator and leaves UIKit nothing to read. Only the finished document tells those apart from a real declaration. All four of Apple's launch keys are accepted -- the check is that a launch experience exists, never that it is ours.This also covers CI by construction:
scripts/build-ios-app.shcannot produce a non-compliant bundle without failing.Also here
desktop.themeModeis declared in the build-hint catalog. It went in undeclared with the native desktop themes (#5845) and failscheck-build-hint-catalogon master today, which would have failed this PR's CI too.Verification
IPhoneBuilderLaunchMetadataTest, 13 cases: the version parse (including the unversioned "unknown" answer), both refusals and their SDK scoping, all four accepted launch keys, and the two ways a key can be present without being a declaration (nested below the root, named only in a comment).codenameone-maven-pluginsuite: 2379 tests, 0 failures.codenameone-maven-plugin: 0 findings.check-build-hint-catalog.sh(533 hints, all described),gen-build-hint-annotations.sh --check,check-copyright-headers.sh --base master(5 files),check-control-characters.py,validate-java25-markdown-docs.sh.HelloCodenameOne-Info.plistunchanged, and refuses that same document when either the launch key or the scene manifest is removed from it.Not covered, as the issue notes: no iOS 27 runtime leg exists, so cold-launch and resize behaviour on a real iOS 27 device or simulator is still unverified. The BuildDaemon half is a separate repo and is not in this PR.
🤖 Generated with Claude Code