According to my know, Solar2D uses templates to build apps for each platform, these templates (Including the target Xcode version) will be generated when Solar2D builds a new release.
This means, if you need to update your xcode version, you need to rebuild the templates for Apple platform and replace it with your current templates.
Do you have pages in mind that are out of date so we can look into it? I’ve been trying to keep the pages up-to-date for the ones I can track. I’ve probably missed on some but a list could help.
@Kan98 can you tell which of the following requirements are no longer relevant so that I can add a warning as such?
I thought the part in bold was also related to image masks 
Just sent the PR making the necessary change.
@bgmadclown Different manifestation of the problem, but it was the same faulty mechanism under the hood. (With similar behavior: either an outright crash or weird-looking shortening rows of pixels, when given a “bad” width.) There was a second problem with updates—after the texture was created, but for example when setting pixels in a mask-type memory bitmap—that @Kan98 flushed out and also fixed.
Speaking of “never got around to”, I do have notes for a lot of 3713+ stuff, and probably a few odds and ends before that. Very rough drafts in many cases, but I suppose it’s something. There is a lot of non-API material that wants some love too (maybe it should be in “guides”), but… well, hasn’t had any. 
Sure, I’ll show you some I’ve discovered. The first one that comes to mind is the one related to masks (Kan98 already advised you).
If you can share some of it maybe we can put together something using ChatGPT to speed up the process. Better than nothing I guess.
Please do. I have added the notice for Image Masks as @Kan98 pointed out. I’ve also discovered a few more stuff that I’ll send PRs to fix.
Here’s something I noticed:
In the plugin.admob documentation, under the adsRequest(https://docs.coronalabs.com/plugin/admob/event/adsRequest/phase.html) event phases, the closed phase is described as occurring only when an interstitial ad is closed. However, in my testing I found that closed also fires for other ad formats—excluding banners—like appOpen, rewardedInterstitial, and rewardedVideo.
Submitted a PR addressing the issue. Can you take a look?
As Kan said, yes, whenever a new version of Xcode is released, a supported GitHub CI runner image is required. Then, Solar2D uses the new Xcode version to compile the template within it and then releases the version. If you want to obtain the engine core compiled with the new Xcode version locally, apart from compiling the source code locally, you can only wait for the new template to be released.
However, it might be possible to accelerate the generation of the new template, for example, by adding a trigger that automatically or manually initiates the compilation upon the appearance of a new GitHub CI runner image, and then obtain the template.
Even further, consider separating the variable content from the release version, such as placing it in a plugin. However, this is generally only applicable to Xcode version updates that do not require manual intervention.
I’m not very satisfied with the current Apple integration, but I can’t start working on it at the moment.
It doesn’t fully support Apple Silicon and the device simulator. The fragmentation of platforms and architectures leads to duplicate code, which could potentially be resolved by using XCFramework or Pods, and the template, also the plugins, should also be reviewed together to make the Apple integration more flexible.
Understood. I suppose it would have been done already if it was simple, but thought it was worth double checking.
Hey @bgmadclown, this platform option was added to Solar2D some time ago, but it’s not mentioned in the documentation: "android-nongoogle" in build.settings, which controls plugin availability.
Here’s an example of how I used it:
["plugin.google.iap.billing.v2"] = {
publisherId = "com.solar2d",
supportedPlatforms = { android = true, ["android-nongoogle"] = false }
}
When you see "android-nongoogle", you might think it refers to all Android stores except Google Play. I tested it by setting Target App Store to "none", expecting the plugin to be excluded, but it still ended up in the APK.
In this post Kan98 suggests it may only apply to the Samsung Store. I tried setting Target App Store to "Samsung" as well, but the plugin still got included.
So, it’d be helpful to clarify how "android-nongoogle" actually works, and I think it definitely deserves a mention in the official docs.
Can we add the platform for the key as Samsung or would it be better as Samsung Galaxy Store?:
I can put it as @Kan98 describes it, “You need to set build target to Samsung for the key to activate.” Is that the correct way to describe it?
I think just add into table
[“android-nongoogle”] = Samsung
Done.
Great job !
All of this is quite confusing, and I believe that associating “android-nongoogle” with builds targeting Samsung makes things even more complicated.
Let’s analyze the situation: there are currently specific parameters for Amazon and the App Store. Also, using just “android” is commonly understood to mean a build intended for Google Play. In that context, the most logical and helpful approach for developers would be to use “android-nongoogle” for builds that are not targeting any of the major app stores like Google Play or the Galaxy Store.
In addition, I suggest introducing a new parameter, such as “galaxy”, specifically for builds targeting the Samsung Galaxy Store (whent you set Target App Store as Samsung), with plugin availability adjusted accordingly.
In my case, I distribute my games through several channels, including one with a Russian company. To generate builds for them, I have to create a separate build.settings file, removing all permissions required by Google Play and any Play Store–specific plugins. Since I can’t have both versions of the build.settings file in the same project, I currently switch them manually—backing up the original and replacing it with the custom one each time I need to build for that company.
If the suggestions above were implemented, the whole process would be much cleaner, more organized, and more practical for developers working with multiple distribution channels.
