Training a completely new base model is extremely expensive (GPT-4: $100M) due to the required compute power to achieve good results, so this is only done by tech companies with enough capital:

• Meta: Llama (public)
• Google: Gemma (public), Gemini (API only)
• OpenAI: GPT (API only)
• Anthropic: Claude (API only)
• Mistral AI: Mistral (public)
• (Many other models and remixes of larger models)

These models are trained on billions of web pages, e.g. wikis, open source projects, etc.

These models often have different variants:

• Different sizes (e.g. 2B, 70B or 405B parameters). Larger models are more powerful, but require more resources.
• Fine tunings (e.g. “instruct models” optimized for chatbots)
• Multimodal models (understand images or speech)

Models have different hardware requirements:

• Small models (≤ 70B): Can run locally (no internet access) on consumer hardware (gaming graphics cards, M1 MacBooks).
• Large models: Require expensive specialized hardware so cloud access is usually cheaper.

LLMs are simple when viewed from the outside:

• Input: Text
• Output: Text

E.g. when the input is an entire chat history in a chat-bot, the LLM can predict what the next word(s) of the text would look like (more chat messages).

By cleverly choosing the input (Prompt Engineering), you can influence the output, e.g. with examples, instructions for language patterns, more context, etc.

System prompts are predefined instructions given to an LLM in addition to user’s input. They set the context and tone for the interaction.

Examples:

• Role: “You are a helpful assistant.”
• Behavior: “Answer in English and provide detailed explanations.”
• Context: “The time is {time} and the user’s name is {name}. Here is a document relevant to the user’s query: {document}”

Data can be stored in vector databases via mathematical “feature vectors”. A collection of vectors is called an embedding.

These vectors lie in a multidimensional vector space (often plotted as a point cloud). Each dimension describes a semantic meaning (feature) of a data element. This has the advantage that related pieces of data are close to each other in the vector space.

Semantic search: A search query is converted to a feature vector and neighbors of this vector (related data) are retrieved.

Embedding Models: Text is converted to feature vectors with specialized embedding models, e.g. nomic-embed-text.

Source: Gutierrez-Osuna, R. Introduction to Pattern Analysis

Source: Google Developer - Machine Learning Crash Course

Retrival augmented generation (RAG) is used to enrich a model with knowledge from documents (e.g. PDFs, videos, websites, …).

These documents are split into chunks that are stored in a vector database as embeddings. Embeddings need to be regenerated if the documents change, so embeddings are not real-time capable.

A user request proceeds as follows:

• The request is converted into a vector in the embedding’s vector space.
• Neighbors of this vector are searched in the vector database (semantic search).
• These vectors are added to the system prompt in their original text form.
• The LLM generates a response based on the additional context in the prompt.

Tool calling allows an LLM to call predefined functions (“tools”) in the executing framework’s code. With this it can call external APIs (search engines, databases, triggers, etc.). Therefore they are real-time capable.

LLMs still only handle text input and output:

• A text description for each tool is added to the LLMs prompt, so it knows how to use them correctly.
• It can emit JSON formatted text during generation.
• The framework intercepts the output and calls the tool.
• The tools result is then added to the system prompt and the LLM can continue with the next tokens.

This works better if the model was fine tuned for tool calling.

Example:

const getRecipesByMainIngedrientTool: RunnableToolFunction<any> = {
    type: 'function',
    function: {
        description: 'Search recipes by main ingredient. Ingredients should be in English and snakecase.',
        function: recipeApi.getRecipesByMainIngredient,
        parameters: {
            type: 'object',
            properties: { ingredient: { type: 'string' } },
        },
        parse: JSON.parse,
    },
};

Fine-tuning adjusts the general behavior of an existing model through further training. For example to use it as a chatbot (question/answer), as a code generator, to write books, or to use certain vocabulary.

There are two options for this:

