Abilities & Limitations of Apple Foundation Models
What is Apple Foundation Models?
It’s worth starting with the most basic question: What is Apple Foundation Models Framework? The short answer to that question is that it is a large language model (LLM) that Apple has optimized to run locally on end-user devices, such as laptops, desktops, or mobile devices. Traditional LLMs operate in data centers equipped with high-powered GPUs, which require substantial memory and substantial power. Bringing that functionality to an end-user device requires significant changes to the model. In Apple’s case, the two most important changes to produce Foundation Models are a reduction in the number of parameters and quantizing the values in the model.
To understand this change, you start with the idea that any machine learning model is formed from a vast amount of numbers. In LLMs, these numbers are referred to as parameters. While the exact size of commercial models is rarely disclosed, the size of some models has been documented at Claude AI’s AI Model Parameter Counts: A Comprehensive Analysis. Recent models often contain hundreds of billions of parameters. Estimates of the number of parameters in the latest models exceed one trillion parameters. As each parameter consists of a number, that number must be represented in a format that computers understand. The most common is the equivalent of the Swift Float type, which represents a number in a 32-bit format (often referred to in machine learning as fp32). The math then shows that the largest models occupy four trillion bytes to store the numbers that form the model, or four terabytes of memory. That is an amount of RAM far exceeding that found in a typical consumer device.
The first step to reduce this number to something that will work on an end-user device is to reduce the number of parameters. The details on how to do this would be a course on its own, but with careful techniques, you can reduce the number of parameters while still having a helpful model, though with limitations from the source model. The method to achieve this will vary depending on the original LLM, the intended use case of the smaller LLM, and the acceptable performance requirements. The result will be a less capable but smaller model.
The second step is to reduce the size of each parameter by using a format that takes less than four bytes of fp32. This technique, known as quantization, reduces these numbers to a lower precision format. This also has the advantage of speeding up model processing and reducing power demands, which is particularly valuable on a mobile device with a finite battery. When done carefully, quantization produces a significantly smaller model with minimal impact on the quality of the output.
Apple Foundation Models contain approximately 3 billion parameters and have been quantized so that each parameter occupies two bits. This lets the entire model fit in eight gigabytes, enough to fit onto the newest Apple devices as of the initial 2025 release. This smaller size does create trade-offs, ones that Apple admits and documents. Apple tuned the model for text generation tasks, including summarization, entity extraction, text understanding, refinement, dialog for games, and generating creative content. More information on the training of Apple’s models can be found in Introducing Apple’s On-Device and Server Foundation Models.
Limitations of LLMs and Apple Foundation Models
Open the Starter app for this lesson. The app expands on the chat-style app created in lesson one. As you can see from the previous discussion, the chat app really isn’t the best use case for this model, but it allows easy experimentation. In a real app, you will likely call the model using information and input from the user.
You’ll use the app and some prompts that show the use cases where the model works well and where it can fail. Start with the following simple prompt:
Please give me a list of five things to do on a visit to the Great Smoky Mountains National Park.
The model will dutifully provide five activities. While yours may vary, they will likely all be reasonable things to do on a visit to a major national park.
However, the information provided here is not perfect. The first item in the list suggests hiking Laurel Falls Trail. As of August 2025, the trail has been closed since January 2025 for repairs, which are expected to last eighteen months. The Alum Cave Trail, mentioned as a destination in the same item, is currently inaccessible due to a road closure caused by a landslide and will likely remain unreachable until at least October 2025.
These mistakes both show the first weakness of LLMs. They only reflect the knowledge they were trained on. And they cannot store factual information beyond their training date. If you ask for factual information beyond that date, it will state this directly, responding that Apple Foundation Models does not have access to data beyond October 2023. This cutoff date will likely change in future versions of Foundation Models.
However, the trail examples demonstrate a subtle way in which information not available until after the training date can yield poor results. Apple does provide a way to mitigate this limitation with tools, something you’ll explore in the next lesson. The main takeaway is that you should not count on recent factual information being present in the model. More importantly, you cannot count on the model knowing that it doesn’t know information from after this cutoff date. This is not the same as a hallucination, which occurs when a model generates factually incorrect or nonsensical responses. Here, the information presented was correct at the time of training, but has become outdated due to later events.
Foundation Model Safety
A key concern when working with any generative AI is safety. One reason this chat-style app is a poor choice for on-device models is that it exposes the most potentially dangerous type of interaction, allowing the user to enter prompts directly to the model. Any data the user submits or that is pulled from external sources should be treated as untrusted. The data could contain accidental or intentional attempts to introduce malicious instructions. Apple has trained the model to handle sensitive topics with care. Perhaps overly so at times. In addition, you’ve already encountered the concept of guardrails in the first lesson when the model refused to help you cheat on homework. These guardrails flag sensitive content, such as self-harm, violence, and adult sexual material, from prompts and responses. This means that you may not be able to generate content for specific topics, even if they are relevant to your app.
Whenever you allow the user to provide input directly to the model, you increase the risk. You should treat all user prompts as untrusted and potentially dangerous and take steps to mitigate concerns before they reach the model. When possible, avoid direct input prompts and instead allow the user to select from options. At the most strict, you can have the user select only from fixed prompts. For example, you could allow the user to choose one of several topics and then add that topic to an existing prompt, enabling the model to produce safer output than if the user were to enter a prompt directly.
The output of a model must also be considered when looking at safety. Creating @Generable models, discussed in the next section, provides one way to restrict a model’s output to predefined options. Always handle guardrail violations and provide appropriate feedback to the user when they are triggered. Ensure that you test your prompts, and with every new update to Foundation Models, all prompts will require validation to ensure they still work as expected.
For more information on safety when using models, see Improving safety from generative model output and Human Interface Guidelines: Generative AI. You can also view a complete list of topics that Apple prohibits at Acceptable use requirements for the Foundation Models framework. Apple prohibits these topics, and even if you get Foundation Models to respond, you’ll find your app at risk of being rejected.
In the next section, you will explore the ways you can instruct and tune model responses.