Optimize the HERE SDK

This optimization guide lists several options to shrink the size of the HERE SDK and to optimize the runtime behavior by reducing the data that needs to loaded or processed.

Remove unused fonts

By removing unused fonts you can reduce the size of the HERE SDK. This is explained here.

ABI splits for Android

Size management: With ABI splits you can reduce the size of the HERE SDK AAR binary file. As a result, your application will occupy less storage space on a device.

By default, the HERE SDK includes the following ABIs for Android: armeabi-v7a, arm64-v8a (mainly used for devices) and x86, x86_64 (mainly used for emulators). You can enable ABI splits to build your app, for example, only for the armeabi-v7a or arm64-v8a architectures.

Do this by modifying your app's build.gradle file:

android {
  (...)
  splits {
    abi {
      enable true
      reset()
      include 'x86_64', 'arm64-v8a' // Choose what you need.
      universalApk false
    }
  }
  (...)
}

Now, when you execute ./gradlew assembleRelease from command line, the following two APKs are generated: app-x86_64-release.apk and app-arm64-v8a-release.apk. Each APK contains only the desired ABI and is therefore much smaller in size. If you change the splits block to set universalApk true, then also a universal APK is generated that contains all ABIs, which is obviously much bigger.

For more information about the splits Gradle block, see Configure Multiple APKs for ABIs.

Note

By default, an APK built with the HERE SDK for release will be around 103 MB or higher - depending on the app features. Therefore, in order to release an app the Play Store, it is required to use either ABI Splits or Android App Bundles (AAB): As of now, the Play Store limits APKs to 100 MB and for ABBs the limit is 150 MB. If you do not want to maintain several APKs built via ABI splits for selected architectures, consider to use ABBs instead.

Fat binary on iOS

The HERE SDK framework for iOS is a fat binary, built for device (arm64) and simulator (x86_64). Therefore it contains both architectures. This allows easy deployment on a simulator and on a real device. It also contains debug symbols to symbolicate crashes in Xcode.

Since the HERE SDK framework conforms to Apple's XCFramework bundle type (XCFW), it is ready to be used for the distribution of your app. As it is the practice, in Xcode you have to select a development team to sign your app, select a Generic iOS Device and select Product -> Archive.

The binary size of an exported app (ie. resulting IPA) for a target device will occupy less space. Note that you can also manually remove files that are not required. However, please keep in mind that the IPA still contains all architectures - unless you explicitly excluded them when archiving: The actual size on the device will occupy much less space and Apple will ensure that only the required architectures are included. Thus, also the actual download size from the App Store will be much smaller. See also this Xcode guide. Therefore, we recommend to keep the HERE SDK framework as it is when the app is deployed through the App Store - since all size optimization happens automatically as part of the deployment process.

More options

Other options to optimize the HERE SDK include:

In addition, all engines contain several options that allow how to configure a feature. For example, when using the SearchEngine, you can specify SearchOptions to limit the returned search results.

results matching ""

    No results matching ""