• Full parameter fine-tuning: An existing model is further trained, but with a specialized dataset. This adjusts all parameters over time, creating a new model. Requires a lot of computing power (expensive).
• Low-rank adaptation (LoRA): Adds additional parameters to a model without affecting the original parameters. Requires less computing power.

Some examples:

# Build release APK
./gradlew assembleRelease
# Build release AAB
./gradlew bundleRelease
# Run tests
./gradlew testReleaseUnitTest
# Install APK on device
abd install my_app.apk
# List connected devices
adb devices
# Connect over wifi (enabled in developer menu)
adb pair <ip>:<port>
# Open shell on device
adb shell
# Enter text
adb shell input text foo
# Press "enter" key
adb shell input keyevent 66
# Simulate process death (app must be in background)
adb shell am kill my.application.id
# Take screenshot
adb exec-out screencap -p > ./screen.png
# Test deep link
adb shell am start -a android.intent.action.VIEW -d https://my.url.io/my_file
# Show log cat output
adb logcat -v color,brief --pid=$(adb shell pidof my.application.id)
# Open a Kotlin REPL
kotlin
# Run a Kotlin script
kotlinc -script my_script.kts

Development on command line requires a JDK (Java Development Kit) and Android SDK in your $PATH.

Android Studio contains an embedded JDK (and a Kotlin compiler), no need to install it separately. Using the embedded JDK also has some other advantages (e.g. command line and Android Studio use the same Gradle daemon).

On MacOS just add this to your ~/.zshrc:

# Android
export ANDROID_HOME="/Users/<YOUR USER NAME HERE>/Library/Android/sdk"
export PATH="${PATH}:${ANDROID_HOME}/tools"
export PATH="${PATH}:${ANDROID_HOME}/tools/bin"
export PATH="${PATH}:${ANDROID_HOME}/platform-tools"

# Kotlin
# Note: You may have to give the binaries execution permission: chmod +x kotlinc
export KOTLIN_HOME="/Applications/Android Studio.app/Contents/plugins/Kotlin/kotlinc"
export PATH="${PATH}:${KOTLIN_HOME}/bin"

# Java (no need to export to $PATH)
export JAVA_HOME="/Applications/Android Studio.app/Contents/jre/Contents/Home"

I highly recommend scrcpy, if you prefer working with a real device or can’t use an emulator (e.g. for Bluetooth apps).

Features:

• Mirror your device’s screen on your desktop: scrcpy
• Take recordings: scrcpy --record recording.mp4
• You can use your keyboard to type on your device or click anywhere with your mouse.
• Shared clipboard, so you can copy and past from and to you device.
• Drag and drop to transfer files or install APKs.

You can use keytool for creating a keystore and adding signing keys to it. It is part of the JDK. This can also also be done in Android Studio (Build → Generate Signed APK).

# Create keystore or add key to existing keystore
keytool -v -genkey -keystore ./keystore.jks -keyalg RSA -keysize 2048 -validity $((365 * 50)) -alias MyKey -deststoretype jks
# List keys in keystore
keytool -v -list -keystore ./keystore.jks
# Move key from one keystore to another (creates other if it does not exist)
keytool -v -importkeystore -srckeystore keystore.jks -destkeystore new_keystore.jks -srcalias MyKey -destalias MyKey -deststoretype jks

Use the drawable-nodpi resource directory if you only have one size of an image. The drawable resource directory is the same as drawable-mdpi and will scale images up on devices with a higher pixel density. A 1600 x 1000 image will be scaled up to 6400 x 4000 on an xxxhdpi device. This can quickly lead to OutOfMemoryError.

For vector assets this is not a problem. However you can use the drawable-anydpi resource directory, which will only be used if no resource is defined for any other density.

You can add a simple splash-screen to you app, by adding a splash theme, which will be shown until the launched activity is fully loaded:

<!-- styles.xml -->
<style name="MyAppTheme.Splash">
    <item name="android:windowBackground">@drawable/splash</item>
</style>

