Environment
✔ Component nativescript has 7.0.11 version and is up to date.
✔ Component @nativescript/core has 7.0.13 version and is up to date.
✖ Component @nativescript/ios is not installed.
✔ Component @nativescript/android has 7.0.1 version and is up to date.
Describe the bug
I tried creating a blank nativescript app and also a blank NS-Vue app using vue-cli-template. In both case, running ns build android gives an apk of size more than 30MBs, the release versions for the same hovers around 25MBs. You can find some more details in the SO post
To Reproduce
For creating a blank nativescript app: ns create [<App Name>] [--js] [--path <Directory>]
Run ns build android
For creating a blank NS-Vue app: vue init nativescript-vue/vue-cli-template <project-name>
Run ns build android
Expected behavior
According to this post on the official website, the size should be around 12MBs which is clearly not the case here.
Dependencies from package.json (for the blank JS project)
{
...
"dependencies": {
"@nativescript/core": "~7.0.0",
"@nativescript/theme": "~2.3.0"
},
"devDependencies": {
"@nativescript/android": "7.0.1",
"@nativescript/webpack": "~3.0.0"
},
}
Additional context
Is there any way to keep the size for blank android app nearby 12MBs or are the docs outdated (misleading) and 30MBs is the new default size?
You are seeing an inflated size because the apk contains multiple architectures. Try building an aab with --aab. The file itself will have a similar size, but will end up being split into smaller apks in the store - hovering around that ~10mb mark.
Please note each Flavor will have different sizes, so the Vue sample will be larger than the vanilla sample (especially since the vue bundles a couple fonts with it also). In addition the smaller size is ONLY if you are using platform splitting or AAB's not a single APK with all 4 platform runtimes in it. Each runtime is actually what takes up the majority of the size, so if you are creating a single APK with all 4 platform runtimes it will be ~30mb.
Alright. Completely understood. But quoting from this post from the official website:
Said another way, blank NativeScript projects for Android are ~12MB by default because they include three copies of the NativeScript runtime built for different Android CPU architectures. (Since iOS has only one CPU architecture, this is not a problem for NativeScript on iOS.)
Also regarding Multiple APKs
Using the multiple APKs feature in a NativeScript application may reduce the ~12MBs default APK size three times -- up to ~4.5MB per ABI (x86, arm64-v8a, armeabi-v7a). This provides a workaround that can dramatically reduce the size of NativeScript APKs when app package size is important.
Isn't the post outdated/misleading?
Hmm, that is Interesting, we might have to do some checking as to why the runtimes are now a lot larger -- thanks for pointing that out. I do know we now ship 4 runtimes, so the APK size would be a bit larger...
Glad I contributed in any way. You guys are doing fantastic work. In the meantime, you guys should update the article on the website. At-least add a note, regarding the 4th CPU architecture and the apk size.
ns build android command build app with attached debugger and you can remove debuger in production(release) modetns deploy android --release --key-store-path mykey.keystore --key-store-password 12345 --key-store-alias my-app --key-store-alias-password 12345 --env.aot --env.uglify
tns build android --release --env.aot --env.uglify --key-store-path mykey.keystore --key-store-password 12345 --key-store-alias my-app--key-store-alias-password 12345 --aab --copy-to dist.aab
bundletool build-apks --bundle=dist.aab --output=dist.apks --ks=mykey.keystore --ks-pass=pass:12345 --ks-key-alias=my-app
bundletool build-apks --connected-device --bundle=dist.aab --output=dist.apks --ks=mykey.keystore --ks-pass=12345 --ks-key-alias=my-app
bundletool install-apks --apks=dist.apks
)
generate key so you can sign your apk and make production ready and don't forget to use parameters with command
--env.aot --env.uglify --env.snapshot --release
OR use --env.report to know your app size
example :
Most helpful comment
Hmm, that is Interesting, we might have to do some checking as to why the runtimes are now a lot larger -- thanks for pointing that out. I do know we now ship 4 runtimes, so the APK size would be a bit larger...