In this post, we will walk you through some steps to build your own Copilot integrating to Xcode and VS Code, running locally on your device so you will not be worried about network or token prices while still being able to enjoy the benefits of AI supports for your productivity.

All of the tools used in this post are open source and free to use, including an open source LLM (Large Language Model) to help you generate code and other tools which can help you run that LLM as a local service and integrate it with your IDE such as Xcode or VS Code. At the end of this article, you can get the final bash file for running all steps at once including installing tools and setup running environment.
# Table of content
- Prerequisites
- Steps to integrate with VS Code 
- Steps to integrate with Xcode IDE
- Further steps
### Prerequisite 
- a MacBook with as least **16GB** of RAM. This is recommended to have smooth experience as coding requires many tools opened concurrently, while running a LLM requires a minimum **~4GB** of RAM.
- Python environment setup. It is recommended to have a Python version in **Homebrew**. If not, run this command in the terminal (assuming it is `zsh`) 
  
```console
brew install python
```
-  A downloaded LLM. We are going to use [ollama](https://github.com/jmorganca/ollama) to run our LLM locally as a service. It's quite simple to setup and use. We will go select a LLM from the [library](https://ollama.ai/library) (or other sources with other formats such as GGUF). In this case, we use the _codellama-7b_  model. Follow the installation guide to install _ollama_ (just download the zip file, extract it and drag the file into Application directory)

We then download the _codellama-7b_ and test it by this command

```console
ollama run codellama
```

Wait for the download to complete and try the model by typing some messages:

![Screenshot 2023-12-24 at 23.40.51.png](https://api.flyingharley.dev/uploads/Screenshot_2023_12_24_at_23_40_51_2f53043165.png)

Close the terminal. One important thing to note here is that the _ollama_ server will run as a background service on port **11434** by default. Just verify that it's running by this command: 

```console
sudo lsof -i :11434
```
![Screenshot 2023-12-24 at 23.48.18.png](https://api.flyingharley.dev/uploads/Screenshot_2023_12_24_at_23_48_18_ebb05f7ba8.png)

### Steps to integrate with VS Code

VS Code is a very popular IDE which supports numerous extensions to boost productivity, especially in the domain of Copilot. [Continue](https://continue.dev/) is a free but powerful extension which provides the ability of customizing the backed LLM for our needs, even with the remote or local LLM server like _ollama_. Checkout the [document](https://marketplace.visualstudio.com/items?itemName=Continue.continue) for its cool features such as code editing, code or file referenced as context, and more.
By a few simple steps, we can integrate the _ollama_ LLM server mentioned earlier to create a fully local Copilot experience.

Open the **Extension** tab from VS Code, search for "Continue" and install this extension. After that, open the configuration file to include our LLM server created in the previous steps:
- Step 1: Open the extension's "config.json" file at path: _~/.continue/config.json_ (we can quickly search and open the file by using **Cmd + P** hot key and typing the file name)
- Step 2: Include the following code inside the "models" array (assuming we are using the _codellama_ LLM as shown earlier):

```js
{
      "title": "Code Llama",
      "provider": "ollama",
      "model": "codellama"
}
```
Save the file and restart VS Code, we can see the option to switch to our recently added LLM like below:

![Screenshot 2023-12-25 at 21.36.51.png](https://api.flyingharley.dev/uploads/Screenshot_2023_12_25_at_21_36_51_6ee50e346d.png)

Please refer to [Continue document](https://continue.dev/docs/walkthroughs/codellama#ollama) for more details.

### Steps to integrate with Xcode IDE
We will use [CopilotForXcode](https://github.com/intitni/CopilotForXcode) as an extension for the Xcode IDE. It offers many functionalities similar to those found in **Continue**, but using a local LLM requires additional steps to make it works. This is due to the current version only supports OpenAI API or at least OpenAI compatible API.

To address this, we will need a **proxy** which can convert LLM server's API into OpenAI-compatible format. For this purpose, we will use [liteLLM](https://docs.litellm.ai/docs/proxy) proxy.

- **Step 1**: Create a running proxy service. Let's start by defining a _config.yaml_ file to enable it to work with our previously set up _ollama_ server as a proxy server
  - [Install](https://docs.litellm.ai/docs/) the liteLLM by this command:

```console
pip install litellm
```

or use the below if it is python3:
```console
pip3 install litellm
```

  - Paste the following code into the newly created file:

```yaml
model_list: 
  - model_name: codellama-litellm
     litellm_params:
      model: ollama/codellama
      api_base: http://0.0.0.0:11434
      api_key: "any"

```
Note that the **api_base** includes the address and port of the _ollama_ server.
Please refer to [this](https://docs.litellm.ai/docs/providers/ollama) for more details
  - Start the liteLLM proxy server by the following command:

```console
litellm --config ./config.yaml
```
  - The server will run on port **8000** by default and you should see this:

![Screenshot 2023-12-25 at 22.08.34.png](https://api.flyingharley.dev/uploads/Screenshot_2023_12_25_at_22_08_34_984db39adb.png)

This **8000** port will be used to receive requests from the CopilotForXcode in the next step.
- **Step 2**: Install the CopilotForXcode and redirect its requests into our created proxy server in Step 1.
  - Install and give the needed permissions for the extension as mentioned in their [document](https://github.com/intitni/CopilotForXcode?tab=readme-ov-file#install)
  - Open the extension and configure the local server:

![Screenshot 2023-12-25 at 22.13.12.png](https://api.flyingharley.dev/uploads/Screenshot_2023_12_25_at_22_13_12_80a666a3dc.png)

Note that we use **localhost** instead of **0.0.0.0** to avoid the error for **App Transport Security policy**.
  - We can test the request by clicking the **Test** button and check the response:

![Screenshot 2023-12-25 at 22.13.28.png](https://api.flyingharley.dev/uploads/Screenshot_2023_12_25_at_22_13_28_f2f4a5f785.png)

  - Then click the **Save** button and back to our Xcode IDE and start using the Copilot!

For simplifying the steps to start the server every time we do coding from now on, let's put them into a simple bash script:
```bash

#!/bin/bash

# Start the ollama server in a new window
(ollama serve &)

# Wait for the server to start listening on port 11434
while ! nc -z localhost 11434; do sleep 0.1; done

# Run the litellm command in the current window
litellm --config ./config.yaml

```

Finally, you can get the bash file for running all the above steps [here](https://github.com/hieupham9809/local-copilot). Every time we need to run that server, just running that bash file and we're good to go!

### Further steps
This approach has some limitations:
- Need more efforts to configure for each LLM, despite many LLM server like _ollama_ does support [importing from other file formats](https://github.com/jmorganca/ollama/blob/main/docs/import.md) such as **GGUF**
- The offline LLM won't be up to date with newest changes & improvement for technical stuffs and it relies on every update/fine-tuning of the current model to get latest updates

Besides that, it's worth to try and it's also good enough for increasing our productivity without being worried about the token costs, etc ... We can think about the way to support Internet searching/crawling based on our needs to make our Copilot more useful. 

large_copilot-thumb.jpeg

medium_copilot-thumb.jpeg

small_copilot-thumb.jpeg

thumbnail_copilot-thumb.jpeg

copilot-thumb.jpeg

In this post, we will walk you through some steps to build your own Copilot integrating to Xcode and VS Code, running locally on your device so you will not be worried about network or token prices while still being able to enjoy the benefits of AI supports for your productivity.

Build a copilot running locally on IDEs by using ollama and liteLLM

After comprehending the complex and demanding tasks involved in the [build process](https://flyingharley.dev/posts/understanding-the-xcode-build-system-part-2), we can now shift our focus to the importance of build performance and how to enhance it by adhering to best practices. This will assist the build system in working more efficiently, providing us, as developers, with additional time to implement our cool features.
The article is divided into 3 parts:
1. [Understanding the general build system and some terminologies (part 1)](https://flyingharley.dev/posts/understanding-the-xcode-build-system-part-1)
2. [Understanding the Xcode build system and Xcode project structure (part 2)](https://flyingharley.dev/posts/understanding-the-xcode-build-system-part-2)
3. **How can we help the Xcode build system (part 3)**

# The build performance
In previous parts, we may have observed that build performance can be influenced by various factors. Some of these factors include  the **dependency order**, the **complexity of expressions**, the **build script** and the **Objective-C/Swift interfaces**.

## The dependency order
![parallel-build-saving-time.png](https://api.flyingharley.dev/uploads/parallel_build_saving_time_39b9fdc91d.png)
We are all aware that processing tasks in parallel, as opposed to one by one or sequentially, leads to increased speed. This is particularly crucial with the support of modern multicore devices; it would be inefficient in terms of both resources and time not to harness their potential. Fortunately, we have a couple of methods to achieve this.

The first method involves enabling the _Parallelize Build_ option in the Scheme editing menu. This allows Xcode to simultaneously build targets that are independent of each other, ultimately enhancing the overall build speed. However, it's important to note that this option is not activated by default, and its use does not guarantee that there will be no build issues, especially in projects with intricate dependencies. It is advisable to test this option to identify potential errors and carefully weigh the trade-off between improved build time and build stability.

![enable-parallel-build.png](https://api.flyingharley.dev/uploads/enable_parallel_build_a9b2968136.png)

The next method involves examining how we have configured dependencies within Xcode. As discussed in the previous article, dependencies are configured through the _Build phase_ in the target setting by _Target Dependencies_ (explicit) and _Link Binary with Libraries_. With a deeper understanding of build dependencies and the current Project/Workspace build configurations, we can enhance build performance by implementing parallelization. The [talk](https://developer.apple.com/videos/play/wwdc2018/408/) from WWDC18 provides us some strategies to "break down" some dependencies that hider parallelization  during the build process.

We can begin by addressing what they refer to as the "Do Everything" dependency. In this example it's the **Test target**, which tests numerous components including **Game**, **Shaders**, **Utilities** requiring it to be built last.

![test-target-before.png](https://api.flyingharley.dev/uploads/test_target_before_5312781f42.png)

We then "break down" the **Test target** into small targets to test each of the above components separately. By doing so, each test target only needs to have dependency on its corresponding component, enable it to be built at an earlier stage.

![test-target-after.png](https://api.flyingharley.dev/uploads/test_target_after_8cefd3a6ba.png)

The next type of dependency is what they refer to as "Nosy Neighbors". This type of dependency to a target needs to exist but it only requires a small portion of that target. By just simply "move" that thing out of the target and create their own target, we can get more parallelism and even significant impact on the overall build timeline.

![break-down-common-code.png](https://api.flyingharley.dev/uploads/break_down_common_code_568ddd68bc.png)

And the last one is what they call the "Forgotten Ones". These are dependencies that we simply forgot to remove or clean up, a common situation that occurs frequently. For instance, there might be a scenario where we initially import another target to access some utility methods. Over time, we may replace those methods with others or decide that we no longer need them. However, we might forget to remove the import statement for that target, leading to a redundant dependency.

## Build Scripts

Build scripts provide a convenient way to customize the build process, such as generating assets or moving files. It is recommended to execute them only when necessary, as running these scripts incurs a cost. It is crucial to note that the Xcode Build System relies on entities known as **input files** and **output files** to determine whether it needs to execute a script. Apple highly recommends declaring these **input files** and **output files**, and you can find detailed guidelines in their [documentation](https://developer.apple.com/documentation/xcode/running-custom-scripts-during-a-build). Some of the rules the build system employs to trigger a script rerun include: **no declared input files or changes in input files**, **missing output files**, and so on.

## The complexity of expressions

_Type inference_ is one of the convenient features not only in Swift but also in modern programming languages nowadays. It can help us avoid boilerplate code and have them easy to read as it will be shorter. However, it's not always useful. Take a look at this example:

![implicit-type.png](https://api.flyingharley.dev/uploads/implicit_type_dbc755125f.png)

It seems short enough but not easy to reason about. It takes more efforts from both the compiler and other developers to figure out which type this **bigNumber** is, as the **pow** method inside this expression doesn't tell anything about that. We can improve this very easily by just simply put the **Double** type after the variable name.

We might also face with this situation while coding: we edit our code with some cool ideas and press the build button. Everything seems okay until we found that the compiler takes longer time to compile our code. Finally, it gives up with the error said that it was unable to type-check our expression in reasonable time. This is not the compiler's fault. This is our responsibility to look back our code and there is definitely some unnecessary complexity here.

![complex-expression-build.png](https://api.flyingharley.dev/uploads/complex_expression_build_4d649a60fc.png)

The provided code should not be accepted in the reviewing process, even if the compiler were somehow strengthened enough to handle it. A clearer and more "Swifty" alternative exists, as demonstrated below:

![complex-expression-fix.png](https://api.flyingharley.dev/uploads/complex_expression_fix_8f77c714bd.png)

When coding in Swift, it's crucial to consider the use of _AnyObject_. While it may be tempting due to its convenience, where we simply utilize methods and properties from the object and let the compiler do the rest, this approach comes with a cost. As Swift processes all source files from the current target and others, it must search for methods and properties to call in this manner. It does so because if there is no matched implementation, it will result in an error. To address this, we can use _Protocol_ instead of _AnyObject_. This allows the compiler to precisely determine what to call, and it provides opportunities to verify whether all implementing types correctly implement those methods and properties.

![avoid-using-any-object.png](https://api.flyingharley.dev/uploads/avoid_using_any_object_66bc38b5d7.png)

## The Swift's file dependency and the Objective-C/Swift interfaces

We might already be aware that **Caching** is a straightforward way to improve performance when handling repetitive tasks, in this case the rebuild process. By reducing the amount of work needed for each rebuild task, we can save time for the compiler. In Swift, the compiler determines which files should be rebuilt based on _file dependencies_ within a module. In simple terms, if a file is changed, files depending on it are more likely to be rebuilt as well, unless the changes are in function bodies and do not affect the file's interface. In the case of **Cross-Target Dependencies**, the entire dependent target will be rebuilt instead.

![cross-target-dependency.png](https://api.flyingharley.dev/uploads/cross_target_dependency_843c5c8d7d.png)

However, these considerations apply specifically to Swift dependencies and Swift targets. In real-world scenarios, we often have mixed Swift and Objective-C interfaces, as illustrated by this diagram:

![mixed-source-dependencies.png](https://api.flyingharley.dev/uploads/mixed_source_dependencies_4dba335b72.png)

With information from the [previous article](https://flyingharley.dev/posts/understanding-the-xcode-build-system-part-2#:~:text=time%20as%20well.-,The%20compilers,-Clang), from left to right, we can see that Swift files depend on Objective-C headers (.h files) through the _Bridging header_, and the Objective-C implementations (.m) depend on those Swift files by using the _Generated header_. If we want to reduce the amount of work on rebuild, we need to shrink the content of _Bridging header_ files and _Generated header_ files as much as possible. For example, by using the _private_ keyword in Swift code, we can prevent it from being unnecessarily exposed in the _Generated header_. Or we can use _categories_ to break up the interface in the _Bridging header_, avoiding some internal types in Objective-C code from being exposed to Swift unexpectedly.

![minimal-bridging-header.png](https://api.flyingharley.dev/uploads/minimal_bridging_header_2aa96fcbaf.png)
![categories-to-break-header.png](https://api.flyingharley.dev/uploads/categories_to_break_header_0fd5c206d6.png)

## And one more thing
Xcode also has a useful feature called **Build With Timing Summary**. We might notice the build performance decreasing just by a "feeling" or when there is a significant time consumed during building. This build option will display more details about each build task and the duration it takes for its build. Simply triggering the build with timing summary will give us more information about what's going on there.

![build-with-timing-summary.png](https://api.flyingharley.dev/uploads/build_with_timing_summary_1863bce30f.png)

# What can the compiler tell us when something goes wrong?
By default, if Xcode encounters an error during a build, it reports the error and stops immediately. We can force it to keep going with the build by the “Continue building after errors” setting in the General tab of Xcode preferences. It then continues to build and reports errors for the rest of our project's files. However, as an error can be the cause of other errors, and we might only be interested in the error causing the issue (root cause), displaying all of the errors can be unnecessary, making it sometimes hard to debug and fix the issue.

Whenever an error occurs, Xcode tries its best to tell us as much information as it can. We first need to switch to Xcode’s issue navigator or use **Cmd-5**. Most of the time, we will see the problem here just by reading the error log and navigating to the source code. If it's not, for example, the **link issue** from the linker, when it fails to look for the symbols needed when linking. In that case, we will need to get more details about the issue by using the **report navigator** (Cmd-9) and see what symbols are missing (sometimes we might need to click the log icon to see where those symbols are referenced from).

![detail-build-error.png](https://api.flyingharley.dev/uploads/detail_build_error_be605958ee.png)

And that's it. In this part, we've walked through some best practices to help the build system to be more efficient by understanding what is does behind the scenes. Those are simple fixes, but they can significantly improve build performance, allowing us to spend less time building and more time coding.

large_xcode-build-part-3.jpeg

medium_xcode-build-part-3.jpeg

small_xcode-build-part-3.jpeg

thumbnail_xcode-build-part-3.jpeg

xcode-build-part-3.jpeg

After understanding [the build process behind the scenes](https://flyingharley.dev/posts/understanding-the-xcode-build-system-part-2) as well as its complex and heavy tasks, its time for us - as our main purpose of this series - to understand how the build performance important is, and how we can gain better performance by following some of the best practices which help the build system do their works more efficient, giving us as developer more free time to implement our cool features.

The article is divided into 3 parts:
1. [Understanding the general build system and some terminologies (part 1)](https://flyingharley.dev/posts/understanding-the-xcode-build-system-part-1)
2. [Understanding the Xcode build system and Xcode project structure (part 2)](https://flyingharley.dev/posts/understanding-the-xcode-build-system-part-2)
3. **How can we help the Xcode build system (part 3)**

Understanding the Xcode build system - Part 3 - How can we help the Xcode build system

small_compiler-swift.png

thumbnail_compiler-swift.png

compiler-swift.png

Building app is a complicated process that requires many tasks needed to be done to make an completed cool app and release it to user. Fortunately, the Xcode IDE handles most of the work behind the scenes, so all we need to do is to click the "Build" button on the toolbar and focus on our development. However, in order to use this efficiently, it is important to understand the process, as there may be times when we need to troubleshoot build errors. In this part, we will take a closer look at Xcode's build system, what it does automatically for us, and what we can do to make the build process more efficient and reliable.

Understanding the Xcode build system - Part 2

As we might notice, accessing files on disk is one of the slowest operations on any devices, especially with a huge number of files, even with small files. In this article, I will discuss about the challenges we were facing during the time of maintenance the Chat data storage feature of the LINE iOS app, and how we improve the performance issue by proposing the new way of managing chat storage that can also help improve user experience while using this feature.
For more details, [please follow to this article](https://engineering.linecorp.com/en/blog/new-way-of-managing-chat-storage-in-the-ios-version-of-line).

large_IMG_D9B7BE299A1F-1.jpeg

medium_IMG_D9B7BE299A1F-1.jpeg

small_IMG_D9B7BE299A1F-1.jpeg

thumbnail_IMG_D9B7BE299A1F-1.jpeg

IMG_D9B7BE299A1F-1.jpeg

Introduce a new way for storing chat data and for quickly getting storage size. Improve UX by providing user a new way for managing their chat more efficiently

The new way of managing Chat storage in the iOS version of LINE

Building app is the thing that we do everyday, especially while development. In this article, we will take a closer look at Xcode's build system, what it does automatically for us, and what we can do to make the build process more efficient and reliable.
The article is divided into 3 parts:
1. **Understanding the general build system and some terminologies (part 1)**
2. [Understanding the Xcode build system and Xcode project structure (part 2)](https://flyingharley.dev/posts/understanding-the-xcode-build-system-part-2)
3. [How can we help the Xcode build system (part 3)](https://flyingharley.dev/posts/understanding-the-xcode-build-system-part-3-how-can-we-help-the-xcode-build-system)

# Some terminologies
## Software build
According to [Wikipedia](https://en.wikipedia.org/wiki/Software_build):
> a build is the process of converting source code files into standalone software artifact(s) that can be run on a computer, or the result of doing so.

In our context, a smartphone is also a "computer" as well. As a software engineering, we do "coding" everyday, and the result of this process is to create a program which can run on our device
## Framework and Library
We might have heard many times about **Framework** and **Library** everyday and they sometimes can be used interchangeably, but they actually have different meanings. The main difference can simply described by this image:

![framework_library_main_difference.png](https://api.flyingharley.dev/uploads/framework_library_main_difference_1a97e1ee1f.png)

For more understanding, I'd recommend you to read this interesting [article](https://www.linkedin.com/pulse/module-package-library-framework-real-life-example-mohammad-ibrahim/).

In iOS development using XCode, those terms mentioned above have slightly more specific meanings.

**Library** is a collection of _object files_ (_.o_ files) that a program can link to. There are two types of library in iOS: **Static library** and **Dynamic library**. Static library as its name stands for, is packed into the main executable and linked at compile time and basically it only contains executable code. Object files in this kind of library are archived into _.a_ file. And since this kind of library is linked at compile time, it will not be **reused** or **shared** between programs.
To improve the above limitation, we also have **Dynamic library** which is referenced by the linker at runtime, so it is not copied into a program. And instead of _.a_ file, dynamic libraries are _.dylib_ files.

At WWDC23, Apple has introduced a [new generation of Library](https://developer.apple.com/videos/play/wwdc2023/10268/) which **inherits** from the above ones called **Mergeable Library**, which makes dynamic libraries become **mergeable**. It takes advantages from both **Static library** and **Dynamic library**. Similar to Dynamic library, it reduces the works of the static linker comparing to Static library (as the **merging** process will be faster than **linking** statically), which helps the build become faster too. Moreover, many dynamic libraries are able to be **merged** into only one, meaning there are less things to do for the dynamic linker, thus improves the app launching as well. It's also able to reduce the size after the merging process.

**Framework** is the one we might be more familiar with e.g. UIKit, CoreData, ... We use them everyday of iOS development. Unlike libraries, frameworks are structured directories containing code, sub-directories, shared libraries, and other support files e.g. assets files, ... Similar to the above principles, the key different between a library and a framework is that the framework can "call" our code, which can be define as **Inversion of Control**. 
And similar to **Library**, we also have **Static framework** and **Dynamic framework**.

**Static frameworks** are linked during build time and **Dynamic frameworks** are linked at runtime. The important thing to note that there is different between **user-provided dynamic frameworks** and **system-provided dynamic frameworks** where we have to embed the user-provided ones within our app bundle and they can not be updated independently from our app like the system-provided ones. For example, an app built with Swift 5.0 will run on systems that have a Swift 5 standard library installed, as well as those with a Swift 5.1 or Swift 6.

![abi-stability.png](https://api.flyingharley.dev/uploads/abi_stability_f0fddf278f.png)

Obviously, the **dynamic framework** can help reduce the app size as well, but it depends on specific situation. Moreover, both **dynamic framework** and **static framework** have trade-offs on performance. The **static framework** has faster startup but slower build times. While the **dynamic framework** can be size-efficient as it can avoid library duplications inside the app bundle. In general, it is recommend to use **static framework** when possible. For more details, I'd like to suggest this [article](https://www.emergetools.com/blog/posts/static-vs-dynamic-frameworks-ios-discussion-chat-gpt)

# Xcode build system
## What is a build system
A **build system** is a collection of software tools that are used to facilitate the build process. We might have heard about many build systems before e.g. GNU Make, CMake, Buck, Bazel, Gradle ... and our Xcode build system. With the helps of build systems, our developer life is more easier and thus we can focus on our development. Bazel's [documentation](https://bazel.build/basics/build-systems#what_is_a_build_system)  has a very straightforward definition about this:

>Fundamentally, all build systems have a straightforward purpose: they transform the source code written by engineers into executable binaries that can be read by machines. Build systems aren't just for human-authored code; they also allow machines to create builds automatically, whether for testing or for releases to production. In an organization with thousands of engineers, it's common that most builds are triggered automatically rather than directly by engineers.

## Why do we need it?
Obviously, most engineers don't need to care about build system when they are learning to code. We usually starts by using the compiler directly to compile our code e.g. _gcc_, _javac_, _swiftc_, ... and our code just works. However this is only a few files and on bigger projects, things are not just simple like that. We might have to deal with many files, many libraries and frameworks, even with many programming languages and many compilers. The build process now is no longer a single-step process. We now need to care about what is called _dependencies_, the orders between them to make sure the build process works properly and correctly. Without the help of the build system, this process will be error-prone and things can easily get out of hand.

So how about using shell scripts in order to automatically do the above tasks? Well, you can get what you want by using shell scripts to automate things. However, we still have to face with other problems including the scalability problem as follow:
- **Tedious**: Shell scripts can become tedious to write and maintain as the project grows in complexity.
- **Slow**: Shell scripts can be slow, especially if they rebuild dependencies every time they are run.
- **Difficult to release**: It can be difficult to release a project that is built using shell scripts, as there are many steps involved and it can be easy to make mistakes.
- **Vulnerable to disaster**: If your hard drive crashes, you may lose all of your build scripts and other important files.
- **Difficult to scale**: It can be difficult to scale a project that is built using shell scripts, as each developer needs to have their own environment set up.
- **Not portable**: Shell scripts are specific to the operating system and shell environment that they are written for. This can make it difficult to use them on other systems.
- **Not robust**: Shell scripts are not as robust as other types of build systems. They are more likely to be affected by errors and unexpected input.
- ...

That's why we not only need a **tool**, but also a **system** to avoid any hassle.

## SDKs
**SDK** stands for _software development kit_. Also known as a devkit, the SDK is a set of software-building tools for a specific platform, including the building blocks, debuggers and, often, a framework or group of code libraries such as a set of routines specific to an operating system (OS). For example, for every official release of Xcode, it is usually included SDKs for platforms such as iOS SDK, watchOS SDK, tvOS SDK and newly visionOS SDK.

## Xcode Command Line Tools
> This is a package enables UNIX-style development via Terminal by installing command line developer tools, as well as macOS SDK frameworks and headers. Many useful tools are included, such as the Apple LLVM compiler, linker, and Make. If you use Xcode, these tools are also embedded within the Xcode IDE.

Behind the scenes, the Xcode IDE use this tool for the build process. This tool also contains some crucial utilities for software development, not only for softwares running on Apple devices. For example the c++ compiler, gcc, git, etc ... are also included. More details about it are described at [here](https://mac.install.guide/commandlinetools/8.html)

## Xcode build system and other build systems

### Xcode
As defined by [Apple](https://developer.apple.com/documentation/xcode/build-system), the Xcode build system manages the tools that transform your code and resource files into a finished app. It organizes the source code and assets in a structure with many terms we might have been familiar with e.g. Project, Workspace, Target, Asset Catalog, Dependencies, ... through the Xcode IDE. They not only help us increase productivity ourself, but also help us with the maintenance and scalability in the future. We will dive deeper into this later in the next section.

Note that the Xcode IDE is totally different with the Xcode build system as it not only contains the Xcode build system but also other tools for development such as code editor, xib editor, debugger and so on.

The Xcode build system is a very useful tool for our development to make a completed app, but it is not the only way. This interesting [Article](https://medium.com/@vojtastavik/building-an-ios-app-without-xcodes-build-system-d3e5ca86d30d) describes how we can build and install an iOS app into the Simulator and Device as well **without** using the Xcode IDE at all.

### Bazel
[Bazel](https://bazel.build/about/intro) is a Google's open-source build and test tool similar to other build systems that have been mentioned before. It uses a human-readable, high-level build language, in this case it is Starlark - a [domain-specific language](https://en.wikipedia.org/wiki/Domain-specific_language) (DSL). It offers the some advantages such as **fast but reliable** by using caches and parallelism, **multiple platforms** (Linux, macOS, Windows), **scalable and efficient for huge project** and **very extensible** (we can use it for development not only in iOS but also in other system, with different language and framework by using **rule** e.g. Android, C / C++, Java, Python, Scala, etc ...) See more details about how to use it especially for [iOS development](https://github.com/bazelbuild/rules_apple/blob/master/doc/tutorials/ios-app.md).

### Buck2
[Buck2](https://github.com/facebook/buck2) is an upgrade to the original [Buck build system](https://buck.build/) ("Buck1") designed by Meta. It is the build system similar to Bazel (distributed compilation with Remote Execution API) and Buck1 but with some improvements such as **2x faster**, **tracks dependencies with far better accuracy** than Buck1, **support for ultra-large repositories through filesystem virtualization**, ...

There is a fact that those above tools can not replace Xcode, they all use some of the Xcode tools such as Xcode IDE, Xcode Command Line tool for the build process.

In the next part, we will go to more details about the Xcode project structure and how it organizes things.

# References
https://www.linkedin.com/pulse/module-package-library-framework-real-life-example-mohammad-ibrahim/
https://medium.com/@m.tabrizi/ios-library-vs-framework-30866c41f100
https://www.emergetools.com/blog/posts/static-vs-dynamic-frameworks-ios-discussion-chat-gpt
https://medium.com/swlh/a-brief-introduction-to-build-systems-1e45cb1cf667

large_build-system-p1-1.webp

medium_build-system-p1-1.webp

small_build-system-p1-1.webp

thumbnail_build-system-p1-1.webp

build-system-p1-1.webp

Building app is the thing that we do everyday, especially while development. In this article, we will take a closer look at Xcode's build system, what it does automatically for us, and what we can do to make the build process more efficient and reliable.
The article is divided into 3 parts:
**1. Understanding the general build system and some terminologies (part 1)**
2. [Understanding the Xcode build system and Xcode project structure (part 2)](https://flyingharley.dev/posts/understanding-the-xcode-build-system-part-2)
3. [How can we help the Xcode build system (part 3)](https://flyingharley.dev/posts/understanding-the-xcode-build-system-part-3-how-can-we-help-the-xcode-build-system)

Harley Pham

Build a copilot running locally on IDEs by using ollama and liteLLM

Understanding the Xcode build system - Part 3 - How can we help the Xcode build system

Understanding the Xcode build system - Part 2

The new way of managing Chat storage in the iOS version of LINE

Understanding the Xcode build system - Part 1