<!-- splash.xml -->
<layer-list xmlns:android="http://schemas.android.com/apk/res/android" android:opacity="opaque">
    <item android:drawable="?android:colorBackground" />
    <item android:drawable="@drawable/ic_launcher_foreground" android:gravity="center" />
</layer-list>

<!-- AndroidManifest.xml -->
<activity
    android:name=".MainActivity"
    android:theme="@style/MyAppTheme.Splash" />

// MainActivity.kt
override fun onCreate(savedInstanceState: Bundle?) {
    setTheme(R.style.MyAppTheme) // app is started, so we can now remove the splash screen theme
    super.onCreate(savedInstanceState)
    setContentView(R.layout.activity_main)
}

You should use the user’s locale specific date (12/31/22 vs. 31.12.22), time, currency and number (10,000.00 vs 10.000,00, Eastern Arabic numerals) formats.

• Dates:
  • Short: DateFormat.getDateFormat(context).format(date)
  • Medium: DateFormat.getMediumDateFormat(context).format(date)
  • Long: DateFormat.getLongDateFormat(context).format(date)
• Time: DateFormat.getTimeFormat(context).format(date)
• Percentage: NumberFormat.getPercentInstance().format(percentage)
• Numbers: NumberFormat.getNumberInstance().format(number)
• Currency:
  • German (Euro): NumberFormat.getCurrencyInstance(Locale.GERMANY).format(amount)
  • US (Dollar): NumberFormat.getCurrencyInstance(Locale.US).format(amount)
  • User locale (Euro): NumberFormat.getCurrencyInstance().apply { setCurrency(Currency.getInstance("EUR")) }.format(amount)

You can draw the app’s background behind system windows (status bar, camera notches, keyboard) by setting android:windowTranslucentStatus="true" on your app’s theme.

To prevent elements like text or buttons from also drawing behind the status bar, they need to receive some padding. This padding is called “window insets”. It usually has different values for all 4 sides is provided by the system at runtime, e.g. when the keyboard is expanded or when device has a notch (at the top in portrait or at the side in landscape mode).

To automatically apply this padding you can set android:fitsSystemWindows="true" on a view or use Modifier.windowInsetsPadding(WindowInsets.systemBars) in Jetpack Compose. The insets will be consumed by the view and no other will receive it, so it is best applied to a view group, like your root layout. These insets will override any other paddings you have defined on the view.

Used for Arabic and Hebrew.

• Make sure you have android:supportsRtl="true" in your Manifest.
• Always use “start” and “end” instead of “left” and “right”, e.g layout_marginStart, layout_constraintStart_toEndOf, layout_gravity="end". If you do this consistently, your layouts should look good on RTL locales without much extra work.
• You can automatically mirror vector assets (e.g. left/right arrows) for RTL locales by using android:autoMirrored="true". No logic or separate drawable in drawable-ldrtl needed.
• Use ViewPager2, which automatically switches scroll direction for RTL locales.
• You can quickly check your XML layouts in Android Studio by selecting “Preview Right to Left” under the locale selection in the layout preview.

These tips have become obsolete with Jetpack Compose, but may be helpful for existing apps:

• For some easy animations add android:animateLayoutChanges="true" on parent layouts, so changes to their children (e.g. visibility) are animated.
• You can add fading edges on scrollable views, so content disappears smoothly at the top and bottom with android:requiresFadingEdge="vertical" and android:fadingEdgeLength="8dp".
• You can add dividers between LinearLayout children with android:showDividers="middle" and android:divider="?dividerHorizontal".
• You can set a TextView to automatically shrink its font size, so the text will shrink to always fit with android:autoSizeTextType="uniform". Do not use wrap_content for width or height or it will not work correctly.

This finding is likely a false positive, as with Android 9 clear text communication (not using HTTPS) is prevented by default. False positives include deeplink URLs in manifest (so app is also opened for http deeplinks) or support for local dev servers in debug builds.

