KiteSSOT/io.github.yuroyami.kitessot/KiteSsotIosExtension

KiteSsotIosExtension

Apple settings inside kiteSsot { ios { ... } }.

The root block holds the truth about your app: its name, its version, its ID. This block holds only what Apple needs on top of that: the bundle suffix, the two version fields, and where your Xcode tree lives.

kiteSsot {
    appName = "Jetzy"
    version = "1.4.0"
    appId = "com.example.jetzy"

    ios {
        bundleIdSuffix = ".iosApp"
        rebuild = 3

        sync {
            targets("iosApp")
        }
    }
}

Every path here already points at the standard Kotlin Multiplatform layout. Set one only when your tree looks different.

Nothing in this block writes a file on its own. Apple sources change only when sync is configured and you run a sync task yourself.

There is one derived read-only value, bundleId: Provider<String>: the root appId followed by bundleIdSuffix.

The two Apple version fields

Apple splits what Android keeps in one place. Getting them confused is the usual cause of a rejected TestFlight upload.

Field	Xcode setting	Who sees it	Rule
marketingVersion	`MARKETING_VERSION`	App Store customers	may repeat across uploads
buildNumber	`CURRENT_PROJECT_VERSION`	TestFlight testers	must be new for each upload of the same version

So a re-upload of 1.4.0 keeps the marketing version and needs a fresh build number. Turn rebuild rather than inventing a version nobody shipped.

What this block does and does not touch

Property	Written into your Xcode project
bundleIdSuffix, marketingVersion, buildNumber	yes, by an explicit sync task
deploymentTarget	no, it only validates the AppIcon catalog
pbxproj, podfile, infoPlist, appDirectory, appIconDirectory	no, they say where to look