Skip 1.6.16 eases testing you apps with the Release configuration

[marcprux]

In order to test an app with all the release build optimizations enabled, iOS developers are accustomed to switching from "Debug" to "Release" configurations in the project's scheme editor.

Skip has always passed along this build configuration option to the Android Gradle build that is performed when the app is run against an Android emulator or device. This is especially helpful for verifying the Android app's performance, as release builds will drastically improve the performance of Jetpack Compose components, so you can get a much truer picture of how your app will behave in the real world. In addition, the Proguard/R8 minification and optimization that is automatically performed by release builds greatly helps to reduce app size, but can sometimes cause issues with naming and reflection. These are much better to catch early in your app's development cycle, rather than waiting for crash reports to show up in the Google Play Console!

Unfortunately, Gradle's default behavior is to treat Debug and Release builds differently in terms of app signing. When building in Debug mode, the Android Gradle Plugin will sign the app with an auto-generated key (stored in ~/.android/debug.keystore). But unlike iOS, where developer builds are signed with the same ad-hoc developer key regardless of the Debug/Release configuration, Gradle will default to enforcing that an actual signing key is present for Release builds, and will fallback to creating an unsigned .apk when it is absent (rendering them un-installable on an emulator or device). So unless the developer had already followed the process of creating their app's signing keys (which is typically done closer to the time when the app is to be uploaded to the Play Store), flipping the build configuration from "Debug" to "Release" would result in a confusing error message about not being able to install the app.

Skip 1.6.16 addresses this issue by having the default build.gradle.kts file that is generated by skip create and skip init fallback to using the debug key when there is no Android/app/keystore.properties file present. This has the benefit of making Release builds work out of the box for developers in the way they likely expect. In addition, signing the Debug and Release builds with the same debug key has the advantage that the same app can be built and run on an emulator or device without having the first delete the app, which is not the case when the app is signed with different keys (Android will prevent an appid that was signed with one key from being overwritten/upgraded by the same appid signed with a different key, which would necessitate manually deleting the app before being able to launch the newly-signed version — which makes going back and forth between Debug and Release builds a very tedious and destructive process).

Note that since this is part of the Android/app/build.gradle.kts file, which, once created, is untouched by Skip's tooling, if you have already created a project prior to Skip 1.6.16, then you will not get this behavior automatically unless you manually update your project. If you haven't customized your build.gradle.kts, then you should just be able to copy & paste the default project's build.gradle.kts contents into your own version and it should work fine.

So in short, you should now be able to easily flip between Debug and Release modes from Xcode, and test out the performance of both your iOS and Android apps when full release optimizations are applied.

As always, Happy Skipping!

[marcprux]

To get a feel for the difference, here is the stock "Hello Skip" template app's "Home" tab, and a demonstration of fling scrolling through a list of 365 items in each of Release and Debug mode:

Release Mode	Debug Mode
Skip_Performance_Release.webm	Skip_Performance_Debug.webm

[christoff-1992]

@marcprux Is there anything specific required when running in release mode when you have Compose integration?

(Previously didn't run the application in debug mode due to not having the signing certs setup. However after updating from 1.6.13 to 1.6.16 I have now attempted to run this in release mode)

In debug mode this runs fine on the Android Emulator but in release mode it will crash with.

Abort message: 'xxxxxx/CircularProgressView_Bridge.swift:43: Fatal error: 'try!' expression unexpectedly raised an error: java.lang.ClassNotFoundException: Didn't find class "xxxxxx.ui.ProgressOverlayComposer" on path: DexPathList[[zip file "/data/app/~~7NgsLY0zzFxLERBZ8UGbQA==/com.xxxxxx.xxxxxx-xxxxxx==/base.apk"],nativeLibraryDirectories=[/data/app/~~7NgsLY0zzFxLERBZ8UGbQA==/com.xxxxxx.xxxxxx-xxxxxx==/lib/arm64, /data/app/~~7NgsLY0zzFxLERBZ8UGbQA==/com.xxxxxx.xxxxxx-xxxxxx==/base.apk!/lib/arm64-v8a, /system/lib64, /system_ext/lib64]]'

This is for the following example:

#if SKIP
import androidx.compose.ui.unit.dp
import androidx.compose.ui.Modifier

struct ProgressOverlayComposer : ContentComposer {
    let progress: Double
    let size: Int
    let colour: Color

    @Composable override func Compose(context: ComposeContext) {
      var modifier = context.modifier
      modifier = modifier.flexibleWidth(ideal: Float(size), min: Float(size), max: Float(size))
      modifier = modifier.flexibleHeight(ideal: Float(size), min: Float(size), max: Float(size))
      androidx.compose.material3.CircularProgressIndicator(
        progress = Float(progress),
        strokeWidth = 12.dp,
        modifier = modifier,
        color = colour.asComposeColor()
      )
    }
}
#endif

In the bridging file I can see it fails on this line.

nonisolated private static let Java_class = try! JClass(name: "xxxxx/ui/ProgressOverlayComposer")

I have put the compose view into its own file to isolate the code whilst testing this named 'ProgressOverlayComposer' as it was part of the main swift view.

When I run in release mode once again I will get the crash.

xxxxx/ProgressOverlayComposer_Bridge.swift:5: Fatal error: 'try!' expression unexpectedly raised an error: java.lang.ClassNotFoundException: Didn't find class "xxxxx.ui.ProgressOverlayComposer"

However I can see this file in the generated build.

Update:

It appears this may be happening as its been removed from the build.

When isMinifyEnabled && isShrinkResources is set to true this fails, but when these are set to false it fails.

buildTypes {
        release {
            signingConfig = signingConfigs.findByName("release")
            isMinifyEnabled = true
            isShrinkResources = true
            isDebuggable = false // can be set to true for debugging release build, but needs to be false when uploading to store
            proguardFiles(getDefaultProguardFile("proguard-android.txt"), "proguard-rules.pro")
        }
    }

I thought this would ensure that they were kept, however apologies if this is my miss understanding.

-keep class xxxxx.module.** { *; }

Update

Looks like I needed to update this to include the .ui

-keep class xxxxx.module.** { ; }
-keep class xxxxx.ui.* { *; }

How are these generated by skip? I know in the example for skip-hello-fuse it only includes the one keep even though there are multiple packages defined for the Models/UI etc.

-keep class hello.skip.fuse.** { *; }

[marcprux]

How are these generated by skip? I know in the example for skip-hello-fuse it only includes the one keep even though there are multiple packages defined for the Models/UI etc.

When a Skip project is created with skip create or skip init, the default proguard-rules.pro file will add a -keep line for the package name of Kotlin package derived from the Swift module name. The .module package suffix occurs in cases when the naming conversion results in only a single element in the package name, which is not legal for an Android package.

So for example if your Swift module is named "HelloSkip" then the resulting package name will be "hello.skip", but if your module is named "Showcase", the resulting package name will be "showcase.module", because just having it be "showcase" would cause an error in the Android build.

You are probably best off starting out with -keep class xxxxx.* { *; }, and then narrowing that down to specific classes that need it over time if you feel your app will benefit from additional minification (or obfuscation). But note that anything that is bridged will need to be un-minified. In the future we may add the @Keep annotation to the auto-generated bridge classes in order to prevent the need of adding them manually to the proguard-rules.pro file.

[christoff-1992]

Thank you that clears this up!