If you are actually using clear text communication, you should have a very good reason, e.g. exception in security config for legacy backend without maintainer.

Other apps may use overlays to listen for touch events (e.g. to get passwords).

There are two ways this can happen:

• Overlays:
  • User has Android 6.0.1 without June security patches or Android <4.0.3. This allowed apps to show a Toast (transparent or with misleading content) infront of other apps and intercept touch events.
  • On newer OS versions the user has to explicitly give permission for apps to draw over other apps.
  • StackOverflow solutions will recommend using android:filterTouchesWhenObscured. This will break legitimate apps like blue light filters. Instead consider raising minSdkVersion, because this is fixed on OS side, and these old versions also contain other security issues, like Heartbleed in Android 4.1.1.
• User has a malicious keyboard app:
  • While iOS has an API for disabling third party keyboards, there is no such thing on Android.
  • Unlike iOS there is no “first party” keyboard, because every OEM can preinstall their own keyboard app.
  • Apart from that, I think users should be allowed to use their preferred keyboard.

You can add FLAG_SECURE to Windows so they don’t appear in screenshots or the recent tasks preview. Preventing screenshots will annoy users, so this only makes sense in very rare cases like password managers that show plaintext passwords.

Findings will usually consider every secret (API keys, passwords, keystores, etc.) with the same severity. But not all secrets are equal. We have to consider these points:

• Does the secret have to be included in the app (APK or at runtime)?
• What can an adversary do with a leaked secret?
• Can we easily revoke and replace this secret?
• Is the codebase hosted in a public repository (e.g. open source project) or a private repository (proprietary project)?

For public projects it makes sense to just hide all kinds of secrets in local.properties or environment variables and provide default secrets. This makes it easier to configure forks and prevents automated bots from grabbing them. If you pushed a secret to a public repository, consider it compromised.

For private projects it is preferable to save complexity and make building and deploying the app as easy as possible (convention over configuration). Here we can distinguish between secrets that must end up in the app and those that don’t:

• Many libraries (e.g. Google Maps) store their API keys in the manifest. Users can just open the manifest and copy the keys. This is by design, because there are hard restrictions on what these keys can do. As long as the key has to end up in the app at some point, e.g. if you provide these keys at runtime via a backend, it can be intercepted by a determined hacker. You can consider these kind of API keys publicly available. Having the above kind of keys in the code is fine for private code repositories. It’s probably easier to extract the key from the app, than to gain access to the codebase.
• For other cases, check if the secret needs to appear in the app. Maybe it is only used at compile time or for an internal test variant of the app. Maybe it can be stored in (and never leave) the backend, which then acts as a proxy to external APIs. Especially risky general purpose secrets like AWS tokens, should not end up in the app and in the code base. Be sure to also rewrite your git commit history, when removing them.

The keystore with the key can be checked into private repositories. This is completely fine in my opinion for the following reasons:

• The keystore is useless without keystore password and key password (unless the passwords can be brute forced, in that case you should just move the key to keystore with a longer password). If an adversary also has access to the passwords, e.g. via secrets manager or CI server, they most likely also have access to other secrets like the keystore.
• If the keystore contains the upload key for Google Play App Signing, then it would be of no use to an adversary (even if they had the passwords), as they also need access to Google Play Console (and the passwords) and you can just invalidate the upload key and generate a new one.
• If it contains the actual signing key, it is preferable to keep it safe in the repository, than to risk losing access to it. Adversaries still need access to Google Play Console though they might create new builds for delivery outside of Google Play if they also have access to keystore password and key password.

If you use Logcat for logging API requests, it may contain sensitive user data, tokens, etc. Other apps cannot access your app’s logs (since Android 4.1). It can still be read via adb logcat, however this requires direct access to the user’s device.

If this is an issue, make sure that these logs do not contain sensitive data or completely remove them by using these ProGuard rules (which make debugging issues in productive apps harder):

# Disable logging
-assumenosideeffects class android.util.Log {
    public static boolean isLoggable(java.lang.String, int);
    public static int v(...);
    public static int d(...);
    public static int i(...);
    public static int w(...);
    public static int e(...);
}

The app can react (e.g. stop working) to running on a rooted device, where the sandbox is not guaranteed.

The benefit is small:

• It can prevent this scenario: User uses your app on a rooted device, installs a malicious app and grants it root access. The malicious app can now access your app’s internal data directory. With root detection the user could not use your app at all, so there is no data to access.
• Root detection is fragile and easily circumvented.

The cost is high:

• Implementing effective root detection requires a lot of effort and complexity (see tamper protection).
• About 3.6% of devices are rooted. Most are custom ROMs, which users install at their own risk. Some devices (One Plus, Xiaomi) are pre-rooted. Affected users can not use the app, will be frustrated and post negative reviews.

In my opinion, this is only useful for very high risk apps (banking), if at all. In that case it could be preferable to show a message to users, that their device is not safe and they are at their own risk.

This checks the integrity of app and environment, to find out if an adversary has recompiled the app or is running it in a hostile environment to analyze it. This usually involves:

• Root detection (see above)
• Emulator detection
• Check if debugger is connected
• …

The benefit is small:

• It is marginally harder to analyze or recompile the app. Checks can be removed and circumvented.

The cost is high:

• Implementing effective tamper protection requires a lot of effort and complexity. It is an arms race between protection tools and bypass tools.
• This might make development harder, e.g. if the app can not run on emulators anymore. Test automation might break.

This might make sense on a small scale, that just checks the app certificate at runtime, to prevent automatic recompilation with injected malware.

Obfuscation with R8 makes it harder to analyze the app, but will not stop a determined hacker. You should enable it in any case, because R8 can dramatically reduce your APK’s download size through code and resource shrinking.

You have to manage a proguard-rules.pro file and check your release builds for shrinking issues. If this was not done from the start of the project, it might be too late to get it working, because of conflicting and really hard to debug errors. This is especially hard if you use proprietary libraries, that do not provide their own consumer-rules.pro.

It will slow down builds, so it should only be enabled for releases:

defaultConfig {
    ...
    proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
}

buildTypes {
    debug {
        // set to true, if you want to debug code shrinking:
        minifyEnabled false
        shrinkResources false
    }
    release {
        minifyEnabled true
        shrinkResources true
    }
}

Certificate pinning is not recommended by Google and Apple and should be avoided except for regulatory requirements.

The benefit is low. Communication between app and backend can not be intercepted (man-in-the-middle) in these additional special cases:

• One of the 150 certificate authorities is compromised and their certificate not immediately revoked by an OS update.
• Developers analyzing the app’s traffic in a hostile environment (though they can just recompile the app without certificate pinning).
• Only rooted devices or devices with Android <7: Third party accessing user device’s certificate store (e.g. companies installing certificates on employee devices).

The cost and risk is high:

• Requires considerably organizational overhead, as you need to keep certificates up to date through regular app updates.
• Old apps will be broken and you will get negative reviews, unless the app has a force-update mechanism.

Supply chain attacks are rare and usually not part of pen tests, but can be a major risk.

Third party dependencies or their transitive dependencies can contain malicious code:

• Gradle plugin uploading environment variables (AWS tokens, API keys, etc.) to third party server.
• Library uploading user data or credentials to a third party server.
• Library injecting ads, bitcoin miners, etc.

To migitate:

• Prefer common libraries:
  • Official (androidx, com.google.*, org.jetbrains.*) plugins and libraries are usually safe.
  • Open source dependencies with lots of stars on GitHub are not immune to attacks but have more oversight. When updating check their changes and don’t use versions that have been out for less than a day.
• Check source code (or even compiled byte code) of small libraries for suspicious code:
  • Unexpected HTTP requests or URLs
  • Access to environment variables
  • Base64 encoded strings that are decoded and executed
  • Files with very long horizontal scrollbars due code hidden after lots of whitespace.
• Check that you are actually using the correct library:
  • Check for typos to prevent typosquatting attacks.
  • In settings.gradle: Ensure mavenCentral() and google() Maven repostories are defined before other repositories like maven { url "https://jitpack.io" }, to prevent “shadowing” of official dependencies.

• AES is an industry standard and is available on all Android versions.
• DES is the predecessor of AES.
• RSA is used for asymmetric (public / private key) cryptography.

The algorithms encrypt data in blocks of fixed length, e.g. AES only encrypts 128 bit blocks. If the data to be encrypted is longer, multiple blocks have to be chained. This is handled by the block mode (ECB, CBC, CTR, GCM).

Never use ECB, as as it forms patterns.

In most modes, the first block has to be initialized with an initialization vector (IV). This IV is generated by the Cipher during encryption, so it can not accidentally be reused when encrypting other data. Block modes affect performance (i.e. encrypting large files).

GCM also has an “authentication tag”, which is used to check data integrity. It is automatically appended to the encrypted data during encryption and split off during decryption. The tag has a length of 128 bits. It is possible (but not recommended) to store only 120, 112, 104 or 96 bits of the tag, e.g. if the blocks size is smaller than 128 bits.

If the last block does not fit the length of the data to be encrypted, it has to be padded (NoPadding, PKCS5Padding, PKCS7Padding).

AES has multiple key sizes: 128, 192, 256. All key sizes are secure and differences are mostly theoretical or regulatory.

• Less is more. If something is complex it will likely break. So complete a feature with minimum amount of necessary code, that is still perfectly understandable. Try to find the “cleanest” solution.
• Development flow: Make it work, then iteratively refactor to make it more simple/readable. Maybe there is a function in the standard library you can use instead, or you can simplify a layout, or some duplicate code can be extracted. Before submitting a merge request, check if you can simplify your changes even further.

This reduces the overall error surface (less code → less potential bugs) and reduces the maintainable surface (less code to touch when refactoring → more flexible).

• Methods should only do one thing (e.g. display, calculate, create, combine, save, get, set, enable, disable, fetch, query, show, hide, etc.) which is reflected in the method name. If there is an “and” in the name, you can probably split it.
• Rule of thumb: Methods should be roughly less than ~20 lines and fit on page without scrolling. If it is too long, then this is an indicator, that it is doing too much and should be split up. This is of course only a rough guideline and not always applicable, so don’t enforce it!
• Methods should be roughly on the same layer of abstraction. E.g. if you have function renderList, then put the code to render items into a separate renderItem function, instead of adding this code to the renderList function.
• Classes should only be responsible for a single feature. E.g. try to prevent an abstract base class, where every shared code is dumped, instead pull this out into extension functions or components.
• Don’t mix business logic details (e.g. SQL database queries) with presentation details (direct view manipulation, animations), instead use a mediator (controller, viewmodel, component, etc.) between classes that manipulate views and classes that handle data sources.

• Relevant principles: Information Hiding, Separation of Concerns, Demeter Law, Interface Segregation, Dependency Inversion
• Reduce scope (references to other classes, member variables, parameters, etc.), e.g. by hiding implementation details behind private fields and methods or using pure functions. Pure functions have no side effects or state (no reference to members) and always give the same output for the same input (testable).
• A classes’ or function’s dependencies should be obvious, when looking at its signature (function parameters, constructor parameters). Never use global state and singletons, as this will hide the fact that a class or function depends on another component, without looking at its implementation. Global state will make it really hard to follow the code, as you have to keep in mind every single place it may be modified and where it is used. Global state also makes code nearly untestable, as dependencies can’t be replaced easily.
• Parameters should not contain more information than a function or class actually needs I.e. don’t pass around a massive context object or the whole viewmodel, if just a callback would suffice.

Loose coupling makes it easier to create a mental model and follow the flow of the code. The code is easier to test and verify, when there are less influencing external factors and we can be more confident, that the code is correct.

• A unit’s (methods, class) name is a mental abstraction for its functionality. So reading the name (or signature) should be enough information to use it, without unexpected behavior. When encountering unexpected behavior, we have to look at the implementation details, which consumes time and reduces our trust in the code. Good code looks boring as it contains no such surprises.
• If something is not obvious (“black magic”, workarounds, bugs in frameworks, deviation from best practices, etc.) or may lead to issues in the future, mark it as a place that needs special attention. E.g. by adding a comment or pulling it into a separate function, where the method names describes the behavior. This prevents surprises, communication overhead and regression, when other developers touch this piece of code.
• Prefer appropriately named methods to comments (self documenting code, i.e. code is the ground truth) and don’t add comments to obvious code. Comments increase the maintenance surface and can be misleading (compiler can’t check comments for correctness, comments are usually never updated). Comments reduce readability (code does not fit on single page, reading flow is broken).

• Ritualistic copy-pasting code is easy, but it is likely a sign of cargo cult programming, i.e. not understanding the reason behind the code. Make sure you know how the code works, maybe there is a better way to do this.
• Copy-pasting code very often leads to copy-paste errors (e.g. something is not renamed). Once there is a change/refactoring to the copied code, the pasted code usually needs to be manually updated in all place (no single source of truth, large maintenance surface), which is easily forgotten. This frequently leads to bugs, that you thought were already fixed.
• Instead move duplicated logic to helper functions, e.g. an extension function for creating a toast message, so the core logic is in a single place (single source of truth) and can be easily changed.
• In general try to keep the signal to noise (business logic code vs. glue code) ration high.
• But: Don’t over-engineer, which may obstruct further development and confuse new developers. Keep it easy to adapt and extend. Sometimes it is better to be flexible, e.g. copy an <ImageView> instead of moving it to a shared <include> layout, if you know the design for it will be different every time.

• No dead or commented out code. This increases maintenance surface or even worse is not maintained at all (not type checked by the compiler). If this is really needed, then only with an explanatory comment why this is still there or when it can be removed, e.g. if dependent on a feature that is developed in parallel. Otherwise this will be forever in the codebase, and other developers will not know if this is still needed or can be safely removed.
• Don’t wrap every class in an explicit interface class. Classes already provide an interface via their public properties and methods (loose coupling). Interfaces reduce development velocity, because now there are two places (interface and implementation) that need to be changed when adding functionality. Interfaces make it hard to follow the code without actually running/debugging the code. Usually it is easy to add an interface later once it is needed, e.g. if there is actually more than one implementation. However for libraries or public APIs an interface adds an additional layer of separation.
• Don’t over-engineer and keep your code flexible.
• But: Some things are not initially planned, but are guaranteed to be needed later in nearly ever project, like error handling or localization.

• Don’t use abstract “base” classes, which grow huge and can’t be split up. They also don’t work with multiple inheritance, e.g. when a framework provides its own base class we have to use. Instead put functionality in pure (extension) functions, or delegate it to separate components, which can be injected where needed.
• Compose your data structures out of other data structures. This simplifies integration with other formats that do not have inheritance, like JSON or relational databases.

• Follow the best practices and don’t fight the system. Usually there is a cleaner and better solution in the official documentation than in StackOverflow code snippets. E.g. for Android it is often suggested to use a custom background to change a button’s color, but this breaks animations unlike the best practice (theming).
• Use the recommended code style for the project’s platform and enforce it via CI and code reviews (even if it seems pedantic). This makes the code more recognizable, it is easier to read and change other developer’s code, and there are less conflicts when autoformatting code.
• A developer should be able to build a project immediately after a checkout with as little effort or help as possible. This should require no complex build process (KISS) and should follow platform convention, e.g. gradle assembleDebug for Android or docker-compose up for backends. Defaults should be provided if possible, so there is no need to configure urls, accounts, keys, etc. If a defaults can not be provided, consider disabling a feature, e.g. use a debug key for signing or providing a template config file, which can be filled in.
• Deployment should be as easy as possible (KISS) for every developer via CI/CD and should only take a few minutes, e.g. merging develop on master. Deployment should not be done locally (e.g. deploying a partial development state).
• Keep the CI/CD config simple (KISS) but effective, so there is less time needed for configuring or debugging the CI and more time for coding. If something is too complex it will likely break, so simplify it or make it easy for a developer to do manually. CI should include at least an automatic build (smoke test). Better yet a code quality check (linter), running tests (even if there are no tests written yet) and deployment.
• Technical documentation (README.md) should provide some of the following:
  • What is this project/codebase about?
  • Special requirements / tools
  • How to build
  • How to deploy / create release
  • Some helpful guides / commands (e.g. architecture/structure, how to update translations, how to make migration, how to fix common issues, URLs for services, etc.)

• TDD is a development technique that also produces a test suite that has high test coverage and protects against future regressions, however TDD is not universally applicable to every task.
• Basic development workflow:
  1. Write test for a tiny part of new feature
  2. Write code until test works
  3. Refactor / clean up code
  4. Make sure tests still works (no regression)
  5. Repeat until feature is done
• Only one thing should be tested per test. For this you can structure tests into three parts, which also helps other developers understand and modify your tests:
  1. Given: Setup the precondition state, e.g. create the class you want to test and write some dummy data into it’s fields.
  2. When: The action you want to test, e.g. call a method on your class.
  3. Then: The expected postcondition, e.g. certain fields in your class should have new values.
• What should (not) be tested?
  • No 100% coverage: Tests increase the maintainable surface of the codebase and reduce development velocity, as they need to be rewritten, when a feature changes or is refactored. So the goal should be not to test everything, but to reduce complexity, so less tests are actually needed.
  • Most code units should be clean and self evident with high confidence, so tests would be redundant. Test only where it makes sense. E.g. don’t test getters/setter or a function that contains only a simple if/else control flow.
  • Good candidates for testing and TDD are complex pure functions (e.g. parsers or date time calculation), code that needs high confidence (e.g. payment processing), or code that can not be easily tested manually (rare crash conditions and edge cases).
  • Don’t test implementation details of external dependencies, e.g. if a parser generated by a code generator can parse every datatype correctly. For critical dependencies a boundary or API test should suffice, so you know early on if it is safe to upgrade the library to a new version.
  • Tests may also contain bugs, so a test should usually not be more complex than the code it tests.
  • UI tests (e.g. on an emulator or browser) are slow and fragile, so prefer unit tests. Viewmodels should act as humble objects.
  • Tests can’t find high level gaps in specification or overall behavior, so explorative QA testing is still needed.
• If projects don’t have tests (or support for tests) from the start, they likely won’t have tests later. Usually there is considerable effort involved in starting to write tests, e.g. mocking dependencies, separating framework from test code, etc. To allow easy testing without obstructions or effort there should be at least one moderately complex test case when starting a new project, that can be used as a template, even if there are no other tests planned yet.

• There are two kinds of errors:
  • If an error would inevitably leave your program in an illegal or broken state that would cause other issues (e.g. data corruption), then it is fatal and should crash the program.
  • If you can recover from the error, so your program always remains in a valid state, then it is an exception and you should handle it. E.g. you could show a message to your users and let them try again after a failed backend request. Your program’s state must always stay valid, e.g. when using optimistic request (showing result before a request is finished), then the previous state (before result was shown) must be restored.
• Never silently suppress exceptions (empty catch block). Swallowed exceptions make it very hard to find the source of bugs and may introduce bugs that could easily be discovered early during development. Instead at least log it and/or pass it to the user as a generic error (in a server return status 500). In rare cases where a specific type of exception is expected and can safely be ignored, add a comment, so it is clear why there is no logging.